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

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

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

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

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

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

関連項目

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

AutoUpgradeアップグレード後チェックの実行

AutoUpgradeをdeployモードで実行しなかった場合は、preupgradeパラメータを指定してAutoUpgradeをpostfixupsモードで実行します。

ノート:

AutoUpgradeをdeployモードで実行した場合、このステップはすでに完了しているため、ここで完了する必要はありません。

アップグレード後にデータベースを確認する方法を確認するには、次の例を使用します。

例7-10 アップグレード後修正モードを使用したAutoUpgradeの実行

Oracle Database 12cリリース2 (12.2)のOracle Databaseをアップグレードしたとします。アップグレード後チェックを実行するには、次の手順を実行します。

  1. Oracleホーム環境をソースOracle Databaseホームに設定します。 

    setenv ORACLE_HOME /u01/app/oracle/product/12.2.0/dbhome_1
    .
  2. Oracleシステム識別子(SID)をソースOracle Database SIDに設定します。 
    setenv ORACLE_SID db122
    .
  3. postfixupsモードでpreupgradeパラメータを使用してAutoUpgradeを実行し、ターゲット・ホームをターゲットのOracle Database Oracleホームに設定します。たとえば: 
    java -jar autoupgrade.jar -preupgrade "target_home=/u01/app/oracle/product/21.0.0/dbhome_1,dir=/autoupgrade/test/log" –mode postfixups
  4. ディレクトリ/autoupgrade/test/log/db122/102/postfixupsの下のファイルpostfixups.xmlで、修正後スクリプト・チェックの結果を確認します。

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

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

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

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

ノート:

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

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のアップグレード後の推奨作業およびベスト・プラクティス

Oracle Databaseのアップグレード後のDBMS_STATSパッケージで作成された統計表のアップグレード

DBMS_STATS.CREATE_STAT_TABLEプロシージャを使用して統計表を作成した場合、DBMS_STATS.UPGRADE_STAT_TABLEを実行してそれらの表をアップグレードします。

次の例で、greenは統計表の所有者で、STAT_TABLEは統計表の名前です。 

EXECUTE DBMS_STATS.UPGRADE_STAT_TABLE('green', 'stat_table');

各統計表にこのプロシージャを実行します。

参照:

DBMS_STATSパッケージの詳細は、『Oracle Database PL/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のアップグレード後の推奨作業およびベスト・プラクティス

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

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

セキュリティを強化するために、パスワードで大/小文字の区別を有効にすることをお薦めします。Oracle Database 21c以降のリリースでは、orapwdファイルのIGNORECASEパラメータはサポートされなくなりました。新しく作成されるすべてのパスワード・ファイルでは、大/小文字が区別されます。大/小文字を区別すると、ユーザーは、正しいパスワード文字列を入力し、さらにその文字列の各文字の大/小文字も正しく区別する必要があるため、パスワードのセキュリティを強化できます。たとえば、パスワードがhPP5620qrの場合、hpp5620QRまたはhPp5620Qrと入力すると失敗します。

以前のOracle Databaseリリースからアップグレードされたパスワード・ファイルでは、大/小文字が区別されない元のパスワードを保持できます。パスワード・ファイルで大/小文字が区別されるようにするには、次の構文を使用して、パスワード・ファイルをある形式から別の形式に移行して大/小文字の区別を強制することをお薦めします。 

orapwd input_file=input_password _file file=output_password_file

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

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

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

  • パスワードは8文字以上にする必要があります。また、welcomeやoracleなどのパスワードは使用できません。
  • 既存のデータベースでパスワードの大/小文字区別を利用するには、データベースのアップグレード作業中に既存のユーザーのパスワードをリセットする必要があります。既存のデータベース・ユーザーごとに、ALTER USER文を使用してパスワードをリセットします。
  • DBA_USERSのPASSWORD_VERSIONS列を問い合せ、10Gのパスワード・バージョンのみを持ち、11Gや12Cのパスワード・バージョンを持たないアカウントのUSERNAMEを見つけます。10Gのパスワード・バージョンのみを持つすべてのアカウントのパスワードをリセットします。

関連項目

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

Oracle XML DBに対するFTPとHTTPのポートおよびHTTP認証の構成

