Обработка на Инфостарте
Учёт встал, на экране native=9002
Журнал транзакций переполнился. До SQL Server у вас доступа нет, администратор недоступен, а бухгалтерия ждёт. Первые минуты решают.
Обработка платная, 10 SM. Она нужна в момент аварии, когда доступа к SQL Server нет. Почему журнал переполняется регулярно и что с этим делать по существу - в разделе блога про журнал транзакций и ошибку 9002.
Ошибка 9002 останавливает работу целиком: не проводятся документы, не идут обмены, не выполняются регламентные задания. При этом сама 1С про причину говорит одно слово, а всё остальное лежит на стороне СУБД, куда 1С-ника на дежурстве обычно не пускают.
Обработка отвечает на три вопроса за минуту: какой журнал упёрся, что мешает ему очиститься и кто его заполняет. Последнее - по имени пользователя и компьютеру, прямо из журнала регистрации.
К серверу баз данных она не подключается принципиально. Для администратора печатаются восемь готовых скриптов под MS SQL и PostgreSQL, а их результат обработка разбирает сама и выдаёт вердикты.
Положить её в базу имеет смысл до аварии. В момент, когда всё стоит, искать инструмент уже поздно.
Что она показывает без доступа к СУБД
Кто держит длинную транзакцию
Имя пользователя, компьютер, приложение и список объектов. Плюс число незавершённых транзакций и откатов. Длительность считается из журнала регистрации по паре событий начала и конца, поэтому цифра в минутах есть даже там, где к СУБД не подойти.
Ошибки СУБД из журнала регистрации
Переполнение журнала транзакций и таймауты на блокировках, собранные в одном месте.
Что работает прямо сейчас
Фоновые и регламентные задания, включая самое долгое. Сеансы и самый старый из них.
Контекст базы
Файловая или клиент-серверная, версия платформы, режим блокировок и что из него следует для tempdb.
Порядок в аварии
- 01
Первая кнопка: посмотреть со стороны 1С
Доступ к серверу баз данных не нужен. Часто уже здесь видно виновника: длинная транзакция с конкретным пользователем.
- 02
Отдать скрипт администратору
Обработка печатает готовый скрипт под вашу СУБД. Администратор выполняет его и возвращает вывод.
- 03
Вставить результат обратно
Разбор идёт автоматически: обработка переводит вывод СУБД в вердикты чинить, внимание, норма.
O'zingiz hal qila olmayapsizmi? Yozing, birga ko'ramiz
Reglament xizmatni shunday sozlaymizki, baza barqaror ishlaydi, bekaplar kafolatli tiklanadi, disklardagi joy esa kutilmaganda tugab qolmaydi.
- Narxi
- 450 000 ₸ danbir martalik sozlash; kuzatib borish - oyiga 150 000 ₸ dan; soliqlarsiz
Mavzu boyicha tahlillar
"tempdb is full": ошибка 9002 в 1С - тушим за пять минут и убираем навсегда
Посреди рабочего дня у всех разом выпадает "Ошибка СУБД" про tempdb и транзакции - и работа встаёт. В сообщении уже есть весь диагноз, если прочитать его по частям. Разбираем, почему журнал служебной базы tempdb переполняется даже на мощном сервере, как тремя командами за пять минут найти держателя журнала и как настроить tempdb и код, чтобы 9002 не возвращалась.
Журнал транзакций 1С разросся: почему и что делать
Файл LDF раздулся до сотен гигабайт и забил диск, а шринк помогает лишь на неделю. Разбираем настоящую причину - модель восстановления FULL без бэкапов журнала - и как лечить правильно, не потеряв возможность восстановления.
Ko'p so'raladigan savollar
Зачем вообще ограничивать рост журнала, если есть мониторинг свободного места?
Чтобы авария была локальной. С потолком переполнится и встанет одна база с понятной ошибкой native=9002, без него журнал растёт, пока не кончится место на всём диске, где обычно живут и tempdb, и соседние базы. Мониторинг это не отменяет, но потолок срабатывает сам, когда на ночной алерт никто не успел.
Обработка подключается к SQL Server и что-то в нём меняет?
Нет. К серверу баз данных она не подключается принципиально: снимает всё, что видно со стороны платформы, и печатает готовый скрипт для администратора. Скрипты только читают системные представления, ничего в базе и настройках СУБД не меняется, сеансы не завершаются.
Откуда она знает длительность транзакций, если не видит СУБД?
Из журнала регистрации. Идентификатор транзакции в нём уже содержит момент старта, конец берётся по последней записи этой транзакции. Поэтому длительность считается даже когда события Транзакция.Начало в настройках журнала выключены.
Нашли держателя журнала. Его убивать?
По возможности нет. Если процесс легитимный и близок к финалу, дешевле подождать; если ждать нельзя, завершать сеанс штатно через консоль кластера 1С, а KILL на стороне SQL это крайняя мера. Откат длинной транзакции занимает время, сравнимое с её жизнью, и журнал всё это время ещё нужен.
Файл журнала огромный, а сжатие его не уменьшает. Почему?
Сжимать надо не файл, а причину. Пока журнал не стал переиспользуемым, DBCC SHRINKFILE честно отработает и не уменьшит ничего. Сначала снимается держатель - транзакция, бэкап журнала или отставшая реплика, - и только потом сжимается файл, с запасом, а не в ноль.
У нас PostgreSQL или файловая база - подойдёт?
Для PostgreSQL симптом тот же, а держатели свои: выбираете PostgreSQL в поле СУБД, и библиотека скриптов меняется на диагностику pg_wal. У файловой базы журнала транзакций СУБД нет вовсе, и обработка честно говорит об этом первой строкой вместо бессмысленных вердиктов.
1C tizimingiz uchun bepul ekspress-audit
1-2 kun ichida bazangizni ko'rib chiqamiz, unumdorlik qayerda yo'qolayotganini topamiz va nima qilish kerakligini aytamiz. Majburiyatsiz.
Vazifani muhokama qilamiz
Eng tezi WhatsApp: vazifa haqida bir-ikki qator yozing, ish kuni davomida javob beramiz.