Сколько времени займет удаление всех записей из непериодического регистра с независимой записью ?
код
НЗ=регистрыСведений.ХХ.создатьнаборзаписей();
НЗ.Записать();
число записей больше 6 млн.
запускал ночью- за полчаса не отработало,
сколько времени уйдет на подобную  операцию, как вы считаете?

В конфигураторе скопируй РС, старый удали, новый переименуй

(1) хитро! ))))

в скуле транкейт тейбл и все дела

(1)
в итоге я так и сделал, меня интересует сама длительность подобной операции.
несколько лет назад добавляли новое измерение в регистр накопления, в конце концов записал туда значения средствами SQL - за неделю средствами 1с было записано где- то 15 % записей - из нескольких млн

(4) длительность подобной операции в сферической базе на сферическом железе в вакууме? Тут даже Ванга отдыхает

(1) Плохое решение.

Лучше залезть в скуль и очистить табличку при помощи команд SQL

(6) чем плохо?

(6) Почему? Физически таблица останется или что?

вместо создания нового руками лучше тогда сравнением-объединением его из старого цф взять, чтоб сохранить индентификаторы метаданных, критично при РИБ и прочей ереси

(4) Скорость зависит от объема данных (количество записей, количество измерений/реквизитов/ресурсов, а так же типов) и железа... Так что в твоем случае цифра может быть любой.

(8)(9) Теряем гуид таблицы.

(0) Если штатно - удалять кусками. Можно параллельно в нескольких сеансах.

(4) Сколько сотен миллионов записей было в регистре?

150 млн примерно

(2)+ 1
http://msdn.microsoft.com/ru-ru/library/ms177570.aspx

(15) Тогда странно. Такой небольшой регистр и так долго реструктуризировался.

(16) Это самый правильный вариант. Удалить строки силами MS SQL

(15) наверно чего-то ваши программеры нафигачили в процедурах ПередЗаписью и ПРиЗаписи у регистра. Опять же подписки на события, которые к регистрам сведений привязаны, проверьте.

(12) Для каких целей ГУИД таблицы тебе будет нужен?

(19) Кстати, да, я бы проверил модуль и подписки.

(20) для обновлений, ты не поверишь.

(3) +1,  решение из (1) плохая идея

(20)>(10)

(22) +1,
помимо проблем с последующими обновлениями (да там через одно место можно вручную связь указать но ...) есть в будущем вероятность проблем огрести - кучу раз наблюдал как базы падали (правд хранилища) когда люди частенько удаляли, добавляли регистры сведений (мы же не знаем как платформа новым РС гуиды выдает, есть подозрение что она "пробелы" потом пытается ликвидировать);
даже в типовых - разработчики их переименовывают как Удалить*** а не удаляют)

(25) не для этого в типовых так делают

(26) ?

(25) Переименовывают для того что бы в несколько релизов их потом удалить, это стандартная схема , что бы не потерять данные.

Базы падали не из-за номеров, а из-за того, что в старых конфах были ошибки в конфигурациях поставщика и расхождение в номерах может ускорить падение базы.

К слову: если всё таки надо удалять регистр средствами 1С, то лучше удалять транзакциями записей по 100 и между транзакциями ставить 1-3 секунды паузу. Да, это долго. За то ни кому работать не мешает.

Одну наивреднейшую огромную базу так чистил от помеченных на удаление. За ночь кластера 1С и СУБД не вывозили проверку целостности. В итоге сделал с паузами, прикрутил протоколирование и за пару недель всё обработалось прекрасно и ни кто ни чего не заметил вообще. А так до сих пор бы топтался на месте

(29) к чему этот гемор? если регистр независимый, то я за хирургическое вмешательство. делов на 5 минут.

(30) Всякое бывает. Я же просто привёл один из вариантов, исключающий ыклинивание в структуру СУБД. Нельзя так поступать и для некоторых это жёсткое правило

(29) а может в несколько потоков тогда лучше?

