При обновлении технологической платформы «1С:Предприятие» до ветки 8.3.17 (например, релизов 8.3.17.1496 или 8.3.17.1386) администраторы баз данных и разработчики часто сталкиваются с неприятной проблемой. При попытке загрузить резервную копию информационной базы из файла выгрузки (.dt) процесс прерывается критической ошибкой:
«ошибка загрузки информационной базы. В информационную базу загружены не все данные по причине: Ошибка СУБД: ORA-01722: неверное число».
При этом на предыдущих релизах платформы (например, 8.3.15.1830) эта же выгрузка разворачивается абсолютно штатно и без каких-либо предупреждений. Более того, если попытаться загрузить этот же файл .dt на платформе 8.3.17, но под управлением СУБД PostgreSQL или MS SQL Server, операция проходит успешно. Это указывает на то, что корень проблемы кроется на стыке обновленных механизмов платформы 8.3.17 и специфики работы СУБД Oracle.
В этой статье мы подробно разберем, почему возникает эта ошибка, проанализируем её причины и рассмотрим пошаговые методы её устранения.
Код ошибки ORA-01722: invalid number генерируется непосредственно СУБД Oracle. Она указывает на то, что СУБД попыталась неявно или явно преобразовать символьную строку в числовое значение, однако строка содержала недопустимые для числа символы (например, буквы, пробелы или неподходящий знак разделителя дробной части).
При загрузке файла .dt платформа 1С последовательно воссоздает таблицы и выполняет пакетную вставку данных. Если в числовое поле таблицы Oracle пытается записаться строка, формат которой СУБД не может распознать как число, транзакция откатывается и процесс загрузки аварийно завершается.
Основными факторами, провоцирующими эту ошибку в связке 1С 8.3.17 и Oracle, являются:
150,50), тогда как в англоязычных стандартах используется точка (150.50). Если сессия 1С передает СУБД числа с точкой, а Oracle настроен на ожидание запятой (или наоборот), СУБД вернет ошибку ORA-01722..dt этот «мусор» экспортируется как есть, а при импорте на строгой платформе 8.3.17 вызывает отказ СУБД.---
Самый быстрый и частый способ устранения этой ошибки — приведение параметров десятичного разделителя в сессии Oracle к единому стандарту, который ожидает сервер «1С:Предприятия».
Разберем по шагам, как настроить параметры локализации:
Шаг 1. Настройка переменных окружения на сервере приложений 1С
Убедитесь, что для учетной записи, под которой запущена служба сервера «1С:Предприятие» (например, USR1CV8), корректно заданы региональные параметры. На сервере под управлением Windows или Linux должна быть установлена соответствующая переменная окружения NLS_LANG. Например, для корректной работы с русским языком и стандартными разделителями часто устанавливают значение:
RUSSIAN_RUSSIA.CL8MSWIN1251 (для Windows)
или
RUSSIAN_RUSSIA.AL32UTF8 (для Linux-серверов).
Шаг 2. Создание триггера AFTER LOGON в Oracle
Чтобы гарантировать, что любое подключение со стороны платформы 1С будет использовать правильные символы разделителей независимо от настроек клиента, администратору СУБД Oracle необходимо создать специальный системный триггер на уровне базы данных или схемы 1С. Этот триггер принудительно устанавливает точку в качестве десятичного разделителя для каждой новой сессии:
CREATE OR REPLACE TRIGGER SET_NLS_DECIMAL_SEPARATOR
AFTER LOGON ON SCHEMA
BEGIN
EXECUTE IMMEDIATE 'ALTER SESSION SET NLS_NUMERIC_CHARACTERS = ''.,''';
END;
/
Параметр NLS_NUMERIC_CHARACTERS = '.,' жестко указывает СУБД Oracle, что первым символом (точкой) разделяется дробная часть числа, а вторым символом (запятой) — группы разрядов. Это предотвращает возникновение ошибки ORA-01722 при массовой обработке числовых данных платформой 1С.
---
Если настройка NLS-параметров не принесла результата, велика вероятность, что в исходной базе данных присутствуют физически поврежденные записи, где в числовых полях содержатся текстовые символы. На платформе 8.3.15 такие записи могли игнорироваться, но 8.3.17 прерывает загрузку.
Перед тем как делать выгрузку в .dt, выполните следующие действия в исходной базе данных (на работающей платформе 8.3.15):
Если исходная база данных перед выгрузкой находилась в файловом режиме, перед тестированием и исправлением обязательно запустите утилиту проверки физической целостности файлов базы данных chdbfl.exe, которая находится в каталоге установки платформы 1С (папка bin).
После успешного завершения процедур исправления сделайте новую выгрузку в .dt и повторите попытку загрузки на платформе 8.3.17.
---
Как совершенно справедливо замечают опытные системные администраторы, файл формата .dt является исключительно средством логического переноса данных между разными типами СУБД (например, при миграции с файловой базы на MS SQL или с Oracle на PostgreSQL). Использовать .dt в качестве регулярного бэкапа для рабочих и тестовых баз крайне не рекомендуется, особенно в крупных корпоративных системах.
Загрузка .dt нагружает сервер приложений 1С, требует огромного объема оперативной памяти и подвержена ошибкам интерпретации типов данных драйверами СУБД.
Чтобы полностью обойти любые ограничения платформы 1С при развертывании копий баз данных, необходимо использовать штатные инструменты СУБД Oracle:
Проанализируем базовый сценарий переноса рабочей базы в тестовую среду с помощью Oracle Data Pump:
1. Выполняем экспорт схемы рабочей базы данных на сервере СУБД:
expdp system/password@work_db schemas=usr1cv8 directory=backup_dir dumpfile=work_db_dump.dmp logfile=export_work.log
2. Импортируем полученный дамп в тестовую схему на сервере СУБД (предварительно очистив целевую схему):
impdp system/password@test_db schemas=usr1cv8 directory=backup_dir dumpfile=work_db_dump.dmp logfile=import_test.log
При таком подходе платформа 1С вообще не участвует в процессе воссоздания таблиц и записи строк, что гарантирует 100% идентичность структуры данных и исключает любые ошибки вида ORA-01722.
Таким образом, мы рассмотрели все возможные варианты решения проблемы. Для оперативного исправления ситуации прямо сейчас воспользуйтесь настройкой региональных параметров сессии Oracle (Решение 1) или исправлением исходных данных (Решение 2). В долгосрочной же перспективе для обеспечения стабильности инфраструктуры мы рекомендуем отказаться от использования формата .dt для регулярного клонирования баз в пользу нативных бэкапов СУБД Oracle (Решение 3).