Почему удалились документы 1С:УПП при переносе базы SQL Server методом отключения/подключения и как их найти?

Мы сталкиваемся с критической ситуацией, когда после переноса базы данных 1С:УПП средствами SQL Server методом отключения (detach) и последующего подключения (attach) произошло загадочное исчезновение документов. Самое тревожное в этой ситуации — это то, что записи о создании, изменении и проведении этих документов сохранились в журнале регистрации 1С, но самих документов в базе нет. Давайте подробно разберем, почему такое могло произойти, какие шаги предпринять для диагностики и как предотвратить подобные инциденты в будущем.

Начальный анализ ситуации: что произошло?

Предполагается, что администратор выполнял перенос базы 1С:УПП. Классический сценарий, описанный в сообщении 6, заключается в следующем:

1. База данных 1С:УПП была отключена от экземпляра MS SQL Server (detach).
2. Файлы данных (.mdf) и журнала транзакций (.ldf) были физически перенесены в новое местоположение (или на другой сервер).
3. База данных была заново подключена к экземпляру MS SQL Server (attach) из нового местоположения.

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

Почему записи в журнале регистрации 1С остались, а документов нет?

Ключевое наблюдение, вызывающее недоумение, состоит в том, что в журнале регистрации 1С записи о документах (создан, изменен, проведен) присутствуют, но самих документов нет. Объяснение этому дает сообщение 4: журнал регистрации 1С хранится не в самой базе данных SQL Server, а на кластере сервера 1С. Это означает, что сервер 1С зафиксировал факт операции с документом в момент ее выполнения, но по каким-то причинам эти изменения либо не были корректно записаны в SQL-базу, либо были утеряны из нее позднее.

Наличие записей в журнале регистрации подтверждает, что в момент их создания 1С "знала" о существовании этих документов и успешно инициировала их сохранение. Отсутствие же документов в SQL-базе прямо указывает на проблему на уровне взаимодействия 1С с SQL Server, повреждения данных на диске, ошибок в процессе переноса или восстановления.

Шаги для диагностики и поиска причин

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

1. Детальный опрос администратора

Первым делом мы должны получить максимально полную информацию от администратора, выполнявшего перенос. Задайте следующие вопросы:

1. Каким именно способом производился перенос? Помимо detach/attach, использовались ли полные бэкапы/ресторы, транзакционные или разностные бэкапы? (Сообщение 5)
2. Были ли созданы предварительные резервные копии базы данных перед переносом? (Сообщение 12) Если нет, это значительно усложняет восстановление.
3. Что произошло со старыми файлами базы данных? Были ли они перемещены (move) или скопированы (copy) с удалением оригинала? Сохранились ли они в исходном месте? (Сообщение 10)
4. Произошли ли какие-либо сбои (например, отключение питания, ошибки сети) во время копирования файлов или в процессе detach/attach? (Сообщение 10)
5. Каков размер файла базы данных до и после переноса? (Сообщение 10)
6. Проверялась ли целостность базы данных после переноса с помощью DBCC CHECKDB?
7. Есть ли возможность подключить "старую" базу (если ее файлы сохранились) к другому экземпляру SQL Server для сравнения? (Сообщение 11)

2. Проверка наличия данных в SQL-таблицах

Документы 1С хранятся в SQL Server как набор таблиц. Каждый вид документа имеет свою "шапку" (основные данные) и, возможно, одну или несколько "табличных частей".

1. Выясните имена SQL-таблиц, соответствующих пропавшим документам. Для этого можно использовать специальные обработки для 1С, которые показывают соответствие объектов 1С и таблиц SQL (например, те, что упоминаются в сообщении 8). Такие обработки доступны на различных ресурсах для 1С-разработчиков.
2. Проверьте наличие записей в этих SQL-таблицах. Выполните SQL-запросы к соответствующим таблицам. Например, если документ "Реализация товаров и услуг" соответствует таблицам _Document123 (шапка) и _Document123_VT456 (табличная часть), выполните:
   Скопировать код

   
   SELECT COUNT(*) FROM _Document123;
   SELECT COUNT(*) FROM _Document123_VT456;
   

   Если количество записей равно нулю или значительно меньше ожидаемого, это подтвердит, что данные отсутствуют непосредственно в SQL-базе.

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

Дополнительные возможные причины потери документов

Помимо очевидных ошибок администратора, существуют и более тонкие технические нюансы, которые могли привести к потере данных. Рассмотрим их подробнее.

