Очистка базы средствами SQL (управляемое приложение)
Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
(1)
Если просто скопировать конфу и развернуть из нее новую базу, она потеряет преемственность со старой. Я это проходил, внутренние идентификаторы предопределенных объектов меняются и потом из старой подкинуть что либо средствами xml становится весьма геморно, например перекидываешь обороты по бухучету и у тебя дублируется план счетов, причем предопределенные счета. Это очень мило, ведь 1С-ка когда такое замечает сразу захлопывается.
Если просто скопировать конфу и развернуть из нее новую базу, она потеряет преемственность со старой. Я это проходил, внутренние идентификаторы предопределенных объектов меняются и потом из старой подкинуть что либо средствами xml становится весьма геморно, например перекидываешь обороты по бухучету и у тебя дублируется план счетов, причем предопределенные счета. Это очень мило, ведь 1С-ка когда такое замечает сразу захлопывается.
Очищать виртуальные таблицы нельзя, т.к. их нет. Если речь о пересчете итогов, то там только одна таблица - собственно, сами итоги. Таблицы оборотов нет.
Ну и пересчитывать итоги после такого грубого вмешательства нужно не "по хорошему", а обязательно.
Ну и пересчитывать итоги после такого грубого вмешательства нужно не "по хорошему", а обязательно.
(2) TTSTV, если взять регистр накопления(остатки или обороты), то нужно всегда помнить, что в базе sql помимо основной таблицы с данными лежит еще таблица с итогами (либо оборотами), которая скорей всего в разы больше основной. А у регистров бухгалтерии и не одна (ИтогиПоСчетамССубконто1, ИтогиМеждуСчетами, ИтогиПоСчетам...).
Я тоже считаю, что после такой чистки запуск ТиИ пересчета итогов и переиндексации обязательны. Но возможность удалять данные из виртуальных таблиц частично я всё же оставил.
ТиИ приходится оставлять на ночь, в моем же случае вопрос времени критичнее достоверности данных, поэтому я чистил "по-быстрому" :-)
Но, опять же, после пересчета итогов и переиндексации получится еще и приличная экономия места.
Я тоже считаю, что после такой чистки запуск ТиИ пересчета итогов и переиндексации обязательны. Но возможность удалять данные из виртуальных таблиц частично я всё же оставил.
ТиИ приходится оставлять на ночь, в моем же случае вопрос времени критичнее достоверности данных, поэтому я чистил "по-быстрому" :-)
Но, опять же, после пересчета итогов и переиндексации получится еще и приличная экономия места.
Автору респект. Тоже делал подобное для тестовых баз.
И совет для удаления больших таблиц: если удаляется бОльшая часть таблицы, выгоднее сделать копию нужной части данных, очистку таблицы TRUNCATE и копирование обратно. Дело в том, что если у вас одна таблица допустим весит 40Гб, при удалении 95% ее содержимого лог базы данных вырастет примерно на 150Гб.
И совет для удаления больших таблиц: если удаляется бОльшая часть таблицы, выгоднее сделать копию нужной части данных, очистку таблицы TRUNCATE и копирование обратно. Дело в том, что если у вас одна таблица допустим весит 40Гб, при удалении 95% ее содержимого лог базы данных вырастет примерно на 150Гб.
Обработка ГУД)) Мне помогло Автору респект
ДО ЭТОГО - пробовал очистить регистр сведений (около 10 миллионов записей - SQL на дохлой тачке) - методом копирования Регистра в конфигураторе и удаления Исходного.... так вот отваливался Конфигуратор по таймауту (потом доперло что "Администрирование/Параметры информационной базы.../ Время ожидания блокировки.." - скорей всего бы помогло )
Надоело экспериментировать... да и время кончилось... начальника ругалась))) скачал обработку выбрал регистр ... поставил галку "Удалить полностью (Truncate table)".
ДО ЭТОГО - пробовал очистить регистр сведений (около 10 миллионов записей - SQL на дохлой тачке) - методом копирования Регистра в конфигураторе и удаления Исходного.... так вот отваливался Конфигуратор по таймауту (потом доперло что "Администрирование/Параметры информационной базы.../ Время ожидания блокировки.." - скорей всего бы помогло )
Надоело экспериментировать... да и время кончилось... начальника ругалась))) скачал обработку выбрал регистр ... поставил галку "Удалить полностью (Truncate table)".
(20) Насколько я помню, в Документогороде большинство "документов" - это элементы справочников. У которых "Период" - это отдельный реквизит, который на sql-е скорей всего называется как _FldXXXX, а не _Period. Поэтому если делать частичное удаление по периоду, то надо сначала уточнить имя реквизита в субд и поправить в обработке. А так не вижу помех, но обязательно сначала всё пробовать на копии!
Для автоматизации. Думаю сделать обрезание данные и формирование БД для разработчика по скрипту. Возможно повешу это на запуск от веб-сервиса - разработчик вводит только что ему нужна свежая БД и получает ее, не имея доступа к серверам SQL и т.д.
(28) Я бы это делал тогда совсем без участия 1С) Скрипт на sql с примерно таким алгоритмом:
1) Транкейтим таблицы Версии объектов и им подобные регистры с ненужными данными
2) Идем по таблицам документов. Отбираем их по DocumentХХХХ и делаем delete по периоду
3) Идём по таблицам регистров накопления, хозрасчетным.... Аналогично делаем delete по периоду. Не забывая про виртуальные таблицы.
и т.д.
И запускать такой скрипт сразу после разворачивания копии базы для разработчика. Всё на стороне субд.
1) Транкейтим таблицы Версии объектов и им подобные регистры с ненужными данными
2) Идем по таблицам документов. Отбираем их по DocumentХХХХ и делаем delete по периоду
3) Идём по таблицам регистров накопления, хозрасчетным.... Аналогично делаем delete по периоду. Не забывая про виртуальные таблицы.
и т.д.
И запускать такой скрипт сразу после разворачивания копии базы для разработчика. Всё на стороне субд.
Скачал обработку, но есть пожелание:
сделать возможным удалять документы и все регистры по этим документам. А не отдельно документы и отдельно регистры.
Была задача: удалить из базы все документы и связанные с ними регистры (любые). Остальное (справочники) в базе оставить.
сделать возможным удалять документы и все регистры по этим документам. А не отдельно документы и отдельно регистры.
Была задача: удалить из базы все документы и связанные с ними регистры (любые). Остальное (справочники) в базе оставить.
Все бы хорошо, но автор погнался за красотой в ущерб эффективности. Для того, чтобы на форме сделать прогресс-бар, он каждый раз заново создает connection и заново его закрывает для каждого вида документа и регистра. 180 видов документов * 30 секунд на эту лабуду - получилось лишних 1.5 часа. Но можно допилить напильником :)
В принципе годная вещь. Мне нужно было грохнуть все доки с движениями в базе размером 160 гиг. За несколько часов управился. Единственное что осталось недочищенным - последовательности. Особенно партионный учет поднапрягает. Через конфигуратор уже чистится черти сколько, оставлю на ночь - пусть маслает.
Вакансии
Главный специалист 1С \ эксперт по технологическим вопросам
Москва
зарплата от 220 000 руб.
Полный день
Москва
зарплата от 220 000 руб.
Полный день