Как исправить ошибку SDBL «Выход за пределы размерности результата» при тестировании и исправлении базы 1С?

← На главную

При выполнении регламентной процедуры «Тестирование и исправление информационной базы» в клиент-серверном режиме администраторы и разработчики нередко сталкиваются с аварийным прерыванием процесса: «Ошибка SDBL: Выход за пределы размерности результата». Примечательно, что при выгрузке базы в файл .dt и последующей проверке в файловом режиме аналогичная операция может проходить без единой ошибки, однако возврат в СУБД вновь приводит к сбою. Выясним причину такого поведения платформы и разберем пошаговые методы устранения неполадки.

Природа и механизм возникновения ошибки SDBL

Аббревиатура SDBL (Simple Data Base Language) обозначает внутренний программный слой платформы 1С:Предприятие. Это транслятор запросов, который переводит внутренние конструкции платформы в команды конкретной СУБД (MS SQL Server, PostgreSQL, Oracle, IBM DB2). Ошибка «Выход за пределы размерности результата» означает, что внутренний парсер платформы ожидал одну структуру метаданных колонок результирующего набора, а сервер баз данных вернул набор данных, не укладывающийся в заданные рамки размерности.

Рассмотрим подробнее типовые ситуации, провоцирующие эту ошибку:

Ошибка релиза платформы: официальная ошибка механизма SDBL, возникающая при обработке реквизитов и измерений с составным типом данных (особенно в конфигурациях, прошедших конвертацию между версиями платформы).
Повреждение структуры или индексов конкретной таблицы: сбой физической структуры данных (например, в адресных классификаторах или регистрах сведений), из-за которого внутренний запрос платформы при проверке ссылочной целостности падает.
Зависание системных таблиц регистрации изменений: нарушение целостности таблиц _ConfigChngR и _ConfigChngR_ExtProps в узлах распределенных информационных баз (РИБ).
Рассинхронизация физической схемы СУБД и метаданных 1С: несоответствие реального состава полей в SQL внутреннему описанию типов в таблицах Config и Params.

Способ 1. Обновление технологической платформы

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

Проверим текущую версию технологической платформы через меню Справка — О программе.
Если используется устаревший релиз ветки 8.2 или ранних сборок 8.3, запланируем регламентное обновление на актуальный стабильный релиз. Ошибка парсера SDBL при сопоставлении размерностей колонок составного типа была исправлена разработчиками платформы в более поздних сборках.
После обновления кластера серверов 1С и клиентских рабочих мест повторим запуск тестирования и исправления. Во многих случаях переход на исправленный релиз полностью снимает проблему без прямого вмешательства в структуру базы данных.

Способ 2. Локализация сбойной таблицы

Если обновление платформы невозможно или не привело к желаемому результату, выясним, какая именно физическая таблица базы провоцирует сбой генератора SDBL. Для этого разберем по шагам процесс локализации:

Трассировка через SQL Server Profiler или Extended Events: запустим трассировку обращений к базе данных непосредственно перед стартом «Тестирования и исправления». Отследим последнее событие SQL:BatchStarting или RPC:Completed перед вызовом исключения. Имя таблицы в последнем запросе SELECT (например, _InfoRg... или _Reference...) укажет на проблемный объект конфигурации.
Пошаговое тестирование: снимем все флажки в окне «Тестирование и исправление» и будем включать проверки по одной. Если сбой происходит только на этапе «Проверка логической целостности» или «Проверка ссылочной целостности», проблема кроется в некорректных связях конкретного справочника, документа или регистра.

Способ 3. Принудительная реструктуризация проблемного объекта

Когда проблемный объект (например, регистр сведений или справочник) найден, необходимо заставить платформу 1С полностью пересоздать его физическую таблицу в СУБД с корректным приведением всех типов полей.

Откроем базу в режиме Конфигуратор.
Найдем проблемный объект метаданных в дереве конфигурации.
Добавим в него временный фиктивный реквизит произвольного типа (например, строка длиной 10 символов) либо незначительно изменим длину существующего строкового поля.
Применим изменения в структуре конфигурации (клавиша F7). Платформа запустит полную реструктуризацию физической таблицы в MS SQL Server, заново создаст индексы и приведет типы полей в строгое соответствие с метаданными.
После успешного сохранения конфигурации удалим добавленный фиктивный реквизит и снова применим изменения.
Повторим тестирование и исправление базы данных.

Способ 4. Перезаполнение служебных данных и классификаторов

Довольно часто ошибка SDBL локализуется в таблицах служебных справочников или адресных классификаторов (КЛАДР/ФИАС). Это происходит из-за повреждения текстовых или ссылочных полей при аварийном завершении предыдущих загрузок.

Если источником ошибки выступает адресный классификатор, откроем соответствующую форму управления классификатором в режиме «1С:Предприятие».
Выполним полную очистку адресных сведений по проблемным регионам.
Запустим тестирование и исправление без данных классификатора, чтобы убедиться в отсутствии ошибки SDBL.
Загрузим адресные классификаторы заново из актуальных файлов поставки.

Способ 5. Регламентное обслуживание на уровне СУБД

В ряде ситуаций расхождение размерности возникает из-за устаревшей статистики SQL-сервера или повреждения некластеризованных индексов таблиц. Выполним комплексное обслуживание средствами СУБД:

Запустим среду SQL Server Management Studio (SSMS).
Выполним проверку целостности базы данных: DBCC CHECKDB ('ИмяБазыДанных') WITH NO_INFOMSGS, ALL_ERRORMSGS;
Если проверка не выявила критических повреждений страниц, запустим дефрагментацию и перестроение всех индексов: EXEC sp_MSforeachtable @command1="ALTER INDEX ALL ON ? REBUILD";
Обновим статистику распределения данных во всех таблицах с полным сканированием: EXEC sp_updatestats;
Перезапустим службу Агент сервера 1С:Предприятия, чтобы очистить внутренний кэш метаданных сервера приложений, после чего проверим работу процедуры тестирования.

Способ 6. Обходной путь через выгрузку и загрузку данных

Если база данных имеет небольшой объем, а проблему необходимо устранить оперативно без углубления в трассировку SQL, используем проверенный практический алгоритм обхода:

В режиме «Конфигуратор» создадим архивную копию базы через меню Администрирование — Выгрузить информационную базу (файл .dt).
Создадим пустую файловую базу и загрузим в неё полученный файл .dt.
В файловой базе выполним полное тестирование и исправление со всеми установленными флагами проверки и режимом «Очищать ссылки / Создавать объекты». В файловом движке транслятор SDBL работает по другим внутренним алгоритмам и успешно исправляет логические ошибки ссылок.
Выгрузим исправленную файловую базу обратно в файл .dt.
Создадим на MS SQL Server абсолютно чистую базу данных, зарегистрируем её в кластере 1С и загрузим подготовленный файл .dt. Все таблицы будут созданы с нуля по актуальной схеме.

Способ 7. Очистка системного кэша и списка баз

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

Закроем все запущенные сеансы «1С:Предприятия» и «Конфигуратора».
Удалим информационную базу из общего списка стартера 1С.
Очистим каталоги локального кэша пользователя в %AppData%\1C\1Cv8 и %LocalAppData%\1C\1Cv8.
Снова добавим базу данных в список стартера, указав слегка видоизмененное имя подключения. Это действие принудительно создаст новый уникальный идентификатор базы в локальном хранилище и исключит влияние старого кэша структуры.