Очистка периодических регистров посредством T-SQL (удаление записей, кроме среза последних)

Администрирование - Чистка базы

Обработка для ленивых. Составит вместо Вас запрос для SQL, который удалит все не актуальные записи (т.е все, кроме среза последних)

Не впервой надо было "чистить" базы данных разных клиентов от избыточных и не нужных данных. Апогеем разгребания шлаков, лично для меня, стала база в несколько сотен ГБ. Соответственно работать с такими массивами с помощью приложения 1с, в принципе невозможно. 

Чаще всего "захламляются" незакрытые регистры остатков с индексами, и вторая по популярности проблема - это цены... А точнее нагромождение давно не используемых цен. О чем мы и будем говорить далее.

В первую очередь скажу – работа с базой данных вне интерфейса 1с не рекомендуется, даже запрещается. Так что, если что-то поломаем, пока чиним - в поддержке 1с нам не помогут.

Далее по самой обработке пару слов. Тестировал на 8.3.6.

В список выбора попадают только периодические регистры (с регистратором или без).

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

  • общее к-во строк
  • количество к удалению
  • количество строк среза
  • запрос на кастрацию нашей базы.
  • запрос кастрации по 10000 строк в одной итерации
  • 4 последовательных запроса для манипуляций с переносом среза

Добавил эти запросы для наглядного понимания уровня хлама, и рациональность использования данного способа (удаление 3-х строк и перестроение индексов ради них - такое себе занятие)

Допустим всего записей 50кк, второй запрос говорит, что обработка удалит 48кк... Т.е. в базе всего 2 миллиона строк актуальных данных... Однозначно мусор в утиль!!!

После данной операции настоятельно рекомендую переформировать индексы изменяемых таблиц. Можно вручную (быстрее), либо запустить пересчет индексов всей базы через "Тестирование и исправление" в конфигураторе.

UPDATE. 03.07.2018. Добавил второй вариант очистки по принципу копирования среза в темп. таблицу. Важно. Перед копированием убедитесь о наличии свободного дискового пространства для копирования таблицы и журнала. Данный подход более эффективен, если количество строк среза составляет менее 40% всей таблицы. Иначе использование не оправдывает риски (truncate, в случае проблем с временной таблицей, мы не сможем отменить)

ВАЖНО. Обработку соединения с базой через АДО не делал намеренно. Зачастую данные операции относительно долгосрочные. Лучше их выполнять без «посредника». Не будет проблем с таймаутом или секундной задержке ответа от сервера, которые приведут к ошибке АДО-соединения и откате изменений. Так что Ctrl+C -> Ctrl+V, товарищи.

Скачать файлы

Наименование Файл Версия Размер
Очистка периодических регистров
.epf 10,17Kb
22.06.18
9
.epf 10,17Kb 9 Скачать

См. также

Лучшие комментарии
6. Alexander.Shvets 202 28.06.18 00:37 Сейчас в теме
upd. Обновил обработку. Исправил ошибку генерации ссылочных полей и названия таблиц. Кто скачивал обработку и не можете повторно скачать - пишите в личку, скину исправленный вариант.
7. Alexander.Shvets 202 03.07.18 03:03 Сейчас в теме
upd. Обновил обработку. Таки добавил вариант с переносом среза во временную таблицу и truncate источника.
Остальные комментарии
Сортировка: Древо
1. tormozit 4741 24.06.18 07:37 Сейчас в теме
Безопаснее сохранять срез/остатки в файл, делать TRUNCATE TABLE для основой таблицы и таблиц итогов и далее загружать и записывать набор записей в регистр из файла.
2. Alexander.Shvets 202 26.06.18 13:09 Сейчас в теме
(1)
сохранять срез/остатки в файл


Если срез до 10КК строк, возможно соглашусь, но если база несколько ТБ?
Думаю клиент не всегда будет рад оплачивать 24+ часов работы за то, что можно сделать за 1.

Миграция данных или конвертация из реляционного вида в любой промежуточный и обратно - гиблое дело по своей сути. Особенно используя текст. Вы же в курсе, что 1с и большие текстовые файлы - тот еще изврат?

"СтрНайти" в 1,5 гиг csv против того же RegExp никак не выйдет победителем.
Лично мне проще потратить 0,3 часа на очистку тб.
Само собой, наличие бекапа необходимо.

А xml без внешней компоненты, с возможностью работать по нодам - тот же гемор.

Проблемы возникали только в случаях, если в таблицах еще до моего вмешательства были логические траблы. А так - ни одного нарекания.
3. Alexander.Shvets 202 26.06.18 13:11 Сейчас в теме
(1)
таблиц итогов


У сведений нет табл итогов. Только индексы по Атрибутам и датам первого и последнего события в разрезе ключа. (срез первых/последних)
4. tormozit 4741 26.06.18 13:24 Сейчас в теме
(3)
У сведений нет табл итогов
Есть же
Прикрепленные файлы:
5. Alexander.Shvets 202 26.06.18 13:36 Сейчас в теме
(4) Я не знаю почему доблестные разработчики платформы называют это таблицами итогов, но в sql они выглядят так (индексы)

А вот у регистров накопления присутствует вирт. таблица (накопительная)

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

Как раз в силу этого публикация не относится к регистрами накоплений. Для них же
использую похожий метод. Сохраняю только не закрытые обороты в отдельную таблицу в том же пространстве sql. Truncate источник, и обратно переносим не закрытые обороты. Таблица итогов в этом случае будет девственно не тронутой. Но я все же вызываю sql скрипт (написанный ребятами из 1с) для перестроения таблицы итогов.

Но об этом возможно в следующей публикации. =)
Прикрепленные файлы:
6. Alexander.Shvets 202 28.06.18 00:37 Сейчас в теме
upd. Обновил обработку. Исправил ошибку генерации ссылочных полей и названия таблиц. Кто скачивал обработку и не можете повторно скачать - пишите в личку, скину исправленный вариант.
7. Alexander.Shvets 202 03.07.18 03:03 Сейчас в теме
upd. Обновил обработку. Таки добавил вариант с переносом среза во временную таблицу и truncate источника.
Оставьте свое сообщение