Обработка на Инфостарте
Учёт встал, на экране native=9002
Журнал транзакций переполнился. До SQL Server у вас доступа нет, администратор недоступен, а бухгалтерия ждёт. Первые минуты решают.
Обработка платная, 10 SM. Она нужна в момент аварии, когда доступа к SQL Server нет. Почему журнал переполняется регулярно и что с этим делать по существу - в разделе блога про журнал транзакций и ошибку 9002.
Ошибка 9002 останавливает работу целиком: не проводятся документы, не идут обмены, не выполняются регламентные задания. При этом сама 1С про причину говорит одно слово, а всё остальное лежит на стороне СУБД, куда 1С-ника на дежурстве обычно не пускают.
Обработка отвечает на три вопроса за минуту: какой журнал упёрся, что мешает ему очиститься и кто его заполняет. Последнее - по имени пользователя и компьютеру, прямо из журнала регистрации.
К серверу баз данных она не подключается принципиально. Для администратора печатаются восемь готовых скриптов под MS SQL и PostgreSQL, а их результат обработка разбирает сама и выдаёт вердикты.
Положить её в базу имеет смысл до аварии. В момент, когда всё стоит, искать инструмент уже поздно.
Что она показывает без доступа к СУБД
Кто держит длинную транзакцию
Имя пользователя, компьютер, приложение и список объектов. Плюс число незавершённых транзакций и откатов. Длительность считается из журнала регистрации по паре событий начала и конца, поэтому цифра в минутах есть даже там, где к СУБД не подойти.
Ошибки СУБД из журнала регистрации
Переполнение журнала транзакций и таймауты на блокировках, собранные в одном месте.
Что работает прямо сейчас
Фоновые и регламентные задания, включая самое долгое. Сеансы и самый старый из них.
Контекст базы
Файловая или клиент-серверная, версия платформы, режим блокировок и что из него следует для tempdb.
Порядок в аварии
- 01
Первая кнопка: посмотреть со стороны 1С
Доступ к серверу баз данных не нужен. Часто уже здесь видно виновника: длинная транзакция с конкретным пользователем.
- 02
Отдать скрипт администратору
Обработка печатает готовый скрипт под вашу СУБД. Администратор выполняет его и возвращает вывод.
- 03
Вставить результат обратно
Разбор идёт автоматически: обработка переводит вывод СУБД в вердикты чинить, внимание, норма.
Не получается самим? Напишите, разберёмся
Настроим регламентное обслуживание так, чтобы база работала стабильно, бэкапы гарантированно восстанавливались, а диски не кончались внезапно.
- Стоимость
- 450 000 - 600 000 ₸ТЗ и разовая наладка, без налогов; сопровождение - от 150 000 ₸/мес отдельно
Разборы по теме
"tempdb is full": ошибка 9002 в 1С - тушим за пять минут и убираем навсегда
Посреди рабочего дня у всех разом выпадает "Ошибка СУБД" про tempdb и транзакции - и работа встаёт. В сообщении уже есть весь диагноз, если прочитать его по частям. Разбираем, почему журнал служебной базы tempdb переполняется даже на мощном сервере, как тремя командами за пять минут найти держателя журнала и как настроить tempdb и код, чтобы 9002 не возвращалась.
Журнал транзакций 1С разросся: почему и что делать
Файл LDF раздулся до сотен гигабайт и забил диск, а шринк помогает лишь на неделю. Разбираем настоящую причину - модель восстановления FULL без бэкапов журнала - и как лечить правильно, не потеряв возможность восстановления.
Частые вопросы
Зачем вообще ограничивать рост журнала, если есть мониторинг свободного места?
Чтобы авария была локальной. С потолком переполнится и встанет одна база с понятной ошибкой native=9002, без него журнал растёт, пока не кончится место на всём диске, где обычно живут и tempdb, и соседние базы. Мониторинг это не отменяет, но потолок срабатывает сам, когда на ночной алерт никто не успел.
Обработка подключается к SQL Server и что-то в нём меняет?
Нет. К серверу баз данных она не подключается принципиально: снимает всё, что видно со стороны платформы, и печатает готовый скрипт для администратора. Скрипты только читают системные представления, ничего в базе и настройках СУБД не меняется, сеансы не завершаются.
Откуда она знает длительность транзакций, если не видит СУБД?
Из журнала регистрации. Идентификатор транзакции в нём уже содержит момент старта, конец берётся по последней записи этой транзакции. Поэтому длительность считается даже когда события Транзакция.Начало в настройках журнала выключены.
Нашли держателя журнала. Его убивать?
По возможности нет. Если процесс легитимный и близок к финалу, дешевле подождать; если ждать нельзя, завершать сеанс штатно через консоль кластера 1С, а KILL на стороне SQL это крайняя мера. Откат длинной транзакции занимает время, сравнимое с её жизнью, и журнал всё это время ещё нужен.
Файл журнала огромный, а сжатие его не уменьшает. Почему?
Сжимать надо не файл, а причину. Пока журнал не стал переиспользуемым, DBCC SHRINKFILE честно отработает и не уменьшит ничего. Сначала снимается держатель - транзакция, бэкап журнала или отставшая реплика, - и только потом сжимается файл, с запасом, а не в ноль.
У нас PostgreSQL или файловая база - подойдёт?
Для PostgreSQL симптом тот же, а держатели свои: выбираете PostgreSQL в поле СУБД, и библиотека скриптов меняется на диагностику pg_wal. У файловой базы журнала транзакций СУБД нет вовсе, и обработка честно говорит об этом первой строкой вместо бессмысленных вердиктов.
Бесплатный экспресс-аудит вашей 1С
За 1-2 дня посмотрим вашу базу, найдём, где теряется производительность, и скажем, что с этим делать. Без обязательств.
Обсудим задачу
Быстрее всего в WhatsApp: напишите пару строк о задаче, ответим в течение рабочего дня.