← На главную

Ситуация, когда пользователь или разработчик вносит изменения в базу данных 1С, они корректно рассчитываются и отображаются, но спустя несколько дней полностью исчезают, встречалась многим специалистам. При этом в журнале регистрации за соответствующий период отсутствуют какие-либо записи о действиях. Разберем по шагам возможные причины этой проблемы и рассмотрим методы диагностики и защиты данных.

Основные пользовательские и административные причины

Прежде чем анализировать системные сбои платформы, проанализируем наиболее частые организационные факторы:

1. Работа пользователя в тестовой копии базы: Это самая распространенная причина. На сервере или локальном ПК создается копия базы для проведения тестов. Если списки информационных баз не разграничены четко, пользователь может случайным образом зайти в копию, внести скидки или документы, а затем открыть рабочую базу и не найти там внесенных данных.
2. Загрузка старого бэкапа поверх рабочей базы: Если администратор или программист выполнил загрузку информационной базы из файла .dt или восстановил резервную копию на стороне СУБД, все данные и изменения конфигурации, внесенные после даты создания этой копии, бесследно исчезают.
3. Динамическое обновление конфигурации: В случае с исчезновением доработок конфигуратора причиной часто является применение механизма динамического обновления или загрузка измененной конфигурации (файла .cf), в которой последние правки отсутствовали.
4. Изменение адресации базы на сервере: При перенастройке кластера серверов 1С база могла быть переадресована на другое имя СУБД или иной инстанс, где данные находились в более старом состоянии.

Технические причины на уровне платформы и СУБД

Если факты работы в копии или загрузки бэкапа исключены, разберем возможные технические причины на уровне платформы 1С и системы управления базами данных:

1. Сбои кэширования и рассинхронизация: При работе кластера серверов 1С с несколькими рабочими процессами rphost может произойти повреждение кэша метаданных. Внесенные изменения могут не сохраниться в СУБД или не отображаться у других пользователей, а после перезапуска рабочего процесса — визуально откатиться. Для решения этой проблемы применяется очистка локального кэша или использование параметра запуска /ClearCache.
2. Откат незавершенных транзакций (Transaction Rollback): Если запись происходила в рамках длительной транзакции и произошел сбой (аварийное завершение процесса rphost, обрыв связи с СУБД), произойдет откат транзакции. Так как фиксация событий в журнале регистрации 1С привязана к успешному завершению транзакции, в ЖР записей не останется.
3. Потеря буфера журнала регистрации: Платформа 1С записывает события в журнал регистрации не моментально, а накапливает их в оперативной памяти. При внезапном сбое питания или падении службы данные буфера теряются. При использовании формата ЖР на базе SQLite (файлы .lgd) целостность структуры файла можно проверить командой: PRAGMA integrity_check;
4. Ограничения RLS и функциональные опции: Данные могли не пропасть из физических таблиц СУБД, а стать недоступными для просмотра конкретному пользователю из-за смены настроек прав на уровне записей (RLS) или переключения функциональных опций.

Алгоритм диагностики и поиска причин

Выясним причину пропажи данных с помощью комплексной проверки всех системных логов:

1. Проверка резервных копий: Развернем вчерашний бэкап базы данных и проверим наличие внесенных изменений. Если в бэкапе данные присутствуют, значит, имел место откат базы или некорректная загрузка конфигурации.
2. Анализ журнала транзакций СУБД: С помощью штатных средств MS SQL Server или PostgreSQL проверим факт выполнения команд INSERT и UPDATE для соответствующих таблиц справочников или регистров.
3. Настройка и анализ Технологического журнала 1С: Подключим Технологический журнал для отслеживания критических ошибок и аварийных завершений процессов. Для этого настроим отбор по следующим событиям:
   • EXCP — исключительные ситуации и падения процессов;
   • DBMSSQL / DBPOSTGRS — выполнение запросов к БД и отмены транзакций;
   • ADMIN — административные действия с информационной базой.
4. Проверка журналов операционной системы: Изучим системный журнал событий ОС (Event Viewer или syslog) на сервере приложений 1С и СУБД для поиска записей о перезапусках служб или сбоях оборудования.

Рекомендации по предотвращению потерь данных

Рассмотрим превентивные меры, которые помогут избежать подобных проблем в будущем:

1. Разграничение тестовых и рабочих сред: Настроим четкое визуальное отличие заголовка окна в тестовых базах и ограничим права обычных пользователей на доступ к тестовым контурам.
2. Регламентация обновлений: Исключим использование динамического обновления в рабочей среде. Любые изменения конфигурации должны выполняться в монопольном режиме с перезапуском рабочих процессов.
3. Ограничение административных прав: Сократим список пользователей, имеющих права на загрузку информационной базы и сокращение журнала регистрации.
4. Внедрение независимого аудита: Для наиболее критичных справочников и документов настроим подписки на события ПередЗаписью и ПриЗаписи, регистрирующие действия пользователей во внешнем файле или логирующие их в отдельной независимой базе данных.