(32) А смысл? Я привёл вариант как сделать так, что-бы ни кто вообще не заметил. Даже архивация и самые вредные пользователи. И этот вариант действует не только для регистров сведений без регистратора!
Несколько потоков, это увеличение блокировок. Не знаю, я в фон.задание врубил и работало оно ни кого не трогая

Есть предположение что время удаления записей сопоставимо с временем на реструктуризацию средствами платформы

(33) А те пару недель что регистр очишался как работа велась? или регистр  был не нужен? тогда вообще зачем очищать?

(35) Я удалял помеченные на удаление. Т.е. они вообще ни как не использовались. Удалялись только те записи, которые вот прям сейчас не используются. И так по кругу. Если регистр используется, то точно так-же: каждый раз отбираешь по критериям, блокируешь, выделяешь 5-10 записей, удаляешь и разблокируешь. Потом секунду ждёшь и заново

Главное секунда ожидания. Любые массовые обработки базу ставят раком-боком. С паузами же ни кто вообще ни чего не замечает

неделя к..еты или 10 мин работы скуля )))

(38) Для военных и неумеющих читать: я привёл пример, когда в СУБД нельзя лазить по тем или иным причинам. А их только с ходу 4 наковырял.
Ну не нравится тебе средствами 1С-ки, твоё право. Кто тебя заставляет то слепо следовать моим советам?????? Неуж то кто сзади с автоматом стоит и требует "делай как написали!!!!! Счиатю до 3-х!!!!"?

4 чего?

(22) Откровенно говоря всегда думал, что обновление идет по именам объектов. По крайней мере при ручном обновлении с cf-ка, сравнение идет по именам.

Возможно, быстрее будет так:

НЗ=регистрыСведений.ХХ.создатьнаборзаписей();
НЗ.ОбменДанными.Загрузка = Истина;
НЗ.Записать(Истина);

(41)  ни разу не видел ситуации: Объект.ХХХ удален, Объект.ХХХ добавлен

(50) Вариантов, когда нельзя лезть в СУБД
1. Религия не позволяет (это у большинства)
2. СУБД неизветсная (например, 1С-вский формат или ещё что)
3. Излишняя сложность (удали ка помеченные на удаление средствами СУБД).
4. Просто отсутствие знаний

(45) --> (40)

(41) А подключение к хранилищу по идентификатору. Проверил пару лет назад(((((

(47) Век живи - век учись. Записал себе на подкорку, ибо программлю исключительно через хранилище.

(48) Ну так вот... я то без опыта сначала данные все новогодние вых-е заливал в базу а потом думал к хранилищу прицепить. Месяц бился неспеша, пока до сути не докопался. Подключаешь к ханилищу, а там даже роли у пользователей исчезают. И всё выглядит так странно, что уж и не знал на кого злиться

(45) расписал отсутствие знаний на 4 пункта

(50) Опыта у тебя нет, но рано или поздно появится. Только молись, что бы ни кто голову не оторвал за порушенную базу, а то всякое бывает (вспоминаю смельчаков-зазнаек из красноярской трои, которые тоже "спешиалисты" по разным СУБД).

Кстати, и не поверишь, с опытом и архивируют базы и изменения вносят в конфигурацию только 2-3 раза в месяц и пользователи ни когда не жалуются на какие-то проблемы

(51) чёт везёт тебе на плохие машины и хреновых специалистов. может сходить карму почистить? или что-там чистят, чакры?

(52) Нет, я просто реалист и у меня нет розовых очков. А опыт есть и не малый. Я тебе привел пункты, когда ты не сможешь даже прикоснуться к СУБД. Тебя просто пошлют нафиг из конторы, да еще и с нарушением

(52) Ну вот как ты будешь в СУБД от 1С удалять что-то? Запрашивать у Нуралиева структуру файла? А если работаешь в конторе, где народу много и соответственно бюрократия разветвлённая и доступ к СУБД возможен только на таком-то уровне доступа, который ты получишь через 2 года? Да всякое бывает

(54) а как ты свертку бы делал на такой базе?
Порцими не получится ибо данные будут не актуальны

(55) Я правильно понимаю, что если свёртку ты сделать не сможешь, то контору пошлёшь нафиг и гордо уйдёшь?
А я просто не сворачиваю. А вообще, политические вопросы, поверь, врозь расходятся со здравым смыслом по твоему мнению.

(55) Кстати, если честно уже и забыл когда базы то сворачивал. По молодости да, как наворотишь фигни всякой, а потом сворачиваешь каждый новый год)))) Не, это уже не моё

(54) начал про знания, закончил, что к базе не пускают.

структура легко расковыривается с помощью профайлера. для ошибок есть тестовые базы и бэкапы. остальное - параноидальный бред.

(58) Это был один пункт, а не 4. Один! И покажи мне хоть одного мистянина, который знает как работать со всеми СУБД, на которых 1Ска крутится

(58) И бред для тебя только от незнаний. Когда сталкиваешься с таким бредом офигиваешь ещё больше. Ты не представляешь как иногда относятся некоторые начальники к работе айтишников))))))

