DBAshnikandrey_anonymousпропущено...
Проблема - в отсутствии базовых представлений о механизмах Globalization Support в оракеле.
обоснуй, пожалуйста? В чём конкретно это отсутствие? В том, что NLS_LANG не имеет отношения к nvarchar2, nclob и т.п.
Имеет-имеет. Для OCI-клиентов, что и было подремонстрировано
Главное для понимания работы NLS - осознать, что все эти переменные/пропертя и т.п. относятся к КЛИЕНТУ.
НЕ к серверу.
Клиент должен честно задекларировать - в какой кодировке он собирается работать.
И работать в задекларированной кодировке.
388 страниц GSG лучше, конечно, осилить - там много интересного и помимо кодировок, суперсетов и т.п..
Но НЕ ВРАТЬ и не выёживаться "от большого ума" - самый главный секрет :)

DBAshnikкто чего конкретно врал????
кто в чём конкретно выёживался????
Попытки установить NLS_LANG в AL16UTF16 - суть попытка солгать серверу про чарсет исходных данных.
Попытки выполнить convert в тот же AL16UTF16 в приложении - суть выёживание.
По факту в случае OCI следовало выставить в NLS_LANG кодировку данных в файлах, в случае же java/jdbc - указывать реальную кодировку данных в этих самых файлах ридеру, что привело бы к трансляции данных в уникодицу и далее - по отлаженной колее в оракель.
...кстати, о птичках.
Не знаю, умеет ли Talend загонять данные в оракеля лодырем (SAS, ODI и даже пентаха коммьюнити - умеют), но ежели умеет - следует, как минимум, рассмотреть этот подход.

Dimitry SibiryakovЕМНИП, UTF16 не может быть использована в качестве кодировки для
NLS_LANG или инициализации Environment OCI.

Откуда дровишки?
AFAIR, ограничение по UTF16 другое - его нельзя назначить database characterset-ом. Только National Characterset-ом.
Про ограничение на клиенте OCI что-то не припоминаю.
По джаве - до java5 внутренней кодировкой джавы был UCS2, после - UTF-16, который является strict superset-ом UCS2.

andrey_anonymousПро ограничение на клиенте OCI что-то не припоминаю.
Спасибо, Дмитрий - буду знать.
Как минимум, sqlplus под win cmd c al16utf16 не работает.
Как и сама консоль:
кодовые страницы utf-16 (1200 и 1201 согласно https://docs.microsoft.com/en-us/windows/desktop/intl/code-page-identifiers) доступны только для managed applications.
Вероятно, первое суть следствие второго.
Надо будет попробовать под другими платформами.

andrey_anonymousКак минимум, sqlplus под win cmd c al16utf16 не работает.
В базе NLS клиента кодировке AL16UTF16 соответствует файл lx207d0.nlb, каковой имеется в наличии (locale builder не даст соврать).
По ходу дело все-таки не в самой кодировке, а в ее поддержке консолью.

Dimitry SibiryakovOCI GuideOCI_UTF16ID is also allowed as a character set ID in the
OCIEnvNlsCreate() function, although this ID is not valid in NLS_LANG or
NLS_NCHAR.

Ну да. Т.е. вообще в OCI можно, но вот конкретно в консоли - нельзя.
Почитал тут линуксоидов - объясняют возможностью наличия null-символа в utf-16 строке, что противно пионерскому духу классической C-строки. А потому нельзя сгенерировать локаль utf-16.
Раз нельзя локаль сгенерировать - то нельзя и консольные утилиты с такой некошерной кодировкой запускать.
Логично же, чо :)
Остались окошечные managed applications, ибо писанные на C юниксы по ходу отвалились как класс, а прочие VAX/VMS-ы и подавно.
Не знаю, насколько OCI вообще дружен с managed...