При работе с крупными базами данных, такими как 1С:ERP 2.1, системные администраторы часто сталкиваются с ситуацией, когда файлы бэкапа журнала транзакций (.trn) внезапно вырастают с нескольких мегабайт до гигабайт. Помочь в анализе распределения места может SQL Базомер. Это не только занимает дисковое пространство, но и может привести к полной остановке работы из-за переполнения диска с архивами или самим файлом .ldf. Чтобы заранее предусмотреть нужные объемы, стоит использовать калькулятор железа для 1C. Проанализируем причины этого явления и разберем пошаговые методы решения проблемы.
Прежде чем предпринимать активные действия, нам необходимо понять, что именно мешает SQL Server очистить журнал после выполнения бэкапа. Даже в модели восстановления FULL при выполнении бэкапа лога (Transaction Log Backup) неиспользуемая часть журнала должна помечаться как свободная. Если этого не происходит, значит, есть активный процесс, удерживающий транзакции.
Для диагностики выполним следующий запрос в SQL Server Management Studio (SSMS):
SELECT name, log_reuse_wait_desc
FROM sys.databases
WHERE name = 'Имя_Вашей_Базы';
Рассмотрим основные значения в колонке log_reuse_wait_desc, которые мы можем увидеть. Сопоставить SQL-таблицы с объектами метаданных поможет отчет Свойства объектов 1С в MS SQL.
Одной из наиболее частых причин резкого роста журнала (как самого файла, так и его бэкапов) является реорганизация или перестроение индексов. Проанализируем ситуацию: если в базе данных на SSD-дисках настроено частое перестроение индексов (Index Rebuild), SQL Server записывает все изменения структуры таблиц в лог.
Рассмотрим пример: если фрагментация индекса превышает 30%, запускается ALTER INDEX REBUILD. На SSD дисках фрагментация может расти очень быстро, и если план обслуживания запускает перестроение ежедневно, объем бэкапа журнала будет сопоставим с объемом самих данных в таблицах. В случае с 1С:ERP после обновления конфигурации структура многих таблиц меняется, что провоцирует массовое перестроение индексов.
Решение: Попробуйте временно отключить или смягчить регламентные задания по обслуживанию индексов в плане обслуживания SQL Server. На производительность SSD-дисков фрагментация влияет значительно меньше, чем на HDD, поэтому агрессивное перестроение часто не оправдано.
Бывает так, что в базе никогда не настраивалась репликация, но статус log_reuse_wait_desc показывает REPLICATION. Это часто случается при восстановлении базы из бэкапа или при использовании механизмов распределенных баз данных (РИБ) 1С. SQL Server считает, что часть транзакций должна быть прочитана агентом чтения лога, и не позволяет их затереть.
Если мы столкнулись с такой ситуацией, выполним следующие шаги по принудительной очистке метаданных репликации:
USE [Имя_Вашей_Базы]
GO
EXEC sp_repldone @xactid = NULL, @xact_segno = NULL, @numtrans = 0, @time = 0, @reset = 1
GO
EXEC sp_removedbreplication 'Имя_Вашей_Базы'
GO
После этих действий необходимо выполнить полный бэкап базы данных и бэкап журнала транзакций.
Иногда причиной роста становится «зависший» сеанс пользователя или фоновое задание 1С. Рассмотрим ситуацию: пользователь начал проводить тяжелый документ или формировать отчет с записью в таблицу, и сеанс прервался (например, из-за сетевого сбоя), но SQL-транзакция осталась открытой. Пока она активна, SQL Server не может очистить журнал транзакций начиная с момента старта этой транзакции.
Выясним причину с помощью команды:
DBCC OPENTRAN ('Имя_Вашей_Базы');
Если команда вернула Transaction information... с указанием SPID, нам нужно найти этот процесс в списке активных соединений и проанализировать его. Если это старое зависшее соединение, его можно завершить командой KILL [SPID].
В ERP 2.1 активно используются механизмы, которые генерируют огромный поток транзакций. Проанализируем два основных:
ОбновлениеИндексаППД выполняется слишком часто при большом объеме изменений, оно постоянно дописывает данные в системные таблицы, что раздувает лог.ИсторияДанных, то каждое изменение записывается дважды.Разберем, как это проверить. В консоли 1С посмотрим на регламентные задания. Если мы видим, что после обновления конфигурации задания ОчисткаНенужныхФайлов или СжатиеТаблиц работают часами, именно они могут быть источником «гигабайтных» бэкапов лога.
Если файл .ldf рос мелкими порциями (например, по 10-50 Мб), внутри него образуется огромное количество VLF. Это замедляет процесс создания бэкапа журнала. Разберем правильный алгоритм приведения лога в порядок:
Подводя итог, если вы столкнулись с аномальным ростом бэкапов лога, действуйте по схеме:
log_reuse_wait_desc на предмет REPLICATION или ACTIVE_TRANSACTION.REBUILD).Помните, что после любых манипуляций с моделью восстановления (переход с FULL на SIMPLE и обратно) цепочка бэкапов прерывается, и нужно обязательно сделать новый Full Backup базы.