1. データベース・アップグレード・ガイド
  2. Oracle Databaseのアップグレード後の作業
  3. Oracle Databaseのアップグレード後に必要な作業

Oracle Databaseのアップグレード後に必要な作業

アップグレードの完了後、現在の環境に対して指定されたこれらの必要な作業を確認して完了します。

Oracle Databaseをアップグレードした後で、次のアップグレード後タスクを実行する必要があります。

親トピック: Oracle Databaseのアップグレード後の作業

手動アップグレード後のLinuxおよびUnixシステム上での環境変数の設定

必要なオペレーティング・システムの環境変数が、新しいOracle Databaseリリースのディレクトリを指していることを確認します。

通常、オペレーティング・システムの環境変数は、プロファイルおよびシェル・スクリプトで設定します。次のOracleユーザー環境変数が新しいOracleホームのディレクトリを指していることを確認します。

  • ORACLE_HOME

  • PATH

以前のリリースのOracleホームを参照する他の環境変数(LD_LIBRARY_PATHなど)を探します。通常、環境変数内のすべての古いOracleホームを新しいOracleホーム・パスに置き換える必要があります。

関連項目

親トピック: Oracle Databaseのアップグレード後に必要な作業

データベース内の無効なオブジェクトの再コンパイル

データベースをインストール、パッチ適用またはアップグレードした後、再コンパイル・ドライバ・スクリプトを使用して、CDBおよびPDB上の無効なオブジェクトを再コンパイルします。

Oracleには、再コンパイル・スクリプトutlrp.sql、utlprp.sqlおよびutlprpom.sqlが用意されています。これらのスクリプトは、Oracle_home/rdbms/adminディレクトリにあります。

ノート:

AutoUpgrade 23.1以降、AutoUpgradeユーティリティを実行すると、AutoUpgradeによってutlprpom.sqlスクリプトが実行され、utlrp.sqlは実行されません。Oracle Database 12cリリース2 (12.2.0.1)以降のリリースへのアップグレードにAutoUpgradeを使用すると、AutoUpgradeはOracle管理スキーマが所有する無効なオブジェクトのみを再コンパイルします。データベースのアップグレードではユーザー・オブジェクトにアクセスする必要がないため、AutoUpgradeは無効なオブジェクトを再コンパイルするときにこのポリシーを維持します。

データベースのインストール後、次の手順ですべての無効なオブジェクトを再コンパイルします。

  1. ディレクトリをOracle_home/rdbms/adminに変更します。たとえば 

    $ cd $ORACLE_HOME/rdbms/admin

  2. Oracleホームのcatcon.plスクリプトを使用して、utlrp.sqlを実行します。たとえば: 

    $ORACLE_HOME/perl/bin/perl catcon.pl --n 1 --e --b utlrp --d '''.''' utlrp.sql

    この使用例では次の点に注意してください。

    • --nパラメータ: 1に設定されているため、各PDBの再コンパイルは順番に実行されます。

    • --eパラメータ: エコーをオンにします。
    • --bパラメータ: ログ・ファイルのベース名を設定します。utlrpに設定されています。

    PDBのシリアル再コンパイルが完了するまでの時間の遅延を予期してください。アップグレードするPDBの数によっては、再コンパイルは、アップグレード・スクリプトの完了に要する時間を大幅に超えて延長される可能性があります。

    utlrp.sqlスクリプトは、無効なオブジェクトの数と使用可能なCPUの数の両方に基づいて、シリアル再コンパイルまたはパラレル再コンパイルで無効なオブジェクトを自動的に再コンパイルします。CPUは、CPUの数(cpu_count)にCPUごとのスレッドの数(parallel_threads_per_cpu)を乗じて計算されます。Oracle Real Application Clusters (Oracle RAC)では、すべてのOracle RACノード全体でこの数が追加されます。

データベースにパッチを適用またはアップグレードした後、無効なOracle所有オブジェクトおよびユーザー所有オブジェクトを再コンパイルするには複数のアプローチがあります。

utlrp.sqlまたはutlprp.sqlを使用して、すべての無効なオブジェクト(Oracleとユーザー・スキーマの両方で無効なオブジェクト)を再コンパイルします。

