← На главную
При проведении документов, обновлении конфигурации или попытке выполнить реструктуризацию таблиц информационной базы разработчики и администраторы могут столкнуться с критической ошибкой механизма SDBL: «В схеме базы данных нет таблицы с именем AccumRgAggOptXXXXX» (где XXXXX — числовой идентификатор объекта метаданных). Проанализируем природу этой ошибки, выясним причины ее возникновения и разберем пошаговые способы исправления ситуации.
Физический смысл ошибки SDBL и таблиц AccumRgAggOpt
Механизм SDBL (Simple DataBase Layer) представляет собой внутренний уровень абстракции платформы 1С:Предприятие для унифицированной работы с различными СУБД (MS SQL Server, PostgreSQL, Oracle DB, IBM DB2). Префикс AccumRgAggOpt указывает на служебные таблицы опций и настроек сети агрегатов для оборотных регистров накопления (в физической структуре СУБД они имеют вид _AccumRgAggOpt<ID>).
Появление сообщения о том, что таблицы нет в схеме базы данных, свидетельствует о рассинхронизации между метаданными конфигурации и физической структурой таблиц на сервере СУБД. Платформа ожидает наличие таблицы параметров агрегатов для конкретного регистра (в данном случае оборотного регистра РегистрНакопления.Закупки), однако в кэше метаданных или в самой СУБД эта таблица отсутствует.
Основные причины сбоя
- Изменение режима совместимости конфигурации. При резком переключении режима совместимости (например, со старых версий 8.2 на 8.3) платформенные правила формирования агрегатов, таблиц регистрации изменений для планов обмена и системных индексов существенно меняются. Если в базе уже были включены агрегаты, платформа может сформировать некорректный план обновления схемы БД.
- Повреждение серверного кэша структуры метаданных. В процессе работы рабочих процессов кластера (
rphost) кэш схемы базы данных может стать неактуальным, из-за чего SDBL обращается по неверным внутренним идентификаторам.
- Предыдущее аварийное завершение обновления. Если процесс реструктуризации был прерван сбоем сети или принудительной остановкой службы, конфигурация базы данных остается в промежуточном несогласованном состоянии.
Разберем практические способы восстановления нормальной работоспособности базы данных от наиболее простых и безопасных к глубоким процедурам реструктуризации.
Способ 1. Отключение агрегатов проблемного регистра в Конфигураторе
Так как таблица AccumRgAggOpt относится исключительно к функционалу агрегатов регистра накопления, самым быстрым способом обойти ошибку является временное отключение агрегатов.
- Откроем Конфигуратор и перейдем к проблемному объекту (например,
РегистрыНакопления.Закупки).
- Откроем окно свойств регистра и перейдем на закладку «Агрегаты».
- Удалим настроенные агрегаты или отключим использование режима агрегатов для данного регистра.
- Применим изменения в конфигурации базы данных, нажав клавишу
F7 или через меню «Конфигурация — Обновить конфигурацию базы данных».
- После успешного завершения реструктуризации агрегаты при необходимости можно настроить и рассчитать заново.
Способ 2. Отключение агрегатов в пользовательском режиме «1С:Предприятие»
Если конфигуратор блокирует применение изменений, можно отключить работу с агрегатами до начала реструктуризации из пользовательского режима:
- Запустим информационную базу в режиме «1С:Предприятие».
- Откроем стандартную обработку «Управление итогами и агрегатами» (или вызовем форму управления итогами).
- Найдем проблемный регистр накопления и выполним отключение использования агрегатов.
- Завершим пользовательские сеансы и повторим реструктуризацию в Конфигураторе.
Способ 3. Очистка серверного и клиентского кэша
Нередко ошибка SDBL является следствием «залипшего» кэша схемы метаданных на сервере приложений 1С. Выполним полную очистку:
- Завершим все активные клиентские сеансы в консоли администрирования кластера серверов 1С.
- Остановим службу «Агент сервера 1С:Предприятия» (
1C:Enterprise Server Agent).
- Перейдем в рабочую директорию сервера 1С (каталог
srvinfo) и внутри папок рабочих процессов удалим каталоги кэша сеансов и метаданных (папки вида snccntx*). Важно: не удаляйте системные конфигурационные файлы 1cv8wsrv.lst и 1cv8reg.lst.
- Очистим локальный кэш пользователя на клиентском компьютере (каталоги
%LOCALAPPDATA%\1C\1cv8 и %APPDATA%\1C\1cv8).
- Запустим службу сервера 1С и повторим попытку реструктуризации.
Способ 4. Пошаговое изменение режима совместимости
Если для базы требуется повысить режим совместимости (например, для внедрения общих реквизитов или новых платформенных механизмов), нельзя менять совместимость скачком через несколько версий.
- Вернем на копии базы предыдущий стабильный режим совместимости.
- Выполним полное обновление конфигурации базы данных.
- Повысим режим совместимости на один шаг (например, с режима
Версия 8.2.13 на Версия 8.2.16, затем на Версия 8.3.1 и т.д.).
- На каждом шаге фиксируем изменения в структуре базы данных по
F7 и дожидаемся успешного завершения реструктуризации всех таблиц.
Способ 5. Пересоздание физической структуры таблиц через выгрузку в .dt
Если ошибка сохраняется, выполним полное пересоздание табличной части на стороне СУБД с помощью платформенного механизма выгрузки/загрузки:
- В Конфигураторе перейдем в меню «Администрирование — Выгрузить информационную базу...» и сохраним файл
.dt.
- Создадим новую пустую базу данных на сервере СУБД (MS SQL / PostgreSQL) и зарегистрируем ее в кластере серверов 1С.
- Откроем Конфигуратор новой чистой базы и выполним «Администрирование — Загрузить информационную базу...», выбрав созданный файл
.dt.
- В процессе загрузки платформа сформирует схему таблиц СУБД заново в строгом соответствии с метаданными конфигурации, автоматически восстановив недостающие служебные таблицы
AccumRgAggOpt.
- После завершения загрузки запустим процедуру «Администрирование — Тестирование и исправление...» с включенными опциями «Реструктуризация таблиц информационной базы» и «Пересчет итогов».