Сталкиваясь с ситуацией, когда одна из многочисленных баз 1С перестает запускаться, намертво зависая на стадии открытия, мы можем почувствовать себя в тупике. Особенно, если это происходит без видимых ошибок, и даже восстановление из свежей резервной копии не помогает. Давайте рассмотрим эту проблему подробнее, проанализируем возможные причины и разберем по шагам, что можно предпринять для ее решения, опираясь на опыт коллег и системных администраторов.
Описываемая ситуация характерна: база 1С:Бухгалтерия 3.0 на платформе 1С v8.3, работающая с MS SQL Server, внезапно перестает запускаться. При попытке открытия в режиме предприятия или конфигуратора система зависает до ввода пароля и может находиться в таком состоянии неопределенное время. В консоли администрирования 1С наблюдаются многочисленные блокировки без привязки к пользователю, а попытки удаления базы или просмотра ее свойств также приводят к зависанию. При этом остальные базы на том же сервере работают нормально.
Мы выясним, как диагностировать такую проблему и какие шаги предпринять для ее устранения.
Первым делом, при возникновении подобных проблем, мы всегда обращаемся к логам. Журнал регистрации 1С (доступный из конфигуратора или предприятия) часто может указать на последние действия в базе или ошибки, которые могли предшествовать зависанию. Если нам удается получить доступ к консоли кластера 1С, там мы также можем просмотреть журнал и активные сеансы.
Однако, для более глубокого анализа нам потребуется Технологический журнал (ТЖ) 1С. Это мощный инструмент для диагностики проблем производительности и зависаний. ТЖ фиксирует множество событий на уровне платформы, включая длительные операции, ошибки, работу с СУБД, фоновые задания и многое другое. Если база висит, а пользователь не доходит до ввода пароля, это часто указывает на проблему, которая происходит на старте базы, еще до инициализации пользовательской сессии.
Для анализа ТЖ нам необходимо:
DBMSSQL, CALL, SESN, EXCP, TLOCK, TDEADLOCK.Если в ТЖ для проблемной базы отсутствуют записи или ругательства, это может означать, что процесс 1С даже не успевает начать полноценную работу с базой или журналирование не настроено на нужный уровень детализации. В таком случае, мы переходим к проверке процессов 1С на сервере.
Зависание базы при старте часто связано с "зависшими" сеансами или рабочими процессами 1С (rphost), которые некорректно завершились или по какой-то причине держат блокировки. Даже если пользователи отсутствуют, фоновые задания или служебные сеансы могут оставаться активными.
Мы рассмотрим следующие шаги:
Консоль администрирования кластера серверов 1С:Предприятия:
Убийство рабочего процесса rphost:
Каждая база 1С обслуживается одним или несколькими рабочими процессами rphost. Зависший процесс rphost может блокировать нормальный запуск базы.
rphost).PID) рабочего процесса известен, откроем "Диспетчер задач" на сервере 1С.rphost.exe по его PID.rphost будет запущен автоматически, и база, возможно, оживет.rphost через консоль кластера, что может помочь разгрузить процесс и сбросить зависшие контексты.Перезапуск службы агента сервера 1С:
Если принудительное завершение отдельных rphost не помогает, или мы не можем определить проблемный процесс, радикальным шагом будет перезапуск всей службы агента сервера 1С. Это приведет к завершению всех рабочих процессов 1С и их перезапуску.
services.msc).1C:Enterprise 8.3 Server Agent).Поскольку проблема проявляется в базе на MS SQL, следующим логичным шагом является проверка состояния базы данных непосредственно в SQL Server. Блокировки, возникающие на уровне СУБД, могут препятствовать нормальному взаимодействию 1С с данными.
Мы выполним следующие действия:
Поиск активных процессов и блокировок:
В SQL Server Management Studio (SSMS) подключимся к нашему SQL Server и выполним запросы для выявления активных сеансов и открытых транзакций:
USE master;
GO
SELECT * FROM sys.sysprocesses WHERE dbid = DB_ID('Имя_проблемной_базы');
GO
EXEC sp_who2; -- Ищем активные сеансы, их PID и блокировки
GO
DBCC OPENTRAN; -- Проверяем открытые транзакции
GO
SELECT * FROM sys.dm_tran_active_snapshot_database_transactions; -- Для баз в режиме snapshot isolation
GO
Мы внимательно изучим результаты. Если найдутся процессы, связанные с нашей базой, которые долго висят, имеют открытые транзакции или статус BLOCKED (заблокированы) или WAITING (ожидают), мы перейдем к следующему шагу.
Принудительное завершение процессов SQL Server:
Если мы обнаружили проблемные процессы, их можно принудительно завершить. Используйте с осторожностью, только если уверены, что процесс не является критически важным для других операций, и понимаете последствия.
KILL <номер_процесса>; -- Например, KILL 59
Где <номер_процесса> — это SPID, полученный из результатов sp_who2 или sys.sysprocesses.
Проверка регламентных заданий SQL Server Agent:
Иногда проблемы с базой данных могут быть вызваны зависшими заданиями SQL Server Agent. Например, задание по пересчету статистик или реиндексации может зависнуть и держать блокировки на базе.
Настройки SQL Server и оптимизация:
Хотя напрямую не решают зависание при старте, неправильные настройки могут усугублять проблемы. Мы обратим внимание на следующие аспекты:
max degree of parallelism (MAXDOP): Для 1С часто рекомендуется значение 1 или 4, чтобы избежать чрезмерного распараллеливания запросов.cost threshold for parallelism: Установим значение, при котором SQL Server начинает рассматривать распараллеливание запросов.LOCK TIMEOUT: Можно установить таймаут для блокировок, чтобы запросы не висели вечно в ожидании..mdf) и журналов транзакций (.ldf) размещены на разных физических дисках для лучшей производительности.tempDB: Для оптимизации работы временных таблиц 1С, увеличим количество файлов tempDB (до количества логических ядер процессора) и убедимся, что они одинакового размера.Одной из наиболее частых причин зависаний базы 1С при запуске, особенно если восстановление из копии не помогает, являются проблемные регламентные задания или динамические обновления.
Динамические обновления конфигурации:
Динамические обновления могут вызвать некорректное состояние базы данных, если были применены с ошибками или не полностью. Мы можем проверить наличие динамических обновлений прямо в SQL Server:
SELECT * FROM config WHERE filename LIKE '%dyn%';
Если для проблемной базы этот запрос выводит записи, это может быть одним из факторов. В некоторых случаях требуется откат или повторное корректное обновление конфигурации базы данных.
Проблемные регламентные задания 1С:
Именно регламентные задания часто являются виновниками зависаний при старте базы. Они могут запускаться автоматически при включении сервера или по расписанию, и если одно из них написано некорректно, зацикливается или пытается обработать огромный объем данных, оно может полностью заблокировать базу.
По опыту, самый эффективный способ диагностики и устранения проблем с регламентными заданиями выглядит так:
Временно запретить запуск всех регламентных заданий:
В консоли кластера 1С, в свойствах проблемной информационной базы, мы можем установить флажок "Запретить выполнение регламентных заданий". Это предотвратит их автоматический запуск при старте базы.
Очистка серверного кэша 1С:
Даже после запрета запуска регламентных заданий, серверный кэш может содержать информацию о них, что может привести к повторному запуску. Мы обязательно очистим кэш сервера 1С. Это можно сделать:
%LOCALAPPDATA%\1C\1CE\ для клиентского кэша и из папок кластера для серверного кэша.Идентификация и отключение конкретного проблемного задания:
После запрета всех заданий и очистки кэша, если база успешно запускается, это подтверждает, что проблема была в одном из регламентных заданий. Теперь нам нужно найти виновника:
Один из пользователей форума успешно решил проблему именно таким образом: "Как попал в конфигуратор, нашел по логам что за регламентное вешает базу и запретил его выполнение. После этого зашел и в предприятие. Если этого не сделать, все повторится снова на следующий день." Это подтверждает важность этого шага.
Помимо вышеописанных шагов, рассмотрим другие важные аспекты, которые могут помочь в диагностике и устранении проблемы:
Версия платформы 1С: Убедимся, что версия платформы 1С актуальна и соответствует требованиям конфигурации. Иногда старые версии платформы могут иметь известные ошибки, вызывающие зависания.
Аппаратные ресурсы сервера: Проверим загрузку CPU, использование оперативной памяти и производительность дисков на сервере 1С и SQL. Нехватка ресурсов может приводить к замедлениям и зависаниям.
rphost или запросами SQL.Антивирусное ПО: Иногда антивирус может сканировать файлы 1С при каждом запуске, что приводит к замедлениям. Рекомендуем добавить каталоги с базами 1С и рабочими каталогами сервера 1С в исключения антивирусной проверки.
Проверка базы на ошибки: Если удалось запустить базу в конфигураторе (даже с отключенными регламентными заданиями), мы выполним стандартное тестирование и исправление базы данных (ТИИ). Это может выявить и исправить логические ошибки в данных, которые могли быть причиной зависаний.
Пересборка индексации и обновление статистик SQL: Устаревшие статистики и фрагментация индексов могут серьезно замедлять работу базы данных. Мы настроим регулярное обслуживание базы данных SQL (реиндексация и обновление статистик).
В случае, описанном в теме, ключевым оказалось выявление и отключение проблемного регламентного задания. Это подчеркивает важность систематического подхода к диагностике: от общих проверок системы и процессов до глубокого анализа логов и конфигурации 1С. Мы всегда помним, что при работе с производственными системами, любые изменения необходимо тщательно тестировать и, по возможности, выполнять в нерабочее время, имея актуальные резервные копии.