К сожалению, немалое количество программистов до сих пор еще поддерживают нетленки, созданные за пару десятков лет существования платформы 1С: Предприятие 7.7. Но даже крупным и вполне успешным предприятиям переход на более совершенную платформу является весьма непростой задачей. Переписать в сжатое время написанное за предыдущие десятилетия, переобучить сотни-тысячи пользователей вынуждают работать на старом ПО.

Как бы там ни было, но имеются весьма большие базы, которые крутятся на платформе 1С версии 7.7. Естественно, сервером БД выступает MS SQL Server. Обновление баз, имеющих миллионы документов и справочники им не уступающие, превращается в весьма продолжительное мероприятие. В моем случае с проблемой продолжительности обновления,  я столкнулся, когда документов в базе стало в районе трех миллионов штук. Не спасла даже долгая нерабочая ночь с 31 декабря на 1 января. В 9 часов утра мне пришлось прервать обновление конфигурации и вернуться к бэкапу. С учетом того, что сейчас за один только год вводится 4 млн документов, то всякие обрезки базы меня не спасали. Нужно было радикальное, но быстрое решение. И оно было найдено.

Проблема долгой реструктуризации базы данных проистекает из-за крайне неоптимального алгоритма, который применяет фирма 1С. При изменении структуры таблицы, создается новая таблица и туда по тысяче записей за раз переносятся данные. После переноса старая таблица удаляется, а новая получает имя старой. Таким образом, простейшая операция добавления нового поля или банальное увеличение длины строкового реквизита приводит к очень затратной операции. Средний SQL сервер в однопоточном режиме выполняет в районе 1000 операций в секунду. Следовательно, для того чтобы добавить один реквизит в справочник с 10 млн элементов, надо затратить 10 000 секунд – почти 3 часа времени. Немало, но еще не так страшно – ведь вряд ли таких справочников слишком много. Но есть такая операция как пересчет ссылок документов. Это формирование таблицы для отбора документов. Там содержится также информация о подчиненных документах. В общем, эта операция еще медленнее – обрабатывается в районе нескольких десятков документов в секунду. Вот здесь количество документов радикально влияет на скорость реструктуризации базы данных.

Такая засада, на которую фирма 1С обрекла своих пользователей, объясняется просто. Необходимо было минимальными затратами выпустить SQL версию своей платформы. Поэтому 1С использует SQL SERVER в основном как хранилище данных. Грубо говоря, 1С заменила DBF-файлы на таблицы SQL. Это позволило минимально изменять работу с данными по сравнению с DBF. Даже банальные списки документов (журналы) реализованы через курсоры, которые позволяют одному пользователю создать колоссальную нагрузку на современнейший многоядерный процессор. Поэтому во всех журналах документов у меня запрещено просматривать большие массивы информации – некоторые отборы ограничивают период журнала до 3 дней, другие более длительные.

В общем, проблема понятна – надо ее решать. В поисках решения наткнулся на статью Андрея Васильева «Изменение структуры баз 1С 7.7 без долгой реструктуризации. Часть 1. Справочники». Огромное ему за нее спасибо! Эта статья позволила обойти проблему добавления поля с пометкой NOT NULL – было предложено при добавлении поля указывать значение по умолчанию.

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

Реализация обработки заняла один месяц. Первая версия успешно изменила структуру базы, но 1С вывалилась с ошибкой. Оказалось, что важен порядок следования полей в таблицах! Это, дорогая редакция, полнейшая некомпетентность разработчиков платформы 1С 7.7. Я многое могу понять, но это бред. Еще бы привязались к порядку записей в таблицах. Ну ладно - имеем, что имеем… Пришлось изобретать велосипед. Так как SQL SERVER не имеет команды изменения порядка реквизитов таблицы, то пришлось сначала сохранять во временной таблице данные столбцов, которые мешают нужному порядку, потом удалять их, далее в нужном порядке добавлять реквизиты, а потом восстанавливать сохраненные данные. Во многих случаях я просто пересоздаю таблицу – например, маленькие (меньше 2000 строк) или когда больше 5 столбцов надо сохранять, удалять, добавлять, а потом восстанавливать. В общем, разработка позволила хорошенько развлечься.

Из-за цейтнота не все необходимые реструктуризации были реализованы. Было сделано только то, без чего обновление именно поддерживаемой мной конфигурации будет некорректно. Разработка оплачивалась из расчета потраченного времени на реализацию. Поэтому по достижению результата (обновление конфы) финансирование было прекращено.

Всё, подготовительные действия выполнены. Теперь все обновления должны проходить по следующей схеме.
1.    Делаем обновление базы Обновление через Объединение конфигураций. Также можно вообще вести разработку в данной базе, тогда Объединение конфигураций не нужно.