時間的な要因があり、無効なオブジェクトのタイプが主にアプリケーション所有のものである場合、Oracle所有の無効なオブジェクトを最初に再コンパイルし、アプリケーション所有の無効なオブジェクトの再コンパイルを後回しにできます。Oracleスキーマで無効なオブジェクトを再コンパイルするには、utlprpom.sqlを使用します。残りの無効なオブジェクトを再コンパイルするには、utlrp.sqlまたはutlprp.sqlを使用します。

ノート:

utlprp.sqlまたはutlprpom.sqlを使用する場合、どちらのスクリプトでも、スクリプトで使用する並列度を定義するか、使用するパラレル再コンパイル・ジョブの数を決定する必要があることに注意してください。

このスクリプトでは次の構文を使用します。baseはログ・ファイルに指定するベース名、Nは再コンパイル・ジョブをパラレルで実行するPDBの数(並列度)、script.sqlは使用するよう選択したOracle再コンパイル・スクリプト、Pはパラレルで実行するPDBの数です。 

$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -b base -d $ORACLE_HOME/rdbms/admin
          -n N -l /tmp script.sql '--pP'

ログ・ファイルのベース名recompを使用してCDBで再コンパイルを実行し、並列度の設定はPDBコンテナごとに3件のジョブとし、使用するよう選択するスクリプトはutlprp.sqlで、一度に最大10個のPDBにわたって再コンパイルするとします。この場合、再コンパイル操作の実行に使用する構文は次のようになります。 

$ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -b recomp -d $ORACLE_HOME/rdbms/admin -n 10 -l /tmp utlprp.sql '--p3'

関連項目

親トピック: Oracle Databaseのアップグレード後に必要な作業

無効なオブジェクトの再コンパイルの進行状況の追跡

これらのSQL問合せを使用して、utlrp.sqlスクリプトによる無効なオブジェクトの再コンパイルの進行状況を追跡します。

ノート:

AutoUpgradeユーティリティを使用してアップグレードした場合、AutoUpgradeがアップグレード中に自動的にこのタスクを処理します。このタスクを実行する必要はありません。

アップグレード後にutlrp.sqlスクリプトを実行して無効なオブジェクトを再コンパイルすることをお薦めします。SQL問合せを実行してスクリプトを監視できます。

例7-4 残っている無効なオブジェクトの数

次の問合せを入力すると、残っている無効なオブジェクトの数が返されます。この数は、utlrp.sqlスクリプトの実行につれて時間とともに減少します。 

select COUNT(*) "OBJECTS WITH ERRORS" from obj$ where status in (3,4,5,6);

例7-5 再コンパイルされたオブジェクトの数

次の問合せを入力すると、utlrp.sqlによってコンパイルされたオブジェクトの数が返されます。この数は、スクリプトの実行につれて時間とともに増加します。 

SELECT COUNT(*) FROM UTL_RECOMP_COMPILED;

例7-6 エラー付きで再コンパイルされたオブジェクトの数

次の問合せを入力すると、utlrp.sqlによってエラー付きでコンパイルされたオブジェクトの数が返されます。 

