1. データベース・アップグレード・ガイド
  2. Oracle Databaseのアップグレード後の作業
  3. Oracle Databaseのアップグレード後の推奨作業およびベスト・プラクティス

Oracle Databaseのアップグレード後の推奨作業およびベスト・プラクティス

Oracle Databaseを更新する場合、これらの適切なプラクティス・ガイドラインを完了することをお薦めします。特に明記されている場合を除き、これらの方法はすべてのタイプのアップグレードにお薦めします。

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

データベースのバックアップ

少なくともレベル1のバックアップを実行するか、時間が許せばレベル0のバックアップを実行することをお薦めします。

関連項目

親トピック: Oracle Databaseのアップグレード後の推奨作業およびベスト・プラクティス

アップグレード後修正スクリプトの実行

CDBおよび非CDBデータベースに対してpostupgrade_fixups.sqlスクリプトを使用する方法を理解するためには、この手順を確認します。

ノート:

AutoUpgradeユーティリティを使用してアップグレードした場合、AutoUpgradeは固定オブジェクトの統計をアップグレード中に自動的に更新します。このタスクを実行する必要はありません。

アップグレード後修正スクリプトは、アップグレード前情報ツール(preupgrade.jar)を実行したときに生成されます。アップグレード後スクリプトは、アップグレード完了後の任意の時点で実行します。プラガブル・データベース(PDB)を持つコンテナ・データベース(CDB)と非CDBデータベースの両方で、アップグレード後修正スクリプトを実行することによって、一般的な警告、エラーおよび推奨事項に関する情報が提供されます。

catcon.plユーティリティまたはSQL*Plusを使用して、このスクリプトを実行できます。

アップグレード後SQLスクリプトとログ・ファイルの場所は、出力フォルダの設定またはOracleベース環境変数の定義によって異なります。アップグレード後修正スクリプトは、アップグレード前修正スクリプトと同じディレクトリ・パスに配置されます。

アップグレード前情報ツールでdirオプションを使用して出力ディレクトリを指定した場合、出力ログおよびファイルはファイル・パス/cfgtoollogs/dbunique_name/preupgradeの該当ディレクトリの下に配置されます。ここで、dbunique_nameは、ソースOracle Databaseの名前です。アップグレード前情報ツールの実行時に出力ディレクトリを指定しなかった場合は、次のデフォルトの場所のいずれかに出力されます。

  • DIRで出力ディレクトリを指定していなくても、Oracleベース環境変数を設定した場合は、生成されるスクリプトとログ・ファイルは次のファイル・パスに作成されます。

    Oracle-base/cfgtoollogs/dbunique_name/preupgrade

  • 出力ディレクトリを指定せず、Oracleベース環境変数も定義していない場合は、生成されるスクリプトとログ・ファイルは次のファイル・パスに作成されます。

    Oracle-home/cfgtoollogs/dbunique_name/preupgrade

アップグレード前情報ツールによって作成されるアップグレード後修正スクリプトは、ソース・データベースが非CDBデータベースとCDBデータベースのどちらであるかによって異なります。

  • 非CDB: postupgrade_fixups.sql

  • CDB: 2つの異なるスクリプト・セット:

    1. postupgrade_fixups.sql: すべてのPDB用の統合スクリプト

    2. 複数のpostupgrade_fixups_pdbname.sqlスクリプト。pdbnameは、スクリプト生成の対象となるPDBの名前です。個々のスクリプトを特定のPDBで実行します。

例6-10 非CDB Oracle Databaseのアップグレード後修正結果のスプーリングの例

出力を確認するために、結果をログ・ファイルにスプールするようにシステムを設定します。ただし、adminディレクトリにはスプールしないでください。 

SQL> SPOOL postupgrade.log
SQL> @postupgrade_fixups.sql
SQL> SPOOL OFF

スクリプト結果のログ・ファイルへのスプーリングをオフにします。

SQL> SPOOL OFF

例6-11 Linux、UNIXおよびWindowsシステムでcatcon.plを使用してアップグレード後修正を実行する方法の例

この項の例では、catconコマンドを使用して、CDBデータベースのすべてのコンテナでpostupgrade_fixups.sqlを実行しています。このコマンドを実行する前に、UNIXおよびLinux環境に対してオペレーティング・システム環境変数ORACLE_HOMEおよびORACLE_SIDが設定されていて、同等の設定がWindows環境に対しても行われていることを確認する必要があります。次の例では、sales1はターゲット・データベースの一意の名前です。

LinuxおよびUNIX環境:

$ORACLE_HOME/perl/bin/perl -I$ORACLE_HOME/perl/lib -I$ORACLE_HOME/rdbms/admin $ORACLE_HOME/rdbms/admin/catcon.pl -l /home/oracle/here/ -b postupg /cfgtoollogs/sales1/preupgrade/postupgrade_fixups.sql

Windows環境:

%ORACLE_HOME%\perl\bin\perl –I%ORACLE_HOME%\perl\lib –I%ORACLE_HOME%\rdbms\admin %ORACLE_HOME%\rdbms\admin\catcon.pl -l c:\tmp\logdir\ -b postupg c:\cfgtoollogs\sales1\preupgrade\postupgrade_fixups.sql

このWindowsの例では、コマンド・オプション-lを使用して、ファイル・パスc:/tmp/logdir/の下にログを作成し、アップグレード後スクリプトの出力をそのディレクトリに配置しています。オプション-bを使用して、出力ファイルに接頭辞postupgを設定しています。

ノート:

catconのパラメータは、これらの例に示されている順序で入力する必要があります。

親トピック: Oracle Databaseのアップグレード後の推奨作業およびベスト・プラクティス

アップグレード後のディクショナリ統計の収集

アップグレードを完了した後に高いパフォーマンスを保証するためには、次の手順を使用してディクショナリ統計を収集します。

