Ситуация, когда конфигурация внезапно оказывается отключенной от хранилища, знакома многим командам разработчиков. Основная сложность заключается в том, что платформа 1С не фиксирует событие отключения в стандартном Журнале регистрации. Это локальное действие, которое изменяет состояние конкретной информационной базы, а не самого хранилища. Однако вычислить «диверсанта» или определить причину сбоя можно с помощью инструментов системного администрирования и глубокого анализа логов. Рассмотрим подробнее, как это сделать.
Когда мы отключаем конфигурацию от хранилища, платформа выполняет удаление служебной информации из базы данных. Все данные о связи с хранилищем хранятся в таблице Files. Конкретно нас интересует запись, где поле FileName имеет значение depot. Проанализируем, как можно поймать этот момент.
Самый надежный способ — установить триггер на удаление строк в таблице Files на стороне SQL Server. Разберем пример логики такого триггера. При попытке удаления записи с именем depot, триггер должен записывать в отдельную служебную таблицу время операции и системное имя пользователя (Windows-авторизация), под которым было совершено действие.
Если триггер не был установлен заранее, мы можем воспользоваться инструментами трассировки, такими как SQL Server Profiler или Extended Events. Нам необходимо отследить выполнение команды DELETE. В тексте запроса (столбец TextData) мы увидим конструкцию, затрагивающую файл depot. Это позволит нам получить точное время и SPID сессии, по которому в консоли администрирования СУБД можно определить рабочую станцию нарушителя.
Если мы хотим решить задачу средствами платформы, воспользуемся Технологическим журналом. Это мощный инструмент, который позволяет фиксировать все запросы к базе данных. Для нашей задачи необходимо настроить сбор событий SDBL (внутренний язык запросов платформы к СУБД). Проанализируем пример настройки файла logcfg.xml:
<log location="C:\LOGS\SDBL_DEPO" history="24">
<event>
<eq property="Name" value="SDBL"/>
<like property="t:text" value="%DELETE%Files%depot%"/>
</event>
<property name="all"/>
</log>
Эта настройка заставит систему записывать в лог все операции удаления из таблицы Files, содержащие упоминание depot. В логе ТЖ будет зафиксировано время события и имя пользователя операционной системы, что даст нам прямую улику. Рассмотрим преимущество этого метода: он работает «мягче» триггеров СУБД и не требует внесения изменений в структуру базы данных на уровне SQL.
Поскольку прямого события в Журнале регистрации (ЖР) нет, мы будем действовать методом исключения. Допустим, с помощью СУБД или ТЖ мы выяснили точное время отключения (например, 14:05:12). Теперь перейдем в Журнал регистрации и проанализируем активные сеансы в этот момент. Нас интересуют сеансы с типом Конфигуратор. Если в это время в конфигураторе работал только один человек, виновник очевиден.
Дополнительно стоит обратить внимание на событие «Конфигурация изменена». Часто отключение от хранилища сопровождается обновлением конфигурации базы данных. Если время изменения конфигурации совпадает с временем пропажи связи с хранилищем, пользователь, совершивший обновление, является главным кандидатом на проверку.
Если в вашей организации используется сервер хранилища (утилита crserver), имеет смысл проверить его логи. При запуске сервера с параметром -logs ведется запись обращений. Хотя само отключение происходит на стороне клиента, непосредственно перед этим пользователь обычно выполняет какую-то операцию (например, захват или получение объектов), чтобы убедиться в актуальности данных. Последний зафиксированный сеанс в логах crserver перед моментом «разрыва» может указать на нужного сотрудника.
Важно помнить, что не всегда в отключении виноват человек. Выясним техническую причину возможного инцидента. Иногда платформа «теряет» хранилище из-за повреждения локального кэша конфигуратора. При некорректном завершении работы 1С (завершение процесса через диспетчер задач, выключение питания) запись в таблице Files может повредиться или стать недоступной. В этом случае в Технологическом журнале вместо события DELETE мы увидим ошибки чтения/записи (события EXCP). Если вы не обнаружили следов намеренного удаления записи depot, скорее всего, имел место технический сбой, и пользователю просто нужно заново подключиться к хранилищу.
Чтобы минимизировать подобные ситуации, рекомендуем придерживаться следующих правил:
Используя предложенные методы мониторинга через СУБД и Технологический журнал, мы сможем не только найти виновника, но и понять истинную причину проблемы, будь то человеческий фактор или системная ошибка.