select COUNT(DISTINCT(obj#)) "OBJECTS WITH ERRORS" from utl_recomp_errors;

この数が予想より多い場合、各オブジェクトでレポートされたエラー・メッセージを確認してください。エラーの原因がシステムの間違った構成やリソース制約にある場合、それらのエラーの原因を修正してutlrp.sqlを再度実行します。

親トピック: Oracle Databaseのアップグレード後に必要な作業

Oracle RACクラスタ・メンバーのアップグレードでのリスナー・ファイルの場所の更新

共有Oracleベース・ホームを使用せず、Oracle Real Application Clustersメンバー・ノードであるOracle Databaseインスタンスでアップグレードを実行する場合は、リスナー・パスを更新する必要があります。

共有Oracleベース・ホームを使用せず、Oracle Real Application Clustersクラスタ・メンバー・ノードであるOracle Databaseインスタンスでアップグレードを実行する場合に、Database Configuration Assistant (DBCA)を使用しないと、すべてのリモートtnsnames.oraファイルを手動で更新する必要があります。ファイルが更新されていない場合、次のエラーが発生します。 

TNS-03505: Failed to resolve name

Oracle Database 21c以降、デフォルトのネットワーク管理ディレクトリは、ローカルのOracleホームの以前のデフォルトであるOracle_home/network (/u01/app/oracle/product/19.1.0/dbhome_1/networkなど)から新しい場所に変更されます。新しいデフォルトの場所は、パスORACLE_BASE/homes/HOME_NAME/network/adminの共有Oracleベース・ホームです。たとえば、/u01/app/oracle/homes/OraDB20Home1/network/adminは特定のOracle Real Application Clusters (Oracle RAC)インスタンスのOracleホームで、読取り専用Oracleホームのデフォルト・パスにあります。そのファイル・パスは、ローカルのtnsnames.oraおよびsqlnet.oraファイルのデフォルトの場所です。

アップグレード中に、Net Configuration Assistant (NetCAまたはnetca)によって、ローカル・ホスト上のネットワーク・リスナー・ファイルtnsnames.oraおよびsqlnet.oraの場所が更新されます。ただし、NetCAは、すべてのクラスタ・メンバー・ノードのインスタンスのネットワーク・リスナー・ファイルの場所を更新するわけではありません。すべてのクラスタ・メンバー・ノードで、アップグレードされたクラスタ・メンバー・ノード・インスタンスに対するサービス・リクエストを解決できるようにするには、次のいずれかを実行する必要があります。

  • 各クラスタ・メンバー・ノードで、tnsnames.oraファイルとsqlnet.oraファイルを既存の場所からORACLE_BASE/homes/HOME_NAME/network/admin/に手動でコピーします。
  • アップグレードされたクラスタ・メンバー・ノードの環境変数を、既存のネットワーク管理ファイルの場所を指すように設定します。

p

回避策を確認するには: -----------tnsnames.oraおよびsqlnet.oraを$ORACLE_BASE/homes/OraDB20Home1/network/admin/sqlnet.oraにコピーまたはTNS_ADMIN=$ORACLE_HOME/network/adminをエクスポート

例7-7 TNSNAMES.ORAおよびSQLNET.ORAを新しいデフォルト・ネットワーク管理ディレクトリにコピー

この例では、既存のtnsnames.oraおよびsqlnet.oraファイルを、各クラスタ・メンバー・ノード上の新しいデフォルトのネットワークの場所にコピーします。

  1. Oracleインストール所有者としてログインし、以前のリリースのネットワーク管理ディレクトリにディレクトリを変更します。たとえば:

    cd $ORACLE_HOME/network
  2. セキュア・コピー(scp)を使用して、リスナー・ファイルを別のクラスタ・メンバー・ノード上のデフォルトのネットワーク・ディレクトリの場所にコピーします。たとえば、racnode2は、リスナー・ファイルをコピーするクラスタ・メンバー・ノードです。
    cd $OLD_ORACLE_HOME/network
scp tnsnames.ora sqlnet.ora \
oracle@racnode2:/u01/app/oracle/homes/OraDB20Home1/network/admin/

例7-8 TNS_ADMIN環境変数の設定

アップグレードされたノードで、Oracleユーザーとしてログインし、既存のリスナー・ファイルの場所を指すようにTNS_ADMINの環境変数を設定します。たとえば: 

/home/oracle oracle> $ export TNS_ADMIN=$ORACLE_HOME/network/admin

親トピック: Oracle Databaseのアップグレード後に必要な作業

Oracle Databaseのアップグレード後にoratabおよびスクリプトが新しいOracleの場所を指すようにするための設定

スクリプトで新しいOracleホームの場所が指し示されている必要があります。

Oracle Databaseを新しいリリースにアップグレードした後は、oratabファイル、およびORACLE_HOMEの値を設定するすべてのクライアント・スクリプトで、新しいOracle Databaseリリース用に作成された新しいOracleホームが指し示されています。AutoUpgradeとリプレイ・アップグレードでは、自動的に、oratabで新しいOracleホームが指し示されるようになります。ただし、アップグレードに使用する方法にかかわらず、クライアント・スクリプトを確認する必要があります。

関連項目

親トピック: Oracle Databaseのアップグレード後に必要な作業

PL/SQLパッケージおよび依存プロシージャの確認

以前のリリースのOracle Databaseにインストールしたパッケージは新しいリリースでは使用できない可能性がありますが、これはアプリケーションに影響する場合があります。

アップグレード後、AutoUpgradeを使用する場合は、無効なオブジェクトに関するAutoUpgradeレポートを確認します。リプレイ・アップグレードを使用する場合は、独自のスクリプトで使用していたパッケージまたは独自のスクリプトからコールしていたパッケージがすべて新しいリリースで使用できることを確認してください。パッケージに依存するプロシージャのテストは、アップグレード計画に含まれる必要があります。

データベース・アプリケーションのコードは、接続先データベースのオブジェクトを参照できます。たとえば、Oracle Call Interface(OCI)およびプリコンパイラ・アプリケーションは無名PL/SQLブロックを発行できます。Oracle Formsアプリケーションのトリガーは、スキーマ・オブジェクトを参照できます。これらのアプリケーションは、参照しているスキーマ・オブジェクトに依存しています。依存性管理の方法は開発環境によって異なります。Oracle Databaseでは、アプリケーションの依存性が自動的に追跡されることはありません。

関連項目

親トピック: Oracle Databaseのアップグレード後に必要な作業

Oracle管理タイプに依存する表のアップグレード

Oracle Database 12cリリース2 (12.2)以降では、Oracle管理タイプに依存するユーザー表を手動でアップグレードする必要があります。

ノート:

AutoUpgradeユーティリティを使用してアップグレードした場合、AutoUpgradeがアップグレード中に自動的にこのタスクを処理します。このタスクを実行する必要はありません。

Oracle管理タイプに依存するユーザー表(AQキュー表など)がデータベースに含まれる場合、アップグレード後にutluptabdata.sqlコマンドを実行して、Oracle管理タイプの変更の影響を受けるすべてのユーザー表に対してALTER TABLE UPGRADEを実行します。この動作変更によって、ユーザー表は、アップグレード中にREAD ONLY状態のままになります。ユーザーは、SYSDBA権限(AS SYSDBA)を使用してアプリケーションにログインし、Oracle管理タイプに依存するアプリケーション表を変更できなくなります。

データベース・アップグレードの完了後にアップグレードする必要がある表を特定するには、データベースにAS SYSDBAで接続し、次の問合せを実行します。 

COLUMN owner FORMAT A30
COLUMN table_name FORMAT A30
SELECT DISTINCT owner, table_name
FROM dba_tab_cols
WHERE data_upgraded = 'NO'
ORDER BY 1,2;

この問合せによって、UPGRADEDとしてリストされないすべての表が示されます。ただし、utluptabdata.sqlスクリプトは、Oracle管理タイプに依存する表のみをアップグレードします。問合せによって表がリストされた場合、utluptabdata.sqlスクリプトを実行して依存ユーザー表にALTER TABLE UPGRADEコマンドを実行し、これらのOracle管理タイプをそのタイプの最新バージョンにアップグレードします。

utluptabdata.sqlスクリプトは、Oracle管理タイプに依存するすべての表に対するALTER権限を持つユーザー・アカウントか、またはAS SYSDBAでログインしているSYSDBAシステム権限を付与されたユーザーを使用して実行する必要があります。

パラメータSERVEROUTPUTがONに設定されている場合、utluptabdata.sqlスクリプトによって、アップグレードされたすべての表の名前が表示され、表のアップグレード中に発生したエラーがリストされます。サーバー出力をONに設定するには、次のコマンドを実行します。 

SET SERVEROUTPUT ON
@utluptabdata.sql

親トピック: Oracle Databaseのアップグレード後に必要な作業

Oracle Databaseのアップグレード後のOracle Textが提供するナレッジ・ベースのインストール

Oracle Textナレッジ・ベースに対してユーザーが拡張した項目は、Oracle Databaseアップグレード後に再生成する必要があります。

ユーザー拡張を再生成すると、指定したOracleホームにインストールされているすべてのデータベースに影響を与えます。

Oracle Textが提供するナレッジ・ベースは新しいOracle Databaseの付属製品の一部ですが、アップグレード後すぐに使用することはできません。アップグレード前には使用可能であったナレッジ・ベースに依存するOracle Textの機能は、アップグレード後には機能しなくなります。これらの機能を再度使用可能にするには、Oracle Textナレッジ・ベースを新しいOracle Databaseリリースのインストール・メディアからインストールする必要があります。

参照:

親トピック: Oracle Databaseのアップグレード後に必要な作業

以前のリリースのOracle APEXの削除

無効なオブジェクトを回避するには、Application Express (APEX) 19.1より前のOracle APEXリリースを削除します。

パッケージDBMS_OBFUSCATION_TOOLKITはOracle Database 11gリリース2 (11.2)で非推奨になりました。Oracle Database 21c以降、DBMS_OBFUSCATION_TOOLKITはサポート対象外になり、DBMS_CRYPTに置き換えられました。Oracle Database 21cより前のリリースでは、Oracle APEXは継続してDBMS_OBFUSCATION_TOOLKITに依存していました。APEXリリース19.2を含むOracle Database 21cでは、この依存性が削除されました。

Oracle Databaseのアップグレード中、APEXはOracle Databaseリリースに付属のリリースに自動的にアップグレードされません。アップグレード前に、preupgradeパラメータを使用してAutoUpgradeを実行すると、出力upgrade.xmlファイルに、APEX 19.1.0.00.15より前のAPEXリリースをアップグレードする必要があることが示されます。これは、以前のリリースがDBMS_OBFUSCATION_TOOLKITに依存しているためです。

INVALIDオブジェクトを回避するには、Oracle Databaseをアップグレードする前または後のいずれかで、APEXを少なくともOracle Database 21cに付属するバージョンにアップグレードしてから、APEXの以前のリリースを削除する必要があります。

  1. 新しいOracle DatabaseのOracleホームにログインします
  2. Oracle APEXを、Oracleホーム(APEX 19.2)に同梱されているOracle Application Express 19.2以上、またはそれ以降のバージョンが使用可能な場合は、それを使用してOracle Application Expressをアップグレードします
  3. 以前のリリースのAPEXユーザーを削除します。

    たとえば:

    drop user APEX_050000 cascade;
drop user APEX_040200 cascade;
drop user APEX_030100 cascade;
  4. 以前のリリースのAPEX SYSが所有するオブジェクトを削除します。

    たとえば:

    drop package SYS.WWV_DBMS_SQL;

ノート:

Oracle APEX 18c (18.1)以降では、SYS.WWV_DBMS_SQLオブジェクトにはOracle APEXリリース・スキーマが追加されています。

たとえば:

SYS.WWV_DBMS_SQL_APEX_180100

親トピック: Oracle Databaseのアップグレード後に必要な作業

読取り専用OracleホームでのDEMOディレクトリの置換

読取り専用Oracleホームをアップグレードした後、以前のリリースのOracle Databaseのdemoディレクトリをコピーし、読取り専用Oracleホームのdemoディレクトリを新しいリリースのdemoディレクトリに置き換えます。

Oracle Database 18c以上のリリースでは、ファイル・パスOracle_home/rdbms/demoに製品デモンストレーション・ディレクトリが含まれています。これらのディレクトリには、各Oracle Databaseリリースのオプションと機能に固有の例と製品デモンストレーションが含まれています。これらの一部は、Oracle Database Examplesをインストールすると、アップグレード後に追加できます。以前のリリースでは、以前のリリースのデモンストレーション・ファイルを使用してダウンロードして作業した場合、2つの問題があります。新しいリリースでレビューおよびテストするために以前のリリースの作業を保存する必要があること、および新しいリリースに固有のデモンストレーションのリフレッシュを取得する必要があることです。

Oracleホームをアップグレードした後、新しいデモンストレーション・ファイルで実行する他の作業をダウンロードして実行したら、古いデモンストレーション・ファイルをリフレッシュできます。

例7-9 以前のリリースのDemoディレクトリのコピーおよび読取り専用Oracleホームでのデモンストレーションのリフレッシュ

アップグレード後に、この手順を使用して、以前のdemoディレクトリの作業を読取り専用Oracleホームに保存し、以前のリリースのdemoディレクトリを新しいリリースのdemoディレクトリで置き換えます。

  1. Oracleソフトウェア所有者ユーザー(oracle)としてログインします。

  2. rdbms/demoディレクトリが読取り専用Oracleホームにコピーされているかどうかを確認します。

    この例では、環境変数ORACLE_BASE_HOMEが読取り専用Oracleホームのパスとして定義されています。

    LinuxおよびUNIXプラットフォーム:

    $ ls -l -d $ORACLE_BASE_HOME/rdbms/demo
/u01/app/oracle/product/19.0.0/dbhome_1/rdbms/demo

    Microsoft Windowsプラットフォーム

    ls -l -d %ORACLE_BASE_HOME%\rdbms\demo 
%ORACLE_BASE_HOME%\rdbms\demo

  3. ディレクトリを読取り専用Oracleホームに変更し、コピーを作成します。ここで、demo.old_release18は以前のリリースのデモンストレーション・ファイルに指定する名前です。 

    cd $ORACLE_BASE_HOME/rdbms
mv demo demo.old_release18

  4. 新しいdemoディレクトリをアップグレードされたOracleホームから読取り専用Oracleホームにコピーします。

    この例では、環境変数ORACLE_HOMEが新しいリリースのOracleホームとして定義されています。

    LinuxおよびUNIX:

    cp -r $ORACLE_HOME/rdbms/demo demo

    Microsoft Windows

    xcopy c:\%ORACLE_HOME%\rdbms\demo c:%ORACLE_BASE_HOME%\rdbms\demo /E

親トピック: Oracle Databaseのアップグレード後に必要な作業

外部ネットワーク・サービスへのアクセス制御リスト(ACL)の構成

Oracle Database 12c以降のリリースには、UTL_TCP、UTL_SMTP、UTL_MAIL、UTL_HTTPまたはUTL_INADDRパッケージに対するファイングレイン・アクセス制御が含まれています。

これらのパッケージを使用するアプリケーションがある場合、Oracle Databaseのアップグレード後に、データベースのネットワーク・アクセス制御リスト(ACL)を構成してから、影響を受けるパッケージを前のリリースと同様に動作させる必要があります。ACLがない場合、エラー「ORA-24247: アクセス制御リスト(ACL)によりネットワーク・アクセスが拒否されました」でアプリケーションが失敗する可能性があります。

参照:

一部のユーザーはホストAに接続し、別のユーザーはホストBに接続するなど、より複雑な状況については、Oracle Databaseセキュリティ・ガイドを参照してください

親トピック: Oracle Databaseのアップグレード後に必要な作業

Oracle Databaseのアップグレード後のOracle Database Vaultの有効化

ターゲットのデータベース・リリースによっては、Oracle Database Vaultを再度有効にするか、アップグレードのために付与されたOracle Database Vaultロールを取り消す必要がある場合があります。

親トピック: Oracle Databaseのアップグレード後に必要な作業

Oracle Database Vaultの無効化なしでのOracle Databaseのアップグレード

Oracle Database 12cリリース2 (12.2.0.1)以降のリリースにアップグレードするには、ルート・コンテナでDV_PATCH_ADMINロールをSYSに共通に付与してアップグレード後に取り消すか、アップグレード後にOracle Database Vaultを無効にして再度有効にします。

Oracle Database Vaultが有効になっており、CDB全体をアップグレードする場合は、次のいずれかの方法を使用します。

  • CDBアップグレード方法1: DV_OWNERロールを持つ共通ユーザーとしてルート・コンテナにログインしてから、GRANT DV_PATCH_ADMIN TO SYS CONTAINER=ALL文を発行することで、DV_PATCH_ADMINをユーザーSYSに一時的に付与します。Oracle Database Vaultの制御は、アップグレード前と同じ状態になります。アップグレードが完了した後は、DV_OWNERユーザーとしてルート・コンテナにログインし、REVOKE DV_PATCH_ADMIN FROM SYS CONTAINER=ALL文を発行してSYSからDV_PATCH_ADMINロールを取り消します。
  • CDBアップグレード方法2: DV_OWNERロールを持つユーザーとして各コンテナにログインしてから、DBMS_MACADM.DISABLE_DVプロシージャを実行します。最初にPDBでOracle Database Vaultを無効にしてから、最後にルート・コンテナでOracle Database Vaultを無効にする必要があります。PDBを1つのみアップグレードしている場合は、そのPDBでのみOracle Database Vaultを無効にできます。アップグレードが完了した後は、DV_OWNERユーザーとして各コンテナにログインしてからDVSYS.DBMS_MACADM.ENABLE_DVプロシージャを実行することで、Oracle Database Vaultを有効にできます。Oracle Database Vaultを有効にする順序は、最初にルート・コンテナで、その後にPDBで有効にする必要があります。PDBは任意の順序で有効にできますが、最初にルート・コンテナを有効にする必要があります。

アップグレード前に手動でOracle Database Vaultを無効にした場合は、アップグレード後に手動でOracle Database Vaultを有効にする必要があります。

アップグレード前にOracle Database Vaultを有効にしていなかった場合は、アップグレード後に手動で有効にできます。

ノート:

この手順は、非CDBアップグレードにも適用されます

関連項目

親トピック: Oracle Databaseのアップグレード後のOracle Database Vaultの有効化

Oracle Database Vaultでのアップグレード後のシナリオ

ターゲットのOracle Databaseリリース、およびアップグレードの準備で選択したオプションに応じて、Oracle Database Vaultのアップグレード後のタスクが変わります。

Oracle Database 21c以降へのアップグレード

次のオプションのいずれかを選択する必要があります。

  • DV_PATCH_ADMINロールをSYSに共通に付与します(container=all)。
  • アップグレード前にOracle Database Vaultを無効にします。

アップグレード前にDV_PATCH_ADMINロールをSYSに付与した場合は、アップグレード後にSYSからDV_PATCH_ADMINロールを取り消します。Oracle Database Vaultを無効にした場合は、アップグレードの完了後に再度有効にします。

Oracle Database 18cおよび19cへのアップグレード

Oracle Database Vaultを無効にする必要はありません。

ノート:

すべてのアップグレードで、アップグレードの完了後、Oracle Database Vaultはアップグレード前にソース・データベースに対して設定されていたのと同じ実施ステータスになります。

親トピック: Oracle Databaseのアップグレード後のOracle Database Vaultの有効化

SQLNET.ALLOWED_LOGON_VERSIONパラメータの動作の確認

10gより前のリリースのクライアントからのOracle Databaseに対する接続は、ORA-28040: 「一致する認証プロトコルがありません」というエラーによって失敗します。

Oracle Database 18c以上では、SQLNET.ALLOWED_LOGON_VERSIONパラメータのデフォルト値がOracle Database 12c (12.2)の11からOracle Database 18c以上のリリースの12に変更されています。このパラメータの使用は非推奨になりました。

SQLNET.ALLOWED_LOGON_VERSIONは、現在、SQLNET.ALLOWED_LOGON_VERSION_SERVERおよびSQLNET.ALLOWED_LOGON_VERSION_CLIENTパラメータに置き換えられています。アップグレードしたデータベースでSQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータを明示的に設定していない場合、リリース10gより前のリリースのクライアントからの接続は、ORA-28040: 「一致する認証プロトコルがありません」というエラーによって失敗します。セキュリティ強化のため、データベース・ユーザーのパスワード検証機能を確認し、SQLNET.ALLOWED_LOGON_VERSION_SERVERおよびSQLNET.ALLOWED_LOGON_VERSION_CLIENTパラメータを設定して正しいパスワード検証機能を使用するようにデータベースを構成します。

既存のデータベースにパスワードで保護されたロール(セキュア・ロール)があり、デフォルトのSQLNET.ALLOWED_LOGON_VERSION_SERVER設定である12を使用してOracle Database 18c以上のリリースにアップグレードする場合、そのセキュア・ロールに含まれるのはリリース10gの検証機能のみであるため、アップグレード後もセキュア・ロールが使用可能な状態になるように、管理者は各セキュア・ロールのパスワードをリセットする必要があります。

参照:

親トピック: Oracle Databaseのアップグレード後に必要な作業