データ・ディクショナリ表はアップグレード中に変更され、作成されるため、データベースのアップグレードの前後でディクショナリ統計を収集することをお薦めします。Oracle Database 12cリリース2 (12.2)以上では、アップグレード後にデータベースを通常モードで起動したときに、統計を手動で収集するようになりました。

ノート:

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

  • 非CDBのOracle Databaseの場合: DBMS_STATS.GATHER_DICTIONARY_STATSプロシージャを使用して、統計を収集することをお薦めします。たとえば、次のSQL文を入力します。 

    SQL> EXEC DBMS_STATS.GATHER_DICTIONARY_STATS;

  • CDBの場合: catconを使用して、マルチテナント・アーキテクチャ全体のデータ・ディクショナリ統計を収集することをお薦めします

    コンテナ・データベースのすべてのPDBのディクショナリ統計を収集するには、次の構文を使用します。

    $ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -l /tmp -b gatherstats -- --x"exec dbms_stats.gather_dictionary_stats"

    特定のPDBに関するディクショナリ統計を収集するには、次のような構文を使用します。

    $ORACLE_HOME/perl/bin/perl $ORACLE_HOME/rdbms/admin/catcon.pl -l /tmp -c
'SALES1' -b gatherstats -- --x"exec dbms_stats.gather_dictionary_stats"

    前述の例では、SALES1というデータベースを指定することにより、実行するコマンドのPDB包含リストを-c SALES1オプションで指定しています。オプション-b gatherstats では、ログの基底名を指定します。オプション--xは、実行するSQLコマンドを指定します。SQLコマンドそのものは、引用符で囲みます。

関連項目

親トピック: Oracle Databaseのアップグレード後の推奨作業およびベスト・プラクティス

DBMS_STATSを使用した固定オブジェクトの統計の再収集

アップグレードの後に、または他のデータベース構成の変更後に、Oracle Databaseに対して代表的なワークロードを実行してから固定オブジェクトの統計を再収集することを強くお薦めします。

ノート:

パフォーマンス・チューニングのための最も正しい固定オブジェクト統計を提供するために、システムが代表的なワークロードを実行している時点で、ベースライン統計を収集することをお薦めします。役立つ結果を得るために、アップグレードの直後にはDBMS_STATS.GATHER_FIXED_OBJECTS_STATSを実行しないでください。

固定オブジェクトは、X$表とその索引です。V$パフォーマンス・ビューは、X$表を通じて定義されます。固定オブジェクトの統計の収集は、データベース・パフォーマンスにとって有益です。これは、オプティマイザが適切な実行計画を生成する際に役立つためで、データベース・パフォーマンスが向上する可能性があります。代表的な統計を取得しないと、実行計画が最適ではなくなる可能性があり、深刻なパフォーマンス問題が発生する場合があります。

データベースで代表的なワークロードが実行されていることを確認し、DBMS_STATS.GATHER_FIXED_OBJECTS_STATS PL/SQLプロシージャを使用して固定オブジェクト統計を収集します。DBMS_STATS.GATHER_FIXED_OBJECTS_STATSでは、INIT.ORAまたはSPFILEからすべての非表示またはアンダースコアのパラメータおよびイベントを削除するための推奨事項も表示されます。

X$表は一時的な性質を持つため、システムで代表的なワークロードが発生したときに固定オブジェクトの統計を収集する必要があります。ピーク負荷時に固定オブジェクトの統計を収集できない場合、システムが実行時の状態で、最も重要なタイプの固定オブジェクト表が移入された後に収集することをお薦めします。

固定オブジェクトの統計を収集するには、次のPL/SQLプロシージャを実行します。

SQL> execute dbms_stats.gather_fixed_objects_stats;

関連項目

親トピック: Oracle Databaseのアップグレード後の推奨作業およびベスト・プラクティス

パスワードのリセットによる大/小文字区別の強制

アップグレードしたデータベースで、デフォルト・ユーザー・アカウントおよびユーザー・アカウントの大/小文字区別のあるパスワードを使用してセキュリティを強化します。

セキュリティを強化するために、パスワードで大/小文字の区別を有効にすることをお薦めします。大/小文字を区別すると、ユーザーは、正しいパスワード文字列を入力し、さらにその文字列の各文字の大/小文字も正しく区別する必要があるため、パスワードのセキュリティを強化できます。たとえば、パスワードがhPP5620qrの場合、hpp5620QRまたはhPp5620Qrと入力すると失敗します。

データベースを保護するため、パスワードはセキュアな方法で作成します。データベースのデフォルト・パスワードを使用している場合、それらのパスワードは変更してください。デフォルトでは、パスワードを変更すると、大/小文字区別が強制されます。事前定義されたユーザー・アカウントのパスワードを含め、すべてのパスワードは、Oracle推奨のパスワード要件を満たしている必要があります。

アップグレード後に新しく作成されたデータベースでは、追加の作業や追加の管理要件はありません。

パスワード変更に関する既存のデータベース要件およびガイドライン

  • Oracle Database 12cリリース1 (12.1)以上のデフォルトのセキュリティ設定が適用されている場合、パスワードは8文字以上にする必要があり、welcomeやoracleなどのパスワードは使用できません。

  • IGNORECASEパラメータは非推奨です。このパラメータは使用しないでください。

  • 既存のデータベースでパスワードの大/小文字区別を利用するには、データベースのアップグレード作業中に既存のユーザーのパスワードをリセットする必要があります。既存のデータベース・ユーザーごとに、ALTER USER文を使用してパスワードをリセットします。

  • DBA_USERSのPASSWORD_VERSIONS列を問い合せ、10Gのパスワード・バージョンのみを持ち、11Gや12Cのパスワード・バージョンを持たないアカウントのUSERNAMEを見つけます。10Gのパスワード・バージョンのみを持つすべてのアカウントのパスワードをリセットします。

