← На главную

Многие администраторы 1С при миграции с MS SQL Server на PostgreSQL сталкиваются с неприятным сюрпризом: после разворачивания файла .dt размер базы данных на диске увеличивается в разы. В данной статье мы разберем, почему это происходит, как диагностировать проблему и какие действия предпринять для оптимизации дискового пространства.

Анализ причин раздувания базы

Основная причина кроется в фундаментальных различиях архитектуры СУБД. В отличие от MS SQL, PostgreSQL использует механизм многоверсионности данных (MVCC). При любом обновлении записи PostgreSQL создает новую версию строки, а старую помечает как «мертвую». До тех пор, пока не отработает процесс VACUUM, эти записи физически занимают место на диске.

Также важно учитывать структуру индексов. В PostgreSQL индексы для таблиц _inforg (регистры сведений) и других объектов конфигурации часто занимают значительно больше места, чем в MS SQL. Это связано с тем, как платформа 1С формирует запросы и как PostgreSQL хранит индексные структуры.

Диагностика проблемных таблиц

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

1. Выполним SQL-запрос к системным таблицам PostgreSQL для получения списка самых «тяжелых» таблиц и индексов.
2. Идентифицируем регистр сведений или накопления, соответствующий идентификатору _inforgXXXX. Для этого можно воспользоваться штатными отчетами «Таблицы информационной базы» или специализированными внешними обработками с портала 1С.
3. Проверим количество записей в проблемной таблице. Иногда причиной роста является некорректная логика работы расширений или накопление «мусорных» данных в регистрах сведений с периодичностью.

Методы оптимизации и обслуживания

Разберем способы, которые помогут вернуть часть дискового пространства и нормализовать работу базы.

1. Регулярное обслуживание через VACUUM

Для PostgreSQL критически важно настроить процесс автоматической очистки (autovacuum). Если стандартных настроек недостаточно для ваших объемов данных, следует увеличить агрессивность очистки для таблиц-гигантов. Если же база уже достигла критического размера, необходимо запланировать технологическое окно и выполнить VACUUM FULL.

Внимание: VACUUM FULL требует монопольной блокировки таблицы, что означает полную недоступность базы для пользователей на время выполнения операции. Учитывайте это при планировании работ.

2. Перестроение индексов

Если индекс раздут сильнее, чем сама таблица, эффективным методом будет его пересоздание. Для этого в PostgreSQL предусмотрена команда REINDEX INDEX CONCURRENTLY. Она позволяет перестроить индекс без блокировки таблицы, что позволяет избежать остановки работы системы.

3. Тестирование и исправление

Иногда раздувание базы вызвано логическими ошибками в данных, которые приводят к бесконечному циклу реструктуризации или записи избыточной информации. Запустите «Тестирование и исправление» в режиме Конфигуратора, выбрав проверку логической и ссылочной целостности. Это поможет очистить базу от «битых» записей.

Рекомендации по профилактике

Для предотвращения подобных ситуаций в будущем рекомендуем придерживаться следующих правил:

• Следите за тем, чтобы в регистрах сведений не накапливались лишние данные. Если регистр используется как временное хранилище или кэш, настройте регламентное задание по очистке устаревших записей.
• При использовании расширений конфигурации проверяйте, не создают ли они дополнительные периодические регистры, которые дублируют данные основной конфигурации.
• Регулярно анализируйте показатели bloat (раздувания) таблиц с помощью SQL-скриптов, чтобы вовремя принимать меры, а не доводить базу до критического состояния.

Помните, что переход на PostgreSQL требует иного подхода к администрированию СУБД, чем привычная работа с MS SQL. Основное внимание стоит уделять настройке autovacuum и своевременному обслуживанию индексов.