На экране The transaction log for database 'tempdb' is full due to 'ACTIVE_TRANSACTION' ... native=9002. Учёт стоит, в чате спрашивают, когда заработает, доступа к SQL Server у вас нет, а админ на обеде. Обработка отвечает на три вопроса за минуту: какой журнал упёрся, что мешает ему очиститься и кто его держит.
Что она делает со стороны 1С
Первая кнопка, доступ к серверу баз данных не нужен. Обработка читает журнал регистрации и показывает:
- самые длинные транзакции с именем пользователя, компьютером, приложением и списком объектов, плюс число незавершённых и откатов;
- ошибки СУБД из журнала: переполнение журнала транзакций и таймауты на блокировках;
- фоновые и регламентные задания: что работает прямо сейчас и дольше всех;
- сеансы: сколько их и какой самый старый;
- саму базу: файловая или клиент-серверная, платформа, режим блокировок и что из него следует для tempdb.
Длительность транзакции берётся из журнала регистрации по паре событий начала и конца, поэтому цифра в минутах есть даже там, где к СУБД не подойти.
Что она делает со стороны СУБД
К серверу баз данных обработка не подключается принципиально: у 1С-ника на дежурстве такого доступа обычно нет и не будет. Вместо этого она печатает готовый скрипт, его выполняет администратор, а результат вставляется обратно в поле и разбирается.
Восемь скриптов: пять для MS SQL и три для PostgreSQL. В списке видны скрипты только выбранной СУБД, переключатель СУБД меняет список целиком.
- MS SQL: полная диагностика журнала (занятость,
log_reuse_wait_desc, файлы и потолки, модель восстановления и бэкапы, tempdb, место на диске), кто держит журнал прямо сейчас, что реально уменьшит файл журнала, настройка tempdb, история ошибок 9002 в логе сервера; - PostgreSQL: полная диагностика pg_wal (размер каталога, слоты, архивация, prepared, долгие транзакции), долгие транзакции и кто держит xmin, что реально уменьшит pg_wal.
Скрипт про уменьшение файла ничего не выполняет, он печатает команды под конкретный случай. Выполнять или нет, решает человек.
Разбор не пересказывает результат, а выносит вердикт по каждому показателю: чинить, внимание или норма. Сначала то, что чинить. У каждой строки написано, что это значит и чем грозит, если оставить как есть.
Ничего не меняет
Обработка только читает. Она не завершает сеансы, не убивает транзакции, не трогает настройки базы и СУБД. Скрипты для администратора помечены отдельно: диагностические читают служебную информацию, аварийные меняют состояние, и что именно они сделают, написано прямо в тексте скрипта.
На чём проверялась
- живая база 1С:Управление торговлей 11.5.22.67, платформа 8.3.27.1606: 10 проверок, журнал регистрации на 46 616 записей, 12 252 транзакции сгруппированы;
- MS SQL Server 2022 (16.0.1000.6) и PostgreSQL 17.9: все восемь скриптов выполнены на живых серверах, блок итога разобран обработкой;
- вердикты прогнаны на синтетических итогах: 16 проверок MS SQL и 9 PostgreSQL, все ветки чинить отработали.
Что в файле
Одна внешняя обработка, две формы: рабочая и частые вопросы. Код открыт. Управляемое приложение, платформа 8.3, конфигурация любая: обработка работает с платформенными объектами и не обращается к прикладным. Скрипты рассчитаны на MS SQL Server 2008 и новее и на PostgreSQL 9.6 и новее, показатели поздних редакций спрятаны так, что отсутствие одного не роняет весь скрипт.
У файловой базы журнала транзакций нет, и обработка честно говорит об этом первой строкой, а не выдаёт бессмысленные вердикты.
Разбор механики
Почему 9002 это не "мало места", чем отличаются LOG_BACKUP и ACTIVE_TRANSACTION, как найти держателя транзакции прямо из журнала регистрации и почему SHRINK не лечение - в статье-спутнике: Журнал транзакций переполнен. Учёт стоит, а доступа к SQL у вас нет.
Проверено на следующих конфигурациях и релизах:
- Управление торговлей, редакция 11, релизы 11.5.22.67
Вступайте в нашу телеграмм-группу Инфостарт