Не впервой надо было "чистить" базы данных разных клиентов от избыточных и не нужных данных. Апогеем разгребания шлаков, лично для меня, стала база в несколько сотен ГБ. Соответственно работать с такими массивами с помощью приложения 1с, в принципе невозможно.
Чаще всего "захламляются" незакрытые регистры остатков с индексами, и вторая по популярности проблема - это цены... А точнее нагромождение давно не используемых цен. О чем мы и будем говорить далее.
В первую очередь скажу – работа с базой данных вне интерфейса 1с не рекомендуется, даже запрещается. Так что, если что-то поломаем, пока чиним - в поддержке 1с нам не помогут.
Далее по самой обработке пару слов. Тестировал на 8.3.6.
В список выбора попадают только периодические регистры (с регистратором или без).
При выборе регистра - отображаются поля, и их роль в запросе. По умолчанию группировка идет по измерениям, поле максимума - период. И походу строятся запросы для SQL
- общее к-во строк
- количество к удалению
- количество строк среза
- запрос на кастрацию нашей базы.
- запрос кастрации по 10000 строк в одной итерации
- 4 последовательных запроса для манипуляций с переносом среза
Добавил эти запросы для наглядного понимания уровня хлама, и рациональность использования данного способа (удаление 3-х строк и перестроение индексов ради них - такое себе занятие)
Допустим всего записей 50кк, второй запрос говорит, что обработка удалит 48кк... Т.е. в базе всего 2 миллиона строк актуальных данных... Однозначно мусор в утиль!!!
После данной операции настоятельно рекомендую переформировать индексы изменяемых таблиц. Можно вручную (быстрее), либо запустить пересчет индексов всей базы через "Тестирование и исправление" в конфигураторе.
UPDATE. 03.07.2018. Добавил второй вариант очистки по принципу копирования среза в темп. таблицу. Важно. Перед копированием убедитесь о наличии свободного дискового пространства для копирования таблицы и журнала. Данный подход более эффективен, если количество строк среза составляет менее 40% всей таблицы. Иначе использование не оправдывает риски (truncate, в случае проблем с временной таблицей, мы не сможем отменить)
ВАЖНО. Обработку соединения с базой через АДО не делал намеренно. Зачастую данные операции относительно долгосрочные. Лучше их выполнять без «посредника». Не будет проблем с таймаутом или секундной задержке ответа от сервера, которые приведут к ошибке АДО-соединения и откате изменений. Так что Ctrl+C -> Ctrl+V, товарищи.
