Приветствую, коллеги. Как сейчас принято выгружать пользователей из Oracle Database 9.2.0.8 в Oracle Database 19.x? Хотел бы сохранить текущий пароль пользователя при переезде с 9.2 на 19. Утверждается, что это не возможно и это позиция компании Oracle. Кто прав?

PuM256, не понял Ваш ответ. Задача уточнилась. Утверждается, что функция Oracle зависит от имени пользователя. В нашем случае при переезде из локальной БД в общую необходимо каждому пользователю заменить имя пользователя (create user 01LIV ...). Я написал позже, чем написал первый пост. Сомнение у меня в том, что функция, которая считает hash value зависит от логина и при смене LIV -> 01LIV значение этой функции, рассчитанное для LIV будет отличаться от значения функции для 01LIV.

Вопрос закрыт, пересозданием пользователя с паролем равным логину. Централизация БД она такая, один конец в прошлом, другой в будущем. Запрос в тех. поддержку Oracle открыл, помучаю америкосов немного своим плохим английским. Но что-то мне, математику, говорит, что вопрос тривиален - hash-функция с большой вероятностью зависит не только от пароля пользователя СУБД и даже в одном экземпляре Oracle database скорее всего все hash-значения уникальны. Но я могу ошибаться.

Завершил расследование темы с поддержкой Oracle. Всё совсем не просто. оказывается. Oracle не раскрыл по непонятной мне причине, какую функцию они используют для получения hash value пароля (we cannot divulge information on HOW the HASH values work or where they come from (I am sure you understand :)). Мне, как математику это не понятно - если функция хэширования достаточно хороша, то в теории невозможно по ее значению вычислить ее аргументы?

Начиная с 11g я даже не могу увидеть hash-значение. Убрали из USERS$. Отправили в My Oracle Support Community (MOSC)) - URL https://community.oracle.com/mosc/categories/database_security_products

Полезные документы:
Oracle Password Management Policy (Doc ID 114930.1)
User Passwords Are No Longer Visible In DBA_USERS As Of 11g (Doc ID 735651.1)
18c: All user connections fail with ORA-01017 except SYS when SEC_CASE_SENSITIVE_LOGON=FALSE (Doc ID 2502204.1)

Вячеслав Любомудров, спасибо за пример кода. Странно. Поддержка Oracle утверждает, что в 19c я не могу использовать hash value от 9.2.0.8., я так понял их ответ.

Запрос 1.
When source database is Oracle9i or lower release, you’ll have to run a database export with the original export client. Starting with Oracle10g you can use Data Pump.

Запрос 1.1 (открыли сами).
Secondly and related to the second part of your question, we cannot divulge information on HOW the HASH values work or where they come from (I am sure you understand :)
So I can only provide you generic information on passwords and differences between 9i and 19c.
However, based on the large change between even 11g and 19c with respect to Passwords and Security, I can only really convey information between 11g and up. From 11g onwards, you will no longer be able to even view the password HASH values that were visible in older versions. For security reasons, it was removed from the USER$ table / view. So you have quite a large jump with what password information you can access between 9i and 19g.

Проверил на целевой БД Oracle 19c. По всем пользователям select * from dba_users даёт NULL в поле PASSWORD.
select * from user$ даёт ORA-00942. Видимо не хватает прав под моим логином либо Oracle спрятал и от SYS USER$
Исходная БД была Oracle 9.2.0.8, сейчас проверил, тоже NULL (под пользователем SYS). select * from user$ даёт PASSWORD при этом.

Добавлю, перенос пользователей я уже сделал, в любом случае при переезде в общую БД пришлось менять имя пользователя и hash-значение скорее всего не подошло бы для нового пользователя в общей БД.

Мне все равно не понятно, почему поддержка Oracle отказалась сообщить, какую функцию они используют для хэширования паролей. Сослались на некий внутренний алгоритм шифрования.
When you create a user you set whatever password you want, but the way it is stored (this hash value you’re talking about) depends on an internal encrypted algorithm.

Вау.