Обработка на Инфостарте · 10 SM
Чёрный ящик SQL Server под 1С: кто занимал tempdb и держал блокировку, когда всё висело
Разбор аварии обычно упирается в перезагрузку: после рестарта SQL Server не помнит, какие запросы шли и сколько tempdb они занимали, а кластер 1С не помнит сеансов. Чёрный ящик снимает эту картину каждую минуту в отдельную базу на том же сервере и держит две недели. Обработка 1С потом открывает любой интервал и пишет рядом с каждым соединением SQL пользователя 1С и базу.
Обработка продаётся на Инфостарте за 10 SM, код открыт. В архиве .epf и скрипты install.sql и uninstall.sql для администратора SQL. MS SQL Server 2016 SP1 - 2022 с SQL Server Agent, платформа 8.3, управляемые формы, сервер 1С под Windows; для имени пользователя нужны БСП и сервер администрирования кластера (RAS). Express, PostgreSQL и файловые базы не поддерживаются.
Когда кассы стоят, никто не садится собирать доказательства. Сервер перезагружают, и вместе с ним уходит всё, что могло назвать виновника: статистика ожиданий и занятость tempdb живут в памяти SQL Server до перезапуска, кластер 1С показывает только текущие сеансы, а технологический журнал часто либо выключен, либо хранится двое суток. Через неделю на вопрос "кто положил tempdb" ответить уже нечем.
Ящик решает это порядком действий: записать до аварии, а не искать после. Задание SQL Server Agent работает внутри самого сервера СУБД, поэтому пишет и тогда, когда сервер 1С не отвечает. Снимки лежат в обычной базе на диске и переживают перезапуск службы.
Отдельная задача - имя человека. SQL Server видит у соединения 1С только номер сеанса и PID рабочего процесса rphost, а на одном rphost сидят сеансы разных баз. Поэтому в обработке есть команда, которая раз в минуту запоминает, какое соединение с СУБД держит каждый сеанс 1С. Разбор сводит два снимка и вместо безымянного номера показывает пользователя, базу, тип клиента и номер сеанса 1С.
Что записывается и что показывает разбор
tempdb по каждому сеансу
Сколько занимают временные таблицы и внутренние объекты: и у запросов, которые идут сейчас, и у сеансов, которые держат временные таблицы между запросами. Именно второй случай чаще всего и съедает tempdb незаметно.
Блокировки и долгие транзакции
Кто кого ждал и сколько, транзакции дольше минуты с объёмом журнала. Брошенная транзакция с нулевой нагрузкой в топ по процессору не попадает, а здесь видна.
Долгие запросы с текстом и планом
Текст запроса и ожидание, у запросов дольше 10 секунд ещё и план. Тексты и планы хранятся один раз на хеш, повторы места не занимают.
Ожидания, файлы, диски, память
Прирост ожиданий сервера и задержек файлов за минуту, выданная запросам память, свободное место на томах. Снимок сразу после перезапуска SQL Server приросты не пишет, чтобы не было ложных пиков.
Главное за период
Кнопка "Сутки" или свой интервал: одним блоком кто больше всех занял tempdb, кто дольше всех держал блокировку, самая долгая транзакция и первая тревога. Ниже подробные таблицы по каждому разделу.
Тревоги до того, как позвонят с касс
Порог на tempdb всего и на один сеанс, мало места на диске, долгая блокировка, долгая транзакция, давно не было бэкапа. Тревога пишется в таблицу и уходит письмом через Database Mail, если он настроен. Повтор не чаще раза в 30 минут.
Прогон на нашем стенде
SQL Server 2022 Standard на 12 ядрах с SQL Agent, кластер 1С 8.3.27 с одним рабочим процессом, тестовая копия УТ 11.5. Аварии устроены искусственно: транзакция держит строку и раздувает tempdb, второй сеанс ждёт её блокировку. 30 прогонов задания подряд, время пишет сама процедура снимка.
| Показатель | Значение | Как надо | Вердикт | Что это значит |
|---|---|---|---|---|
| Длительность снимка | 166 мс | до 1 с | норма | среднее за 30 прогонов, максимум 273 мс |
| Нагрузка на процессор | 0,02 % | - | норма | 160 мс процессора раз в минуту на сервере с 12 ядрами |
| Рост базы снимков в покое | около 1,7 МБ в сутки | - | инфо | 954 снимка за 15 ч 44 мин заняли 1,1 МБ; файлы базы при установке сразу 320 МБ, место выделяется заранее |
| Авария 1: tempdb одним сеансом | 480 МБ | порог 100 МБ | чинить | разбор назвал пользователя 1С, базу и номер сеанса; тревога записана в ту же минуту |
| Авария 1: блокировка | 81 с | порог 30 с | чинить | держатель с именем пользователя 1С, жертва ждала разделяемую блокировку все 81 секунду |
| Авария 2: брошенная транзакция без записи сеансов 1С | 3 мин | порог 2 мин | внимание | имени нет, разбор честно пишет PID рабочего процесса и "сеанс 1С в снимках не найден" |
Разбор результата
Снимок стоит серверу меньше одной пятисотой процессора и килобайты в минуту. Обе искусственные аварии записаны с первой минуты, и там, где сеансы 1С писались, разбор назвал человека. Второй прогон показал, зачем нужна осторожность: rphost держит соединения пулом, и первая сборка приписала брошенную транзакцию чужому сеансу с тем же номером SQL. Теперь сопоставление идёт только внутри одного эпизода захвата соединения, а без данных разбор пишет, что сеанс не найден, и имени не выдумывает.
Как поставить
- 01
Собрать скрипт установки
На вкладке "Установка" задать пороги тревог, срок хранения и учётную запись службы 1С. Обработка соберёт скрипт и сохранит его в файл.
- 02
Отдать администратору SQL
Скрипт выполняется один раз под учётной записью с правами sysadmin. Он заводит базу снимков, задание раз в минуту и роль только для чтения снимков. Повторный запуск историю не стирает.
- 03
Включить запись сеансов 1С
Подключить обработку как дополнительную через БСП и поставить команду "Записать сеансы 1С" по расписанию раз в минуту. Без этого шага ящик тоже работает, но вместо имени пользователя покажет PID рабочего процесса.
- 04
Разобрать период
Вписать сервер SQL, нажать "Сутки" или задать интервал аварии. Первым блоком идёт главное за период, ниже таблицы.
Özünüz həll edə bilmirsiniz? Yazın, birlikdə baxaq
1C klasteri və VBİS üzrə Grafana dashboardları, problem zamanı Telegram-a alertlər. Nasazlığı istifadəçilərdən əvvəl bilirsiniz - deqradasiyanı isə qəzadan həftələr öncə görürsünüz.
- Qiyməti
- 450 000 ₸-dəntam tətbiq; vergilərsiz
Mövzu üzrə təhlillər
1С висела, серверы перезагрузили: какие следы аварии остались и сколько они живут
После перезагрузки SQL Server и кластера 1С большая часть улик пропадает сразу, остальная через дни. Разбираем по источникам, что где хранится и когда стирается, что успеть сохранить за две минуты до рестарта, как по журналу регистрации доказать, что беда общая для всех баз, как читать события vCenter голым SOAP и что поставить заранее, чтобы следующую аварию было по чему разбирать. Иллюстрация - зависание касс в рознице, где через три недели назвать виновника было уже нечем.
Кто блокирует базу 1С: найти виновника сейчас и восстановить, кто держал ночью
Когда база встаёт, вопрос звучит одинаково: кто её держит. Ответ на него собирается за пять минут тремя способами - консолью кластера, командой rac и запросом к СУБД, и у каждого способа своя слепая зона. Хуже другое: к моменту, когда вы открыли консоль, виновник обычно уже отпустил замок, и на вопрос про ночь снимок текущего момента не отвечает вовсе. Разбираем оба случая: как назвать держателя по имени прямо сейчас и как устроить историю снимков, по которой утром видно, кто держал базу с двух до четырёх.
"tempdb is full": ошибка 9002 в 1С - тушим за пять минут и убираем навсегда
Посреди рабочего дня у всех разом выпадает "Ошибка СУБД" про tempdb и транзакции - и работа встаёт. В сообщении уже есть весь диагноз, если прочитать его по частям. Разбираем, почему журнал служебной базы tempdb переполняется даже на мощном сервере, как тремя командами за пять минут найти держателя журнала и как настроить tempdb и код, чтобы 9002 не возвращалась.
Рядом по теме
Чек-ап СУБД под 1С
Ящик отвечает на вопрос "кто", чек-ап на вопрос "почему так настроено": MAXDOP, порог параллелизма, число файлов tempdb, возраст бэкапов.
Анализ нагрузки кластера 1С
История с другой стороны: процессы, память и сеансы кластера 1С регламентным заданием, чтобы после аварии было что смотреть кроме текущей консоли.
Почему висели кассы и что стёрли перезагрузки
Разбор аварии, из которой появилась обработка: где должны были лежать следы и почему через три недели их не осталось.
Tez-tez verilən suallar
Ящик переживёт перезагрузку сервера СУБД?
Да. Снимки лежат в обычной базе на диске, а не в памяти сервера, поэтому перезапуск службы или всей машины их не трогает. Снимок сразу после старта сервера не пишет приросты ожиданий: счётчики обнулились, и сравнивать не с чем.
Читает ли обработка таблицы информационной базы?
Нет. Задание читает служебную статистику SQL Server и историю бэкапов, обработка подключается только к своей базе снимков. Данные документов, справочников и регистров не нужны и не читаются.
Откуда берётся имя пользователя 1С?
Из самой платформы. Команда "Записать сеансы 1С" раз в минуту спрашивает у кластера через RAS, какое соединение с СУБД держит каждый сеанс, и пишет пару "номер сеанса SQL, PID рабочего процесса" в базу снимков. Разбор ищет совпадение только внутри одного эпизода захвата соединения, поэтому чужой сеанс из пула не подставится.
Сколько места займёт база снимков?
При установке файлы сразу выделяются на 320 МБ, чтобы база не прирастала кусками. Сами данные в покое около 1,7 МБ в сутки. Под нагрузкой с двумя десятками интересных сеансов в минуту расчёт даёт 15-25 МБ в сутки, это оценка по размеру строк, а не замер на боевом сервере. Старше 14 суток снимки удаляются сами раз в час, срок меняется.
Подойдёт для PostgreSQL или SQL Server Express?
Нет. Нужен SQL Server Agent, а в Express его нет. Под PostgreSQL ящика нет, файловые базы не поддерживаются.
Даёт ли обработка рекомендации по настройке сервера?
Нет, её дело записать, кто и что занимал. Настройки сервера под 1С проверяет Чек-ап СУБД: параллелизм, файлы tempdb, память, модель восстановления и бэкапы.
1C sisteminiz üçün pulsuz ekspress-audit
1-2 gün ərzində bazanıza baxıb, məhsuldarlığın harada itdiyini tapacağıq və nə etmək lazım olduğunu deyəcəyik. Öhdəliksiz.
Tapşırığı müzakirə edək
Ən sürətlisi WhatsApp: tapşırıq barədə bir-iki sətir yazın, iş günü ərzində cavab verəcəyik.