Как узнать дату и время последней загрузки информационной базы из файла .dt?

При администрировании серверов 1С:Предприятия нередко возникает необходимость выяснить, когда именно информационная база была развернута или обновлена из файла выгрузки .dt. Например, это требуется для расследования инцидентов, поиска причин потери введенных документов или контроля регламентных работ системных администраторов.

Сложность заключается в том, что платформа 1С штатно не сохраняет специальную метку времени с историей загрузки .dt внутри прикладных констант или метаданных конфигурации. Сам по себе файл выгрузки представляет собой логический дамп данных, в который не включаются журналы транзакций СУБД и файлы администрирования. Однако определить точный момент загрузки можно косвенными, но крайне надежными методами. Разберем по шагам все доступные варианты решения этой задачи.

Способ 1. Анализ журнала регистрации 1С

Рассмотрим самый простой и доступный способ, не требующий прямого доступа к серверу СУБД. При загрузке информационной базы из файла выгрузки .dt существующий журнал регистрации полностью заменяется или очищается, так как история событий в дамп не упаковывается. Сразу после успешного завершения загрузки и старта кластера начинают выполняться фоновые и регламентные задания, фиксируя свои действия в новом журнале.

Проанализируем ситуацию через интерфейс платформы:

1. Откроем информационную базу в режиме Конфигуратора или в режиме «1С:Предприятие» под учетной записью с административными правами.
2. Перейдем в меню Администрирование > Журнал регистрации.
3. Установим интервал просмотра без ограничений по начальной дате или снимем все установленные отборы по периоду.
4. Найдем самую первую хронологическую запись в списке. Как правило, первой записью будет событие старта фонового задания, сеанса конфигуратора или запуск системного фонового процесса. Время этой первой записи и будет являться моментом окончания загрузки .dt с точностью до секунд.

Если в самой базе журнал регистрации был отключен политиками безопасности, проверим физические файлы на сервере 1С. Для платформы версии 8.2 журнал хранится в текстовом формате в рабочем каталоге кластера серверов по пути srvinfo\reg_xxxx\<GUID_базы>\1Cv8Log. Дата и время создания первого файла журнала с расширением .log или .elf на уровне файловой системы операционной системы покажут точный момент старта записи после развертывания базы.

Способ 2. Анализ системных таблиц в СУБД (MS SQL Server)

Если информационная база работает в клиент-серверном варианте под управлением Microsoft SQL Server, выясним причину и время изменений через системные представления метаданных СУБД. Во время импорта данных из файла .dt платформа 1С полностью пересоздает структуру хранения: существующие прикладные таблицы удаляются с помощью команды DROP TABLE, после чего создаются заново оператором CREATE TABLE.

Посмотрим на пример SQL-запроса, который позволяет получить точную дату и время создания прикладных таблиц базы данных:

SELECT MIN(create_date) AS MinCreateDate, MAX(create_date) AS MaxCreateDate 
FROM sys.tables;

Разберем подробнее результат выполнения этого запроса. Значение поля MinCreateDate покажет время, когда платформа начала пересоздавать таблицы при инициализации структуры из файла .dt, а MaxCreateDate зафиксирует завершение создания последних объектов. Этот диапазон дает абсолютную точность без необходимости запуска клиентских приложений 1С.

Если на сервере СУБД включена стандартная трассировка (параметр default trace enabled), мы можем дополнительно проанализировать события с кодами EventClass 46 (создание объекта) и EventClass 47 (удаление объекта). Это позволит увидеть точную хронологию массового удаления старых и появления новых таблиц базы данных.

Способ 3. Проверка файловой структуры рабочего каталога сервера 1С

Рассмотрим метод проверки через файлы кластера серверов srvinfo, если прямого доступа к SQL-серверу нет, а журнал регистрации не дал однозначного ответа. При загрузке дампа платформа обновляет служебные папки информационной базы, в частности кэши и индексы полнотекстового поиска.

Разберем порядок действий на сервере приложений:

1. Перейдем в рабочий каталог кластера серверов: ...\srvinfo\reg_xxxx\<Уникальный_Идентификатор_Базы>\.
2. Обратим внимание на подкаталог полнотекстового поиска 1Cv8FTxt, а также служебные конфигурационные файлы.
3. Посмотрим свойства папок и дату их изменения в проводнике операционной системы. При полной перезаписи базы из .dt дата модификации и создания этих служебных директорий обновляется в соответствии со временем загрузки архива.

Важное ограничение: системный идентификатор базы (GUID) в кластере серверов при загрузке .dt в уже созданную пустую базу не изменяется. Поэтому ориентироваться следует именно на дату изменения внутренних каталогов (индексов и логов), а не на дату добавления базы в консоли администрирования кластера.

Способ 4. Анализ системных журналов и технологического журнала 1С

Проанализируем дополнительные источники аудита, которые фиксируют действия администраторов:

1. Технологический журнал (ТЖ): Если на сервере предварительно был настроен сбор событий через файл конфигурации logcfg.xml, отследим события DBMSSQL (массовые DDL-запросы пересоздания таблиц) или события администрирования ADMIN. Они содержат детализированную информацию о ходе загрузки с точностью до миллисекунд.
2. Журналы операционной системы (Windows Event Log): В системных логах «Приложение» (Application) и «Система» (System) проверим время старта процессов 1cv8.exe под учетной записью администратора в режиме Конфигуратора, всплески дисковой активности и контрольные точки службы ragent / rphost.

Сопоставление времени очистки журнала регистрации 1С и даты пересоздания таблиц sys.tables в СУБД дает стопроцентно точный результат и позволяет с уверенностью утверждать, в какой именно момент времени была выполнена загрузка архива .dt.