Ситуация, когда одна из многих баз на сервере внезапно перестает запускаться, "зависая" на заставке 1С:Предприятие, является довольно распространенной в практике системного администрирования. Особенно характерно это для клиент-серверного варианта работы. В этой статье мы подробно разберем, почему база может вести себя подобным образом, и проанализируем шаги, которые помогут вернуть ее в рабочее состояние.
Проблема часто осложняется тем, что восстановление из бэкапа в ту же самую базу не дает результата, а создание базы под новым именем временно решает вопрос. Это прямо указывает на то, что корень проблемы кроется не только в самих данных, но и в настройках окружения, кэшировании или параметрах взаимодействия с SQL-сервером.
Прежде чем приступать к сложным манипуляциям на сервере, проанализируем настройки клиентского подключения. Часто 1С "зависает" из-за бесконечного поиска лицензии или поврежденного локального кэша.
Очистка списка баз и локального кэша. Первым делом попробуем полностью удалить базу из списка в окне запуска 1С и добавить ее заново. Это очистит локальные временные файлы, привязанные к идентификатору базы. Если это не помогло, необходимо вручную очистить содержимое папок %AppData%\1C\1cv8\ и %LocalAppData%\1C\1cv8\.
Настройка поиска лицензий. Если в вашей сети используются программные лицензии, а в настройках базы включен поиск аппаратного ключа, это может вызвать длительные задержки (таймауты). Разберем, как это отключить:
Если манипуляции на клиенте не помогли, значит проблема на стороне сервера 1С:Предприятие. Когда база работает под новым именем, но не работает под старым — это явный признак того, что сервер хранит "отравленный" кэш для конкретного идентификатора информационной базы.
Переподключение базы в консоли администрирования. Выясним, поможет ли перерегистрация базы в кластере. Для этого:
Глубокая очистка серверного кэша. Иногда удаления из консоли недостаточно. Проанализируем состояние папки snccntx. Это каталог, где сервер 1С хранит данные сеансов. Рассмотрим алгоритм очистки:
1C:Enterprise 8.3 Server Agent.C:\Program Files\1cv8\srvinfo\reg_1541).snccntx и удалим ее.Если база по-прежнему не запускается, перейдем к профессиональному инструменту диагностики — Технологическому журналу. Он покажет, на какой именно операции (обращение к СУБД, чтение метаданных или проверка прав) происходит зависание.
Создадим файл logcfg.xml в папке conf на сервере 1С (обычно C:\Program Files\1cv8\conf). Разберем пример минимальной настройки для отслеживания ошибок и длительных запросов:
<config xmlns="http://v8.1c.ru/7.4/get/logcfg">
<log location="C:\logs\1c_debug" history="2">
<event>
<eq property="name" value="EXCP"/>
</event>
<event>
<eq property="name" value="SDBL"/>
<gt property="duration" value="1000000"/>
</event>
<property name="all"/>
</log>
</config>
В этом конфиге мы указали системе записывать все исключительные ситуации EXCP и запросы к базе данных SDBL, длящиеся более 1 секунды. После запуска базы под этим журналом, проанализируем файлы в папке C:\logs\1c_debug. Если мы увидим там событие TLOCK, это будет означать наличие блокировок, мешающих входу.
Иногда проблема кроется в "плохом" плане запроса, который SQL-сервер закэшировал именно для этой базы. При смене имени базы SQL-сервер строит планы заново, поэтому база начинает работать. Рассмотрим, как сбросить кэш планов без переименования.
Откроем SQL Server Management Studio и выполним следующий скрипт (предварительно узнав db_id вашей базы):
-- Узнаем ID нашей базы
SELECT DB_ID('Имя_Вашей_Базы_SQL');
-- Сбросим процедурный кэш для конкретной базы
DECLARE @dbid INT = DB_ID('Имя_Вашей_Базы_SQL');
DBCC FLUSHPROCINDB(@dbid);
GO
Также проверим критически важные настройки самой базы данных SQL. Проанализируем параметры Auto Close и Auto Shrink. Оба этих параметра должны находиться в состоянии False. Если Auto Close включен, SQL-сервер закрывает ресурсы базы каждый раз, когда выходит последний пользователь. При попытке входа нового пользователя 1С может просто "отвалиться" по таймауту, пока SQL заново инициализирует файлы данных.
Часто база "висит" при старте из-за того, что при входе первого пользователя запускаются тяжелые регламентные задания или инициализируется индекс полнотекстового поиска, который был поврежден. Выясним, как это проверить.
В консоли администрирования серверов 1С откроем свойства информационной базы и установим галочку "Блокировка регламентных заданий включена". Попробуем войти в базу. Если вход выполнен успешно — значит, проблема в одном из фоновых заданий (например, обновление индекса ПП или расчет итогов).
Если же подозрение падает на полнотекстовый поиск, а зайти в программу для его отключения не получается, можно физически удалить папку Index, которая находится в каталоге с данными этой базы на сервере (если бы это была файловая база). Для SQL-версии попробуем выполнить команду в Конфигураторе (если он открывается): Управление полнотекстовым поиском -> Очистить индекс. Если даже Конфигуратор виснет, попробуйте временно отключить службу 1С, очистить папку временных файлов сервера и запустить базу с установленной блокировкой заданий.
Таким образом, мы рассмотрели комплекс мер от простых (очистка кэша) до глубоких (анализ ТЖ и SQL планов). Последовательное выполнение этих шагов позволяет диагностировать и устранить причину "зависания" даже в самых сложных случаях.