Как очистить таблицу 1С в SQL и не разрушить базу

Очистка таблиц 1С напрямую в SQL Server — задача, к которой администраторы прибегают, когда штатные средства конфигуратора работают слишком медленно или недоступны. Типичные сценарии: разросшиеся таблицы итогов регистров, журналы регистрации, таблицы версионирования объектов и очереди обмена, которые занимают десятки гигабайт и тормозят работу базы.

Однако прямое вмешательство в структуру данных 1С через SQL — одна из самых рискованных операций в администрировании. Платформа 1С хранит данные в таблицах с техническими именами вида _AccumRg12345 или _Document15678, и ошибка в выборе таблицы приводит к потере учётных данных. Кроме того, официальная поддержка 1С не распространяется на базы, в которые вносились прямые изменения на уровне СУБД.

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

Когда очистка таблиц через SQL оправдана

Прямая работа с СУБД имеет смысл в ограниченном числе случаев. Первый — журнал регистрации и технические таблицы, которые 1С не очищает штатно либо очищает очень медленно. Второй — таблицы итогов регистров накопления и сведений, которые можно безопасно пересчитать после очистки средствами самой платформы. Третий — аварийные ситуации, когда база не открывается из-за переполнения диска, и нужно срочно освободить место.

Не стоит лезть в SQL ради учётных данных: документов, справочников, движений по регистрам. Удаление строк из таблицы документа напрямую нарушит ссылочную целостность — в регистрах останутся движения, ссылающиеся на несуществующий документ, а в других таблицах — «битые» ссылки. Для таких задач существуют пометка на удаление, обработки свёртки базы и типовые механизмы удаления устаревших данных.

Подготовка: резервная копия и блокировка базы

Перед любой операцией с таблицами выполните полную резервную копию средствами SQL Server. Копии файловой выгрузки .dt недостаточно для оперативного отката — восстановление из неё на большой базе занимает часы. Полный бэкап через BACKUP DATABASE позволяет вернуть состояние за минуты.

Второй обязательный шаг — исключить работу пользователей. Удалите активные сеансы через консоль кластера серверов 1С и установите блокировку соединений, либо переведите базу в однопользовательский режим на уровне SQL Server (single user). Параллельные транзакции во время очистки приводят к блокировкам, а в худшем случае — к рассогласованию данных, если платформа продолжает писать в очищаемую таблицу.

TRUNCATE или DELETE: что выбрать

Для полной очистки таблицы используется TRUNCATE TABLE. Команда работает практически мгновенно даже на таблицах с сотнями миллионов строк, потому что не пишет каждую удалённую строку в журнал транзакций, а освобождает страницы данных целиком. Ограничения: TRUNCATE нельзя применить к таблице, на которую ссылается внешний ключ, и нельзя указать условие — удаляется всё.

DELETE FROM с условием WHERE подходит для выборочной очистки — например, удаления записей журнала старше определённой даты. Команда полностью журналируется, поэтому на больших объёмах работает медленно и может раздуть файл журнала транзакций. Для удаления миллионов строк лучше выполнять DELETE порциями в цикле по несколько тысяч записей с паузами.

-- Полная очистка технической таблицы
TRUNCATE TABLE dbo._InfoRg12345;

-- Выборочное удаление старых записей
DELETE FROM dbo._InfoRg12345
WHERE _Fld678 < '2023-01-01';

Сравнение вариантов

TRUNCATE TABLE

Мгновенная полная очистка, минимальная нагрузка на журнал. Не поддерживает WHERE и не работает при внешних ключах

DELETE с WHERE

Выборочное удаление по условию. Медленно на больших объёмах, раздувает журнал транзакций — удаляйте порциями

Штатная обработка 1С

Медленнее, но сохраняет целостность данных и поддерживаемость базы. Предпочтительный вариант для учётных данных

Безопасные сценарии очистки типовых таблиц

Журнал регистрации

Журнал регистрации в клиент-серверном варианте хранится не в таблицах SQL, а в отдельных файлах формата lgd в каталоге базы (папка с GUID базы, подкаталог 1Cv8Log). Для его сокращения используется штатная настройка в конфигураторе: «Администрирование» → «Настройка журнала регистрации» → «Сократить». Прямое удаление файлов lgd при работающем сервере приведёт к ошибкам записи журнала.

Таблицы итогов регистров

Таблицы итогов (в структуре хранения — таблицы итогов регистров накопления и сведений) допустимо очищать, если сразу после этого выполнить пересчёт итогов штатными средствами: через «Тестирование и исправление» с включённым пересчётом итогов или программно методом ПересчитатьИтоги(). До завершения пересчёта отчёты по регистру будут показывать неверные данные.

Таблицы обмена и версионирования

