← На главную

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

Разберем по шагам, почему происходят такие "чудеса", как работают механизмы поиска при обмене и что нужно делать для корректного восстановления работоспособности базы данных.

Причина №1: Искажение или обрезание номера документа при обмене

Проанализируем ситуацию с обменом. Если вы используете нетиповые правила конвертации и переносите данные с помощью универсальной обработки, обратите внимание на то, как настроен поиск существующих объектов.

В рассматриваемом случае разработчик отключил поиск по внутреннему идентификатору (GUID) и настроил поиск по номеру и дате документа. Однако при приведении номера к соответствию отрабатывал кривой алгоритм, который срезал номер документа.

К чему это приводит:

1. При загрузке данных система ищет документ по номеру и дате.
2. Из-за того, что номер был обрезан, система либо не находит нужный документ (и создает дубль), либо, что хуже, находит совершенно другой документ с похожим коротким номером.
3. Далее происходит перезапись найденного документа или применение к нему правил очистки табличных частей. Визуально это выглядит так, будто ваши оригинальные документы "исчезли" или были испорчены.

Причина №2: Отсутствие поиска по GUID (внутреннему идентификатору)

Выясним причину, почему обмен без поиска по GUID опасен после восстановления данных из копий. Когда вы восстанавливаете документы из резервной копии базы путем их выгрузки-загрузки (например, обработкой XML), система 1С генерирует для них новые внутренние идентификаторы (GUID). Даты и номера остаются прежними, но для базы это физически новые объекты.

Если управленческая база (из которой идет загрузка) ведет регистрацию изменений и использует регистры сведений типа СоответствияОбъектовИнформационныхБаз, она опирается на старые GUID. При следующем обмене управленческая база может не найти "свой" старый GUID, посчитать восстановленный вами документ чужим или ошибочным, и применить к нему правило замещения или даже пометки на удаление.

Причина №3: Нарушение физической целостности таблиц SQL и индексов

Посмотрим на проблему с другой стороны. Иногда документы после жесткого падения сервера СУБД никуда не пропадают и не удаляются обменом, но они перестают отображаться в журналах документов и списках.

В архитектуре платформы 1С на базе SQL данные самого документа хранятся в одной таблице (например, _DocumentX), а данные для отображения в списках — в таблицах журналов (например, _DocumentJournalY). При внезапном прерывании транзакции во время падения сервера может возникнуть ситуация, когда в таблицу документа данные записались, а в индексы или таблицу журнала — нет.

Чтобы проверить эту гипотезу, можно открыть консоль запросов и выполнить прямой запрос к таблице документа. Если запрос вернет данные, значит документ жив. В таких случаях перенос документов из копии не требуется и даже вреден. Помогает переиндексация.

Причина №4: Смена реквизитов (контрагентов) после реструктуризации

Рассмотрим подробнее пугающий симптом: после запуска реструктуризации базы программа присвоила документам поступления совершенно других контрагентов. Это говорит о серьезном нарушении ссылочной целостности (образовании "битых ссылок" или смещении данных в таблицах).

При реструктуризации 1С создает в SQL новую пустую таблицу с измененной структурой и копирует туда данные из старой запросом INSERT INTO ... SELECT. Если после сбоя SQL в старой таблице образовались дублирующиеся идентификаторы, записи вида <Объект не найден> или произошло смещение колонок, то при слепом копировании платформа 1С может неверно сопоставить внутренние идентификаторы. В итоге ссылка в реквизите документа начинает указывать на другой GUID в таблице справочника контрагентов.

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

Правильный алгоритм восстановления базы после сбоя сервера SQL

Чтобы избежать подобных проблем с пропаданием документов и "перемешиванием" ссылок, после любого жесткого падения базы с сервером выполните следующие действия строго по порядку:

1. Проверка средствами SQL: До запуска службы 1С:Предприятия необходимо выполнить проверку базы средствами самого SQL Server (выполнить команду DBCC CHECKDB), чтобы найти и попытаться устранить физические повреждения страниц памяти в файлах базы данных.
2. Очистка кэша: Обязательно очистите сеансовые данные и кэш кластера серверов 1С. Это предотвратит использование платформой "битых" структур при первом запуске.
3. Тестирование и исправление (ТИИ) в Конфигураторе 1С: До любых попыток переноса недостающих данных через обработки обмена (XML), запустите ТИИ. Обязательно установите флажки:
   • Реиндексация таблиц информационной базы (это вернет "пропавшие" из списков, но существующие физически документы).
   • Проверка логической целостности.
   • Проверка ссылочной целостности (с вариантами очистки или создания объектов при обнаружении битых ссылок).
4. Анализ обмена: Если перенос документов из резервной копии все же необходим, проверьте правила обмена. Убедитесь, что номера не обрезаются, а также подумайте о включении поиска по внутреннему идентификатору (GUID), если базы являются узлами распределенной или тесно интегрированной системы.

Следуя этим правилам, мы минимизируем риск потери данных и нарушения логической структуры базы после любых аппаратных сбоев.