Упростим ситуацию и будем рассматривать только удаление из базы данных документов указанных
типов, даты меньше заданной (D). Под документом в широком смысле мы понимаем:
Cовокупность записей в таблице GD_DOCUMENT, шапка и позиции.
Присоединенные к ним записи 1-к-1 (включая записи в специфических таблицах документов, связанные через поле documentkey).
Связанные с ними таблицы с уточняющей информацией (например, USR$INV_ADDINFO). По сути это 1-к-1, но через отдельное поле внешний ключ. Из структуры БД мы не можем знать, что некоторая таблица несет уточняющую информацию, поэтому определим список таких таблиц через константу в программе.
Бухгалтерские проводки (AC_RECORD, AC_ENTRY).
Складское движение (INV_CARD, INV_MOVEMENT).
Ко всему вышеперечисленному связанные записи в кросс-таблицах множеств.
Типы указываем, так как некоторые документы (например, зарплатные или по ОС) удалять нельзя за весь период.
Процесс "обрезания" базы сводится к следующему:
Вычисляем бухгалтерские и складские остатки на заданную дату. Сохраняем их в базе.
Формируем массив М из ИД записей, которые останутся в результирующей базе:
Сканируем все таблицы, не относящиеся к документам. Добавляем в М ИД записи (если он есть и целочисленный) и идентификаторы всех ссылок на таблицы документов. Прочие ссылки нас не интересуют, так как все записи из прочих таблиц в любом случае будут сохранены.
Выбираем из таблиц документов указанных типов записи с датой больше либо равно D. Сканируем их аналогичным образом, добавляя ИД в М.
Сканируем аналогичным образом таблицы документов остальных типов.
Запоминаем информацию о структуре БД в части обрабатываемых таблиц.
Отключаем ключи, индексы, триггеры, ограничения на таблицах, из которых будем удалять записи.
Удаляем записи, отсутствующие в М.
Удаляем из таблицы GD_RUID записи для удаленных ИД.
Восстанавливаем структуру БД.
Подготовка исходной базы данных:
Пользователю рекомендуется провести бэкап-разбэкап исходной базы перед началом процесса.
Кэш не должен превышать 500 Мб.
Режим принудительной записи должен быть отключен
Если задействован наш механизм замены внешних ключей, то отключенные ключи должны быть включены.
Аудит средствами платформы Гедымин должен быть отключен.
Для оценки эффективности процесса будем использовать количество записей до и после "обрезания" в затрагиваемых процессом таблицах.
5 комментариев:
А что на счёт остатков клиентов? Они нужны для возвратов.
Впрочем, если урезать базу на дату начала предыдущего года, то документы годичной давности сохранятся и остатки по клиентам можно не сохранять.
Относительно данных по зарплате. Там основные по объёму таблицы это “Начисление по табелю” (USR$WG_TBLCHARGE) и “Журнал начислений” (USR$WG_CHARGEREG).
Причём вся информация, которая содержится в USR$WG_CHARGEREG есть в USR$WG_TBLCHARGE. Годичный объём занимает у нас порядка 1 300 000 записей в каждой из них. Было бы логично оставить только USR$WG_TBLCHARGE.
Можно также в процессе сжатия базы создать архивную базу, куда в такую же таблицу USR$WG_TBLCHARGE переместить все записи с датой меньше начала предыдущего года. Тогда информация за год, которая в основном и нужна, останется в текущей базе, а если нужна более старая – её можно вытянуть запросом к архивной базе. Если создать служебную таблицу, где хранить информацию о том какие таблицы находятся в архиве, с какой по какую дату, путь к архивной базе – можно создание запроса автоматизировать.
Сальдо бухгалтерское и складское выводится на начало обрезания. Так что все остатки будут идти, если отчеты строятся по бухгалтерским/складским таблицам, а не напрямую по таблицам документов.
А как быть с остатками ОС? Ведь предыдущие движения по ним потеряются. А нужно строить карточку ОС-6, где долдны быть видны все переоценки, допоступления/списания затрат.
Все будет Ок с основными.
Отправить комментарий