Ускорение реструктуризации таблицы 1С #806425

Доброго времени суток! Имеем базу 1С на 8.2 на сервере МС СКЛ Сервер 2012 В базе есть регистр накопления (по остаткам) и 5 типов документов, которые делают в него движения. Хочу удалить один из типов документов (вообще удалить из конфы, т.к. он устарел, не используется и мозолит глаза). Проблема заключается в том, что при попытке обновить конфигурацию базы данных начинается реструктуризация этого регистра накопления, а в нем порядка 22 млн строк и реструктуризация, по моим оценкам, займет часов 10-12. Это слишком долго! Нашел статью: в целом идея понятна, но конкретно в моем случае не пойму как скопировать таблицы так, чтобы убрать из них ненужный тип данных. Кто-нибудь делал подобное на практике? Нужна помощь

Если причина только в том, что "он устарел, не используется и мозолит глаза" - забить. Заморочиться этим документом следует при следующей свертке базы.

в этой базе куча такого мусора...не используемые документы, регистры. Хочу почистить. Свертка базы как-то не предвидится

ну лежит и лежит. леший с ним. как в говорилось - убирать только послепри глобальной чистки. или при переходе на глобально новую версию. имхо, то чем вы хотите заниматься - от безделья. лучше что-нибудь полезное сделайте. в % по размеру базы или быстродействии выигрыш будет копеечный. стоит ли это таких усилий?

Удали движения этого документа из регистра, потом уже обновляй БД

10 часов это не много. Можно на ночь или выходной поставить. Предварительно убедится в копии в том, что хватит 10-12 часов. И без бубна удалить.

Движений нет. Документы уже вычистил. Но реструктуризация все-равно идет полностью по всему РН

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

На 8.3.10-11 перейди, там ускорили все это дело

у меня нет столько. Юзеры заканчивают работу почти в полночь. Склад начинает работу с 7 утра. Ночью работают ревизоры + куча регламентов выполняется. По хорошему есть часа 2-3

Да, читал об этом, но совершенно не понятно на сколько ускорили

Если документов уже нет, как вариант можно отложить удаление на праздники. Например новогодние.

, Вплоть до возможности фонового обновления. Он запустит задание на реструктуризацию и потом на короткий промежуток времени выгонишь пользователей, либо ночью. Регистрация изменений в таблицах идет аналогично РИБ в этот момент.

попробуй на копии. тем более они уже скоро.

продублирй проведение в временный регистр, перенеси туда данные тихой сапой, потом старый тыдыщ и новый переименовать

была такая идея. Косяк в том, что по тому РН куча отчетности и перейти на имя другого регистра, пусть даже временно, крайне проблемно

Почитаю про этот вариант, спасибо!

так и не надо переходить, даже временно

+100 Данные пользователей и работоспособность базы намного важнее "красивого" вида в конфигураторе. Понимание этого есть показатель профессионализма. Добавь проверку, чтобы кто-нибудь сдуру не создал этот документ, и успокойся. Кстати, то что "в этой базе куча такого мусора...не используемые документы, регистры" — тоже показатель. Скорее всего они были опрометчиво созданы.

Хз, как ты там меряещь, взял регистр останковый, select COUNT(*) from [_AccumRg23481] 3149926 удалил из регистраторов все виды доков, кроме одного, реструктуризация менее минуты. Движения доков, естесственно не очищал.

Посмотрел потом в 1с-ине, движений нет, итогов нет. Всё ровно

Откуда там 10 часов возьмётся ?!

если че, 8.3.8.2167, регистр ТоварыНаСкладах в УПП

+SQL2008R2

Как ты удалил все виды регистраторов кроме нужного?

зашел в свойства регистра и понажимал на красный крестик :)

на закладке регистраторы

тю, я думал ты это средствами скула сделал

Нафига ? Когда и так реструктуризация меньше минуты.

Вот и спрашиваю, откуда там у тебя 10 часов она делается.

Так у тебя 3 миллиона, а у него 22 )

22/3 ~ 6 минут максимум. Откуда 10 часов ?

и то не не факт, что так долго будет.

А насколько верны и обоснованы твои расчеты? Сделать копию, провернуть все в ней и замерить время выполнения не пробовал?

У нас на днищенском сервере раньше регистр бухгалтерии быстро перестраивался, было около 3млн записей, занимало минут 10-15. Сейчас порядка 21млн - реструктуризация может около 30 часов идти, поэтому и перешли на фоновое обновление. Просто сравнить объемы и рассчитать время - не совсем корректно.

Оттуда, что зависимость нелинейная, таким образом твоя экстраполяция неверна

Всё не читал, но на SSD реструктуризация такого регистра должна занять не более часа.

Пробовал конечно. 3 мл у меня реструктуризировалось около часа. ХЗ почему так долго. Может дело в самом регистре, может в медленной файловой системе. Но не так давно делал реструктуризацию нескольких таблиц, в общей сложности тоже порядка 20 млн записей было...ушло как раз 10 часов. Еще раз так юзеров мучить не хочется.

+ Скорость замедляется по мере работы. первые пару миллионов достаточно быстро, но потом скорость постепенно снижается

"3 мл у меня реструктуризировалось около часа." Это за гранью. На ответь и общий размер базы озвучь.

господа, вы в топике увидели?

В режиме совместимости с 8.2, по крайней мере, не работает - проверено вчера на регистре с >100 млн. записей.

Ерундой не занимайтесь, переименуйте документ в "Удалить<ИмяДокумента>" и оставьте так. В типовых куча таких объектов болтается, вреда от них нет.

Я вот тоже думаю, висит и висит, кому мешает?

Конечно. Что это меняет? 1С когда-то что-то ускоряла? Бу-га-га! (если речь не про вторую версию реструктуризации в 8.3.11)

Как проверял?

Да, тупо, как автор, коллега вчера прибил регистратор и общая тестовая база занялась реструктуризацией на полдня, потом пришлось прервать. Платформа 8.3.10.2580 в режиме совместимости 8.2.16, регистр сведений примерно ~100 млн. записей. Правда, возможно дело было в том, что в tempdb тесно стало. В общем, надо изучить вопрос, но я бы на буст в 8.3.10 не рассчитывал. Тем более, пишут что все-таки это в 8.3.11 будет.

Так новый вариант реструктуризации надо запускать по-иному, штатно при обновлении конфигурации БД будет работать старый вариант