В процессе эксплуатации систем на базе 1С:Предприятие 8.3 администраторы и программисты часто сталкиваются с ситуацией, когда физический размер базы данных на SQL Server начинает стремительно расти, при этом стандартные отчеты внутри 1С показывают, что полезных данных в системе значительно меньше. Разберем ситуацию, когда в базе обнаруживаются огромные таблицы с префиксом AccumRgChngR, о которых сама платформа 1С «ничего не знает».
Для начала проанализируем, что представляют собой эти таблицы. Префикс AccumRgChngR (Accumulation Register Change Registration) зарезервирован для таблиц регистрации изменений регистров накопления. Эти таблицы создаются автоматически, как только регистр накопления включается в состав любого Плана обмена.
Рассмотрим механизм их наполнения. Даже если вы явно не используете обмены данными, в свойствах регистра может быть включен режим «Авторегистрация». В этом случае при каждой записи в регистр система будет создавать запись в соответствующей таблице AccumRgChngR для каждого узла, зарегистрированного в плане обмена. Если в базе существуют неиспользуемые узлы (например, созданные случайно или оставшиеся от старых настроек), эти таблицы будут расти бесконечно, пока не займут всё доступное дисковое пространство.
Одной из самых загадочных проблем является то, что программный метод ПолучитьСтруктуруХраненияБазыДанных() может не возвращать информацию об этих таблицах. Выясним причину такого поведения. Платформа 1С работает со структурой SQL на основе своих метаданных. Если в конфигурации регистр был исключен из планов обмена или сам план обмена был удален, 1С должна отправить команду в SQL на удаление соответствующих таблиц.
Однако в некоторых случаях (сбои при реструктуризации, нехватка прав пользователя SQL, некорректное завершение процесса обновления) физическая таблица в SQL остается, а запись о ней в метаданных 1С исчезает. Такие таблицы называются «осиротевшими» (orphaned tables). Платформа больше не считает их своими и игнорирует при построении структуры хранения, но SQL Server продолжает хранить в них гигабайты данных.
Обратим внимание на нумерацию таблиц, которую заметил автор темы. Если большинство рабочих таблиц имеют идентификаторы вроде AccumRgChngR14000, а проблемные — AccumRgChngR7409, это явный признак того, что данные таблицы были созданы в гораздо более ранних версиях конфигурации или «переехали» из другой базы при некорректном объединении.
Чтобы убедиться, что проблема именно в расхождении метаданных и физической структуры, мы можем использовать следующий код для анализа текущей структуры хранения:
ТаблицаСтруктуры = ПолучитьСтруктуруХраненияБазыДанных(, Ложь);
Для Каждого СтрокаСтруктуры Из ТаблицаСтруктуры Цикл
Если Найти(СтрокаСтруктуры.ИмяТаблицыХранения, "AccumRgChngR") > 0 Тогда
Сообщить("Таблица: " + СтрокаСтруктуры.ИмяТаблицыХранения +
" соответствует объекту: " + СтрокаСтруктуры.ИмяТаблицы);
КонецЕсли;
КонецЦикла;
Если после выполнения данного скрипта вы не обнаружите в списке те таблицы, которые видите в SQL Management Studio, значит, мы имеем дело с «мусором», который платформа не контролирует.
Самым надежным и безопасным способом решения данной проблемы, как подтверждает практика, является использование файла .dt. Разберем по шагам, почему это работает:
.dt платформа 1С выполняет логическое чтение данных. Она обращается только к тем таблицам, которые описаны в текущих метаданных конфигурации. Все «лишние» таблицы, существующие в SQL, просто игнорируются и не попадают в архив..dt система заново создает структуру таблиц в SQL «с чистого листа» строго по актуальным метаданным.После завершения этой процедуры объем базы данных сократится до реального объема полезных данных, а все «фантомные» таблицы исчезнут.
Если база данных слишком велика для выгрузки в .dt (например, несколько терабайт), можно рассмотреть более радикальные методы в консоли SQL. Проанализируем ситуацию: если мы точно уверены, что таблицы AccumRgChngR7409 и AccumRgChngR8409 не связаны с метаданными, их можно удалить командой DROP TABLE или очистить через TRUNCATE TABLE.
Важно: Перед выполнением любых операций в SQL напрямую, обязательно создайте резервную копию базы данных (Backup)!
Также стоит проверить планы обмена в самой 1С. Выясним, нет ли там лишних узлов, выполнив простой запрос в консоли запросов 1С:
ВЫБРАТЬ
ПланОбмена.Ссылка,
ПланОбмена.ЭтотУзел
ИЗ
ПланОбмена.Полный КАК ПланОбмена
ГДЕ
ПланОбмена.Ссылка <> ПланОбмена.ЭтотУзел
Если вы нашли узлы, которые не используются, их нужно удалить. Это автоматически очистит таблицы регистрации изменений, если связь метаданных еще сохранена.
Многие пользователи пытаются решить проблему через Shrink в SQL Server, но не получают результата. Проанализируем причину: операция Shrink уменьшает физический размер файлов базы данных, высвобождая только неиспользованное (пустое) пространство. Поскольку «фантомные» таблицы заполнены записями изменений, SQL считает это пространство занятым. Сжатие станет эффективным только после того, как таблицы будут удалены или очищены.
Чтобы избежать подобного разрастания в будущем, рекомендуем придерживаться следующих правил:
Таким образом, мы выяснили, что основная причина появления «невидимых» для 1С таблиц заключается в рассинхронизации физической схемы базы данных и описания объектов в конфигурации. Метод выгрузки/загрузки через .dt остается эталонным способом приведения базы в порядок.