← На главную

Обновление конфигурации 1С, особенно когда необходимо «перепрыгнуть» через несколько релизов в условиях ограниченного времени (например, в ночное технологическое окно), — это задача, требующая четкого понимания механизмов платформы и работы СУБД. Рассмотрим ситуацию, когда у нас есть база на MS SQL Server, и мы опасаемся, что регламентные задания или медленная работа файлового варианта сорвут сроки открытия магазинов. Разберем основные риски, типичные ошибки и наиболее эффективные стратегии решения этой задачи.

Анализ рисков при обновлении на копии базы

Многие специалисты рассматривают вариант «обновить копию — загрузить её вместо рабочей базы». Проанализируем, почему этот путь таит в себе скрытые угрозы:

1. Потеря данных. Пока вы обновляете копию (а это может занять несколько часов), в рабочей базе могут продолжаться процессы (например, загрузка чеков, если кто-то забыл выключить терминал, или регламентные операции). При замене рабочей базы данными из копии эти изменения будут безвозвратно утеряны.
2. Идентификатор информационной базы (GUID). При загрузке базы из бэкапа или файла .dt платформа 1С распознает изменение расположения. Если вы укажете, что это копия, заблокируются все внешние соединения, обмены и сервисы (например, 1С-ЭДО или интеграция с маркетплейсами). Если укажете, что база перемещена, вы рискуете задублировать данные в облачных сервисах, если копия «стучалась» туда во время тестов.
3. Синхронизация. В 1С:Розница 2.3 часто настроен обмен с 1С:Управление торговлей. При обновлении через копию могут «отвалиться» узлы обмена, если правила конвертации или версия конфигурации в копии не будут соответствовать ожидаемым метаданным узлов.

Метод 1: Ручное управление отложенным обновлением (Рекомендуемый)

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

Установите в консоли кластера 1С блокировку регламентных заданий. Это предотвратит запуск фоновых процессов, которые могут мешать обновлению (например, расчет себестоимости или извлечение текста для поиска).

После применения обновления метаданных (через конфигуратор), запустите базу в режиме «Предприятие». Программа сообщит, что обновление не завершено, так как регламентные задания заблокированы. Не пугайтесь этого сообщения.

Проанализируем шаги для ручного запуска:

1. Откройте консоль регламентных заданий (через «Обслуживание» или внешнюю обработку).
2. Найдите задание ОтложенноеОбновлениеИнформационнойБазы.
3. Запустите его принудительно, используя команду ЗапуститьВручную.

Таким образом, будет работать только нужный поток обновления данных, а все остальные «мусорные» задания останутся в режиме ожидания.

Метод 2: Подготовка и загрузка CF-файла

Этот метод считается профессиональным стандартом при обновлении сложных систем. Рассмотрим его пошагово:

1. Создаем полную копию рабочей базы на SQL-сервере.
2. На копии выполняем пошаговое обновление через все промежуточные релизы.
3. После того как копия успешно обновлена до финального релиза и в ней выполнены все обработчики обновления, выгружаем файл конфигурации .cf.
4. В рабочей базе (в монопольном режиме) заходим в Конфигуратор и выбираем Конфигурация — Загрузить конфигурацию из файла (или «Сравнить и объединить»).

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

Ускорение процесса на стороне SQL-сервера

Если время ограничено 10 часами, проанализируем настройки СУБД, которые помогут выиграть время:

Переведите базу в режим Simple (простая модель восстановления). Это критически важно, так как при массовом обновлении данных файл лога транзакций (.ldf) может разрастись до сотен гигабайт, что приведет к остановке сервера. В режиме Simple лог будет очищаться автоматически.

В современных версиях БСП (Библиотеки стандартных подсистем), на которой базируется Розница 2.3, можно ускорить процесс, настроив многопоточность. В разделе «Обслуживание» — «Результаты обновления программы» установите количество потоков (например, 4 или 8 в зависимости от ядер сервера). Это позволит выполнять РегламентныеЗадания по обновлению данных параллельно.

Специфика Розницы 2.3: Маркировка и драйверы

При «прыжке» через несколько релизов в Рознице важно помнить о торговом оборудовании. Разберем, на что обратить внимание:

• Драйверы ККТ: Новые релизы часто требуют обновления драйверов торгового оборудования до конкретных версий. Проверьте это заранее на копии, иначе утром кассы могут не открыться.
• Маркировка (Честный Знак): Если вы пропускаете релизы, в которых менялась структура хранения кодов маркировки, убедитесь, что обработчики обновления отработали корректно. Посмотрите в журнале регистрации, нет ли ошибок по объектам Справочник.ШтрихкодыУпаковокТоваров.

Итоговый алгоритм безопасного обновления

Подведем итог и составим план действий:

1. Делаем бэкап рабочей базы средствами SQL Server.
2. На копии (тоже SQL) прогоняем все обновления, фиксируем время и возможные ошибки.
3. Если на копии всё прошло успешно, в рабочее окно в основной базе загружаем итоговый .cf.
4. Применяем изменения (F7).
5. Запускаем «Предприятие», при необходимости включаем только ОтложенноеОбновлениеИнформационнойБазы.
6. Для ускорения используем параметр запуска:
   Скопировать код

   
   /C ЗапуститьОбновлениеИнформационнойБазы /СЗавершитьРаботуПользователей
   

7. Проверяем результат через форму «Результаты обновления программы».

Использование файлового варианта для обновления SQL-базы, как предлагали в некоторых источниках, — это тупиковый путь. Скорость записи в файл (.1cd) значительно ниже, чем в SQL, и риск повреждения базы при сбое в разы выше. Работайте только в рамках SQL-инфраструктуры для достижения максимальной надежности и скорости.