База 1С:ERP занимает 1,3 ТБ, хранит 14 млн документов и растёт на 80 ГБ в месяц. Останавливать её можно максимум на час в день. Обычное обновление уже не помещается в это окно.
Такие исходные данные описала компания «1С-Рарус» в кейсе перехода с 1С:ERP 2.5.5.82 на 2.5.7.316. Команда готовила обновление на копии и переносила часть реструктуризации на уровень СУБД.
Этот принцип подходит и для базы меньшего размера. Вынесите подготовку из рабочего окна, затем измерьте этап с монопольным доступом. После этого станет видно, что мешает: диски, память или сама процедура обновления.
Из чего складывается время обновления
Фраза «обновление заняло шесть часов» не объясняет задержку. В общее время попадают разные операции:
- подготовка релиза и сравнение конфигураций;
- применение изменений конфигурации;
- реструктуризация таблиц;
- выполнение обработчиков обновления;
- проверки после запуска базы.
Эти операции по-разному нагружают сервер. Сравнение конфигураций использует процессор и память. Перестроение таблиц читает и записывает данные. Ожидание завершения сеансов от характеристик оборудования не зависит.
Обновление структуры таблиц требует монопольного доступа. Пока в базе остаются пользователи или фоновые задания, платформа не перейдёт к этому этапу. Скрипты отключения сеансов убирают ручное ожидание, но не сокращают реструктуризацию.
Новые регистры, реквизиты и индексы увеличивают объём работы. Чем крупнее затронутые таблицы, тем больше данных СУБД читает, перестраивает и записывает.
Измеряйте этапы отдельно. Иначе можно заменить сервер из-за сорока минут, которые обновление потратило не на работу, а на ожидание пользователей.
Почему один апгрейд не гарантирует короткое окно
SSD сокращает задержки при чтении и записи. Дополнительная память снижает обмен СУБД с накопителем. Но ни SSD, ни память не отменяют монопольный доступ и обработчики обновления.
Апгрейд нужен, когда журнал и метрики показывают дисковую задержку или нехватку ОЗУ. Если время уходит на изменение крупной таблицы, сначала уменьшите объём операций в рабочей базе.
| Где проходит время | Что вы увидите | Поможет ли оборудование | Что проверить сначала |
|---|---|---|---|
| Ожидание монопольного доступа | Структура базы ещё не меняется | Нет | Сеансы, фоновые задания и блокировки |
| Чтение и запись таблиц | Накопители заняты во время реструктуризации | Возможно | Задержку дисков и запас места |
| Нехватка памяти | СУБД активно обращается к диску | Возможно | Потребление ОЗУ и лимиты памяти СУБД |
| Обработчики обновления | Структура уже изменена, но процесс продолжается | Обычно нет | Журнал выполнения и данные конфигурации |
| Подготовка релиза | Рабочая база ещё не меняется | Нет причины держать простой | Перенос подготовки на отдельный контур |
Вывод: покупать оборудование до разметки времени рано. Сначала найдите операцию, которая не помещается в окно.
Что сделали с базой 1,3 ТБ
В кейсе «1С-Рарус» обновляли 1С:ERP с версии 2.5.5.82 до 2.5.7.316. Рабочая база содержала 14 млн документов. Каждый месяц в ней появлялось ещё около 500 тысяч документов, а объём рос примерно на 80 ГБ.
Подготовку проводили на копии. Для реструктуризации применили механизм, который переносил максимум операций на уровень СУБД.
При добавлении реквизита в табличную часть механизм перестраивал только изменённую часть. При изменении индексов он обходился без создания новых таблиц и переноса данных.
Здесь важен не абстрактный «быстрый сервер». Команда сократила объём работы, которую требовалось выполнить при остановленной рабочей базе.
Допустимое окно в кейсе составляло не более часа в день. Это ограничение проекта, а не обещание обновить любую базу такого размера за 60 минут.
На вашей базе окно подтвердит только пробный прогон. Копия должна быть свежей, а тестовый контур — сопоставимым с рабочим по СУБД, дискам и настройкам памяти.
Подготовьте отдельный контур
Начните с резервной копии средствами СУБД. Восстановите её в отдельную базу и сохраните исходную копию до завершения всех прогонов.
Для продуктивной базы 1С на SQL Server проверьте модель восстановления. В рекомендациях по настройке 1С для MS SQL Server указана Recovery Model Full. Практический порядок резервирования разобран в руководстве по резервной цепочке SQL Server.
Для PostgreSQL тоже нужен отдельный тест восстановления. Если база копируется через pg_dump, сценарий проверки можно сверить с разбором оборванного дампа базы 1С.
Не обновляйте единственный экземпляр резервной копии. Для каждого прогона создавайте отдельное восстановление. Тогда неудачная попытка не уничтожит исходную точку возврата.
Тестовый контур не обязан повторять продуктивный сервер до последнего ядра. Однако слабые диски или урезанная память изменят длительность монопольного этапа. Такой прогон покажет порядок операций, но не подтвердит рабочее окно.
Перед тестом сопоставьте настройки СУБД на двух контурах. Разные лимиты памяти, размещение файлов и характеристики хранилища превратят сравнение времени в догадку.
Проведите первый прогон без попытки ускорить всё сразу
На первом прогоне соберите исходную картину. Не меняйте одновременно диски, память, порядок обновления и настройки СУБД. Иначе вы не поймёте, какое действие изменило результат.
Зафиксируйте:
- время восстановления копии;
- время подготовки конфигурации;
- начало и конец монопольного этапа;
- длительность реструктуризации;
- время обработчиков обновления;
- время проверок и первого запуска;
- максимальное потребление памяти;
- загрузку и задержку дисков;
- сообщения платформы и СУБД.
Лог нужен не для отчёта о выполненной работе. По временным меткам вы отделите ожидание сеансов от записи таблиц и обработчиков конфигурации.
Пакетный запуск сокращает ручные паузы и убирает часть модальных окон. Скрипты также отключают пользователей без ожидания оператора. Медленный диск или тяжёлую реструктуризацию автоматизация не исправит.
Если обновление прервалось, не запускайте его повторно поверх той же тестовой базы. Сохраните её состояние, поднимите новую копию и определите этап сбоя по порядку диагностики базы после неудачного изменения конфигурации.
Меняйте по одному условию за прогон. Например, сначала перенесите копию на сопоставимые диски. Настройки памяти проверяйте уже на следующем восстановлении.
Разберите задержку по признакам
После первого прогона выберите одно ограничение. Исправьте его и повторите обновление на новой копии. Два запуска на одной уже изменённой базе нельзя сравнивать: во втором запуске набор операций будет другим.
| Признак во время прогона | Вероятное ограничение | Проверка | Следующее действие |
|---|---|---|---|
| Процесс ждёт до начала реструктуризации | Активные сеансы или фоновые задания | Сопоставить журнал с завершением сеансов | Автоматизировать блокировку входа и отключение пользователей |
| Диски заняты, память не исчерпана | Чтение и запись крупных таблиц | Проверить задержку накопителей во время операции | Повторить тест на сопоставимом хранилище, затем оценить SSD |
| Растёт обмен с диском при заполненной памяти | СУБД не хватает ОЗУ | Сопоставить память процесса СУБД и дисковую активность | Пересчитать лимиты памяти или добавить ОЗУ |
| Долго меняется одна таблица | Большой объём реструктуризации | Найти затронутый объект в журнале | Сократить набор изменений или проверить другой механизм реструктуризации |
| Структура изменилась быстро, задержка осталась | Обработчики обновления | Отделить их время от реструктуризации | Проверить данные и логику конкретного релиза |
| Между этапами возникают длинные паузы | Процесс зависит от оператора | Сопоставить паузы с ручными действиями | Перевести повторяемые операции в пакетный запуск |
Вывод: каждое действие привязано к наблюдаемому признаку. Замена сервера без такого признака остаётся догадкой.
Если упор приходится на диск, сравните задержку именно во время изменения таблиц. Постоянная высокая загрузка накопителя ещё не доказывает проблему: важна связь с медленным этапом.
С памятью действует тот же принцип. Свободная ОЗУ сама по себе ничего не решает. Смотрите, сколько памяти получила СУБД и растёт ли дисковый обмен во время обновления.
Когда обновлять частями
Разбиение большой конфигурации на несколько этапов снижает нагрузку одного запуска. Такой маршрут пригодится, если его требует порядок перехода между релизами или единый пакет перегружает тестовый контур.
Каждый этап нужно проверить на свежей копии. Универсального количества промежуточных релизов нет: маршрут зависит от исходной и целевой версии.
Не делите обновление ради ощущения контроля. Дополнительный этап требует отдельного запуска, проверки результата и точки возврата. Он оправдан, только если сокращает монопольную часть или нужен для поддерживаемого перехода.
Сначала сравните два маршрута на копиях. Запишите длительность монопольного доступа для каждого этапа, а затем проверьте, сколько рабочих окон понадобится.
Как назначить рабочее окно
После повторного прогона у вас останется измеренное время монопольного этапа. Сравнивайте с окном именно его, а не весь тест от восстановления копии до последней проверки.
В окно входят и служебные операции:
- отключение пользователей;
- проверка фоновых заданий и сеансов;
- изменение рабочей базы;
- проверки после запуска;
- время на остановку работ и возврат к прежнему состоянию.
Допустим, база может стоять 60 минут. Это не значит, что реструктуризация вправе занять 59 минут. Одна задержка тогда оставит вас без проверки и возврата.
Резерв времени рассчитывают по пробному прогону. Сложите длительность монопольного этапа, проверки после запуска и действия при отказе от продолжения. Запишите каждое исходное значение в плане работ.
Отдельно задайте точку остановки. Например: если реструктуризация не завершилась к назначенному времени, команда прекращает продолжение и переходит к заранее проверенному сценарию возврата.
Такой порог нельзя придумывать во время работ. При остановленной базе и ожидающих пользователях решение почти всегда принимают позже, чем следовало.
Что обязательно, а что зависит от диагноза
Часть подготовки нужна при любом обновлении. Остальные действия имеют смысл только после измерения.
| Действие | Статус | Зачем нужно | Когда выполнять |
|---|---|---|---|
| Свежая резервная копия средствами СУБД | Обязательно | Даёт точку возврата и материал для теста | До любых изменений |
| Восстановление в отдельный контур | Обязательно | Проверяет копию и отделяет тест от рабочей базы | До пробного обновления |
| Пробный прогон с журналом времени | Обязательно | Показывает длительность каждого этапа | Перед назначением окна |
| Проверка результата | Обязательно | Подтверждает запуск базы и нужных функций | После каждого прогона |
| Перенос на SSD | По признаку | Сокращает ожидание накопителей | При подтверждённой дисковой задержке |
| Добавление памяти | По признаку | Снижает обмен СУБД с диском | При подтверждённой нехватке ОЗУ |
| Обновление частями | По признаку | Снижает нагрузку одного этапа | Если маршрут перехода это допускает |
| Пакетный запуск | По признаку | Убирает ручные паузы и модальные окна | Когда процесс тормозит оператор |
| Оптимизированная реструктуризация | По условиям релиза | Сокращает перенос данных при изменении структуры | После проверки применимости на копии |
Вывод: копия, тест и журнал нужны всегда. Апгрейд и изменение процедуры отвечают на найденную задержку.
Перед рабочим запуском подготовьте тот же порядок команд, который прошёл проверку на копии. Импровизация сводит пользу репетиции к нулю.
Правило допуска к рабочей базе
Не назначайте обновление по размеру базы или характеристикам сервера. Допуск даёт успешный прогон на свежей копии.
Проверьте пять пунктов:
- Копия восстановилась в отдельный контур.
- Обновление завершилось без ручного исправления данных.
- Монопольный этап измерен отдельно.
- Он помещается в окно вместе с проверками и возвратом.
- Журнал и порядок действий сохранены для рабочего запуска.
Если хотя бы один пункт не выполнен, рабочее окно ещё не подтверждено. Перенесите больше подготовки на копию или устраните найденное ограничение.
Для базы 1,3 ТБ из кейса «1С-Рарус» план строился вокруг копии и оптимизированной реструктуризации. Из этих данных не следует обещание «поставим SSD и уложимся за час». Ваш срок покажет только репетиция на свежей копии.