Развертывание тестового контура на основе резервной копии рабочей базы — стандартная задача для администраторов и разработчиков систем на платформе «1С:Предприятие 8.3». Однако при выполнении этой операции напрямую через средства СУБД (например, восстановление бэкапа в MS SQL Server или PostgreSQL) специалисты часто сталкиваются с крайне неприятной проблемой. При попытке создать любой документ, бизнес-процесс или элемент справочника в восстановленной тестовой базе система выдает критическую ошибку вида: Значение "XXXXX" поля "Код" не уникально.
В этой статье мы подробно проанализируем причины возникновения данной ошибки, изучим внутренние механизмы платформы 1С, отвечающие за генерацию кодов, и рассмотрим пошаговые сценарии полного устранения проблемы. Кроме того, мы разберем критически важные риски, специфичные для конфигурации «1С:Документооборот» (1С:ДО), которые необходимо устранить сразу после развертывания копии.
Для того чтобы понять, почему база данных начинает выдавать неуникальные номера, нам необходимо заглянуть под капот платформы «1С:Предприятие 8.3». Начиная с версии 8.3, за генерацию кодов справочников и номеров документов отвечает специальный внутренний сервис нумерации, работающий на стороне сервера приложений 1С в рамках рабочих процессов rphost.
Рассмотрим по шагам, как функционирует этот механизм в штатном режиме:
SELECT MAX(...) при создании каждого объекта, сервер приложений 1С предварительно кэширует в своей оперативной памяти пул доступных номеров (обычно по умолчанию резервируется до 10 номеров вперед).Теперь проанализируем ситуацию, которая приводит к конфликту:
50720 и закешировал последующие номера до 50730.50720).rphost) для этой тестовой базы по-прежнему хранятся старые указатели нумераторов, оставшиеся от предыдущего состояния тестовой базы (например, там зафиксировано, что последний выданный номер был 50710, и следующим нужно выдать 50711).50711. Но в восстановленной из рабочей базы таблице СУБД этот номер уже физически занят реальным документом! В результате платформа пытается записать дублирующийся ключ и возвращает ошибку СУБД о неуникальности индекса или поля «Код».Это объясняет, почему выгрузка и загрузка базы через встроенный механизм 1С (файлы .dt) обычно не вызывают таких проблем: при загрузке .dt сервер приложений полностью пересоздает описание информационной базы и принудительно сбрасывает все кэши. Но для крупных баз данных использование .dt нецелесообразно из-за низкой скорости работы и высоких требований к памяти, поэтому SQL-восстановление остается основным методом, требующим ручного вмешательства в кэш нумерации.
Самый быстрый, надежный и «законный» способ исправить нумерацию без перезапуска оборудования — использовать встроенный метод платформы ОбновитьНумерациюОбъектов(). Этот метод заставляет сервер приложений 1С полностью очистить текущий кэш номеров для указанных объектов и заново считать максимальное значение непосредственно из физических таблиц базы данных при следующем обращении.
Рассмотрим, как запустить этот процесс. Для этого нам потребуется открыть базу в режиме «1С:Предприятие» под пользователем с полными правами администратора.
Если у вас есть доступ к консоли кода (внешней обработке «Групповая обработка объектов», «Универсальный подбор и обработка» или любой другой консоли выполнения кода), мы можем выполнить сброс нумерации одной командой.
Чтобы сбросить кэш нумераторов абсолютно по всей базе данных (для всех справочников, документов и бизнес-процессов), выполним следующий код:
// Сброс кэша нумераторов для всей информационной базы
ОбновитьНумерациюОбъектов();
Если ошибка возникает локально, в конкретном объекте метаданных (например, в справочнике «Визы согласования», как в примере из сообщения форума), мы можем обновить нумерацию точечно, передав в качестве параметра массив метаданных конкретного объекта:
// Сброс кэша нумерации для конкретного справочника "Визы согласования"
МассивМетаданных = Новый Массив;
МассивМетаданных.Добавить(Метаданные.Справочники.ВизыСогласования);
ОбновитьНумерациюОбъектов(МассивМетаданных);
После выполнения этого кода сервер приложений 1С обратится к таблице СУБД Справочники.ВизыСогласования, найдет запись с максимальным кодом (например, 50721), запишет её как отправную точку и при создании нового элемента корректно выдаст код 50722.
Если у вас нет под рукой консоли кода или вы хотите гарантированно очистить всю оперативную память рабочих процессов от старых данных, можно прибегнуть к административным методам.
Поскольку кэш нумерации живет внутри процессов rphost, перезапуск службы «Агент сервера 1С:Предприятия 8.3» приведет к полной очистке оперативной памяти и сбросу всех кэшей. При старте службы и первом обращении к объектам сервер приложений считает актуальные максимальные номера из SQL-таблиц.
Важное предупреждение: Делать это на общем сервере приложений, где помимо тестовой базы работают пользователи продуктивных баз, крайне не рекомендуется! Перезапуск службы прервет сеансы всех пользователей во всех базах данного кластера.
Правильным архитектурным решением в данном случае является развертывание отдельной службы Агента сервера 1С (на отдельном порту, например, 1640 вместо стандартного 1540) специально для тестовых сред. Это позволит вам безболезненно перезапускать рабочие процессы тестового контура в любое время, не мешая работе пользователей на "проде".
Исправление нумерации — это лишь малая часть айсберга при создании тестовой копии 1С:ДО. Конфигурация «1С:Документооборот» глубоко интегрирована с внешним миром (электронная почта, файловые хранилища, другие СУБД). Если вы просто развернете SQL-копию и запустите ее, это может привести к катастрофическим последствиям для рабочего контура.
Проанализируем основные зоны риска:
В 1С:ДО настроены учетные записи встроенной или легкой почты, работающие по протоколам IMAP или POP3. Если запустить тестовую базу с включенными регламентными заданиями, она немедленно начнет опрашивать рабочие почтовые ящики.
Если используется протокол POP3, тестовая база скачает новые письма сотрудников и безвозвратно удалит их с почтового сервера. Рабочая база их больше никогда не увидит. Кроме того, тестовая база начнет рассылать реальным клиентам, контрагентам и сотрудникам ложные уведомления о просроченных задачах.
В 1С:ДО файлы документов обычно хранятся вне базы данных — в сетевых папках (томах). Пути к этим томам прописаны в базе в регистре сведений.
При восстановлении базы в тестовый контур эти пути останутся неизменными и будут указывать на продуктовые сетевые каталоги. Если разработчик или тестировщик в тестовой базе решит отредактировать, заменить или удалить какой-либо документ, изменения физически произойдут в рабочей папке файлов. Это приведет к порче или потере оригиналов документов организации.
Регламентные задания тестовой базы могут автоматически запуститься и отправить тестовые документы через веб-сервисы в другие продуктивные системы (например, в 1С:ERP или 1С:ЗУП).
Чтобы избежать описанных проблем, мы рекомендуем строго придерживаться следующего регламента развертывания тестовой базы из бэкапа:
Шаг 1. Блокировка регламентных заданий до старта базы
Сразу после восстановления базы из SQL-бэкапа и перед ее регистрацией в консоли администрирования серверов 1С (или сразу при регистрации новой базы в кластере) обязательно установите признак «Блокировка регламентных заданий включена». Это гарантирует, что при запуске базы ни одно фоновое задание (включая загрузку почты и синхронизацию) не начнет выполняться автоматически.
Шаг 2. Интерактивный запуск и подтверждение копии
Запустите базу под учетной записью администратора. Механизмы Библиотеки стандартных подсистем (БСП) определят изменение параметров подключения к СУБД и выведут диалоговое окно с вопросом: "Информационная база была перемещена или восстановлена из резервной копии?".
Обязательно выберите вариант «Это копия информационной базы». Платформа автоматически переведет все интеграционные механизмы, отправку писем и регламентные задания в безопасный режим блокировки.
Шаг 3. Запуск скрипта пост-настройки тестовой базы
Создадим специальную административную обработку или напишем код, который выполнит окончательную подготовку базы к безопасной работе тестеров и разработчиков. Ниже представлен шаблон такого кода:
Процедура ПодготовитьТестовуюБазуДляРазработки() Экспорт
// 1. Очищаем кэш нумераторов для предотвращения ошибок уникальности кодов
ОбновитьНумерациюОбъектов();
ЗаписатьВЛог("Кэш нумерации успешно обновлен.");
// 2. Обезопасим интеграцию по почте
// Отключаем системную учетную запись почты и учетные записи пользователей
Запрос = Новый Запрос;
Запрос.Текст =
"ВЫБРАТЬ
| УчетныеЗаписиЭлектроннойПочты.Ссылка КАК Ссылка
|ИЗ
| Справочник.УчетныеЗаписиЭлектроннойПочты КАК УчетныеЗаписиЭлектроннойПочты";
Результат = Запрос.Выполнить().Выбрать();
Пока Результат.Следующий() Цикл
ОбъектУчетки = Результат.Ссылка.ПолучитьОбъект();
// Меняем адреса серверов на несуществующие, чтобы отправка и получение физически не работали
ОбъектУчетки.СерверИсходящейПочтыSMTP = "localhost";
ОбъектУчетки.СерверВходящейПочтыPOP3 = "localhost";
ОбъектУчетки.СерверВходящейПочтыIMAP = "localhost";
ОбъектУчетки.Записать();
КонецЦикла;
ЗаписатьВЛог("Все почтовые учетные записи переведены на безопасный локальный хост.");
// 3. Подменяем пути к томам хранения файлов
// Перенаправляем тома хранения в изолированную тестовую папку
ЗапросТома = Новый Запрос;
ЗапросТома.Текст =
"ВЫБРАТЬ
| ТомаХраненияФайлов.Ссылка КАК Ссылка
|ИЗ
| Справочник.ТомаХраненияФайлов КАК ТомаХраненияФайлов";
РезультатТома = ЗапросТома.Выполнить().Выбрать();
Пока РезультатТома.Следующий() Цикл
ОбъектТома = РезультатТома.Ссылка.ПолучитьОбъект();
Для Каждого СтрокаПути Из ОбъектТома.ПапкиИХранилища Цикл
// Подменяем пути для Windows и Linux на тестовую папку
СтрокаПути.ПутьWindows = "C:\Test_Files_Storage\" + ОбъектТома.Наименование;
СтрокаПути.ПутьLinux = "/mnt/test_files_storage/" + ОбъектТома.Наименование;
КонецЦикла;
ОбъектТома.Записать();
КонецЦикла;
ЗаписатьВЛог("Пути к томам хранения файлов успешно перенаправлены на тестовый каталог.");
КонецПроцедуры
Процедура ЗаписатьВЛог(ТекстСообщения)
ЗаписьЖурналаРегистрации("ПодготовкаТестовойБазы",
УровеньЖурналаРегистрации.Информация,,, ТекстСообщения);
КонецПроцедуры
Шаг 4. Включение регламентных заданий
После того как все критические адреса, тома файлов и настройки интеграций заменены на тестовые аналоги, мы можем зайти в консоль администрирования серверов 1С и снять флаг «Блокировка регламентных заданий включена». Теперь база готова к полноценной, а главное — полностью безопасной отладке и тестированию.
Ошибки уникальности кодов при разворачивании бэкапа через СУБД — это штатная особенность работы кэширующей системы сервера приложений 1С. Мы проанализировали эту проблему и выяснили, что она легко устраняется вызовом метода ОбновитьНумерациюОбъектов().
Однако помните, что для таких сложных систем, как «1С:Документооборот», простое исправление нумерации — это лишь первый шаг. Всегда используйте комплексный подход к развертыванию тестового контура, блокируйте регламентные задания до первого старта, перенаправляйте пути хранения файлов в тестовые каталоги и отключайте отправку реальной почты, чтобы защитить ваши продуктивные данные и рабочую среду от повреждения.