Каждый системный администратор СУБД и серверов 1С рано или поздно сталкивается с ситуацией, когда одна из рабочих баз данных неожиданно перестает отвечать на запросы. При этом симптомы выглядят крайне загадочно: пользователи не могут зайти в систему (клиентское приложение застывает еще до появления окна авторизации и не выдает никаких ошибок), а при попытке открыть свойства этой базы или список её соединений в консоли администрирования кластера 1С сама консоль намертво зависает. Примечательно, что остальные базы данных на этом же сервере продолжают работать в штатном режиме, а со стороны MS SQL Server база выглядит абсолютно здоровой и имеет статус ONLINE.
В этой статье мы подробно проанализируем причины возникновения такого технологического сбоя, выясним, почему стандартный перезапуск службы сервера 1С или даже всего физического сервера не всегда решает проблему, и рассмотрим пошаговые алгоритмы реанимации базы данных.
Для начала разберем архитектуру взаимодействия компонентов. Утилита администрирования кластера серверов 1С не связывается с SQL-сервером напрямую. Любые действия — будь то получение списка активных сеансов, просмотр свойств базы или изменение параметров блокировок — выполняются через обращение к рабочим процессам сервера приложений (rphost), которые обслуживают данную конкретную информационную базу.
Если поток процесса rphost, выделенный под работу с конкретной базой, заблокирован критической ошибкой, ушел в бесконечный цикл или ожидает ответа от СУБД, то любой запрос от консоли администрирования к этому потоку встает в очередь ожидания. В результате консоль администрирования блокирует свой графический интерфейс, ожидая ответа на RPC-вызов, который никогда не завершится (или завершится по очень длительному таймауту). Именно поэтому зависает только та ветка консоли, которая относится к сбойной базе, в то время как соседние базы в консоли открываются без проблем. Для оперативного анализа зависших запросов и ожиданий со стороны СУБД можно использовать обработку для анализа текущих запросов и состояния SQL-сервера.
Проанализируем основные технические причины этой проблемы и разберем детальные инструкции по их устранению.
Динамическое обновление конфигурации в процессе активной работы пользователей — одна из самых частых причин разрушения структуры метаданных и возникновения блокировок в таблицах конфигурации. При выполнении такого обновления платформа пытается на лету подменить конфигурацию для новых сеансов, записывая данные в таблицы dbo.Config и dbo.ConfigSave.
Если в этот момент на сервере выполнялись тяжелые фоновые задания или пользователи совершали транзакции, таблицы конфигурации могут войти в состояние взаимной блокировки (deadlock). СУБД MS SQL Server имеет встроенный механизм обнаружения дедлоков (Deadlock Detector), который по истечении времени ожидания блокировки (Lock Timeout) принудительно аварийно завершает («убивает») транзакцию-блокировщик. Именно поэтому в некоторых случаях база может «сама по себе» ожить через 15–30 минут — СУБД просто разорвала зависшее соединение.
Если база не ожила, а перезапуск службы 1С не помогает, нам необходимо очистить кэш динамического обновления на уровне базы данных СУБД. Выполним следующие шаги:
1C:Enterprise 8.3 Server Agent), чтобы разорвать все активные подключения к СУБД.
USE [Имя_Вашей_Базы_Данных];
GO
-- Удаляем временную конфигурацию, подготовленную к обновлению
DELETE FROM dbo.ConfigSave;
-- Очищаем маркеры незавершенных транзакций динамического обновления
DELETE FROM dbo.Config WHERE FileName = 'commit';
DELETE FROM dbo.Config WHERE FileName = 'dynamicCommit';
DELETE FROM dbo.Config WHERE FileName = 'dbStruFinal';
GO
В некоторых релизах платформы (в частности, ветках 8.3.12, 8.3.15 и ряде соседних версий) присутствует известный платформенный баг, связанный с таблицей dbo.DepotFiles. Данная таблица используется сервером приложений 1С для временного кэширования файлов конфигурации, механизмов расширений и интеграции с хранилищем.
Суть проблемы заключается в том, что рабочий процесс rphost в какой-то момент начинает циклически опрашивать эту таблицу с огромной скоростью, порождая миллионы запросов в секунду. В результате весь пул соединений к СУБД, выделенный под эту базу, мгновенно забивается. С точки зрения MS SQL база абсолютно работоспособна, но сервер приложений 1С физически не может выделить новое соединение для авторизации пользователей и обработки запросов консоли администрирования.
Для решения этой проблемы выполним очистку таблицы:
TRUNCATE выполняется мгновенно и не забивает лог транзакций):
USE [Имя_Вашей_Базы_Данных];
GO
TRUNCATE TABLE dbo.DepotFiles;
GO
При внезапных перезагрузках сервера по питанию, аварийных завершениях процесса rphost или сбоях сети файлы сессионных данных, которые хранятся непосредственно на сервере 1С в специальном каталоге кэша сеансов, могут записаться некорректно и повредиться. При попытке запустить рабочий процесс сервер пытается прочитать битый кэш сеансов, уходит в бесконечный цикл обработки исключений и блокирует базу для подключений.
Чтобы сбросить зависшие и поврежденные сессионные данные, выполним ручную очистку серверного кэша сеансов:
C:\Program Files\1cv8\srvinfo\reg_1541\ (где reg_1541 — идентификатор вашего главного порта кластера).snccntx. Внутри неё находятся подкаталоги, имена которых соответствуют уникальным идентификаторам (UID) баз данных, зарегистрированных в кластере.1CV8Reg.lst), мы можем удалить конкретную папку с этим UID внутри папки snccntx. Если мы сомневаемся или хотим гарантированно очистить кэш сессий для всех баз, полностью удалим всё содержимое папки snccntx.Иногда системные администраторы или сторонние скрипты резервного копирования (например, выполняющие «холодный» бэкап транзакций или снэпшоты виртуальных машин) для проведения технических работ переводят базу данных на уровне MS SQL в режим одиночного пользователя — SINGLE_USER. Если в процессе работы скрипта произошел сбой, база может остаться в этом режиме.
В режиме SINGLE_USER база данных SQL-сервера может принимать ровно одно активное соединение. Первое же регламентное задание 1С, фоновый процесс или веб-сервис мгновенно забирает это единственное свободное соединение. Любые последующие попытки сервера приложений открыть новые потоки для авторизации пользователей или обращения консоли кластера будут отвергнуты SQL-сервером, вызывая «мертвое» зависание со стороны 1С.
Проанализируем текущее состояние базы данных. В консоли SQL Server Management Studio проверим статус базы. Если рядом с именем базы в скобках указано (Single User), необходимо срочно вернуть её в многопользовательский режим:
MULTI_USER:
USE master;
GO
ALTER DATABASE [Имя_Вашей_Базы_Данных]
SET MULTI_USER
WITH ROLLBACK IMMEDIATE;
GO
Параметр WITH ROLLBACK IMMEDIATE критически важен: он мгновенно отменяет все незавершенные транзакции активного пользователя (которым обычно является зависший фоновый процесс 1С) и закрывает его соединение, позволяя СУБД успешно применить команду переключения режима.
Если сервер СУБД MS SQL был перезагружен некорректно (например, произошло аварийное отключение питания, «синий экран» операционной системы или принудительное завершение процесса sqlservr.exe через диспетчер задач), то при последующем старте СУБД запускается обязательный автоматический процесс восстановления целостности баз данных.
СУБД анализирует лог транзакций (файл .ldf) и выполняет две ключевые фазы:
.mdf).Если в момент сбоя в базе 1С проводился крупный документ, закрывался месяц или выполнялась реструктуризация таблиц, процесс отката этой массивной транзакции может занять значительное время — от 15 минут до нескольких часов. В этот период в консоли СУБД рядом с именем базы будет отображаться статус In Recovery (Восстановление данных). До тех пор пока этот процесс полностью не завершится, СУБД не позволит серверу приложений 1С подключиться к базе, отвечая отказом на любые запросы авторизации.
Выясним причину задержки запуска СУБД. Нам необходимо открыть журнал логов SQL-сервера (SQL Server Logs) в SSMS и найти записи, относящиеся к восстанавливаемой базе данных. СУБД пишет в лог процент выполнения фазы восстановления и примерное оставшееся время. В этой ситуации категорически запрещено повторно перезагружать сервер или службу SQL — это лишь приведет к тому, что процесс восстановления начнется сначала, увеличивая риск повреждения файлов базы данных. Необходимо просто дождаться окончания процедуры.
Для того чтобы минимизировать риски возникновения внезапных зависаний баз данных в будущем, рекомендуем придерживаться следующих правил администрирования:
logcfg.xml) необходимо определить логирование событий DBMSSQL и DBPOSTGRS, а также сбор событий ожидания блокировок LOCK. Это позволит при следующем инциденте сразу увидеть проблемный SQL-запрос, приведший к коллапсу.UPDATE STATISTICS) и регулярную реиндексацию таблиц. Неактуальная статистика приводит к тому, что SQL-сервер строит неэффективные планы запросов, которые могут зависнуть намертво при попытке обработать большие объемы данных.