参照:

親トピック: Oracle Databaseのアップグレード後の推奨作業およびベスト・プラクティス

10Gパスワード・バージョンを使用するユーザーのパスワードの確認と再設定

セキュリティを向上するため、10Gバージョンのパスワードを使用しているユーザー・アカウントを確認しパスワードをリセットして、より安全なバージョンのパスワードが今後使用されるようにします。

現行ユーザーのすべてのパスワード・バージョンの確認

DBA_USERSデータ・ディクショナリ・ビューに問い合せて、ユーザー・アカウント用に構成されたパスワード・バージョンすべてのリストを出すことができます。

たとえば: 

SELECT USERNAME,PASSWORD_VERSIONS FROM DBA_USERS;

USERNAME                       PASSWORD_VERSIONS
------------------------------ -----------------
JONES                          10G 11G 12C 
ADAMS                          10G 11G
CLARK                          10G 11G
PRESTON                        11G
BLAKE                          10G

PASSWORD_VERSIONS列は、アカウントに存在するパスワード・バージョンのリストを示しています。10Gは、以前の、大/小文字を区別しないOracleパスワード・バージョン、11GはSHA-1ベースのパスワード・バージョン、12CはSHA-2ベースのSHA-512パスワード・バージョンを表します。

  • ユーザーjones: このユーザーのパスワードは、SQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータ設定が8のときに、Oracle Database 12cリリース12.1で再設定されました。これにより、3つのすべてのパスワード・バージョンを作成できます。

  • ユーザーadamsおよびclark: これらのアカウントのパスワードは当初Oracle Database 10gで作成され、Oracle Database 11gで再設定されました。Oracle Database 11gソフトウェアは、その時点でデフォルトのSQLNET.ALLOWED_LOGON_VERSION設定の8を使用していました。大/小文字を区別しないことがデフォルトで有効になっているため、これらのパスワードは、prestonのパスワードと同様に大/小文字が区別されるようになりました。

  • ユーザーpreston: このアカウントは排他モード(SQLNET.ALLOWED_LOGON_VERSION = 12)で実行されていたOracle Database 11gデータベースからインポートされたものです。

  • ユーザーblake: このアカウントはまだOracle Database 10gパスワード・バージョンを使用しています。この段階では、ユーザーblakeはログインできません。

10Gパスワード・バージョンを使用するユーザーの再設定

セキュリティを強化するには、すべてのユーザーのアカウントから10Gパスワードを削除します。次の手順で、10Gパスワード・バージョンを持つユーザーのパスワードを再設定するには、ログインが許可される前のクライアントの機能レベル要件を制御するSQLNET.ALLOWED_LOGON_VERSION_SERVER設定を、一時的に緩和する必要があります。設定を緩和することで、それらのユーザーがログインしてパスワードを変更し、10Gパスワード・バージョンに加えてより新しいパスワード・バージョンを生成できるようになります。後で、排他モードを使用するようにデータベースを設定し、クライアントがO5L_NP機能を使用できることを確認できます。そうすれば、パスワードにもう10G,が含まれず、より安全な11Gおよび12Cパスワード・バージョンだけを持つように、ユーザーはもう一度パスワードを再設定できます。

  1. DBA_USERSビューに問い合せて、10Gパスワード・バージョンだけを使用するユーザーを見つけます。
    SELECT USERNAME FROM DBA_USERS 
WHERE ( PASSWORD_VERSIONS = '10G '
OR PASSWORD_VERSIONS = '10G HTTP ')
AND USERNAME <> 'ANONYMOUS';
  2. 次のようにして、データベースが排他モードで実行されないように構成します。
    1. sqlnet.oraファイルのSQLNET.ALLOWED_LOGON_VERSION_SERVER設定を、デフォルトよりも許容度が高くなるように編集します。たとえば:
      SQLNET.ALLOWED_LOGON_VERSION_SERVER=11
    2. データベースを再起動します。
  3. DBA_USERSビューに問い合せて、10Gパスワード・バージョンのみを使用するユーザーを期限切れにします。

    11Gまたは12C、あるいはその両方のパスワード・バージョンを持つユーザーではなく、10Gパスワード・バージョンだけを持つユーザーを期限切れにする必要があります。

    たとえば: 

    ALTER USER username PASSWORD EXPIRE;
  4. 期限切れにしたユーザーにログインするよう、依頼します。

    ユーザーがログインすると、パスワードを変更するよう求められます。データベースは10Gパスワード・バージョンに加えて、欠落している11Gおよび12Cパスワード・バージョンを生成します。データベースは許容モードで実行中のため、10Gパスワード・バージョンは引き続き存在します。

  5. ユーザーが接続しているクライアント・ソフトウェアにO5L_NP機能があることを確認します。

    Oracle Databaseリリース11.2.0.3以上のすべてのクライアントにO5L_NP機能があります。以前のOracle Databaseクライアントがある場合は、CPUOct2012パッチをインストールする必要があります。

  6. すべてのクライアントにO5L_NP機能が導入されたら、次のようにしてサーバーのセキュリティを元の排他モードに設定します。
    1. インスタンス初期化ファイルからSEC_CASE_SENSITIVE_LOGONパラメータを削除するか、またはSEC_CASE_SENSITIVE_LOGONをTRUEに設定します。
      SEC_CASE_SENSITIVE_LOGON = TRUE
    2. サーバーのsqlnet.oraファイルからSQLNET.ALLOWED_LOGON_VERSION_SERVERパラメータを削除するか、サーバーのsqlnet.oraファイルでSQLNET.ALLOWED_LOGON_VERSION_SERVERの値を12に設定しなおして、排他モードに設定します。
      SQLNET.ALLOWED_LOGON_VERSION_SERVER = 12
    3. データベースを再起動します。
  7. まだ10Gパスワード・バージョンを持っているアカウントを見つけます。
    SELECT USERNAME FROM DBA_USERS