(59) я ж написал, что все твои пункты вытекают из одного - незнания и непонимания как оно работает.

что тебе ещё показать?

(61) Как ты очистишь регистр сведений или удалишь помеченные на удаления объекты не средствами 1С, если она крутится в файловой базе?

(60) некий процент параноидальных клиентов, не даёт повода устраивать истерики на тему "лазить в базу на прямую это зло"

(62) сколько платишь?

(61) Например, 1-й пункт. Какие незнания? Я неплохо знаю MS SQL, PostgreSQL и SQLite. Для них пишу на асме всякие безделушки. Но ни когда в структуру базы не полезу, где хозяйничает 1С. Ни когда!!!!!!! Просто риски от таких вмешательств в конечном итоге гораздо дороже обходятся. Сиюминутно для крутости можно, а в работе нельзя.
Так какое тут незнание?

(64) 0 рублей и столько же копеек. Или мы к оплате подошли? О нееет! Хорошо, я как клиент буду рассуждать
"И зачем мне такой спец, который полезет куда-то, куда франч (или знакомый или еще кто) не советует? Нафиг надо, лучше позову нормального специалиста"

(65) тебе бы проповедником работать.

Пункт два давай обсудим. Вот ты знаешь сколько стоит получить сертификаты по ДБ2? А по MS SQL-ю? Ну а например в гос конторах которые покрупнее без них, увы, тебя не допустят к работе. Т.е. ты такой прикольный приходишь, говоришь "ща вам за рупь писят очищзу регистр и за свой счет пойду получу бумаги по ДБ2"? Круть. Я бы поржал и позвал нормального спеца

(67) Эх, к сожалению жизнь такая... Я же тоже был новичком и тоже думал, что "да тут же всё просто". И тоже считал всех дураками. Задумайся просто. Вот сейчас сильно жалею, что не прислушивался к опытным. А они смеясь пытались рассказать что-то. Самое главное - не надо ни чего усложнять

Ха! Да вот примитивнейший пример: в одной конторе у меня нет к СУБД доступа. Вообще. А у другого сотра к админству 1С. А знаешь почему? Лучше я прикинусь дубом, чем потом будут гонять по нудным задачкам.

(69) хех... новичок, ну-ну.

ок. воюй с неверными дальше. мне сложно аргументированно отвечать на такой поток сознания.

(71) Причины глянь. Ты то отталкиваешься от того, что "да что тут делать?", а я от многообразия ситуаций. Ну а раз нет аргументированного "потока сознания", тогда удачи в ковыряниях СУБД
))))

(4) У меня 11 миллионов записей генерируются и записываются за 2 часа.

запусти удаление всех записей - за сколько отработает?
а то я не смог вчера проверить- утром запустил на тестовой - забыл что у меня раз в два дня сервер предприятия перезапускается - оно и выбилось :(

.