Oracle Database Configuration Assistant (DBCA)は、Oracle Database 12c以降のリリースでOracle XML DB用のポートを構成しません。アップグレードではダイジェスト認証が使用されます。

ポートを構成する場合、改善されたセキュリティ機能を利用するために、Oracle XML DB Repositoryへのアクセス用にHTTPの認証も構成することをお薦めします。

Oracle Database 12c以降では、ダイジェスト認証のサポートを提供することによって、データベースのセキュリティが向上しました。ダイジェスト認証は、HTTPプロトコルで一般に使用され、ほとんどのHTTPクライアントでサポートされている業界標準のプロトコルです。ほとんどのHTTPクライアントではこれがサポートされています。ダイジェスト認証により、暗号化(HTTPS)接続が使用されない場合でも、パスワードが常にセキュアな方法で送信されます。ダイジェスト認証をサポートすることによって、組織では、パスワードの漏えいを心配することなくOracle XML DB HTTPを使用するアプリケーションをデプロイできます。Oracle XML DBでのダイジェスト認証のサポートでは、Oracle XML DB HTTPサーバーとMicrosoft Web Folders WebDAVクライアントとの互換性も引き続き維持されます。

新しいリリースのインストールまたはアップグレード後に、次のようにOracle XML DBのFTPおよびHTTPポートを手動で構成する必要があります。

  1. DBMS_XDB_CONFIG.setHTTPPort(HTTP_port_number)を使用して、Oracle XML DBのHTTPポートを設定します。 

    SQL> exec DBMS_XDB_CONFIG.setHTTPPort(port_number);

  2. Use DBMS_XDB_CONFIG.setFTPPort(FTP_port_number)を使用して、Oracle XML DBのFTPポートを設定します。 

    SQL> exec DBMS_XDB_CONFIG.setFTPPort(FTP_port_number);

    ノート:

    手順内のFTPおよびHTTPで使用するポート番号は、DBMS_XDB_CONFIG.getFTPPortおよびDBMS_XDB_CONFIG.getHTTPPortをそれぞれ使用することによって問い合せることができます。

  3. 使用されているすべてのポート番号を確認するには、DBMS_XDB_CONFIG.usedportを問い合せます。

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

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

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

Oracle Database 23c以降、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パスワード・バージョンを表します。

ノート:

Oracle Database 23c以降、Oracle Database 11gで導入されたSHA-1検証機能は非推奨です。

Oracle Database 12cで導入されたsalt付きの複数ラウンドSHA-512パスワード・ハッシュ("検証機能"とも呼ばれる)は、パスワードのセキュリティを強化します。データベースで11gの検証機能(11G)がまだ使用されている場合は、12c (12C)の最適化解除済PBKDF2ベースの検証機能にアップグレードできるように、リセットすることをお薦めします。

  • ユーザー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パスワード・バージョンを削除し、ユーザーが11G以降の検証機能を使用していることを確認する必要があります。リリース23c以降にすでにアップグレードしてある場合、10Gパスワード・バージョンのみを使用しているユーザーは、10Gパスワード・バージョンがサポートされなくなったためにデータベースにログインできません。管理者は、このユーザーのパスワードを手動で再設定する必要があります。

  1. すべてのクライアントにO5L_NP機能があることを確認します。そのためには、それらにCPUOct2012パッチが適用されていることを確認します。
    O5L_NPの詳細は、『Oracle Database Net Servicesリファレンス』を参照してください。
  2. DBA_USERSデータ・ディクショナリ・ビューを問い合せて、10G検証機能のみを持つユーザー・アカウントを検索します。
    SELECT USERNAME FROM DBA_USERS 
WHERE ( PASSWORD_VERSIONS = '10G '
OR PASSWORD_VERSIONS = '10G HTTP ')
AND USERNAME <> 'ANONYMOUS';
  3. アカウント管理者としてログインした後、これらのアカウントのパスワードを変更して、これらのアカウントに11Gおよび12C検証機能を両方ともプロビジョニングできるようにします。(10G検証機能はサポートが終了しているため、この検証機能しか使用できないユーザーは、このパスワード変更操作自体を実行できず、管理ユーザーがそれらのユーザーのパスワードを再設定する必要があります。)
  4. 帯域外形態の安全な通信を使用してユーザーに新しいパスワードを送信し、ユーザー自身がパスワードを変更するよう依頼します。