WHERE PASSWORD_VERSIONS LIKE '%10G%' 
AND USERNAME <> 'ANONYMOUS';
  8. まだ10Gパスワード・バージョンを持っているアカウントを期限切れにします。
    ALTER USER username PASSWORD EXPIRE;
  9. これらのユーザーにアカウントにログインするよう、依頼します。

    ユーザーはログインするときに、パスワードを再設定するようプロンプトが表示されます。そうすると、データベースはそのアカウントに11Gおよび12Cパスワード・バージョンだけを生成します。データベースは排他モードで実行されているため、10Gパスワード・バージョンはもう生成されません。

  10. 次の問合せを再実行します。
    SELECT USERNAME FROM DBA_USERS
WHERE PASSWORD_VERSIONS LIKE '%10G%' 
AND USERNAME <> 'ANONYMOUS';

    この問合せで返された結果が0件だった場合は、10Gパスワード・バージョンを持つユーザー・アカウントがないことを意味します。したがって、データベースは以前のリリースよりもよりセキュアなモードで実行されています。

親トピック: Oracle Databaseのアップグレード後の推奨作業およびベスト・プラクティス

Oracle Grid Infrastructure、Oracle ASMおよびOracle Clusterwareの理解

Oracle ClusterwareとOracle Automatic Storage Management (Oracle ASM)は、両方ともOracle Grid Infrastructureインストールの一部です。

Oracle Grid Infrastructureは、単一サーバーにインストールした場合、Oracle ASMとともにOracle Restartインストールとしてデプロイされます。クラスタにインストールした場合は、Oracle ASMとともにOracle Clusterwareインストールとしてデプロイされます。

Oracle Restartは、単一インスタンス環境におけるOracle Databaseの可用性を向上します。Oracle Restartをインストールし、データベース、リスナー、Oracle ASMインスタンスなどのOracle Databaseソフトウェア・スタックの一部が一時的に失敗した場合、失敗したコンポーネントはOracle Restartによって自動的に再起動されます。また、これらのすべてのコンポーネントは、データベース・ホスト・コンピュータが再起動されるときに、Oracle Restartによって起動されます。コンポーネントは、コンポーネント間の依存性を考慮して適切な順序で起動されます。

Oracle Clusterwareは、単一サーバーを単一システムとして連携するようにクラスタ化できるポータブル・クラスタ・ソフトウェアです。Oracle RACに必須なインフラストラクチャも提供します。また、Oracle Clusterwareでは、クラスタ内の任意のOracleアプリケーションまたはその他のアプリケーションを保護できます。いずれの場合でも、Oracle Clusterwareはそれらのシステムにおけるインテリジェント機能としてクラスタ・ノード間の必要な連携を確実にします。

親トピック: Oracle Databaseのアップグレード後の推奨作業およびベスト・プラクティス

Oracle Grid InfrastructureのインストールとアップグレードおよびOracle ASM

Oracle ASMは、Oracle Grid Infrastructureとともにインストールされます。

以前のリリースまでは、Oracle ASMは、Oracle Databaseインストールの一部としてインストールされていました。Oracle Databaseリリース11.2以上では、Oracle ASMは、Grid Infrastructureコンポーネントのインストール時にインストールされます。Oracle ASMは、Oracle ClusterwareとOracleホームを共有します。

参照:

Oracleホーム、ロール割当て済のシステム権限グループ、様々なインストール・ソフトウェア所有者ユーザー、および他の変更の詳細は、使用しているプラットフォームの『Oracle Grid Infrastructureインストレーション・ガイド』を参照してください。

親トピック: Oracle Databaseのアップグレード後の推奨作業およびベスト・プラクティス

新機能の適宜追加

データベース・アップグレード計画の一環として新機能を確認してください。

『Oracle Database新機能ガイド』では、新しいOracle Databaseリリースで使用可能な多くの新機能について説明されています。これらのどの新機能がデータベースおよびアプリケーションに有効かを判断してください。その後、これらの機能を使用する計画を立てることができます。

新しいOracle Databaseソフトウェアを使用するためにすぐに変更する必要はありません。データベースおよびアプリケーションに、新機能の拡張機能を徐々に取り入れることもできます。

参照:

Oracle Database新機能ガイド

親トピック: Oracle Databaseのアップグレード後の推奨作業およびベスト・プラクティス

必要な新しい管理手順の作成

スクリプトおよびプロシージャの再確認を計画し、必要に応じて変更します。

新しいOracle Databaseリリースの機能をよく理解したうえで、データベース管理用のスクリプトおよびプロシージャを再確認し、変更が必要かどうかを判断します。

それぞれのアプリケーションに必要な変更を、データベースにも行う必要があります。たとえば、データベースで整合性制約を使用可能にした場合、アプリケーションでのデータ・チェックの一部を削除できます。

親トピック: Oracle Databaseのアップグレード後の推奨作業およびベスト・プラクティス

表領域アラートのしきい値の設定

アップグレード後、アップグレードしたOracle Databaseの表領域アラートのしきい値はnullに設定され、アラートは無効化されます。

データベース内で監視対象となる表領域を特定し、それらの表領域に適切なしきい値を設定する必要があります。

Oracle Database 18c以上のリリースでは、新しく作成されたOracle Databaseインストールでは、次の値がデフォルトとして使用されます。

  • 警告(表領域の使用率が85%の場合)

  • クリティカル(表領域の使用率が97%の場合)

親トピック: Oracle Databaseのアップグレード後の推奨作業およびベスト・プラクティス

ロールバック・セグメントから自動UNDOモードへの移行

データベース・リリースがOracle Database 11gより前の場合は、ロールバック・セグメント(手動UNDO管理)を使用してアップグレードしたデータベースを、自動UNDO管理に移行する必要があります。

