← На главную

При внесении изменений в метаданные крупного регистра (например, плана счетов или регистра бухгалтерии «Хозрасчетный») платформа «1С:Предприятие» выполняет реструктуризацию таблиц в СУБД MS SQL Server. Если в этот момент происходит падение процесса rphost, аварийное завершение Конфигуратора или сбой сети, табличная структура базы данных может остаться в промежуточном состоянии.

В этой статье мы подробно разберем механику возникновения ошибки Invalid object name 'dbo._AccRg...', выясним, почему простое переименование таблицы в SQL не решает проблему полностью, и рассмотрим проверенный пошаговый алгоритм восстановления работоспособности базы.

Механика реструктуризации 1С на уровне SQL

Для того чтобы понять причину сбоя, проанализируем, как платформа 1С производит реструктуризацию таблиц на сервере СУБД:

1. Платформа переименовывает существующую рабочую таблицу _AccRg500 в промежуточную с суффиксом _AccRg500OG (Old Group).
2. Создается новая пустая таблица с обновленной структурой под именем _AccRg500NG (New Group).
3. Данные из таблицы _AccRg500OG порциями копируются в новую таблицу _AccRg500NG.
4. Старая таблица _AccRg500OG удаляется, а новая _AccRg500NG переименовывается в стандартное рабочее имя _AccRg500.

Если в процессе переноса данных происходит аварийное завершение, платформа не успевает завершить цепочку переименований. В результате рабочая таблица _AccRg500 отсутствует, а в базе остается только таблица со старыми данными _AccRg500OG.

Почему обычного переименования таблицы в SQL недостаточно?

Рассмотрим ситуацию: если вручную переименовать таблицу _AccRg500OG обратно в _AccRg500 через SQL Server Management Studio (SSMS), 1С сможет запускаться в режиме «Предприятие», проводить документы и формировать отчеты. Однако при последующих попытках обновления конфигурации или реструктуризации процесс будет наглухо зависать.

Это происходит по нескольким причинам:

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

2. Конфликт с таблицей DBSchema. Информация о структуре хранения данных фиксируется в системной таблице DBSchema. Ручные изменения в SQL не обновляют запись в DBSchema, создавая рассинхронизацию между конфигурацией метаданных и физической структурой СУБД.

Решение проблемы по шагам

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

1. Восстановление основной таблицы в SQL. Перейдем в SQL Server Management Studio (SSMS) и найдем таблицу регистра с постфиксом OG (например, dbo._AccRg500OG). Переименуем её в стандартное имя без суффикса (dbo._AccRg500). Это позволит платформе 1С снова видеть записи регистра.
2. Создание выгрузки информационной базы. Запустим 1С в режиме Конфигуратора и выполним выгрузку информационной базы в файл (меню Администрирование – Выгрузить информационную базу...). В процесс выгрузки платформа собирает данные на уровне логических объектов метаданных, игнорируя сбойные служебные индексы SQL.
3. Загрузка в чистую базу. Создадим новую пустую базу данных на сервере 1С и SQL. Через Конфигуратор новой базы выполним загрузку ранее созданного .dt-файла (меню Администрирование – Загрузить информационную базу...).
4. Автоматическое пересоздание служебных таблиц. При загрузке файла платформа 1С автоматически сформирует чистую структуру таблиц, заново создаст все служебные таблицы итогов, пересчитает виртуальные таблицы с постфиксами NG и приведет таблицу DBSchema в полностью корректное состояние.

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

Для минимизации рисков падения платформы при реструктуризации больших регистрационных таблиц рекомендуется придерживаться следующих правил:

Очистка кэша сервера. Перед проведением тяжелых обновлений останавливайте службу 1C:Enterprise Server и очищайте сеансовый кэш кластера (папки сеансов в каталоге сервера 1С), чтобы рабочий процесс rphost не задействовал устаревшую схему базы.

Настройка модели восстановления SQL. На время реструктуризации больших баз переводите модель восстановления информационной базы в SQL Server в режим Simple (Простая). Это предотвратит переполнение журнала транзакций (.ldf) и защитит от сбоев по причине нехватки свободного места на диске.