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

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

Oracle Databaseを更新する場合、これらの適切なプラクティス・ガイドラインを完了することをお薦めします。これらのプラクティスは、手動とDBUAの両方のアップグレードにお薦めです。

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

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

本番データベースの全体バックアップを実行します。

このステップは必須ではありませんが、本番データベースをバックアップすることを強くお薦めします。

参照:

RMANを使用したデータベースのバックアップの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

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

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

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

アップグレード後修正スクリプトは、アップグレード前情報ツール(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で実行します。

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

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

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

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

SQL> SPOOL OFF

例4-6 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)以上では、アップグレード後にデータベースを通常モードで起動したときに、統計を手動で収集するようになりました。

  • 非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に対して代表的なワークロードを実行してから固定オブジェクトの統計を再収集することを強くお薦めします。

固定オブジェクトは、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 18cの表領域アラートのしきい値はNULLに設定され、アラートは無効化されます。

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

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

  • 警告(表領域の使用率が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 Databaseの統合監査の使用への移行

統合監査の全機能を使用するには、手動で統合監査に移行する必要があります。

統合監査では、すべてのOracle Database監査証跡(データベース監査証跡ではSYS.AUD$、ファイングレイン監査ではSYS.FGA_LOG$、Database VaultではDVYS.AUDIT_TRAIL$など)は、1つの監査証跡にまとめられますが、これは、単一インスタンスのインストールではUNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューを、Oracle Real Application Clusters環境ではGV$UNIFIED_AUDIT_TRAILを問い合せることによって表示できます。

参照:

このリリースでの監査機能の変更の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。

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

Oracle Databaseでの統合監査の移行プロセスの理解

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

デフォルトでは、アップグレードされたデータベースでは、統合監査は有効化されていません。以前のリリースからOracle Database 12cアップグレードした場合は、データベースでは以前のリリースで使用していたものと同じ監査機能が使用されています。新しく作成されたデータベースでは、統合監査の混合モードの方式がデフォルトで有効化されます。統合監査への移行が完了すると、従来の監査は無効化され、新しい監査レコードが統合監査証跡に書き込まれます。

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

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

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

    ノート:

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

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

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

    ノート:

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

    参照:

親トピック: アップグレードしたOracle Databaseの統合監査の使用への移行

Oracle Databaseでの統合監査への移行

マルチテナント・コンテナ・データベース(CDB)でこの手順を使用して、統合監査に移行します。

CDB環境で、rootで次の手順を実行します。この手順によって、rootCDBとそれに関連する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 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. 統合監査を有効化します。

    • LinuxおよびUNIX

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

    • 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

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

    net start OracleService%ORACLE_SID%

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

    srvctl start database -db db_name

親トピック: アップグレードしたOracle Databaseの統合監査の使用への移行

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

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

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

参照:

親トピック: アップグレードしたOracle Databaseの統合監査の使用への移行

統合監査機能の削除

この手順を使用して、統合監査を削除し、混合モードの監査を使用します。

データベースで統合監査を使用できるようにした後で、統合監査を使用しないことに決定した場合、この手順を使用して、統合監査機能を削除できます。この場合、データベースでは混合モードの監査機能が使用されます。

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

    sqlplus sys as sysoper
Enter password: password

SQL> SHUTDOWN IMMEDIATE
SQL> EXIT

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

    net stop OracleService%ORACLE_SID%

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

    srvctl stop database -db db_name

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

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

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

      make -f ins_rdbms.mk uniaud_off ioracle 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
    5. 
                     

                  

                  

                     

                        

                           
親トピック: アップグレードしたOracle Databaseの統合監査の使用への移行

                        

                     

                  

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

                  

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

                     
新しいOracle Databaseリリースへのアップグレード後に、統合監査に変更しないことを選択した場合、OracleドキュメントおよびOracle Technology Networkで従来の非統合監査に関する情報が提供されています。 

                     
    
                        
  • 
                           
    Oracle Databaseセキュリティ・ガイド: このガイドは、監査を構成する際の主要な情報源です。このマニュアルのOracle Databaseリリース11gバージョンを使用する必要があります。このガイドにアクセスするには:
                           
    
                           
      
                              
    1. 
                                 
      次のURLのOracle Technology Networkに移動します。
      
                                 
      http://www.oracle.com/technetwork/index.html
      
                              
      2. 
                              
    2. 
                                 
      「ダウンロード」メニューで、「データベース」の下にある「Database 11g」を選択します。
                                 
      
                              
      3. 
                              
    3. 
                                 
      「ダウンロード」ページで、「ドキュメント」タブを選択します。
                                 
      
                              
      4. 
                              
    4. 
                                 
      最新のOracle Database 11g Release 2 (11.2)の「ドキュメント」ページから、「ライブラリの表示」リンクを選択して、リリース11gドキュメント・セットのホーム・ページを表示します。 
                                 
      
                              
      5. 
                              
    5. 
                                 
      「検索」フィールドで、「マスター・ブック・リスト」リンクを選択します。
                                 
      
                              
      6. 
                              
    6. 
                                 
      「セキュリティ・ガイド」を検索します。
                                 
      
                              
      7. 
                              
    7. 
                                 
      このガイドの「HTML」または「PDF」リンクのいずれかを選択します。
                                 
      
                              
      8. 
                           
    
                        
    • 
                        
  • 
                           
    Oracle Database SQL言語リファレンス: このガイドでは、統合監査および非統合監査の両方の環境でのAUDIT文およびNOAUDIT文の使用方法について説明しています。 
                           
    
                        
    • 
                        
  • 
                           
    Oracle Databaseリファレンス: このガイドは、非統合監査環境に関連付けられている初期化パラメータおよびデータ・ディクショナリ・ビューの使用方法について説明しています。
                           
    
                        
    • 
                        
  • 
                           
    Oracle Database Vaultの管理者ガイド: このガイドでは、非統合監査環境でDatabase Vaultに対する監査を構成する方法を説明しています。
                           
    
                        
    • 
                        
  • 
                           
    Oracle Label Security管理者ガイド: このガイドでは、非統合監査環境でOracle Label Securityに対する監査を構成する方法を説明しています。
                           
    
                        
    • 
                     

                  

                  

                     

                        

                           
親トピック: アップグレードした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. 
                        
  2. マルチテナント環境ではDBA_PDB_HISTORYビューに問い合せて、監査レコードの転送元のコンテナ固有のCLI表に関連付けられた正しいGUIDを見つけます。
    
                              
    次に例を示します。
    SQL> SELECT PDB_NAME, PDB_GUID FROM DBA_PDB_HISTORY;

PDB_NAME  PDB_GUID
--------  --------------------------------
HR_PDB    33D96CA7862D53DFE0534DC0E40A7C9B
...
    
                        
    3. 
                        
  3. マルチテナント環境の、監査レコードの転送を行うコンテナに接続します。
    
                              
    現在接続しているコンテナとは別のコンテナでは転送操作を実行できません。 
    
                           
    
                        
    4. 
                        
  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. 
                        
  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. 
                        
  6. UNIFIED_AUDIT_TRAILデータ・ディクショナリに問い合せて、レコードが正しく転送されたことを確認します。
    
                              
    問合せUNIFIED_AUDIT_TRAILを行うことを強くお薦めします。監査レコードが正常に転送されたら、問合せUNIFIED_AUDIT_TRAILを行う必要があります。これは、V$UNIFIED_AUDIT_TRAIL動的ビューの問合せではOSの過剰ファイルにある監査レコードしか表示されないからです。
                              
    
                           
    
                        
    7. 
                     

                  

                  

                     

                        

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

                        

                     

                  

                  
               

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

               

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

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

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

               

               

                  

                     

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