Oracle Exclusive Mode

[Ogeeon]

Здравствуйте, уважаемые коллеги.
Мы планируем наконец-то обновить Oracle. Сейчас у нас 11.2.0.4, надо перейти на актуальный, 19.
Как всегда есть как минимум одно "но".
В документе https://docs.oracle.com/en/database/ora ... rades.html
написано, что учётки только со старыми версиями паролей не смогут подключаться к серверу, если установить параметру SQLNET.ALLOWED_LOGON_VERSION_SERVER значение больше 11.
Но хочется этот параметр установить в актуальное значение, чтобы воспользоваться вкусностями 19го Оракла.
Учёток, для которых DBA_USERS.PASSWORD_VERSIONS даёт только 10G, у нас несколько, при чём две из них - GAL, владельца галактической схемы, и GAL#ATLANTIS.
Все остальные пароли можно обновить, но как быть с этими двумя? Предлагаемый Ораклом вариант "просрочить" пароль и попросить пользователя зайти снова - по понятным причинам не пройдёт с этими пользователями.

Вопрос - что можно сделать в подобной ситуации?

[AlexMK]

Учёток, для которых DBA_USERS.PASSWORD_VERSIONS даёт только 10G, у нас несколько, при чём две из них - GAL, владельца галактической схемы, и GAL#ATLANTIS.
Все остальные пароли можно обновить, но как быть с этими двумя? Предлагаемый Ораклом вариант "просрочить" пароль и попросить пользователя зайти снова - по понятным причинам не пройдёт с этими пользователями.

Вопрос - что можно сделать в подобной ситуации?

а почему Вы думаете, что не пройдет ?

1) аккаунт владельца схемы НИКОГДА не используется для создания сессии путем логина.
на сколько мне помнится у него привилегия CREATE SESSION даже не назначается.
так что можете на этого "юзера" поставить пароль вообще какой вздумается.

2) что касается GAL#ATLANTIS ... то пароль у него "известный" - ваш АБД или человек из сапорта, который вашу организацию курирует этот пароль вам "раскроет"

только имейте в виду то, что все инсталляции SQL*NET на клиентских машинах нужно будет обновить до адекватной версии.

[VAt]

Удалось ли вам обновить БД? Через какой способ мигрировали?

[Ogeeon]

Пока переход приостановили по организационным причинам.
Но на тестовом сервере всё нормально прошло через DBUA. hcheck.sql никакого криминала не нашёл, рекомендации preupgrade.jar я выполнил, и всё гладко обновилось.