К сожалению, немалое количество программистов до сих пор еще поддерживают нетленки, созданные за пару десятков лет существования платформы 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 столбцов надо сохранять, удалять, добавлять, а потом восстанавливать. В общем, разработка позволила хорошенько развлечься.
Из-за цейтнота не все необходимые реструктуризации были реализованы. Было сделано только то, без чего обновление именно поддерживаемой мной конфигурации будет некорректно. Разработка оплачивалась из расчета потраченного времени на реализацию. Поэтому по достижению результата (обновление конфы) финансирование было прекращено.
|