Проверка базы данных перед миграцией на PostgreSQL

Обработка проверяет базу 1С перед переездом с MS SQL на PostgreSQL и говорит, что сломается, до того как вы откроете окно переключения. Родилась из боевого переноса базы на 276 ГБ, который встал четыре раза подряд и каждый раз молча. В комплекте две версии обработки: под управляемое приложение и под обычные формы.

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

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

В нашем случае причина нашлась одна и та же во всех четырёх срывах, и находится она проверкой, которую эта обработка печатает. Сколько эта проверка идёт - честные цифры ниже, в отдельной таблице.

Зачем она, если главный скрипт есть в статье бесплатно

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

• Пятнадцать проверок по метаданным, которых в SQL не видно вообще: режим управления блокировкой поимённо по объектам, разделение итогов, шрифты макетов, тома хранения, внешние компоненты с разбором манифеста внутри архива.
• Разбор вывода в вердикты. Скрипт отдаёт столбец строк, и его надо читать глазами. Обработка превращает его в «чинить / внимание / норма» с пояснением по каждому пункту и полным списком объектов.
• Два сценария переезда. Состав проверок для «меняем только СУБД» и «меняем СУБД и ОС» разный, и ни один чек-лист, который мне попадался, их не разделяет.
• Библиотека из восьми скриптов под MS SQL, PostgreSQL, Windows- и Linux-хост, а не один.

Что проверяет сама, без подключения к СУБД

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

Сценарий «только СУБД» (Windows остаётся):

• версия платформы против доступности ibcmd infobase replicate - на крупной базе это решающий пункт плана, потому что .dt там просто не выгрузится;
• режим управления блокировкой данных, включая поимённый список объектов, оставшихся на автоматических блокировках при формально управляемой базе;
• разделение итогов регистров накопления;
• длины строковых измерений против лимитов обеих СУБД, с оценкой запаса;
• отдельно - индексы, которые уже нарушают лимит MS SQL: после переезда они станут легальными, и это выигрыш, а не риск;
• неограниченные строки в измерениях регистров сведений и индексируемых реквизитах: длинное значение уедет в TOAST, когда кортеж перерастёт порог, а значение длиннее 2704 байт в btree не проиндексируется вовсе;
• полнотекстовый индекс и оценка, что он будет перестраиваться;
• участие в РИБ и разделение данных;
• число таблиц хранения как вход для расчёта места.

Сценарий «СУБД и ОС» добавляет:

• внешние компоненты - обработка лезет внутрь архива компоненты, читает манифест и говорит точно, есть ли там сборка под Linux. Списком «посмотрите сами» тут не отделаешься, потому что смотреть надо в каждый файл;
• шрифты в макетах: Arial, Times New Roman, Calibri и прочие, которых на голом Linux нет и из-за которых разъезжаются печатные формы;
• тома хранения файлов с незаполненным полным путём Linux;
• Windows-пути в строковых константах;
• список регламентных заданий для просмотра глазами.

Как устроена работа с СУБД

Обработка к СУБД не подключается. Она печатает готовый диагностический скрипт с подсветкой, вы отдаёте его администратору, а вставленный обратно вывод она разбирает и превращает в вердикты.

Каждый скрипт отдаёт один столбец строк вида КЛЮЧ=значение, а не несколько таблиц результатов. Это сделано ради копирования: выделили столбец, скопировали, вставили. Разбор читает пары ключ-значение, поэтому ему всё равно, из SSMS вы копировали, из psql или из файла.

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

Библиотека скриптов:

• для MS SQL: поиск невидимых символов в уникальных индексах (главный), паспорт базы, ключи индексов против лимитов, индексы мимо платформы, топ таблиц по объёму, логистика переезда (копии, журнал, место);
• для PostgreSQL: паспорт кластера с проверкой наличия типов mchar и mvarchar, значимые параметры под 1С, послемиграционная проверка индексов;
• для Windows-хоста: ресурсы сервера и состояние службы;
• для Linux-хоста: локаль и шрифты, учётная запись, лимиты, huge pages.

Главная проверка

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

Механика: строки 1С в PostgreSQL кладёт в типы mchar и mvarchar, а они сравниваются через ICU. ICU схлопывает Unicode-совместимые формы: неразрывный пробел равен обычному, № равно No, ™ равно TM, многоточие равно трём точкам. MS SQL считает такие строки разными, PostgreSQL одинаковыми, и уникальный индекс, проживший годами, на новой СУБД не создаётся.

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

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

Разбор результата даёт не «найдены проблемы», а полный список объектов и число строк к исправлению. Это принципиально: частичная починка не работает. Проверено на живом переносе: вычистили 745 групп из 755, и перенос встал ровно там же, потеряв ещё пятьдесят минут. В оставшихся десяти группах было 14 строк, всего к исправлению 759. Одна оставшаяся пара роняет создание индекса так же надёжно, как семьсот сорок пять.

Вердикты

По каждому пункту есть развёрнутое пояснение, почему это важно, и полный список затронутых объектов.

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

• платформа 8.3.20 и 8.3.27;
• MS SQL Server 2022;
• на Windows - PostgreSQL 17.9-3.1C от 1С, на Linux - Postgres Pro 1С 17.10 под Ubuntu 22.04;
• боевая конфигурация с 4465 таблицами хранения, база 276 ГБ.

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

Пишу честно, чтобы не было сюрпризов.

• Не подключается к СУБД и не выполняет скрипты сама. Запускает их администратор.
• Не читает тексты модулей - платформа их в рантайме не отдаёт. Поэтому вызовы COM, ЗапуститьПриложение и КомандаСистемы, которые чаще всего и ломаются на Linux, показать нельзя: по регламентным заданиям выдаётся список для просмотра глазами.
• Проверка на невидимые символы приблизительная по своей природе. Совместимых форм в Unicode сотни, нормализация закрывает шесть самых частых. Точный ответ даёт только прогон на самой PostgreSQL.
• Оценка длин ключей идёт по объявленным длинам, то есть по худшему случаю. Фактические длины даёт скрипт, и они обычно в разы меньше.
   

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

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

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

1. Открыть обработку в базе, которую собираетесь переносить.
2. Выбрать сценарий переезда.
3. Нажать «Проверить базу» - это то, что видно платформе, без СУБД.
4. Выбрать скрипт, отдать администратору, вставить вывод в правое поле, нажать «Разобрать результат».
5. Разобрать вердикты «чинить», починить всё до последней строки, прогнать проверку заново до нуля.
6. Перепроверить непосредственно перед окном переезда: данные меняются каждый день.

Другие наши инструменты диагностики 1С:

• Карта объёмов базы 1С - из чего состоит база и куда ушли гигабайты.
• Чек-ап СУБД под 1С - правильно ли СУБД настроена под платформу.
• Трансформатор SQL в 1С - что на самом деле делает конкретный запрос.
• Оптимизатор временных таблиц - как переписать то, что нашли.