1. Модель восстановления базы данных SQL Server (Recovery Model)

Мы выясним, какая модель восстановления была установлена для базы данных.

• Простая модель (Simple Recovery Model): При этой модели журнал транзакций автоматически усекается (очищается) при каждом контрольном событии (checkpoint). Это означает, что невозможно восстановить базу данных на определенный момент времени, а только до момента последнего полного или разностного резервного копирования. Если администратор переносил базу без создания предварительной резервной копии и произошла ошибка, все данные, измененные с момента последнего бэкапа, могли быть утеряны без возможности восстановления по журналу транзакций. В таком случае, если файл журнала транзакций (.ldf) был перенесен без соответствующей базы данных (.mdf) из старого бэкапа, он мог быть бесполезен.

• Полная модель (Full Recovery Model): Эта модель сохраняет все записи журнала транзакций до тех пор, пока журнал не будет сам резервно скопирован. Это позволяет восстановить базу данных на любой момент времени, включая восстановление после ошибочных операций. Если база данных работала в полной модели восстановления, но файл журнала транзакций (.ldf) был утерян или поврежден во время переноса, это может привести к невозможности восстановления актуального состояния базы данных, даже если основной файл данных (.mdf) был успешно перенесен.

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

2. Некорректное перемещение файлов данных и журнала транзакций

Хотя метод detach/attach является стандартным способом перемещения базы данных, он требует абсолютной точности:

• Повреждение файлов во время копирования: Если файлы .mdf или .ldf были повреждены в процессе копирования (например, из-за сбоев диска, сети или недостаточного свободного места), то при последующем подключении база данных может быть неполной или поврежденной.
• Неполное копирование: Если какой-либо файл был скопирован не полностью, то при подключении SQL Server не сможет найти все необходимые данные или журнал.
• Проблемы с правами доступа: При отключении базы данных учетная запись, выполнившая detach, становится владельцем файлов и единственным пользователем с полными разрешениями. При переносе на новый сервер или в новое местоположение необходимо убедиться, что учетная запись службы SQL Server имеет соответствующие права доступа (чтение и запись) к новым файлам базы данных. Отсутствие прав может сделать данные недоступными, даже если физически они присутствуют.

3. Ошибки на файловой системе или дисках

Мы проанализируем состояние дисковой подсистемы. Проблемы с дисковым хранилищем могут быть причиной потери данных:

• Поврежденные сектора: Наличие поврежденных секторов на дисках, где хранились файлы базы данных, могло привести к порче данных во время копирования или даже до него.
• Ошибки чтения/записи: Сбои в работе дискового контроллера или RAID-массива могли вызвать некорректное чтение или запись данных, что привело к потере целостности файлов базы данных.

Такие проблемы бывает трудно обнаружить сразу, и они могут проявиться только при попытке доступа к поврежденным данным.

4. Потеря настроек базы данных при detach/attach

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

• Изменение владельца базы данных: Владелец базы данных может измениться на учетную запись, выполнившую команду attach. Это может потребовать ручной корректировки.
• Отключение функций: Могут быть отключены такие функции, как Trustworthy или Service Broker, которые могут быть необходимы для корректной работы 1С или некоторых её механизмов. Например, Service Broker используется 1С для фоновых заданий и других асинхронных операций.

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

5. "Осиротевшие" пользователи (Orphaned Users)

Когда база данных переносится на другой экземпляр SQL Server, могут возникнуть "осиротевшие" пользователи (Orphaned Users). Это происходит, когда логин пользователя в базе данных (database user) не связан с соответствующим логином на экземпляре SQL Server (server login). В результате сервер 1С или пользователи могут не получить доступ к своим объектам в базе, даже если сами данные физически присутствуют.

Для решения этой проблемы мы можем использовать системную хранимую процедуру sp_change_users_login с опцией auto_fix или вручную пересоздать связки. Пример использования sp_change_users_login:

USE [ИмяВашейБазыДанных];
GO
EXEC sp_change_users_login 'Auto_Fix', 'ИмяПользователяБазыДанных';
GO

Выполните этот запрос для всех пользователей базы данных, связанных с 1С. Также вы можете просмотреть список осиротевших пользователей:

USE [ИмяВашейБазыДанных];
GO
EXEC sp_change_users_login 'Report';
GO

6. Несовместимость версий SQL Server или 1С