Очереди обмена данными и история версий объектов накапливаются годами и могут занимать значительную часть базы. Очистка возможна, но после неё узлам обмена потребуется повторная регистрация изменений или начальная выгрузка. Предпочтительнее штатные механизмы: удаление регистрации изменений по узлу и настройка сроков хранения версий.

Проверка результата и восстановление работоспособности

Сразу после очистки выполните контрольный запрос SELECT COUNT(*) к обработанной таблице — он должен вернуть ноль для TRUNCATE или ожидаемое число оставшихся строк для DELETE. Затем проверьте размер базы и журнала транзакций: при необходимости усечения журнала выполните бэкап лога (для модели восстановления Full).

Далее — проверка на уровне 1С. Запустите «Тестирование и исправление» в режиме проверки ссылочной целостности, откройте ключевые отчёты по затронутым регистрам и убедитесь, что данные согласованы. Только после успешной проверки снимайте блокировку соединений и возвращайте пользователей в базу.

Контрольные точки

Как проверить результат

Количество строк в таблице

Норма

COUNT возвращает 0 или ожидаемый остаток

Тревожный признак

Строки остались — условие WHERE не охватило данные или очищена не та таблица

Ссылочная целостность

Норма

Тестирование и исправление не находит битых ссылок

Тревожный признак

Ошибки ссылочной целостности — восстанавливайте бэкап

Отчёты по регистрам

Норма

Обороты и остатки сходятся с данными до очистки

Тревожный признак

Расхождения — итоги не пересчитаны или затронута таблица движений

Типичные ошибки и альтернативы прямой очистке

Самая частая ошибка — очистка таблицы по догадке, без сверки со структурой хранения. Вторая — забытый бэкап или бэкап, который не проверяли на восстановление. Третья — очистка таблицы итогов без последующего пересчёта, из-за чего отчёты начинают врать, и это обнаруживается только через недели.

Во многих случаях прямого вмешательства можно избежать. Для регистров сведений есть штатное удаление записей через набор записей, для устаревших данных — типовые обработки свёртки и удаления, для журнала регистрации — настройка сокращения. Эти механизмы медленнее, но сохраняют базу в поддерживаемом состоянии и не требуют остановки работы на часы.

Маршрут решения

Как выбрать действие

Нужно очистить таблицу итогов или техническую таблицу целикомTRUNCATE TABLE после бэкапа, затем пересчёт итогов средствами 1С

Нужно удалить часть записей по условиюDELETE с WHERE порциями по несколько тысяч строк

Нужно удалить учётные данные — документы, движения, справочникиТолько штатные механизмы 1С: пометка на удаление, свёртка, типовые обработки

База не открывается из-за переполнения дискаСначала очистка журнала регистрации и технических таблиц, учётные данные не трогать

Частые вопросы

Можно ли очистить таблицу документов напрямую в SQL?

Технически команда выполнится, но результатом станут битые ссылки по всей базе: движения в регистрах, ссылки из других документов и справочников останутся, указывая на удалённые записи. Документы удаляют только штатно — через пометку на удаление и обработку «Удаление помеченных объектов».

Почему после DELETE размер файла базы не уменьшился?

DELETE освобождает страницы внутри файла данных, но не возвращает место операционной системе. Для уменьшения файла нужна операция сжатия (DBCC SHRINKFILE), после которой обязательно выполняется реиндексация, так как сжатие сильно фрагментирует индексы.

Потеряю ли я поддержку 1С после прямых изменений в SQL?

Прямые модификации данных на уровне СУБД выводят базу из рамок поддерживаемой конфигурации обслуживания. На практике это означает, что при обращении в поддержку с проблемой целостности данных вам могут рекомендовать восстановление из копии. Ещё одно основание применять прямую очистку только к техническим таблицам и документировать каждую операцию.

Как быстро очистить журнал регистрации?

Штатный путь — конфигуратор, «Администрирование» → «Настройка журнала регистрации» → кнопка «Сократить» с указанием даты. Журнал хранится в файлах lgd в каталоге базы, а не в таблицах SQL, поэтому команды DELETE/TRUNCATE к нему не применимы. Удалять файлы lgd вручную при работающем сервере нельзя.

Что делать, если после очистки отчёты показывают неверные данные?

Наиболее вероятная причина — очищены таблицы итогов, но пересчёт не выполнен. Запустите «Тестирование и исправление» с включённым пересчётом итогов либо программный пересчёт по конкретным регистрам. Если расхождения остались — проверьте, не была ли затронута таблица движений, и при необходимости восстановите базу из резервной копии.

Как удалить миллионы строк, не переполнив журнал транзакций?

Выполняйте DELETE порциями в цикле: удаляйте по 5–50 тысяч строк за итерацию с помощью DELETE TOP (N) ... WHERE, повторяя, пока затронутых строк не станет ноль. Между итерациями при модели восстановления Full делайте бэкап журнала, при Simple журнал усекается автоматически после checkpoint.