Oracle Databaseのアップグレード後の推奨作業およびベスト・プラクティス
Oracle Databaseを更新する場合、これらの適切なプラクティス・ガイドラインを完了することをお薦めします。これらのプラクティスは、手動とDBUAの両方のアップグレードにお薦めです。
- データベースのバックアップ
本番データベースの全体バックアップを実行します。 - アップグレード後修正スクリプトの実行
CDBおよび非CDBデータベースに対してpostupgrade_fixups.sql
スクリプトを使用する方法を理解するためには、この手順を確認します。 - アップグレード後のディクショナリ統計の収集
アップグレードを完了した後に高いパフォーマンスを保証するためには、この手順を使用してディクショナリ統計を収集します。 - DBMS_STATSを使用した固定オブジェクトの統計の再収集
アップグレードの後に、または他のデータベース構成の変更後に、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 ASMは、Oracle Grid Infrastructureとともにインストールされます。 - 新機能の適宜追加
データベース・アップグレード計画の一環として新機能を確認します。 - 必要な新しい管理手順の作成
スクリプトおよびプロシージャの再確認を計画し、必要に応じて変更します。 - 表領域アラートのしきい値の設定
アップグレード後、Oracle Database 12cデータベースの表領域アラートのしきい値はNULLに設定され、アラートは無効化されます。 - ロールバック・セグメントから自動UNDOモードへの移行
データベース・リリースがOracle Database 11gより前の場合は、ロールバック・セグメント(手動UNDO管理)を使用してアップグレードしているデータベースを自動UNDO管理に移行する必要があります。 - Oracle Data Guard Brokerの構成
InitialConnectIdentifierはDGConnectIdentifierに置き換えられたため、Oracle Database 10gからのアップグレードに影響します。 - LONGデータ型からLOBデータ型への表の移行
ALTER TABLE
文を使用して、LONG
データ型の列をCLOB
に、LONG RAW
データ型の列をBLOB
に変更できます。 - アップグレードしたOracle Databaseの統合監査の使用への移行
統合監査の全機能を使用するには、手動で統合監査に移行する必要があります。 - DBMS_SCHEDULERジョブの削除および再作成
以前のリリースからのアップグレード後にDBMS_SCHEDULERジョブが機能しなくなった場合は、ジョブを削除して再作成します。 - アップグレード後の統合監査レコードの転送
アップグレードし、統合監査に移行した後で高いパフォーマンスを得る方法を理解するためには、これらのトピックを確認します - アップグレードした本番Oracle Databaseのテストの概要
アプリケーションが期待どおり動作することを確認するため、テスト・データベースに実行したテストを本番データベースに対して繰り返します。
親トピック: Oracle Databaseのアップグレード後の作業
データベースのバックアップ
本番データベースの全体バックアップを実行します。
このステップは必須ではありませんが、本番データベースをバックアップすることを強くお薦めします。
参照:
RMANを使用したデータベースのバックアップの詳細は、『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つの異なるスクリプト・セット:
-
postupgrade_fixups.sql
: すべてのPDB用の統合スクリプト -
複数の
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 12cリリース2 (12.2)以降、アップグレード後にデータベースを通常モードで起動したときに、統計を手動で収集するようになりました。
-
非CDBのOracle Databaseの場合:
DBMS_STATS.GATHER_DICTIONARY_STATS
プロシージャを使用して、統計を収集することをお薦めします。たとえば、次のSQL文を入力します。SQL> EXEC DBMS_STATS.GATHER_DICTIONARY_STATS;
-
CDB (マルチテナント・アーキテクチャ) Oracle Databaseの場合:
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コマンドそのものは、引用符で囲みます。
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;
パスワードのリセットによる大/小文字区別の強制
アップグレードしたデータベースで、デフォルト・ユーザー・アカウントおよびユーザー・アカウントの大/小文字区別のあるパスワードを使用してセキュリティを強化します。
セキュリティを強化するために、パスワードで大/小文字の区別を有効にすることをお薦めします。大/小文字を区別すると、ユーザーは、正しいパスワード文字列を入力し、さらにその文字列の各文字の大/小文字も正しく区別する必要があるため、パスワードのセキュリティを強化できます。たとえば、パスワードが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のパスワード・バージョンのみを持つすべてのアカウントのパスワードをリセットします。
- 10Gパスワード・バージョンを使用するユーザーのパスワードの確認と再設定
セキュリティを向上するため、10G
バージョンのパスワードを使用しているユーザー・アカウントを確認しパスワードをリセットして、より安全なバージョンのパスワードが今後使用されるようにします。
参照:
-
パスワードの大/小文字区別の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください
-
パスワードの強度の詳細は、『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
パスワード・バージョンだけを持つように、ユーザーはもう一度パスワードを再設定できます。
親トピック: パスワードのリセットによる大/小文字区別の強制
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 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 12cリリースの機能をよく理解したうえで、データベース管理用のスクリプトおよびプロシージャを再確認し、変更が必要かどうかを判断します。
それぞれのアプリケーションに必要な変更を、データベースにも行う必要があります。たとえば、データベースで整合性制約を使用可能にした場合、アプリケーションでのデータ・チェックの一部を削除できます。
表領域アラートのしきい値の設定
アップグレード後、Oracle Database 12cデータベースの表領域アラートのしきい値はNULLに設定され、アラートは無効化されます。
データベース内で監視対象となる表領域を特定し、それらの表領域に適切なしきい値を設定する必要があります。
新しく作成されたOracle Database 12cインストールでは、次の値がデフォルトとして使用されます。
-
警告(表領域の使用率が85%の場合)
-
クリティカル(表領域の使用率が97%の場合)
ロールバック・セグメントから自動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領域はロールバック・セグメントとして外部に割り当てられます。
Oracle Data Guard Brokerの構成
InitialConnectIdentifierはDGConnectIdentifierに置き換えられたため、Oracle Database 10gからのアップグレードに影響します。
DGConnectIdentifier
の値は、常時、すべてのData Guardネットワーク・トラフィック用に使用されます。Oracle Databaseリリース10gの構成をアップグレードする場合は、最初にOracle Database 11gにアップグレードする必要があり、InitialConnectIdentifier
の値は、そのデータベースのDGConnectIdentifier
の新しい値として保持されます。Oracle Real Application Clusters (Oracle RAC)データベースをアップグレードする場合、データベース管理者は、InitialConnectIdentifier
プロパティの値がすべてのインスタンスに適用されることを確認する必要があります。
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監査証跡(データベース監査証跡では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での統合監査への移行
マルチテナント・コンテナ(CDB)データベースでこの手順を使用して、統合監査に移行します。 - 統合監査への移行後の古い監査レコードの管理の概要
統合監査証跡を使用する準備として古い監査証跡を確認、アーカイブおよび削除します。 - 統合監査機能の削除
この手順を使用して、統合監査を削除し、混合モードの監査を使用します。 - 統合監査を使用しない場合のドキュメント参照の取得
ここにリストされているドキュメントにアクセスして、非統合監査の情報を取得できます。
参照:
このリリースでの監査機能の変更の詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
Oracle Databaseでの統合監査の移行プロセスの理解
アップグレードしたデータベースで使用する監査ポリシーを決定します。
デフォルトでは、アップグレードされたデータベースでは、統合監査は有効化されていません。以前のリリースからOracle Database 12cアップグレードした場合は、データベースでは以前のリリースで使用していたものと同じ監査機能が使用されています。新しく作成されたデータベースでは、統合監査の混合モードの方式がデフォルトで有効化されます。統合監査への移行が完了すると、従来の監査は無効化され、新しい監査レコードが統合監査証跡に書き込まれます。
監査ポリシーを有効化して使用方法を構成するには、次のように1つの方法を選択します。
-
純統合監査機能を使用。
統合監査に移行して、統合監査の全機能を使用します。統合監査への移行手順が完了すると、新しい監査ポリシーを作成および有効化でき、事前定義された監査ポリシーも使用できます。これらのポリシーの監査レコードは、統合監査証跡に書き込まれます。以前の監査証跡および監査レコードは保持されますが、新しい監査レコードは以前の監査証跡には書き込まれません。
注意:
以前のリリースの監査構成は、統合監査システムでは効果がありません。統合監査証跡内では、統合監査ポリシーのみが監査レコードを生成します。
-
混合モードの監査機能を使用。
混合モードの監査機能は、従来の監査機能と統合監査機能の両方を同時に実行でき、新しいデータベースとアップグレードされたデータベースの両方に適用されます。混合モードの統合監査機能は、1つ以上の事前定義された統合監査ポリシーを有効化すると使用可能になります。これらのポリシーの監査レコードは、統合監査証跡に書き込まれます。Oracle Databaseの以前のリリースでの監査構成も使用可能で、この構成の監査レコードは以前の監査証跡に書き込まれます。純統合監査機能を使用することに決定した場合、それに移行できます。
注意:
データベースが書込み不可な場合、監査レコードは、
$ORACLE_BASE/audit/$ORACLE_SID
ディレクトリにある新しい形式のオペレーティング・システム・ファイルに書き込まれます。参照:
-
事前定義された監査ポリシーの詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
-
ora_SecureConfig監査ポリシーの詳細は、『Oracle Databaseセキュリティ・ガイド』を参照してください。
-
Oracle Databaseでの統合監査への移行
マルチテナント・コンテナ・データベース(CDB)でこの手順を使用して、統合監査に移行します。
CDB環境で、root
で次の手順を実行します。この手順によって、root
CDBとそれに関連するPDBの両方が統合監査に移行されます。
-
SYSDBA
権限を持つユーザーSYS
としてSQL*Plusにログインします。sqlplus sys as sysdba Enter password: password
プラガブル・データベース環境では、このログインにより、
root
に接続されます。 -
次の問合せを使用して、使用しているOracle Databaseが統合監査に移行したかどうかを確認します。
SQL> SELECT VALUE FROM V$OPTION WHERE PARAMETER = 'Unified Auditing';
VALUE
列の出力がTRUE
の場合、データベースで統合監査がすでに有効化されています。以前の監査レコードの管理に進むことができます。出力がFALSE
の場合は、この手順の残りのステップを完了してください。 -
データベースを停止します。単一インスタンス環境では、SQL*Plusから次のコマンドを入力します。
SQL> SHUTDOWN IMMEDIATE SQL> EXIT
Windowsシステムでは、Oracleサービスを停止します。
net stop OracleService%ORACLE_SID%
Oracle RACインストールの場合は、次のようにして、各データベース・インスタンスを停止します。
srvctl stop database -db db_name
-
リスナーを停止します。(Oracle RACおよびOracle Grid Infrastructureリスナーでは、リスナーを停止する必要はありません。)
lsnrctl stop listener_name
lsnrctl
status
コマンドを実行すると、リスナーの名前を検索できます。名前はAlias
設定で示されます。 -
ディレクトリ
$ORACLE_HOME/rdbms/lib
に移動します。 -
統合監査を有効化します。
-
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内のバイナリが更新されるようにする必要があります。
-
-
リスナーを再起動します。
lsnrctl start listener_name
-
データベースを再起動します。
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セキュリティ・ガイド』の監査証跡レコードの削除に関する説明
統合監査機能の削除
この手順を使用して、統合監査を削除し、混合モードの監査を使用します。
データベースで統合監査を使用できるようにした後で、統合監査を使用しないことに決定した場合、この手順を使用して、統合監査機能を削除できます。この場合、データベースでは混合モードの監査機能が使用されます。
-
データベースを停止します。
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
-
$ORACLE_HOME/rdbms/lib
ディレクトリに移動します。 -
統合監査実行可能ファイルを無効にします。
-
UNIX: 次のコマンドを実行します。
make -f ins_rdbms.mk uniaud_off ioracle ORACLE_HOME=$ORACLE_HOME
-
Windows:
%ORACLE_HOME%/bin/orauniaud12.dll
ファイルの名前を%ORACLE_HOME%/bin/orauniaud12.dll.dbl
に変更します。
-
-
データベースを再起動します。
sqlplus sys as sysoper Enter password: password SQL> STARTUP SQL> EXIT
Windowsシステムでは、Oracleサービスを再度起動します。
net start OracleService%ORACLE_SID%
Oracle RACインストールの場合は、次の構文を使用して、各データベース・インスタンスを起動します。
srvctl start database -db db_name
統合監査を使用しない場合のドキュメント参照の取得
ここにリストされているドキュメントにアクセスして、非統合監査の情報を取得できます。
Oracle Database 12cへのアップグレード後に、統合監査に変更しないことを選択した場合、OracleドキュメントおよびOracle Technology Networkで従来の非統合監査に関する情報が提供されています。
-
Oracle Databaseセキュリティ・ガイド: このガイドは、監査を構成する際の主要な情報源です。このマニュアルのOracle Databaseリリース11gバージョンを使用する必要があります。このガイドにアクセスするには、次の手順を実行します。
-
次のURLのOracle Technology Networkに移動します。
-
「ダウンロード」
メニューで、「データベース」
の下にある「Database 11g」
を選択します。 -
「ダウンロード」ページで、「ドキュメント」タブを選択します。
-
最新のOracle Database 11g Release 2 (11.2)の「ドキュメント」ページから、「ライブラリの表示」リンクを選択して、リリース11gドキュメント・セットのホーム・ページを表示します。
-
「検索」フィールドで、「マスター・ブック・リスト」リンクを選択します。
-
「セキュリティ・ガイド」を検索します。
-
このガイドの「HTML」または「PDF」リンクのいずれかを選択します。
-
-
Oracle Database SQL言語リファレンス: このガイドでは、統合監査および非統合監査の両方の環境での
AUDIT
文およびNOAUDIT
文の使用方法について説明しています。 -
Oracle Databaseリファレンス: このガイドは、非統合監査環境に関連付けられている初期化パラメータおよびデータ・ディクショナリ・ビューの使用方法について説明しています。これらのリストについては、『Oracle Databaseセキュリティ・ガイド』を参照してください。
-
Oracle Database Vault管理者ガイド: このガイドでは、非統合監査環境でDatabase Vaultに対する監査を構成する方法を説明しています。
-
Oracle Label Security管理者ガイド: このガイドでは、非統合監査環境でOracle Label Securityに対する監査を構成する方法を説明しています。
DBMS_SCHEDULERジョブの削除および再作成
以前のリリースからのアップグレード後にDBMS_SCHEDULERジョブが機能しなくなった場合は、ジョブを削除して再作成します。
アップグレード後にDBMS_SCHEDULERジョブが機能しないことに気づいたら、それらのジョブを削除して再作成してください。この問題は、アップグレード処理からの問題報告がなく、システム・オブジェクトが有効な場合でも発生する可能性があります。
アップグレード後の統合監査レコードの転送
統合監査をアップグレードし、移行した後で高いパフォーマンスを得る方法を理解するためには、これらのトピックを確認します。
- アップグレード後の統合監査レコードの転送について
統合監査レコードをOracle Database 12cリリース12.1から、このリリースのAUDSYS
スキーマ下の新しいリレーショナル表に転送すると、統合監査証跡の読取りパフォーマンスが向上します。 - アップグレード後の統合監査レコードの転送
DBMS_AUDIT_MGMT.TRANSFER_UNIFIED_AUDIT_RECORDS PL/SQLプロシージャを使用して、統合監査レコードをAUDSYSの新しいリレーショナル表に転送できます。
アップグレード後の監査レコードの転送の概要
統合監査レコードをOracle Database 12cリリース12.1から、このリリースのAUDSYS
スキーマ下の新しいリレーショナル表に転送すると、統合監査証跡の読取りパフォーマンスが向上します。
今回のリリースから、統合監査レコードは直接、AUDSYSスキーマにある新しい内部リレーショナル表に書き込まれます。Oracle Database 12cリリース12.1では、統合監査レコードは共通ロギング・インフラストラクチャ(CLI) SGAキューに書き込まれていました。そのリリースの統合監査に移行した場合は、そのリリースの統合監査レコードをこの新しい内部表に転送して、より高い読取りパフォーマンスを得ることができます。この転送を実行することは必須ではありませんが、新しい内部表により統合監査証跡の読取りパフォーマンスが向上するため、これをお薦めします。これは1回かぎりの操作です。アップグレード後に生成されたすべての新しい統合監査レコードはこの新しい表に書き込まれます。この表は読取り専用で、表のメタデータとデータを変更しようとすると、それらはすべて強制的に監査されます。
Oracle Database 12cリリース12.2にアップグレードした後に、以前のリリースのUNIFIED_AUDIT_TRAIL
に統合監査レコードが存在している場合は、この転送プロシージャを使用してそれらを新しい内部リレーショナル表に転送し、統合監査証跡の読取りパフォーマンスを高めることを検討してください。
SYS
スキーマの場合と同様、SELECT ANY TABLEシステム権限がある場合はAUDSYSスキーマの問合せはできません。さらに、この表はユーザーがSELECT ANY DICTIONARYシステム権限か、この内部表に対する明示的なSELECT権限を持っていないかぎり、ALL_TABLESデータ・ビューでスキーマ・オブジェクトとしてリストされません。データベースが読取り/書込みモードでオープンするまで、監査レコードはOSの過剰ファイルに書き込まれます(.bin
形式)。ただし、データベースが読取り/書込みモードでオープンした後に、DBMS_AUDIT_MGMT.LOAD_UNIFIED_AUDIT_FILESプロシージャを使用してこれらのOSファイルの監査レコードを内部リレーショナル表に転送することはできません。
親トピック: アップグレード後の統合監査レコードの転送
アップグレード後の監査レコードの転送
DBMS_AUDIT_MGMT.TRANSFER_UNIFIED_AUDIT_RECORDS PL/SQLプロシージャを使用して、統合監査レコードをAUDSYSの新しいリレーショナル表に転送できます。
親トピック: アップグレード後の統合監査レコードの転送
アップグレードした本番Oracle Databaseのテストの概要
アプリケーションが期待どおり動作することを確認するため、テスト・データベースに実行したテストを本番データベースに対して繰り返します。
テスト・データベースを新しいOracle Databaseリリースにアップグレードしてテストした場合、新しいOracle Database 12cリリースにアップグレードした本番データベースでも同じテストを繰り返すことができます。結果を比較し、相違点を記録します。必要に応じて、アップグレードのテストを繰り返します。
新しいOracle Databaseで既存のアプリケーションが正常に動作するかどうかを確認するために、この新しくアップグレードされた本番データベースをテストします。また、利用可能なOracle Databaseの機能を追加して、機能拡張についてもテストします。ただし、アプリケーションがアップグレードの前と同様に動作するかどうかを最初に確認してください。