Галактика в вопросах и ответах

Здравствуйте, уважаемые коллеги.
Мы планируем наконец-то обновить 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.
Все остальные пароли можно обновить, но как быть с этими двумя? Предлагаемый Ораклом вариант "просрочить" пароль и попросить пользователя зайти снова - по понятным причинам не пройдёт с этими пользователями.

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

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

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

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

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

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

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

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

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