2.    Тестируем конфигурацию.

3.    Запускаем базу Обновление в режиме 1С:Предприятие, открываем обработку «Ручное обновление базы SQL».

В качестве каталога обновляемой базы выбираем каталог рабочей базы. Изменяем строку подключения к обновляемой БД. Если для вас всё это темный лес, то вы, скорее всего, не готовы к пользованию обработкой. На этом стоит остановиться тогда. Чтобы не вносить постоянно изменения в поля, воспользуйтесь стандартным механизмом сохранения данных формы (вторая пиктограмма слева вверху формы обработки). Корректность строки подключения можно проверить, щелкнув по кнопке «Проверка подключения».

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

Самое приятное в данной технологии, что обновление, тестирование и анализ изменений мы делаем в удобное нам время (как правило, рабочее) – не торопясь анализируя необходимые изменения в структуре БД.

Скрипт изменения написан так, что его можно запустить на выполнение вручную в Среде Microsoft SQL SERVER Management Studio. Но это не более, чем опция. Основной режим – выполнение обновления через обработку.

4.    Все тесты и проверки выполнены, пора переходить к обновлению. Прежде всего необходимо, чтобы из программы вышли ВСЕ пользователи. После этого СТРОГО ОБЯЗАТЕЛЬНО надо выполнить полный бэкап обновляемой БД. Иначе если что-то пойдет не так, то вы не сможете вернуть всё как было. Файлы 1Cv7.MD и 1Cv7.DDS особой необходимости бэкапить нет, так как они автоматически сохраняются в папке базы с именами типа 1Cv720220604 053500.md (в имени отражается дата и время бэкапа).

5.    После успешного бэкапа остается только нажать на кнопку «Выполнить обновление». Во время этого процесса происходит следующее:

•    Устанавливается однопользовательский режим БД. Этот этап может сильно затянуться, если кто-то вошел в базу или, возможно, база открыта в Среде Microsoft SQL SERVER Management Studio. Пока не установится однопользовательский режим, процесс продолжен не будет.
•    Последовательно выполняются все скрипты обновления. ЛЮБАЯ ошибка на этом этапе требует восстановления БД из сделанного непосредственно перед обновлением бэкапа. Не искушайте судьбу! Ошибка во время выполнения скриптов – восстановление БД из бэкапа!
•    Переименовываются файлы 1Cv7.MD и 1Cv7.DDS. На их место копируются файлы из базы Обновление. Может получиться так, что в это время кто-то зайдет в 1С и заблокирует эти файлы. Программа обязательно сообщит в табло сообщений о неудаче с копированием файлов. Ничего страшного. Выкидываем заблокировавшего файлы пользователя и ВРУЧНУЮ переименовываем файлы 1Cv7.MD и 1Cv7.DDS. На их место ВРУЧНУЮ копируем файлы из каталога базы Обновление. Будет время и я изменю этот момент и сделаю его более безопасным.
•    Возвращается многопользовательский режим. Можно заходить в режиме 1С:Предприятие.

Все действия во время обновления комментируются в табло сообщений.

Как видите, опасных моментов в процессе ручного обновления немало. Поэтому этот метод следует использовать только если особых вариантов обновить базу нет из-за слишком длительного процесса.
Но если вы обновили базы вышеописанным способом, а потом изменяли конфигурацию рабочей базы традиционным способом, то для возврата к ручному обновлению потребуется привести конфигурацию Обновление к актуальному состоянию. Для этого достаточно зайти в конфигуратор базы Обновление и выполнить «Конфигурация\Загрузить измененную конфигурацию» и сохранить.

Немного о времени на обновление. Если раньше реструктуризация занимала несколько часов (последний раз 8+ и завершения я не дождался), то с помощью моей методики на это уходит от нескольких секунд до десятков минут. Пока самое долгое было 25 минут. Типичное время – в районе 1-2 минут. Размер базы 260+ ГБ.

Для работы обработки необходимы две внешние компоненты – 1cpp.dll и FormEx.dll. Но я думаю, что в базах большого размера эти компоненты применяются по умолчанию. Версии я использую самые последние на данный момент. Думаю, тут проблем быть не должно.

Есть один тонкий момент! Я использую Секретный релиз платформы v77.27.7. Т.е. в качестве сервера SQL мной используется MS SQL SERVER 2008R2 (можно новее). Соответственно и все запросы проверены только для этой связки. С родным сервером могут быть сюрпризы…

Код обработок открыт и более-менее комментирован.

Тестировалось на Секретном релизе 1С:Предприятие 7.7.027.7

Ого! Респект и уважуха за такую капитальную работу! И за решение выложить в паблик.
Очень крутая и нужная штука.