Добрый день всем.

Вот похожеая проблема https://github.com/laurenz/oracle_fdw/issues/334

Конверчу данные с помощью утилиты ora2pg все ОК но есть одна таблица с записяфми где я получаю
2021-07-30T08:49:26.4066130Z [2021-07-30 08:49:26] ERROR (log error enabled):
ERROR: invalid byte sequence for encoding "UTF8": 0xed 0xa7 0x98

create table dnproperty
( ..
value VARCHAR2(4000 CHAR),
) ; вот это поле

Вот нахожу проблемыне записи
SELECT value , CONVERT( value , 'AL32UTF8', 'UTF8' ) u8
, a.*
FROM dnproperty a
where
value != CONVERT( value , 'AL32UTF8', 'UTF8' )

В осн. японские ирегоилфсыф типа 😉
В одной схеме была 1 запись ну я удалил символ
но вот в 2-й схеме уже таких записей 2000+
и пока как то не хочется портить информацию

Решение на стороне оракла такое понятно :
update bad_table set bad_columm = convert(bad_column,'AL32UTF8','UTF8');

На стороне оракла c кОнстаантами работает врод ок :
SELECT '😉' as t1 , CONVERT( '😉' , 'AL32UTF8', 'UTF8' )
, CONVERT( '😉' , 'UTF8', 'AL32UTF8' ) as b2_conv
, case when '😉' = CONVERT( '😉' , 'AL32UTF8', 'UTF8' ) then 0 else 1 end diff1
from dual ;

но в скл в CONVERT(, 'AL32UTF8', 'UTF8' ) поле показывает квадратики - т.е НЕ корректно

Если забить напрямую в Dbeaver постгрес скл
create table a0_ois_dev ( c varchar(2000), d date );
insert into a0_ois_dev ( c) values ( '😉') ;
тоже все вставляет ОК.

Есть ли какой то трюк чтоб корректно данные скопиоавуать ?


ps объяснение причины мне понятно - а вот РЕШЕНИЕ НЕТ.
You are correct in that the difference between
al32utf8 and utf8 is in better support for supplementary characters with
al32utf8.
If supplementary characters are inserted in a UTF8 database, they will be
treated as 2 separate undefined characters, occupying 6 bytes in storage.
Oracle recommends using al32utf8 for any newly defined supplementary
characters.

Ок - допустим причина в этом.

мне надо конвернтнуть в utf8 постгрес корректно
'😉' - можно вставить данные прямо в пострес корректно

условием value != CONVERT( value , 'AL32UTF8', 'UTF8' ) я нашел проблемные записи.
проблема тогда возможно на стороне ora2pg


но вот корректного решения-воркараунда не вижу.
Его и ищу.

Проконтролировать байты проблемных записей на каждом шаге цепочки не предлагать?..

Не понял идеи от слова совсем
записи которые некорректно конвертятся ora2pg я нашел
и даже конкретный иероглиф найду если надо - не проблема.

@Vadim Lejnin
select * from v$nls_parameters ;

NLS_CHARACTERSET AL32UTF8
env. var : NLS_LANG=American_America.UTF8

Но процесс запускается через yml и докер - надо проверить откуда берется переменная и ее значение.
(м.б в этом и причина)

@Elic СПс за ссылки почитаю мат. часть

Смотришь какие байты лежат в Оракуле (DUMP).
Смотришь какие байты приходят в ora2pg.
Смотришь какие байты он отправляет в PG.
Смотришь какие байты приходят в PG и лежат там.

Сравниваешь. Эти байты должны быть абсолютно одинаковые на каждом этапе.


нет никакого дампа оракла
из лога ora2pg
2021-07-30T08:49:26.4066130Z [2021-07-30 08:49:26]
ERROR (log error enabled): ERROR: invalid byte sequence for encoding "UTF8": 0xed 0xa7 0x98
вот 3 байта которы ora2pg считает Не верными
из за того что он НЕ пишет эту запись в постгрес ничего нет естественно.
мало того что нет этой записи (пол-беды) - НЕТ всего батча с корректными остальными записями
(или возможно нет части батча с этой Не корректной с точки зрения ora2pg записи - тут точно не скажу )
(я по моему выставлял размер батча 10000 это настраивается в ora2pg.config)
Для предыдущей схемы я нашел единственную запись и просто удалил этот японский символ (там документ 2014 года - архивный по сути)
но тут 2000+ записей и так поступать пока не хочется (как минимум надо будет апрув запрашивать у кастомера)

а вот это очень интересно - сейчас попробую
правда там ранится из докера (я пока не понимаю как там подтягиваются env. переменные )
но это похоже на правду