Развертывание информационной базы 1С:Предприятие на СУБД Oracle Database — процесс, требующий ювелирной настройки системного окружения. В отличие от Microsoft SQL Server или PostgreSQL, где локализация баз данных автоматизирована в большей степени, Oracle требует жесткого согласования языковых параметров (NLS — National Language Support) на стороне сервера СУБД, сервера приложений 1С и клиента Oracle.
Одной из наиболее распространенных и труднорешаемых проблем при первоначальной установке базы является ошибка: «Ошибка установки параметров NLS. Проверьте, была ли выполнена настройка NLS с помощью Locale Builder». В этой статье мы подробно разберем причины этой неисправности и пошагово рассмотрим методы её полного устранения.
Для корректного сравнения и сортировки строк платформа 1С:Предприятие использует собственное правило языкового упорядочивания (сортировку) под названием V81C_GENERIC_M. По умолчанию СУБД Oracle ничего не знает об этом правиле. Чтобы научить СУБД работать с сортировкой 1С, используется утилита Oracle Locale Builder, входящая в состав клиента и сервера Oracle. С её помощью на основе специального конфигурационного файла платформы генерируются бинарные файлы локализации (с расширением .nlb), которые должны быть физически подключены к среде выполнения Oracle.
Если сервер 1С при попытке инициализации базы данных обнаруживает, что СУБД Oracle или локальный клиент не поддерживают требуемую кодировку или правило сортировки, процесс прерывается аварийно.
Выясним основные причины, из-за которых это происходит, и разберем по шагам, как настроить систему без ошибок.
---
Рассмотрим стандартную архитектурную ситуацию: сервер приложений 1С:Предприятие установлен на одной машине (например, под управлением Windows Server), а сервер СУБД Oracle функционирует на другом, удаленном компьютере (например, под управлением Linux или другой версии Windows).
Частой ошибкой администраторов является генерация файлов локализации .nlb на сервере 1С и размещение их только в локальном каталоге клиента Oracle. Так делать нельзя!
Поскольку основные операции по сортировке и индексации данных происходят непосредственно внутри СУБД, сгенерированные файлы локализации должны в обязательном порядке физически находиться на обеих машинах:
Проанализируем процедуру копирования:
Найдем на сервере 1С каталог, куда установлен клиент Oracle. Обычно путь выглядит как C:\app\client\product\[версия]\client_1\nls\data. Сюда необходимо поместить сгенерированные файлы.
Передадим эти же файлы администратору базы данных (DBA) удаленного сервера Oracle. Он должен поместить их в аналогичный каталог на сервере СУБД. Путь на сервере Oracle зависит от операционной системы:
%ORACLE_HOME%\nls\data$ORACLE_HOME/nls/dataВажный нюанс: После копирования файлов на сервер СУБД необходимо обязательно перезапустить службы Oracle Database (или перезагрузить инстанс базы данных), иначе СУБД не прочитает новые файлы инициализации локали из каталога nls\data.
---
Обратим внимание на параметры кодировки базы данных. Перед созданием базы данных 1С на СУБД Oracle нам необходимо выяснить текущую кодировку самого сервера СУБД. Подключимся к СУБД через SQL*Plus или Oracle SQL Developer и выполним следующий запрос:
SELECT * FROM nls_database_parameters
WHERE parameter IN ('NLS_CHARACTERSET', 'NLS_NCHAR_CHARACTERSET');
Допустим, в результате выполнения запроса мы получили значение NLS_CHARACTERSET = AL32UTF8. Это современный стандарт Юникода, который часто используется по умолчанию.
Теперь проверим настройки клиента Oracle на сервере 1С. Если в реестре Windows в ветке Oracle (или в системных переменных среды) параметр NLS_LANG настроен на однобайтовую кодировку (например, AMERICAN_AMERICA.WE8MSWIN1252 или RUSSIAN_RUSSIA.CL8MSWIN1251), возникнет жесткий конфликт конвертации данных при установке сессии 1С.
Для исправления ситуации приведем кодировку клиента в полное соответствие с кодировкой сервера СУБД. Откроем редактор реестра regedit на сервере 1С и найдем ветки:
HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\KEY_[Имя_Дома_Oracle]HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ORACLE\KEY_[Имя_Дома_Oracle]Изменим значение параметра NLS_LANG на соответствующее кодировке сервера СУБД. В нашем примере с UTF8 правильное значение будет:
AMERICAN_AMERICA.AL32UTF8 (или RUSSIAN_RUSSIA.AL32UTF8)
---
Рассмотрим ситуацию, когда при попытке прописать системную переменную среды ORA_NLS10 (или ORA_NLS11) сервер 1С начинает выдавать ошибку «OCI вернуло сообщение об ошибке». В логах это обычно маскируется под ошибку инициализации окружения ORA-12705: Cannot access NLS data files or invalid environment specified.
Выясним причину этой ошибки. Переменная ORA_NLS10 принудительно указывает библиотекам OCI, где искать файлы локализации. Ошибка инициализации возникает в двух случаях:
lx0boot.nlb, lx1boot.nlb), из-за чего клиент вообще теряет способность работать с языковыми параметрами.Решение: Если файлы локализации скопированы непосредственно в стандартный каталог клиента nls\data внутри %ORACLE_HOME%, то переменные ORA_NLS10 / ORA_NLS прописывать в системе вообще не требуется! Клиент найдет их автоматически по умолчанию. Удалим эти переменные из системных переменных окружения Windows и перезапустим сервер приложений 1С.
---
Для генерации правильных файлов локализации крайне важно использовать именно ту версию конфигурационного файла (с расширением .nlt), которая поставляется с вашей версией платформы 1С:Предприятие. Эти файлы находятся в дистрибутиве платформы в каталоге Additional\OracleDatabase.
Посмотрим на различия файлов конфигурации для разных версий платформы 1С:
lx327c5.nlt. При компиляции он перезаписывает системные файлы lx0boot.nlb и lx1boot.nlb.lx327c6.nlt. При его генерации создается обновленный загрузочный файл lx1boot.nlb и файл пользовательской таблицы lx327c6.nlb.Выполним процедуру генерации по шагам:
lbuilder.bat (или lbuilder.exe) из каталога %ORACLE_HOME%\bin.lx327c6.nlt из дистрибутива вашей версии платформы 1С 8.3.V81C_GENERIC_M.lx1boot.nlb и lx327c6.nlb.nls\data клиента Oracle (на сервере 1С) и сервера СУБД (на сервере Oracle), предварительно сделав резервную копию оригинальных файлов в этих каталогах.---
Даже если файлы скопированы корректно, операционная система Windows Server может блокировать доступ к ним для процесса сервера 1С. По умолчанию служба 1С:Предприятие (процесс ragent.exe) работает под управлением локальной учетной записи USR1CV8 или системной учетной записи Network Service.
Учетная запись, от имени которой запущена служба сервера 1С, должна обладать полными правами на чтение и выполнение файлов в каталоге клиента Oracle.
Проверим и настроим права доступа:
C:\app\client).USR1CV8). Если служба работает под Network Service, добавим этого пользователя.nls\data). При необходимости нажмем кнопку «Заменить все записи разрешений дочернего объекта наследуемыми от этого объекта».---
Перед тем как совершить очередную попытку создания базы данных 1С в консоли администрирования кластера, выполним итоговую сверку по нашему списку:
lx1boot.nlb и lx327c6.nlb скопированы в nls\data на сервере 1С.nls\data на сервере Oracle Database.NLS_LANG на сервере 1С соответствует кодировке базы данных (например, AMERICAN_AMERICA.AL32UTF8).ORA_NLS10 (или проверена её точность).USR1CV8 имеет полные права на чтение каталога клиента Oracle на сервере приложений.Соблюдение этой последовательности действий гарантирует успешную инициализацию языковых параметров СУБД и избавит вас от ошибок NLS при создании информационной базы 1С на Oracle Database.