自動UNDO管理は、デフォルトのUNDO領域管理モードです。システムで使用するUNDO領域管理モードは、UNDO_MANAGEMENT初期化パラメータで指定します。

  • UNDO_MANAGEMENTがAUTOに設定されている場合(またはUNDO_MANAGEMENTが設定されていない場合)、データベース・インスタンスは自動UNDO管理モードで起動します。

    UNDO_MANAGEMENT初期化パラメータがNULLの場合のデフォルトは、Oracle Database 11gリリース1 (11.1)以降では自動UNDO管理モードです。以前のリリースでは、手動UNDO管理モードがデフォルトです。以前のリリースをアップグレードするときには注意してください。

  • UNDO_MANAGEMENTが MANUALに設定されている場合、UNDO領域はロールバック・セグメントとして外部に割り当てられます。

  1. UNDO_MANAGEMENTパラメータを UNDO_MANAGEMENT=MANUALに設定します。
  2. インスタンスを再起動して標準的なビジネス・サイクルを一通り実行し、代表的なワークロードを取得します。ワークロードを評価し、自動UNDO管理で必要なUNDO表領域のサイズを計算します。
  3. 標準的なビジネス・サイクルを完了したら、次のファンクションを実行してUNDO表領域のサイズを収集すると、UNDO表領域のサイズ変更に役立ちます。このファンクションを実行するにはSYSDBA権限が必要です。
    DECLARE
   utbsiz_in_MB NUMBER;
BEGIN
   utbsiz_in_MB := DBMS_UNDO_ADV.RBU_MIGRATION;
end;
/

    このファンクションではPL/SQLプロシージャが実行され、システム構成およびシステムのロールバック・セグメントの使用状況を基にして、新しいUNDO表領域のサイズを求める方法に関する情報が提供されます。このファンクションはサイズ変更に関する情報を直接戻します。

  4. 必要なサイズのUNDO表領域を作成し、UNDO_MANAGEMENT=AUTOに設定するかパラメータを削除して、自動UNDO管理を有効にします。
  5. Oracle RAC構成の場合は、すべてのインスタンスでこれらのステップを繰り返します。

親トピック: Oracle Databaseのアップグレード後の推奨作業およびベスト・プラクティス

LONGデータ型からLOBデータ型への表の移行

ALTER TABLE文を使用して、LONGデータ型の列をCLOBに、LONG RAWデータ型の列をBLOBに変更できます。

LOBデータ型(BFILE、BLOB、CLOBおよびNCLOB)には、LONGデータ型よりも多くのメリットがあります。

次の例では、long_tab表のlong_colというLONG列が、CLOBデータ型に変更されます。 

SQL> ALTER TABLE Long_tab MODIFY ( long_col CLOB );

この方法でLONG列をLOBに変換した後も、表に設定されている既存の制約およびトリガーはすべて使用できます。ただし、表のすべての列で、ドメイン索引およびファンクション索引を含むすべての索引が使用不可となるため、ALTER INDEX ... REBUILD文を使用してすべての索引を再構築する必要があります。また、LONG列上のドメイン索引は、LONG列をLOBに変更する前に削除する必要があります。

参照:

LOBデータを使用するためのアプリケーションの変更の詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照してください。

親トピック: Oracle Databaseのアップグレード後の推奨作業およびベスト・プラクティス

アップグレードしたOracle Databasesでの従来の監査の無効化

従来の監査はOracle Database 21cで非推奨となり、Oracle Database 23cでサポートが終了しました。ご使用のデータベースで従来の監査を無効にし、統合監査のみを使用することをお薦めします。

統合監査と従来の監査(混合モード)は、Oracle Database 12c以降デフォルトの監査モードでした。混合モードの監査は、統合監査に慣れるためと、従来の監査から移行するために提供されていました。Oracle Database 21cで従来の監査が非推奨となったため、ご使用のデータベースで従来の監査を無効にし、統合監査のみを使用することをお薦めします。『Oracle Databaseセキュリティ・ガイド』の手順を参照してください。

関連項目

親トピック: Oracle Databaseのアップグレード後の推奨作業およびベスト・プラクティス

Oracle Databaseの監査の理解

アップグレードしたデータベースで使用する監査ポリシーを決定します。

新しく作成されたデータベースでは、統合監査の混合モードの方式がデフォルトで有効になります。この方式では、従来の監査と統合監査が両方含まれています。事前定義された監査ポリシーであるORA_SECURECONFIGポリシーとORA_LOGIN_LOGOUTポリシーは、デフォルトで有効になります。従来の監査を無効にし、統合のみを使用することをお薦めします。

以前のリリースからOracle Database 12cアップグレードした場合は、データベースでは以前のリリースで使用していたものと同じ監査機能が使用されています。従来の監査を無効にすることを検討し、純統合監査の使用を開始できるように、事前定義された監査ポリシーであるORA_SECURECONFIGポリシーとORA_LOGIN_LOGOUTポリシーが有効になっていることを確認してください。

監査ポリシーを有効化して使用方法を構成するには、次のように1つの方法を選択します。

  • 純統合監査機能を使用。

    統合監査に移行して、統合監査の全機能を使用します。統合監査への移行の手順が完了した後は、新しい監査ポリシーを作成および有効化でき、事前定義された監査ポリシーを使用することもできます。これらのポリシーの監査レコードは、統合監査証跡に書き込まれます。以前の監査証跡および監査レコードは保持されますが、新しい監査レコードは以前の監査証跡には書き込まれません。

    ノート:

    以前のリリースの監査構成は、統合監査システムでは効果がありません。統合監査証跡内では、統合監査ポリシーのみが監査レコードを生成します。

  • 混合モードの監査機能を使用。

    混合モードの監査機能は、統合監査への移行に役立ちます。これは、従来の監査機能と統合監査機能の両方を同時に実行でき、新しいデータベースとアップグレードしたデータベースの両方に適用されます。混合モードの統合監査機能は、1つ以上の事前定義された統合監査ポリシーを有効化すると使用可能になります。これらのポリシーの監査レコードは、統合監査証跡に書き込まれます。Oracle Databaseの以前のリリースでの監査構成も使用可能で、この構成の監査レコードは以前の監査証跡に書き込まれます。純統合監査機能を使用することに決定した場合、それに移行できます。

    ノート:

    データベースが書込み不可な場合、監査レコードは、$ORACLE_BASE/audit/$ORACLE_SIDディレクトリにある新しい形式のオペレーティング・システム・ファイルに書き込まれます。