親トピック: 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のアップグレード後の推奨作業およびベスト・プラクティス

ロールバック・セグメントから自動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 23cでは、従来の監査はサポートされなくなりました。ご使用のデータベースで従来の監査を無効にし、統合監査のみを使用することをお薦めします。

統合監査と従来の監査(混合モード)は、Oracle Database 12c以降デフォルトの監査モードでした。混合モードの監査は、統合監査に慣れるためと、従来の監査から移行するために提供されていました。Oracle Database 21cで従来の監査が非推奨になり、23cで従来の監査のサポートが終了するため、統合監査に移行することをお薦めします。ご使用のデータベースで従来の監査を無効にし、統合監査のみを使用することをお薦めします。

関連項目

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

Oracle Databaseの監査の理解

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

新しく作成されたデータベースでは、統合監査がデフォルトで有効化されます。事前定義された監査ポリシーであるORA_SECURECONFIGポリシーとORA_LOGIN_LOGOUTポリシーは、すぐに使用できる状態で有効になっています。

ノート:

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

関連項目

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

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 Databaseでの従来の監査の無効化

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

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

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

関連項目

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

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

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

新しいOracle Databaseリリースへのアップグレード後に、従来の監査を引き続き使用する場合は、以前のリリースのOracleドキュメントおよびOracle Technology Networkに情報が記載されています。従来の監査は、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 Databaseでの従来の監査の無効化

再構築対象の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のアップグレード後のリカバリ・カタログ・アップグレードについて

RMANクライアントで要求されるバージョンより古いリカバリ・カタログ・スキーマを使用している場合、そのカタログをアップグレードする必要があります。

参照:

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

Oracle Databaseのアップグレード後のタイムゾーン・ファイルのバージョンのアップグレード

データベースのアップグレードを完了した後にAutoUpgradeアップグレード前レポートによってタイムゾーン・ファイルのアップグレードを指示され、このタスクを完了するようにAutoUpgradeを設定しない場合は、サポートされている方法のいずれかを使用してタイムゾーン・ファイルをアップグレードします。

デフォルトでは、AutoUpgradeはデータベースのタイム・ゾーンを最新の使用可能なレベルに変更します。タイム・ゾーンをアップグレードしない場合は、AutoUpgrade構成ファイル内のローカル・パラメータtimezone_upgを明示的にnoに設定する必要があります。たとえば:

upg1.timezone_upg=no

ノート:

AutoUpgrade構成ファイルでタイムゾーン・ファイルのアップグレードを明示的に無効にする場合は、このタスクをアップグレード計画の一環として実行するか、後で実行することをお薦めします。

関連項目

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

アップグレードされたデータベースでの無効なリリース更新バグ修正の有効化

実行計画の変更の原因となる可能性があるリリース更新のバグ修正は無効になっているため、使用する無効なバグ修正を有効にすることをお薦めします。

データベースをアップグレードした後、リリース更新に含まれる実行計画の変更の原因となるバグ修正パッチがデフォルトで無効になっている状態でインストールされます。これらのバグ修正は、修正を有効にするまで有効になりません。これらの修正は、PFILEコマンドまたはALTER SYSTEMコマンドで手動で有効にすることも、DBMS_OPTIM_BUNDLEパッケージを使用することもできます。AutoUpgrade 19.12以降、DBMS_OPTIM_BUNDLEパッケージには58個の標準修正が含まれています。これで、DBMS_OPTIM_BUNDLEを使用して修正を追加できるようになりました。修正を追加すると、追加した修正はデフォルトの修正に加えて実行されます。

本番システムで使用するこれらの無効になっているパッチを有効にし、アップグレード・テスト計画の一部としてこれらのパッチを使用して完全なワークロード・パフォーマンス・テストを実行することをお薦めします。

DBMS_OPTIM_BUNDLEを使用して、実行計画を変更する可能性があるために無効にされたパッチを有効にする方法の詳細は、Oracle Database PL/SQLパッケージおよびタイプ・リファレンス、およびMy Oracle Supportノート2147007.1を参照してください。

関連項目

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

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

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

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

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

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