Хотя метод detach/attach обычно подразумевает, что целевой экземпляр SQL Server должен быть той же версии или новее, могут возникнуть нюансы совместимости между версиями SQL Server и платформы 1С. Некоторые версии платформы 1С могут требовать определенной версии SQL Server или иметь особенности, которые необходимо учитывать при миграции. Несоответствие может приводить к некорректной работе или потере данных, если новая версия SQL Server некорректно интерпретирует или модифицирует структуру данных.

7. Ошибки целостности данных

Мы рассмотрим возможность возникновения ошибок целостности данных. При переносе больших объемов информации или при наличии проблем в исходной базе данных до переноса могут возникнуть логические ошибки целостности данных:

• Нарушенные связи: Могут быть нарушены ссылочные связи между "шапками" документов, их табличными частями и другими связанными справочниками или регистрами. Если, например, были утеряны записи из таблиц "шапок" документов, но записи в регистрах, которые ссылаются на эти документы, остались, то 1С может видеть ссылки, но не сами объекты.
• Дублирование или отсутствие записей: Сбои при копировании могли привести к дублированию или, наоборот, к пропуску некоторых записей, что нарушило бы логику работы 1С с данными.

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

8. Проблемы с дисковым кэшированием

В редких случаях некорректная работа дисковых контроллеров с кэшированием без батарейного питания (write-back caching без защиты) может привести к потере данных при сбоях питания. SQL Server может считать, что данные записаны на диск, тогда как они всё ещё находятся в кэше контроллера и не были физически сброшены. В случае внезапного отключения питания эти данные могут быть безвозвратно утеряны. Это не связано напрямую с переносом, но может усугубить ситуацию при возникновении других сбоев.

9. Отсутствие предварительного тестирования миграции

Критически важный момент, часто игнорируемый: отсутствие адекватного тестирования миграции на тестовом контуре. Если перенос выполнялся сразу на продуктивной среде без предварительной проверки на копии, все выявленные проблемы становятся продуктивными. Тестирование позволяет выявить потенциальные проблемы совместимости, производительности и целостности данных до того, как они затронут реальную работу.

Рекомендации по предотвращению подобных ситуаций

Для минимизации рисков при работе с критически важными базами данных 1С и SQL Server мы настоятельно рекомендуем следующее:

1. Всегда создавайте полную резервную копию: Перед любой операцией переноса, обслуживания или модификации базы данных SQL Server, всегда выполняйте полную резервную копию. Убедитесь, что бэкап можно восстановить и проверить его целостность.
2. Используйте полную модель восстановления (Full Recovery Model): Для всех критически важных баз данных 1С на SQL Server устанавливайте полную модель восстановления. Регулярно выполняйте резервное копирование журнала транзакций, чтобы обеспечить возможность восстановления на любой момент времени (Point-in-Time Recovery).
3. Тщательно проверяйте права доступа: Убедитесь, что учетная запись службы SQL Server имеет полные права на чтение и запись в папках, где будут храниться файлы базы данных.
4. Проверяйте целостность базы данных: После любого переноса или восстановления базы данных всегда запускайте команду DBCC CHECKDB для проверки логической и физической целостности данных.
Скопировать код

USE [ИмяВашейБазыДанных];
GO
DBCC CHECKDB WITH NO_INFOMSGS, ALL_ERRORMSGS;
GO

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

5. Тестируйте миграции: Перед выполнением переноса на продуктивной среде, всегда проводите тестовую миграцию на отдельном, изолированном контуре. Проверяйте работоспособность 1С, целостность данных и производительность.
6. Документируйте действия: Ведите подробный журнал всех операций с базами данных, включая даты, время, выполненные команды и ответственных лиц. Это поможет при анализе проблем в будущем.
7. Проверяйте настройки SQL Server: Убедитесь, что все необходимые настройки базы данных (владелец, опции Trustworthy, Service Broker, совместимость) соответствуют требованиям 1С после переноса.
8. Решайте проблемы с "осиротевшими" пользователями: Если база переносилась на новый экземпляр SQL Server, проверьте и исправьте "осиротевших" пользователей.

В случае с данной ситуацией, отсутствие предварительного бэкапа перед переносом (как признался администратор в сообщении 12) является критической ошибкой, которая значительно усложняет возможность восстановления утраченных данных. Дальнейшие действия должны быть направлены на тщательный анализ всех упомянутых нами аспектов для выявления корневой причины проблемы и предотвращения ее повторения в будущем.