関連項目

親トピック: アップグレードしたOracle Databasesでの従来の監査の無効化

Oracle Databaseでの従来の監査の無効化および統合監査の使用

マルチテナント・コンテナ(CDB)・データベースの場合はこの手順を使用して、従来の監査を無効にし、統合監査を使用します。

rootで次の手順を実行します。この手順により、root CDBとそれに関連するPDBの両方が、統合監査を使用するように構成されます。

ノート:

今すぐ統合監査の使用を開始することをお薦めします。これはOracle Database 21cで非推奨となり、Oracle Database 23cでサポートが終了しました。

移行時に従来の監査を使用し続ける必要がある場合は、統合監査をコンテナ・データベース(CDB)のルートのみから無効にできます。個々のプラガブル・データベース(PDB)については無効にできません。

ただし、統合監査が無効になっているときは、個々のPDBで、そのPDBでローカル監査ポリシーが有効になっているかどうかに応じて、混合モードの監査を使用できます。CDB共通監査ポリシーが有効になっている場合、すべてのPDBで混合モード監査が使用されます。

  1. SYSDBA権限を持つユーザーSYSとしてSQL*Plusにログインします。 

    sqlplus sys as sysdba
Enter password: password

    マルチテナント環境では、このログインによってrootに接続されます。

  2. 次の問合せを使用して、使用しているOracle Databaseが統合監査に移行したかどうかを確認します。

    SQL> SELECT VALUE FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';

    VALUE列の出力がTRUEの場合、データベースで統合監査がすでに有効化されています。以前の監査レコードの管理に進むことができます。出力がFALSEの場合は、この手順の残りのステップを完了してください。

  3. データベースを停止します。単一インスタンス環境では、SQL*Plusから次のコマンドを入力します。

    SQL> SHUTDOWN IMMEDIATE
SQL> EXIT

    Windowsシステムでは、Oracleサービスを停止します。

    net stop OracleService%ORACLE_SID%

    Oracle Real Application Clusters (Oracle RAC)インストールの場合、次のようにして各データベース・インスタンスを停止します。 

    srvctl stop database -db db_name

  4. リスナーを停止します。(Oracle RACおよびOracle Grid Infrastructureリスナーでは、リスナーを停止する必要はありません。)

    lsnrctl stop listener_name

    lsnrctl statusコマンドを実行すると、リスナーの名前を検索できます。名前はAlias設定で示されます。

  5. ディレクトリ$ORACLE_HOME/rdbms/libに移動します。

  6. Oracleユーザーの統合監査を有効にします。

    • LinuxおよびUnix

      make -f ins_rdbms.mk uniaud_on oracle ORACLE_HOME=$ORACLE_HOME

    • Microsoft Windows

      ファイル名を%ORACLE_HOME%/bin/orauniaud12.dll.dblから%ORACLE_HOME%/bin/orauniaud12.dllに変更します。

    ノート:

    Oracleホームを共有していないOracle RACデータベースの場合、各クラスタ・メンバー・ノードでこのステップを繰り返して、各クラスタ・ノードのローカルORACLE_HOME内のバイナリが更新されるようにする必要があります。

  7. リスナーを再起動します。

    lsnrctl start listener_name

  8. データベースを再起動します。

    SQL*Plusにログインしてから、STARTUPコマンドを入力します。 

    sqlplus sys as sysoper
Enter password: password

SQL> STARTUP

    Microsoft Windowsシステムの場合、Oracleサービスを開始します。

    net start OracleService%ORACLE_SID%

    Oracle RACインストールの場合は、各データベース・インスタンスを起動します。

    srvctl start database -db db_name

統合監査に移行した後、My Oracle SupportドキュメントID 2369172.1「データベース監査証跡のLOB列ではSecurefile Storageを使用する必要があります」を参照し、Oracleホーム・スクリプトOracle_home/rdbms/admin/auditpostupgrade.sqlに関する情報を確認します。統合監査のパフォーマンス上の利点を得るために、アップグレードの完了後にこのスクリプトを実行することをお薦めします。

関連項目

親トピック: アップグレードしたOracle Databasesでの従来の監査の無効化

統合監査への移行後の古い監査レコードの管理について

統合監査証跡を使用する準備として古い監査証跡を確認、アーカイブおよび削除します。

Oracle Databaseで従来の監査を無効にして統合監査を使用するための手順が完了した後は、データベースで使用していた以前の監査レコードが、以前の監査証跡に残っています。これらの監査レコードをアーカイブして、監査証跡を削除できます。統合監査が使用可能な場合、新しい監査レコードは統合監査証跡に書き込まれます。

関連項目

親トピック: アップグレードしたOracle Databasesでの従来の監査の無効化

純統合監査から混合モードの監査への移行

混合モードの監査構成で従来の監査を有効にするには、この手順を使用します。

従来の監査を混合モードで再度有効にする場合は、この手順を使用して従来の監査を有効にします。この場合、データベースでは混合モードの監査機能が使用されます。

ノート:

従来の監査は非推奨となっておりOracle Database 23cでサポートが終了していることに注意してください。そのことに基づいて計画してください。

  1. データベースを停止します。

    sqlplus sys as sysoper
Enter password: password

SQL> SHUTDOWN IMMEDIATE
SQL> EXIT

    Microsoft Windowsシステムの場合は、次のようにOracleサービスを停止します。

    net stop OracleService%ORACLE_SID%

    Oracle RACインストールの場合は、次のようにして、各データベース・インスタンスを停止します。 

    srvctl stop database -db db_name

  2. $ORACLE_HOME/rdbms/libディレクトリに移動します。

  3. 統合監査実行可能ファイルを無効にします。

    • Linux/Unix: 次のコマンドを実行します。 

      make -f ins_rdbms.mk uniaud_off oracle ORACLE_HOME=$ORACLE_HOME

    • Microsoft Windows: %ORACLE_HOME%/bin/orauniaud12.dllファイルの名前を%ORACLE_HOME%/bin/orauniaud12.dll.dblに変更します。

  4. データベースを再起動します。 

    sqlplus sys as sysoper
Enter password: password

SQL> STARTUP
SQL> EXIT

    Microsoft Windowsシステムでは、Oracleサービスを再度起動します。

    net start OracleService%ORACLE_SID%

    Oracle RACインストールの場合は、次の構文を使用して、各データベース・インスタンスを起動します。 

    srvctl start database -db db_name

親トピック: アップグレードしたOracle Databasesでの従来の監査の無効化

統合監査を使用しない場合のドキュメント参照の取得

ここにリストされているドキュメントにアクセスして、非統合監査の使用方法に関する構成情報を取得できます。

新しいOracle Databaseリリースへのアップグレード後に、統合監査に変更しないことにした場合は、OracleドキュメントおよびOracle Technology Networkで従来の監査に関する情報を参照してください。従来の監査はOracle Database 21cで非推奨となっておりOracle Database 23cでサポートが終了していることに注意してください。そのことに基づいて計画してください。

『Oracle Databaseセキュリティ・ガイド』は、監査を構成する際の主要な情報源です。このマニュアルのOracle Databaseリリース11gバージョンを使用する必要があります。このガイドにアクセスするには

  1. 次のOracle Technology Networkのdocs.oracle.comサイトで、データベース・ページにアクセスします。

    https://docs.oracle.com/en/database/index.html

  2. 「Oracle Database」を選択します。

  3. 「ダウンロード」ページで、「ドキュメント」タブを選択します。

  4. リリース・リスト・フィールドで「Earlier Releases」を選択し、「Oracle Database 11g Release 2 (11.2)」を選択します。

  5. Oracle Database 11gリリース2 (11.2)の「Documentation」ページから、「All Books」リンクを選択して、ドキュメント・セットの刊行物を表示します。

  6. 「セキュリティ・ガイド」を検索します。

  7. このガイドの「HTML」または「PDF」リンクのいずれかを選択します。

親トピック: アップグレードしたOracle Databasesでの従来の監査の無効化

再構築対象のOracle Text索引の識別

新しいOracle Databaseリリースへのアップグレード後にトークン表の再構築が推奨されるOracle Text索引の識別に役立つスクリプトを実行できます。

Oracle Database 12cリリース1 (12.2.0.1)をOracle Database 18c以降のリリースにアップグレードすると、Oracle Textトークン表($I、$Pなど)が64バイトから255バイトに拡張されます。しかし、索引で使用されている既存のトークン表のサイズ範囲が小さいと、拡張後のトークン列範囲をOracle Text索引で利用できなくなります。255バイトのサイズ範囲を使用するように索引を再構築する必要があります。Oracleは、再構築が推奨される索引の識別に役立つスクリプトを提供しています。

My Oracle Supportからスクリプトを取得してください。

https://support.oracle.com/rs?type=doc&id=2287094.1

親トピック: Oracle Databaseのアップグレード後の推奨作業およびベスト・プラクティス

DBMS_SCHEDULERジョブの削除および再作成

以前のリリースからのアップグレード後にDBMS_SCHEDULERジョブが機能しなくなった場合は、ジョブを削除して再作成します。

アップグレード後にDBMS_SCHEDULERジョブが機能しないことに気づいたら、それらのジョブを削除して再作成してください。この問題は、アップグレード処理からの問題報告がなく、システム・オブジェクトが有効な場合でも発生する可能性があります。

親トピック: Oracle Databaseのアップグレード後の推奨作業およびベスト・プラクティス

アップグレード後の統合監査レコードの転送

統合監査をアップグレードし、移行した後で高いパフォーマンスを得る方法を理解するためには、これらのトピックを確認します。

親トピック: Oracle Databaseのアップグレード後の推奨作業およびベスト・プラクティス

アップグレード後の監査レコードの転送について

統合監査レコードをOracle Database 12cリリース12.1から、新しいOracle DatabaseリリースのAUDSYSスキーマ下の新しいリレーショナル表に転送すると、統合監査証跡の読取りパフォーマンスが向上します。

Oracle Database 12cリリース2以降、統合監査レコードは直接、AUDSYSスキーマにある新しい内部リレーショナル表に書き込まれます。Oracle Database 12cリリース12.1では、統合監査レコードは共通ロギング・インフラストラクチャ(CLI) SGAキューに書き込まれていました。そのリリースの統合監査に移行した場合は、より高い読取りパフォーマンスを得るために、そのリリースの統合監査レコードを新しいOracle Databaseリリースの内部表に転送できます。この転送を実行することは必須ではありませんが、統合監査証跡の読取りパフォーマンスを向上させるため、転送をお薦めします。これは1回かぎりの操作です。アップグレード後に生成されたすべての新しい統合監査レコードはこの新しい表に書き込まれます。この表は、読取り専用の表です。この表のメタデータまたはデータを変更しようとすると、それらはすべて強制的に監査されます。

