Проверка базы 1С перед переносом на MS SQL Server: опасные даты и широкие индексы

Обработка смотрит базу до переноса на MS SQL Server и отвечает на шесть вопросов человеческим языком: что сломается, почему и что с этим делать. Работает только средствами платформы, к СУБД не подключается, в базу ничего не пишет.

Зачем она нужна

Перенос базы между СУБД опасен не тем, что падает. Он опасен тем, что не падает.

Штатная репликация ibcmd infobase replicate завершается кодом 0 и словами "успешно завершена". Количество строк до и после совпадает до единицы. Стандартная приёмка "строки сошлись, значит перевезли" такой прогон проходит насквозь. А внутри строк значения уже другие.

Два механизма, которые это делают, и оба тихие:

• Смещение дат. Если в базе-приёмнике указано смещение 0, все даты раньше 1753 года платформа кладёт в 01.01.1753. Пустая дата 1С и соседняя с ней становятся одной и той же. ЗначениеЗаполнено() после этого возвращает истину там, где обязана вернуть ложь.
• Ширина ключа индекса. У MS SQL предел ключа кластерного индекса 900 байт, некластерного 1700 начиная с версии 2016. У PostgreSQL около 2704. Индекс, который в источнике живёт спокойно, на приёмнике создаётся с предупреждением, пока фактические данные в предел влезают, и падает позже, на первой длинной записи.

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

Как читается отчёт

Не таблица с кодами проверок, а дерево из трёх колонок:

Шесть вопросов первого уровня:

1. С какими параметрами проверяли
2. Переживут ли даты перенос на MS SQL Server?
3. Создадутся ли индексы ваших объектов на приёмнике?
4. Создадутся ли индексы служебных таблиц платформы?
5. Хватит ли выбранной версии MS SQL Server?
6. Чего эта проверка НЕ видит

Внутри каждого - объекты, к которым вердикт относится. Раскрыл строку и видишь имя объекта как в конфигураторе.

Так выглядит прогон на типовой базе: параметры приёмника, кнопка, дерево с вердиктами.

Что даёт нового по сравнению со "у вас проблема"

Главное отличие от списка проблемных индексов - разбор ключа по байтам с виновником. Обработка не просто говорит, что ключ широкий, она показывает, из чего он набран:

РегистрСведений.ЛогированиеПакетовОбмена     2167 байт     КРИТИЧНО
Главный вклад: Идентификатор - 2058 байт из 2167.
Состав ключа: Идентификатор 2058 + ИмяМетода 100 + НомерВызова 9.

Дальше понятно, что делать: укоротить строковый реквизит "Идентификатор" или снять с него индексирование. Без разбора человек видит число 2167 и не знает, откуда оно взялось.

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

Проверка дат: что именно она ищет

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

В отчёт попадает поимённый список: объект, реквизит, сколько значений пострадает и минимальная дата. Пустая дата подписана явно - 01.01.0001 (пустая дата 1С), чтобы её не путали с потерянным значением.

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

Разные лечения разведены намеренно

Индексы ваших объектов и индексы служебных таблиц платформы стоят в разных узлах, потому что чинятся по-разному:

• свои объекты - укоротить строковый реквизит в ключе или снять индексирование;
• служебные таблицы (хранилища настроек, тела сообщений сервисов интеграции) - руками не чинятся вовсе, их создаёт платформа. Лечится обновлением платформы до переноса либо выбором приёмника посвежее.

Отдельный узел считает, что изменится от смены версии приёмника: сколько отказов снимет переход с 2014 на 2016 и сколько останется в любом случае.

На чём проверялась

Расчёт ширины ключа сверялся с самой СУБД: по sys.index_columns и sys.columns на базе, доступной и платформой, и напрямую по SQL. Совпало точно - 59 ключей шире 900 байт против 59, 26 шире 1700 против 26, контрольные индексы на 1152, 2107 и 1024 байта до байта.

На PostgreSQL сверка шла тем же способом: состав ключа хранилища настроек снят запросом к pg_index до прогона, ожидалось 546 байт, обработка показала 546.

Чего обработка не делает

• не подключается к СУБД и не выполняет SQL;
• не генерирует скрипты для администратора;
• ничего не записывает в информационную базу;
• не запускает сам перенос - ibcmd остаётся за администратором;
• не делает сверку после переноса, смотрит только источник.

Чего она не видит, обработка говорит про себя сама, отдельным узлом отчёта: тип индекса платформа не сообщает, физический размер строк и TOAST PostgreSQL через платформенный API не виден, поведение ключей шире 1700 байт взято из документации, а не из замера.

Что нужно для запуска

• платформа 8.3.20 и новее, управляемые формы;
• права на открытие внешних обработок и на чтение данных;
• любая конфигурация - обработка работает по структуре хранения;
• любая текущая СУБД: расчёт идёт по метаданным и отвечает на вопрос, что получится в приёмнике.

Как пользоваться

1. Открыть на базе-источнике, то есть на той, которую собираетесь переносить.
2. Указать смещение дат, которое поставите базе-приёмнику, и версию MS SQL Server.
3. Нажать "Проверить базу".
4. Раскрыть строки с вердиктом КРИТИЧНО и ВНИМАНИЕ - внутри объекты и разбор.
5. Кнопка "Частые вопросы" открывает справку на девять вопросов, интернет для неё не нужен.

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