← На главную

При обслуживании баз данных 1С:Предприятие 7.7, работающих на MS SQL Server, нередко возникает желание «оптимизировать» объем таблиц путем удаления якобы избыточных записей в регистрах. Рассмотрим, почему попытка удалить «дубликаты» в таблицах итогов RG% прямым запросом к SQL является опасной ошибкой, которая неминуемо ведет к нарушению целостности данных и появлению критических ошибок в отчетах.

Понимаем архитектуру регистров 1С 7.7

Для начала разберемся, как устроены регистры в платформе 1С 7.7. Регистры состоят из двух основных групп таблиц:

1. RA% — это таблицы движений (архив записей). Каждая строка здесь соответствует движению конкретного документа.
2. RG% — это таблицы итогов (снимки состояния регистра на определенные даты).

Многие разработчики ошибочно принимают многократное повторение данных в RG% за мусор. Однако поле PERIOD — это системный признак, который 1С использует для хранения итогов. Если по набору измерений (товару, фирме, партии) в новом периоде не было движений, 1С при процедуре «открытия периода» автоматически копирует состояние итогов из предыдущего периода в текущий. Это штатное поведение системы, необходимое для быстрой работы отчетов. Таким образом, наличие десятков строк с одинаковыми измерениями, но разными датами — это не дубликаты, а история накопленных итогов.

Разбираем последствия прямого удаления данных

Когда вы удаляете записи в RG% (таблицах итогов) через DELETE, вы не просто очищаете «лишнее», вы уничтожаете исторический срез данных, на который опирается механизм отчетов. Если вы при этом удаляете связанные движения в RA%, вы лишаете платформу базы для пересчета итогов.

Результат таких действий предсказуем:

• При первой же операции «Пересчет итогов» или выгрузке/загрузке базы система обнаружит отсутствие данных, на основании которых должны строиться остатки.
• В отчетах появятся «красные минуса» (отрицательные остатки), так как 1С не увидит приходных движений, которые вы удалили из RA%.
• База данных станет неконсистентной, и исправить ситуацию «на лету» будет крайне сложно без восстановления из резервной копии.

Как правильно проводить «свертку» базы данных

Если возникла реальная необходимость уменьшить размер базы или очистить историю за 15 лет, используйте только штатные и проверенные механизмы свертки. Рассмотрим алгоритм действий:

1. Создание документов ввода остатков: Вы должны сформировать документы, которые зафиксируют текущие остатки на выбранную дату (точку свертки). Это создаст «фундамент» для новой базы.
2. Пометка на удаление документов: Все документы, предшествующие дате свертки, помечаются на удаление средствами 1С (через код или штатные обработки).
3. Очистка системы: Удаление помеченных объектов должно происходить штатно, чтобы 1С корректно обработала ссылки в _1SJOURN, _1SCRDOC и других служебных таблицах.
4. Пересчет итогов: После выполнения очистки необходимо выполнить процедуру «Управление бухгалтерскими итогами» (или «Управление итогами» для регистров), чтобы 1С пересчитала остатки, опираясь на созданные документы ввода остатков.

Рекомендации по обслуживанию

Вместо попыток вырезать данные «по живому», проанализируем другие способы повышения производительности:

Обслуживание индексов: Большие таблицы RG% и RA% требуют регулярной переиндексации и обновления статистики на уровне MS SQL Server. Это дает гораздо больший прирост скорости, чем уменьшение количества строк.

Модель бэкапа: Если вас беспокоит размер резервных копий, настройте бэкап с онлайн-сжатием. Современные версии SQL Server справляются с базами размером в сотни гигабайт без необходимости удаления исторических данных.

Использование «Двигателя регистров»: Профессионалы используют готовые обработки, называемые «двигателями регистров». Они считывают остатки на нужную дату, записывают их в специально созданный документ и позволяют корректно «обрезать» историю, не нарушая связей внутри RA% и RG%.

Главный вывод: Если вы не являетесь экспертом в архитектуре таблиц 1С 7.7, никогда не применяйте прямые запросы DELETE к системным таблицам. Это прямой путь к потере данных и необходимости восстановления всей учетной системы.