新しいOracle Databaseリリースにアップグレードした後に、以前のリリースのUNIFIED_AUDIT_TRAILに統合監査レコードが存在している場合は、この転送プロシージャを使用してそれらを新しい内部リレーショナル表に転送し、統合監査証跡の読取りパフォーマンスを高めることを検討してください。

SYSスキーマの場合と同様、SELECT ANY TABLEシステム権限がある場合はAUDSYSスキーマの問合せはできません。さらに、この表はユーザーがSELECT ANY DICTIONARYシステム権限か、この内部表に対する明示的なSELECT権限を持っていないかぎり、ALL_TABLESデータ・ビューでスキーマ・オブジェクトとしてリストされません。データベースが読取り/書込みモードでオープンするまで、監査レコードはオペレーティング・システムの過剰ファイルに書き込まれます(.bin形式)。ただし、データベースが読取り/書込みモードでオープンした後に、DBMS_AUDIT_MGMT.LOAD_UNIFIED_AUDIT_FILESプロシージャを使用してこれらのオペレーティング・システム・ファイルの監査レコードを内部リレーショナル表に転送することはできません。

親トピック: アップグレード後の統合監査レコードの転送

アップグレード後の監査レコードの転送

DBMS_AUDIT_MGMT.TRANSFER_UNIFIED_AUDIT_RECORDS PL/SQLプロシージャを使用して、統合監査レコードをAUDSYSの新しいリレーショナル表に転送できます。

  1. AUDIT_ADMINロールを付与されたユーザーとして、データベース・インスタンスにログインします。

    たとえば、非マルチテナント環境では、次のとおりです。

    sqlplus sec_admin
Enter password: password

    マルチテナント環境では、rootとして接続します。

    sqlplus c##sec_admin@root
Enter password: password

    このプロシージャの実行はPDBだけではなくrootでも実行できます。これは、UNIFIED_AUDIT_TRAILビューがコンテナ別であるからです。さらに、転送手順もコンテナ別です。つまり、rootからの転送を実行してもPDBの統合監査証跡にある統合監査レコードには影響がありません。

  2. マルチテナント環境ではDBA_PDB_HISTORYビューに問い合せて、監査レコードの転送元のコンテナ固有のCLI表に関連付けられた正しいGUIDを見つけます。

    たとえば:

    SQL> SELECT PDB_NAME, PDB_GUID FROM DBA_PDB_HISTORY;

PDB_NAME  PDB_GUID
--------  --------------------------------
HR_PDB    33D96CA7862D53DFE0534DC0E40A7C9B
...
  3. マルチテナント環境の、監査レコードの転送を行うコンテナに接続します。

    現在接続しているコンテナとは別のコンテナでは転送操作を実行できません。

  4. DBMS_AUDIT_MGMT.TRANSFER_UNIFIED_AUDIT_RECORDSプロシージャを実行します。
    たとえば:
    SQL> EXEC DBMS_AUDIT_MGMT.TRANSFER_UNIFIED_AUDIT_RECORDS;

PL/SQL procedure successfully completed.

    または、PDB GUIDを指定するために次を実行します。

    SQL> EXEC DBMS_AUDIT_MGMT.TRANSFER_UNIFIED_AUDIT_RECORDS ('33D96CA7862D53DFE0534DC0E40A7C9B');

PL/SQL procedure successfully completed.
  5. データベースが読取り/書込みモードでオープンしている場合は、DBMS_AUDIT_MGMT.LOAD_UNIFIED_AUDIT_FILESプロシージャを実行します。

    データベースが読取り/書込みモードでオープンするまで、監査レコードはオペレーティング・システム(OS)のファイルに書き込まれます。DBMS_AUDIT_MGMT.LOAD_UNIFIED_AUDIT_FILESプロシージャは、そのファイルに存在する統合監査レコードをデータベース表に移動します。OS過剰ファイルに存在する統合監査レコードは、V$UNIFIED_AUDIT_TRAIL動的ビューの問合せにより見つけることができます。

    たとえば、このプロシージャをHR_PDBコンテナの監査レコードに実行する場合は、まず、そのPDBに接続する必要があります。 

    SQL> CONNECT sec_admin@HR_PDB
Enter password: password

SQL> EXEC DBMS_AUDIT_MGMT.LOAD_UNIFIED_AUDIT_FILES;

PL/SQL procedure successfully completed.
  6. UNIFIED_AUDIT_TRAILデータ・ディクショナリに問い合せて、レコードが正しく転送されたことを確認します。

    問合せUNIFIED_AUDIT_TRAILを行うことを強くお薦めします。監査レコードが正常に転送されたら、問合せUNIFIED_AUDIT_TRAILを行う必要があります。これは、V$UNIFIED_AUDIT_TRAIL動的ビューの問合せではOSの過剰ファイルにある監査レコードしか表示されないからです。

親トピック: アップグレード後の統合監査レコードの転送

アップグレードした本番Oracle Databaseのテストについて

アプリケーションが期待どおり動作することを確認するため、テスト・データベースに実行したテストを本番データベースに対して繰り返します。

テスト・データベースを新しいOracle Databaseリリースにアップグレードしてテストした場合、新しいOracle Databaseリリースにアップグレードした本番データベースでも同じテストを繰り返すことができます。結果を比較し、相違点を記録します。必要に応じて、アップグレードのテストを繰り返します。

新しいOracle Databaseリリースでアプリケーションが適切に動作することを確認するには、新しくアップグレードされた本番データベースを既存のアプリケーションでテストします。また、使用可能なOracle Database機能を追加してテストし、拡張機能をテストすることもできます。ただし、アプリケーションがアップグレードの前と同様に動作するかどうかを最初に確認してください。

親トピック: Oracle Databaseのアップグレード後の推奨作業およびベスト・プラクティス