Как исправить ошибку при сжатии базы данных MS SQL Server в 1С?

При обслуживании больших информационных баз 1С на базе MS SQL Server системные администраторы часто сталкиваются со ситуацией, когда штатная операция сжатия базы данных (Shrink Database) завершается аварийно или выдает ошибку по таймауту. Особенно остро эта проблема проявляется при ограниченном свободном месте на диске хранилища.

Рассмотрим причины возникновения этой проблемы и разберем эффективные способы ее обхода с использованием инструментов SQL Server Management Studio (SSMS) и команд T-SQL.

Выясним причины сбоя при сжатии базы данных

Проанализируем основные факторы, которые мешают выполнению сжатия в графическом интерфейсе SQL Server Management Studio:

1. Таймаут подключения клиентского приложения. Запуск сжатия через графический мастер интерактивного интерфейса ограничен внутренним временем ожидания выполнения команды со стороны клиента. При больших объемах данных база не успевает обработать все экстенты, и клиент выдает ошибку по истечении времени ожидания.
2. Нехватка дискового пространства для журнала транзакций. Процесс перемещения страниц данных с конца файла в начало является полностью журналируемой транзакцией. При сильном дефиците свободного места файл журнала транзакций (.ldf) стремительно разрастается и заполняет оставшийся диск, что приводит к остановке операции.
3. Блокировки активными транзакциями. Если в базе находятся незавершенные пользовательские сеансы или фоновые задания 1С, они удерживают блокировки на таблицы, препятствуя освобождению физических страниц.

Обход ошибки через выполнение T-SQL сценария

Чтобы избежать отмены операции по таймауту графического интерфейса, выполним сжатие путем непосредственного запуска T-SQL скрипта в окне запроса. Это позволит серверу выполнять задачу в фоновом режиме без ограничений клиентского таймера.

Разберем алгоритм получения и запуска скрипта по шагам:

1. Откроем SQL Server Management Studio и подключимся к экземпляру сервера.
2. В дереве объектов вызовем контекстное меню для нужной базы данных и перейдем в раздел Задачи (Tasks) > Сжать (Shrink) > База данных (Database) или Файлы (Files).
3. В верхней части открывшегося окна мастера нажмем кнопку Сценарий (Script) и выберем действие Сценарий в новое окно запроса (Script Action to New Query Window).
4. Закроем окно диалога мастера. В открывшемся окне редактора запросов появится автоматически сгенерированная команда SQL.
5. Нажмем кнопку Выполнить (Execute) для запуска запроса.

Сжатие отдельных файлов базы данных вместо базы целиком

Попытка сжать сразу всю базу данных зачастую не приносит результата, так как операция пытается обработать данные и журнал единым блоком. Посмотрим на альтернативный подход: выполнение сжатия для конкретных файлов — файла данных (.mdf) и файла журнала (.ldf) по отдельности.

В окне сжатия файлов выберем тип файла Данные (Data). Чтобы сервер выполнил реорганизацию страниц с перемещением их в начало файла, установим переключатель в положение Реорганизовать страницы перед освобождением неиспользуемого места (Reorganize pages before releasing unused space) и зададим желаемый целевой размер.

Пошаговое сжатие с помощью T-SQL команд

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

Рассмотрим варианты команд DBCC SHRINKFILE:

1. Мгновенная обрезка неиспользуемого пространства в конце файла (TRUNCATEONLY)
Данный режим не перемещает страницы данных внутри файла, за счет чего выполняется мгновенно и не выказывает нагрузки на журнал транзакций:

-- Мгновенная обрезка файла данных без перемещения страниц
DBCC SHRINKFILE (Имя_Логического_Файла, TRUNCATEONLY);

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

-- Перевод базы в простую модель восстановления для минимизации роста журнала
ALTER DATABASE [Имя_Базы] SET RECOVERY SIMPLE;

-- Порционное сжатие файла данных до 40000 МБ
DBCC SHRINKFILE (Имя_Логического_Файла, 40000);

-- Сжатие файла журнала транзакций до минимального размера
DBCC SHRINKFILE (Имя_Логического_Файла_Лога, 1);

Для узнавания точного логического имени файла выполним системный запрос sp_helpfile или посмотрим свойства файла в консоли SSMS.

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

Проанализируем важные нюансы, которые следует учитывать при проведении сжатия:

• Фрагментация индексов. Механизм сжатия перемещает страницы хаотично, что вызывает критическую фрагментацию индексов 1С (до 90–99%). После сжатия рекомендуется выполнить обслуживание индексов (Reindex/Rebuild), однако стоит иметь в виду, что перестроение индексов заново увеличит файл базы.
• Очистка кэша планов. При возникновении технических задержек перед сжатием можно выполнить сброс процедурного кэша SQL Server вызовом DBCC FREEPROCCACHE.
• Завершение сеансов. Перед выполнением процедур оптимизации убедимся, что в базе 1С отсутствуют активные пользовательские соединения и запущенные регламентные задания.