GoldenGate: репликация между СУБД с разными кодировками
Александр Рындин,
Oracle СНГ Источник: блог Alexander Ryndin, 20 Июль 2011, http://www.oraclegis.com/blog/?p=2138 В настоящее время GoldenGate обеспечивает ограниченную поддержку репликация данных между базами данных с различной кодировкой. Преобразование в другую кодировку поддерживается, если целевой базой данных при репликации является СУБД Oracle. | Если быть честным, то это заслуга не GoldenGate, а клиента СУБД Oracle, который и осуществляет непосредственное преобразование кодировок.
Физика процесса
- Параметр NLS_CHARACTERSET – это характеристика базы данных В этом параметре записана кодировка, в которой создана база данных Oracle. Увидеть значение этого параметра можно в представлении nls_database_parameters. Например, его значение может быть – CL8ISO8859P5 или AL32UTF8.
- Параметр NLS_LANG – это характеристика клиентской сессии. Она задает в какой кодировке клиент хочет видеть или предоставлять данные. Таким образом, одни клиенты могут пожелать получать данные в UTF8 (веб-сайт), другие в CP1251 (Windows-приложение), а третьи в CP866 (консольные приложение). Программное обеспечение Oracle само заботится о преобразовании данных, хранящихся в СУБД Oracle к нужной кодировке и наоборот. Например, значение параметра NLS_LANG может быть AMERICAN_AMERICA.UTF8 или AMERICAN_AMERICA.CL8MSWIN1251.
По сути, эта пара NLS_CHARACTERSET и NLS_LANG задает вектор преобразования кодировки при прохождении данных между клиентов и базой.
Таким образом, когда Oracle видит, что база в UTF8, а клиент сказал, что хочет NLS_LANG=AMERICAN_AMERICA.CL8ISO8859P5, он автоматом преобразует текстовые данные к кодировке CL8ISO8859P5.
Как это настроить в GoldenGate
Поскольку процесс Replicat в GoldenGate работает через стандартный клиент Oracle, то можно использовать вышеописанную функциональность для преобразования кодировки. Настраивается очень просто:
1) на целевой системе в файл параметров replicat прописываем строку:
Кодировка (CL8MSWIN1251) должна совпадать с кодировкой базы-источника, потому что в trail-файлах данные сохраняются именно в кодировке источника. При вставке в базу данных replicatом они будут автоматически преобразовываться в кодировку СУБД, указанную в NLS_CHARACTERSET.
2) необязательно, но считает best practice:
Это делается на случай, если GoldenGate будет захватывать изменения не из журналов СУБД, а с помощью fetch – это может происходить в случае объектных типов данных.
3) если кодировки разной размерности (например, однобайтовая 1251 и мультибайтовая UTF8), то обязательно создаем DEF-файл и используем на replicat директиву SOURCEDEFЫ. А вот директива ASSUMETARGETDEFЫ работать не будет.
Related Posts:
- Шаблоны для настройки GoldenGate
- Загрузка SHP-файлов различной кодировки в Oracle Spatial
- Обработка временной зоны в GoldenGate
- Ошибка ORA-01722: неверное число или ORA-01722: invalid number
- Гетерогенная репликация Oracle->MySQL с помощью GoldenGate
Кракозябры в PL/SQL Developer [дубликат]
Доброго всем времени. Вопрос, думаю, несложный будет для Вас. Открываю PL/SQL Developer БД запросом и в текстовых полях отображаются кракозябры? Как победить? Лезть в настройки БД через Oracle Configuration Assistant или же в девелопере настройка?
Отслеживать
2,324 1 1 золотой знак 17 17 серебряных знаков 35 35 бронзовых знаков
задан 18 фев 2014 в 7:41
nightin_gale nightin_gale
547 2 2 золотых знака 8 8 серебряных знаков 20 20 бронзовых знаков
4 ответа 4
Сортировка: Сброс на вариант по умолчанию
Ошибка в вашей настройке языка. Клиент Oracle берет настройку языка из виндовой переменной NLS_LANG, если я правильно помню, ее нужно установить в значение RUSSIAN_AMERICA.CL8MSWIN1251.
Сделать в Винде это можно в «Свойствах системы», закладка «Дополнительно», кнопка «Переменные среды». Добавляете этот параметр, если он не создался клиентом Oracle и задаете значение.
Отслеживать
ответ дан 18 фев 2014 в 16:02
4,021 14 14 серебряных знаков 19 19 бронзовых знаков
Спасибо большое, поменял, помогло!) Только небольшая поправочка — это меняется в ключе реестра, а где именно можно узнать из Developer-a: «Help — > Support Info -> Registry»
19 фев 2014 в 6:16
Я точно правил через переменные среды, про реестр тоже слышал. Возможно, разные версии клиента воспринимают разные способы для установки значения.
19 фев 2014 в 18:04
Коллеги, порядок применения настроек следующий. Если значение NLS_LANG изменено в реестре, то сначала используется оно, но если создана переменная окружения, то она сильнее, и имеет приоритет. Так можно запускать разные приложения bat-файлами с разными настройками, делая set nls_lang=. Ну а после того как клиентсое приложение уже запустилось, оно может само выдать ALTER SESSION и менять nls_language и nls_territory сколько угодно раз. То же касается и большинства других NLS-настроек, и не только.
Al32utf8 что за кодировка
B2. Настройка драйвера БД для Oracle
Oracle Database (или Oracle DBMS) – объектно-реляционная СУБД. Oracle может быть использована в качестве внешней БД для Dr.Web Enterprise Security Suite.
Сервер Dr.Web может использовать СУБД Oracle в качестве внешней базы на всех платформах, кроме FreeBSD (см. п. Установка и поддерживаемые версии ).
Для использования СУБД Oracle необходимо:
1. Установить экземпляр БД Oracle с настройками кодировки AL32UTF8 . Также можно использовать существующий экземпляр БД c указанной кодировкой.
2. Настроить драйвер БД на использование соответствующей внешней базы. Это можно сделать в конфигурационном файле или при помощи Центра управления: меню Конфигурация Сервера Dr.Web , вкладка База данных .
Если вы планируете использовать в качестве внешней базы данных БД Oracle через ODBC-подключение, то при установке (обновлении) Сервера, в настройках инсталлятора отмените установку встроенного клиента для СУБД Oracle (в разделе Поддержка баз данных → Драйвер базы данных Oracle ).
В противном случае работа с БД Oracle через ODBC будет невозможна из-за конфликта библиотек.
Установка и поддерживаемые версии
Для возможности использования БД Oracle в качестве внешней базы необходимо установить экземпляр БД Oracle и настроить для него кодировку AL32UTF8 ( CHARACTER SET AL32UTF8 / NATIONAL CHARACTER SET AL16UTF16 ). Это можно сделать следующими способами:
1. При помощи инсталлятора БД Oracle (используйте расширенный режим установки и конфигурирования БД).
2. При помощи SQL-команды CREATE DATABASE .
Более подробная информация о создании и конфигурации БД приведена в документации к БД Oracle.
В случае использования кодировки, отличной от указанной, национальные символы будут отображаться некорректно.
Клиент для доступа к БД (Oracle Instant Client) входит в состав установочного пакета Dr.Web Enterprise Security Suite.
Dr.Web Enterprise Security Suite поддерживает следующие версии СУБД: Oracle9i Database Release 2: 9.2.0.1 – 9.2.0.8 и выше.
При настройке обращения к СУБД Oracle используются параметры, описываемые в таблице ниже.
Al32utf8 что за кодировка
Делаю пакет SSIS для преобразования MDB (Access) с юникод. полями
в Оракл 11 в котором поля VARCHAR2
Поля в оракле будут VARCHAR2 (NVARCHAR нельзя юзать)
В моей тестовой системе у оракла NLS_CHARACTERSET WE8MS1252 (америк.)
В целевой системе оказалось AL32UTF8 (не могу поставтиь к сожалению оракл. сервер с такой бд)
и мой пакет перестал работать — стал разбираться
в SSIS есть 2 типа строковых полей DTS_STR обычные, DT_WSTR — юникодные
оказалось чтобы записать в оракл. VARCHAR2 поля считанные из аксесса (юникод.) мне надо было
1 когда NLS_CHARACTERSET WE8MS1252
преобразовать их из юникода в строки (- иначе ругалось can’t convert between unicode and non-unicode data)
и писать строковые поля туда
2 когда NLS_CHARACTERSET AL32UTF8
не трогать — т.е писать напрямую юникодные поля в VARCHAR2
понимаю что это дела SSIS и все таки
?1 чем отличается NLS_CHARACTERSET WE8MS1252 vs AL32UTF8
?2 когда AL32UTF8 — оно возвращает из VARCHAR юникод. значения или нет ?
и как это можно проверить
Igor Korolyov
05.01.11 16:11:05
Кодировка базы определяет в каком виде ХРАНЯТСЯ строки — наподобиии фоксового CPDBF() — если данные хранятся в одной из однобайтных кодировок (WE8MS1252 равно как и CL8MSWIN1251 являются однобайтными) то в них НИКАК не сохранить юникодные данные. Более того, поскольку кодировка определяет набор допустимых символов, то в общем случае в базу с кодировкой WE8MS1252 невозможно будет записать кириллицу, а в базу с кодировкой CL8MSWIN1251 — западноевропейские спец-буковки и символы.
Однако это ещё пол-дела. Самое интересное наступает тогда, когда с базой начинает работать клиент (SSIS такой же клиент как и прочие) дело в том, что у клиента НЕЗАВИСИМО настраивается кодировка (при помощи переменной окружения NLS_LANG или одноименного ключа в реестре). Тогда клиентское ПО Oracle (или сам сервер) дополнительно проводит конвертацию из одной кодировки в другую. Конечно же преобразовать без потерь 1251 в 1252 невозможно — равно как и unicode в любую из однобайтных кодировок.
AL32UTF8 — это как раз юникодная кодировка (со внутренним представлением данных в кодировке UTF8).
К сожалению поставленные вопросы не совсем корректны чтобы можно было на них дать точный ответ. Просто мысли.
1) Записать в базу с основной кодировкой (договооримся сразу что N*CHAR поля и соответственно NLS_NCHAR_CHARACTERSET кодировку мы не рассматриваем) WE8MS1252 юникодные данные невозможно без потерь. «Потеряно» будет как минимум всё что не укладывается в рамки западноевропейских буковок (в т.ч. кириллица) — как максимум, ещё и сами западноевропейские буковки исказатся.
2) Записать в базу с основной кодировкой AL32UTF8 юникод МОЖНО — но опять же всё сильнейшим образом зависит от настроек клиента — в идеале он тоже должен быть настроен на AL32UTF8 или хотя-бы на другой юникод (например AL16UTF16).
3) Настройку NLS_LANG клиента крайне желательно делать такой-же как и настройку NLS_CHARACTERSET сервера — дабы избежать перекодировки пре передаче строковых данных.
4) Отмазка «не могу поставить» не канает. Как минимум есть Oracle 10gXE Universal, который именно юникодный и есть. Его без проблем можно локально себе установить и тестировать что надо.
КРАЙНЕ рекомендую если не внимательно прочесть, то хотя-бы ознакомится с вот этим документом (его положения в принципе и к предыдущим версиям СУБД относятся).
download.oracle.com
Гулин Федор
05.01.11 18:02:34
Игорь СПАСИБО
(вообщем то и расчитывал что ты ответишь
1 про конвертацию чего то слышал — но
3 да выставлял NLS_LANG AMERICAN_AMERICA.AL32UTF8 на удалленом ПК (точнее на удаленной виртуальной машине) — пл-скл девелопер ругался
4 поставить действительно не могу — причин масса и не только технических
— всё сильнейшим образом зависит от настроек клиента
2 ССИС это вещь в себе — но вроде пишет юникод в varchar2 — по крайней мере с пл-скл девелопера
выглядит это похоже
Гулин Федор
09.08.13 18:12:52
Игорь появлися еще один подвопрос
Оракл 11
NLS_CHARACTERSET = AL32UTF8
с win ты все объяснил
счас оракл. сервер на линуксе
я загонял скл-лоадером данные с винды ( лок. ПК)
— все ок с NLS_LANG = AMERICAN_AMERICA.AL32UTF8
потом пробую с юинкса тоже через слк-лоадер
и смотрю что данные с западными символами ок записались
даже без установки перемненной NLS_LANG
в CTL : CHARACTERSET WE8ISO8859P1
csv файлы в ANSI кодировке
в юниксе
locale :
LANG=en_US.UTF-8
LC_CTYPE=»en_US.UTF-8″
LC_NUMERIC=»en_US.UTF-8″
LC_TIME=»en_US.UTF-8″
LC_COLLATE=»en_US.UTF-8″
LC_MONETARY=»en_US.UTF-8″
LC_MESSAGES=»en_US.UTF-8″
LC_PAPER=»en_US.UTF-8″
LC_NAME=»en_US.UTF-8″
LC_ADDRESS=»en_US.UTF-8″
LC_TELEPHONE=»en_US.UTF-8″
LC_MEASUREMENT=»en_US.UTF-8″
LC_IDENTIFICATION=»en_US.UTF-8″
LC_ALL=
Bürvenich , HÖFLER Все загналось Ок
правильно ли я понял что
берется установка LANG=en_US.UTF-8
и так как она совпадает с оракл. — то промежуточных преобразований не происходит
и все ок
Igor Korolyov
10.08.13 00:09:49
Гулин Федор
правильно ли я понял что
берется установка LANG=en_US.UTF-8
и так как она совпадает с оракл. — то промежуточных преобразований не происходит
и все ок
Да. Преобразования, очевидно, делает либо сам лоадер (скорее всего), либо клиент по его указанию — ну когда из WE8ISO8859P1 делает юникод, который уже далее без преобразований поступает в БД.
Но мне кажется что есть моменты, когда всё-же лучше явно иметь переменную NLS_LANG Что-то при экспорте/импорте кажись «коротило».