Проблема стремительного роста информационной базы — одна из самых актуальных для администраторов 1С, особенно когда речь идет о таких насыщенных данными конфигурациях, как 1С:Документооборот КОРП. Когда база начинает "весить" сотни гигабайт, возникают сложности с резервным копированием, падением производительности и нехваткой дискового пространства. Рассмотрим подробно, как провести полноценное "расследование" и найти скрытые источники потребления места.
Прежде чем приступать к очистке, нам необходимо точно выяснить, какие именно объекты занимают больше всего места. Разберем два основных способа получения этой информации.
Во-первых, проанализируем базу на уровне SQL-сервера. Поскольку имена таблиц в СУБД для 1С имеют зашифрованный вид (например, _InfoRg1234 или _Document56), нам потребуется сопоставить их с реальными объектами метаданных. Для получения списка самых тяжелых таблиц в SQL Management Studio (SSMS) можно запустить следующий запрос:
SELECT
t.NAME AS TableName,
p.rows AS RowCounts,
SUM(a.total_pages) * 8 AS TotalSpaceKB,
SUM(a.used_pages) * 8 AS UsedSpaceKB,
(SUM(a.total_pages) - SUM(a.used_pages)) * 8 AS UnusedSpaceKB
FROM
sys.tables t
INNER JOIN
sys.indexes i ON t.OBJECT_ID = i.object_id
INNER JOIN
sys.partitions p ON i.object_id = p.object_id AND i.index_id = p.index_id
INNER JOIN
sys.allocation_units a ON p.partition_id = a.container_id
GROUP BY
t.Name, p.Rows
ORDER BY
TotalSpaceKB DESC
Во-вторых, воспользуемся программными методами 1С. Разберем по шагам, как получить расшифровку этих таблиц. В платформе 1С существует метод ПолучитьСтруктуруХраненияБазыДанных(), который возвращает соответствие имен таблиц в SQL и имен объектов в конфигураторе. Проанализируем пример кода для получения этого списка:
СтруктураХранения = ПолучитьСтруктуруХраненияБазыДанных();
Для Каждого Таблица Из СтруктураХранения Цикл
Сообщить("Объект 1С: " + Таблица.ИмяМетаданных + " -> Таблица СУБД: " + Таблица.ИмяТаблицыХранения);
КонецЦикла;
Для тех, кто предпочитает готовые инструменты, существует известная обработка "Базопузомер". Она позволяет визуализировать распределение веса базы по справочникам, документам и регистрам в удобном интерфейсе.
Выясним главную причину роста в 1С:Документооборот. По умолчанию файлы (сканы, документы MS Office) часто сохраняются непосредственно в базе данных. Это приводит к раздуванию таблицы Files. Посмотрим, почему это критично: хранение двоичных данных в SQL делает базу неповоротливой и затрудняет обслуживание индексов.
Решение: Настроим хранение файлов в томах на диске. Рассмотрим процедуру переноса:
Проанализируем ситуацию, когда файлы уже вынесены, но база продолжает расти. В 1С:Документооборот включен механизм версионирования. При каждом изменении карточки документа или процесса система создает новую запись в регистре сведений. Если пользователи активно редактируют объекты, регистр _InfoRg (версии объектов) может стать гигантским.
Разберем, как оптимизировать этот процесс. Необходимо зайти в настройки версионирования и установить сроки хранения (например, хранить версии только за последние 6 месяцев). Также стоит отключить версионирование для тех справочников, изменения в которых не критичны для бизнеса.
Если ваша база синхронизируется с другими конфигурациями (например, с 1С:Бухгалтерией), источником роста могут стать таблицы регистрации изменений. Рассмотрим сценарий: обмен по какой-то причине перестал работать или один из узлов плана обмена был удален некорректно. В этом случае 1С будет бесконечно накапливать ссылки на измененные объекты в специальных служебных таблицах, ожидая успешной выгрузки.
Проанализируем количество зарегистрированных изменений в мониторе обмена данными. Если вы видите миллионы записей, которые не уходят — это и есть причина разрастания базы. Очистка регистрации для неактивных узлов мгновенно высвободит место.
Выясним влияние системных механизмов платформы 8.3. К ним относятся:
Не забудем про очевидные, но важные вещи. Проанализируем Журнал регистрации. В современных версиях 1С он хранится в формате SQLite (файл 1Cv8.lgd), но при определенных настройках он может находиться и внутри базы. Регулярно выполняйте сокращение журнала регистрации через конфигуратор, удаляя записи старше года.
Что касается SQL-сервера, проанализируем LDF-файл (Лог транзакций). Если база работает в модели восстановления Full, лог транзакций будет расти бесконечно, пока не будет сделан бэкап лога. Если вам не нужна возможность восстановления на любую секунду времени, переключите модель восстановления в Simple.
В "Документообороте" сотни тысяч завершенных бизнес-процессов (согласования, ознакомления) остаются в базе навсегда. Проанализируем возможность архивации. Завершенные задачи прошлых лет можно переносить в архивную базу или удалять после согласования с юридическим отделом. Используйте типовые обработки по удалению помеченных объектов для очистки старых процессов и связанных с ними задач.
Подведем итог: Для эффективного контроля размера базы 1С необходимо регулярно проверять структуру хранения данных через SQL-запросы, выносить файлы во внешние хранилища, следить за глубиной хранения версий объектов и своевременно обслуживать индексы и лог транзакций СУБД. Совместное применение этих мер позволит держать объем информационной базы в разумных пределах.