"Журнал транзакций для базы данных "YourDb" переполнен"

Порядок действий

1. Прочитайте хвост сообщения. После “due to” (в русской локализации “из-за”) SQL Server уже назвал причину. Если в тексте стоит tempdb, вам на другую страницу: ошибка 9002 в tempdb. Если имя рабочей базы, идём дальше.

2. Снимите диагноз двумя запросами. Первый покажет модель восстановления и держателя, второй - сколько процентов журнала занято по каждой базе экземпляра.

-- что мешает переиспользовать журнал
SELECT name, recovery_model_desc, log_reuse_wait_desc
FROM sys.databases
WHERE name = 'YourDb';

-- размер журнала и процент заполнения по всем базам
DBCC SQLPERF(LOGSPACE);

3. При LOG_BACKUP сделайте копию журнала прямо сейчас, на диск, где есть место. Сразу после неё место внутри файла освободится.

-- разовая копия журнала, место внутри .ldf освободится после неё
BACKUP LOG [YourDb]
TO DISK = N'E:\Backup\YourDb_log_01.trn';

Потом поставьте копии журнала в план обслуживания с шагом 15-60 минут или осознанно перейдите на SIMPLE (см. вопросы ниже).

4. При ACTIVE_TRANSACTION ищите сеанс-держатель.

-- самая старая открытая транзакция в базе
DBCC OPENTRAN ('YourDb');

-- все открытые транзакции базы с сеансами, старые сверху
SELECT s.session_id, s.login_name, s.host_name, s.program_name,
       t.transaction_begin_time
FROM sys.dm_tran_database_transactions dt
JOIN sys.dm_tran_active_transactions t ON t.transaction_id = dt.transaction_id
JOIN sys.dm_tran_session_transactions st ON st.transaction_id = dt.transaction_id
JOIN sys.dm_exec_sessions s ON s.session_id = st.session_id
WHERE dt.database_id = DB_ID('YourDb')
ORDER BY t.transaction_begin_time;

В host_name для 1С окажется сервер приложений srv1c: в СУБД ходят рабочие процессы, а не компьютеры пользователей. Человека ищут по журналу регистрации. Без доступа к SQL Server это делает обработка “Диагностика журнала транзакций”: называет держателя по имени и компьютеру и печатает скрипт для администратора. Сеанс завершают в консоли кластера 1С, KILL на стороне SQL - крайняя мера: откат идёт почти столько же, сколько жила транзакция.

5. Нужна минута форы, а диск забит? Добавьте второй файл журнала на другой диск, когда причина снята - уберите его через REMOVE FILE.

-- временный второй файл журнала на другом диске
ALTER DATABASE [YourDb]
ADD LOG FILE (NAME = YourDb_log2, FILENAME = N'F:\SQLLog\YourDb_log2.ldf',
              SIZE = 4GB, FILEGROWTH = 1GB);

6. Журнал снова переиспользуется - один раз сожмите файл и задайте приращение в мегабайтах. Мелкий шаг дробит журнал на тысячи VLF и тормозит старт базы.

USE [YourDb];
-- целевой размер в мегабайтах, с запасом под обычную нагрузку
DBCC SHRINKFILE (YourDb_log, 8192);

ALTER DATABASE [YourDb]
MODIFY FILE (NAME = YourDb_log, FILEGROWTH = 1GB);

Как проверить, что исправлено

• Запрос из шага 2 показывает NOTHING или LOG_BACKUP, который сбрасывается после каждой копии журнала.
• Процент в DBCC SQLPERF(LOGSPACE) падает после бэкапа журнала.
• Документ в 1С проводится, обмен проходит без ошибки СУБД.
• Через неделю .ldf того же размера, что после шринка. Растёт - причина не снята, назад к шагу 2.

Чтобы не встретить её снова

Переполнение с ровным шагом, раз в неделю, означает FULL без копий журнала. Внезапное посреди дня - чью-то длинную транзакцию. Модель восстановления, размер и приращение журнала с вердиктом по каждому пункту проверяет чек-ап СУБД под 1С.