25 REDOログ・ファイル分析のためのLogMinerの使用
LogMinerは、Oracle Databaseの一部であり、SQLインタフェースを介してオンラインおよびアーカイブのREDOログ・ファイルを問い合せることができます。
REDOログ・ファイルには、データベースでのアクティビティの履歴情報が含まれています。LogMinerはコマンドラインから使用できます。
ノート:
dbms_logmnr.start_logmnr
パッケージのcontinuous_mine
オプションは、Oracle Database 19c (19.1)ではサポートされなくなり、使用できなくなりました。
- LogMinerのメリット
ユーザー・データまたはデータベース・ディクショナリに対して行われたすべての変更は、データベースのリカバリ操作を実行できるように、Oracle REDOログ・ファイルに記録されます。 - LogMinerの概要
DBAとしてのOracleのLogMinerツールは、PL/SQLプロシージャおよびファンクションのセットを使用して、REDOログ・ファイル内の変更されたレコードを検索するのに役立ちます。 - CDBでのLogMinerの使用
LogMinerセッションの確認に使用するビューと、ログのマイニングに使用する構文について説明します。 - Oracle GoldenGateのサプリメンタル・ロギングの構成方法
Oracle Database 21c以降は、Oracle Databaseは個々の表の論理レプリケーションおよびサプリメンタル・ロギングを有効にするサポートを提供します。 - LogMinerディクショナリ・ファイルおよびREDOログ・ファイル
正確なログ・マイニング結果を取得するには、LogMinerがLogMinerディクショナリとどのように連携するかを学習します。 - LogMinerの起動
LogMinerを起動するには、DBMS_LOGMNR.START_LOGMNR
プロシージャをコールします。 - 分析するREDOデータについてのV$LOGMNR_CONTENTSの問合せ
分析するREDOデータにアクセスするには、V$LOGMNR_CONTENTS
ビューを問い合せます。 - V$LOGMNR_CONTENTSに返されるデータのフィルタリングと書式設定
V$LOGMNR_CONTENTS
ビューのフィルタリング機能と書式設定機能を使用して、表示されるデータおよび表示する方法を管理し、データが返される速度を制御する方法について説明します。 - V$LOGMNR_CONTENTSに返されたDDL文の再適用
LogMinerを使用して1つ以上のDDL文を実行する場合は、V$LOGMNR_CONTENTS
INFO
列を問い合せ、USER_DDL
としてマークされたSQL DDLのみを実行します。 - DBMS_LOGMNR.START_LOGMNRの複数回のコール
DBMS_LOGMNR.START_LOGMNR
のコールに成功し、V$LOGMNR_CONTENTS
ビューから選択した後でも、現在のLogMinerセッションを終了せずにDBMS_LOGMNR.START_LOGMNR
を再度コールし、異なるオプションおよび時間範囲またはSCN範囲を指定できます。 - LogMinerおよびサプリメンタル・ロギング
LogMinerのサプリメンタル・ロギング機能の使用方法について説明します - ビューでのLogMiner操作情報へのアクセス
LogMiner操作情報(REDOデータではない)は、ビューに含まれています。 - 一般的なLogMinerセッションのステップ
LogMinerを使用してデータを抽出およびマイニングできる一般的な方法について説明します。 - LogMinerの使用例
データ・マイニングにLogMinerを使用する方法を確認するには、示されている例を確認してください。 - サポートされるデータ型、記憶域属性、およびデータベースとREDOログ・ファイルのバージョン
データ型と記憶域属性のサポートに関する情報およびサポートされるデータベースとREDOログ・ファイルのリリースについて説明します。
親トピック: その他のユーティリティ
25.1 LogMinerのメリット
ユーザー・データやデータベース・ディクショナリに対するすべての変更は、Oracle REDOログ・ファイルに記録されます。これによってデータベース・リカバリ操作が実行できます。
LogMinerには、REDOログ・ファイルに対して適切に定義された使いやすい包括的なリレーショナル・インタフェースが用意されているため、強力なデータ監査ツールとしても、高度なデータ分析ツールとしても使用できます。次に、LogMinerの主要機能の一部を示します。
-
アプリケーション・レベルで発生したエラーなど、データベースの論理的破損が発生した時期を特定します。
WHERE
句の値に誤りがあったために不適切な行を削除した、不適切な値で行を更新した、不適切な索引を消去したなどのエラーがこれに含まれます。たとえば、ユーザー・アプリケーションで、すべての社員の給与を10%増額するところを100%増額するように誤ってデータベースを更新してしまったり、データベース管理者(DBA)が誤って重要なシステム表を削除してしまったりすることがあります。エラーが発生した時期を正確に知ることは、時刻ベースまたは変更ベースのリカバリの開始時期の特定に役立ちます。この情報から、破損する直前の状態にデータベースをリストアできます。LogMinerを使用したこのような処理方法の詳細は、「列の値に基づいたV$LOGMNR_CONTENTSの問合せ」を参照してください。 -
トランザクション・レベルでファイングレインなリカバリを行うために必要な処置を特定します。既存の依存性についての正しい理解と認識があれば、表固有のundo操作を実行し、表を元の状態に戻すことができます。そのために、LogMinerは、元のSQL文の発行順序を逆にたどる表固有の再構築されたSQL文を適用します。例については、「使用例1: LogMinerを使用した特定のユーザーによる変更の追跡」を参照してください。
通常は、表を以前の状態にリストアしてから、アーカイブされたREDOログ・ファイルを適用して、表をロールフォワードします。
-
傾向分析により、パフォーマンス・チューニングとキャパシティ・プランニングを実行します。どの表で更新や挿入が最も多いかを判断できます。その情報は、ディスク・アクセス統計に関する履歴的観点を提供するため、チューニングに使用できます。例については、「使用例2: LogMinerを使用した表アクセス統計の計算」を参照してください。
-
事後監査を実行します。LogMinerを使用して、データベースで実行されたデータ操作言語(DML)文およびデータ定義言語(DDL)文、これらの文が実行された順序、および文の実行者を追跡できます。(ただし、LogMinerをそのような目的に使用するには、そのイベントが発生した時期を知り、分析に適したログを指定できる必要があります。そうでない場合、多数のREDOログ・ファイルのマイニングが必要となり、時間がかかる場合があります。LogMinerの使用は、データベース使用の監査のための補助と考えてください。データベースの監査の詳細は、『Oracle Database管理者ガイド』を参照してください。
親トピック: REDOログ・ファイル分析のためのLogMinerの使用
25.2 LogMinerの概要
DBAとしてのOracleのLogMinerツールは、PL/SQLプロシージャおよびファンクションのセットを使用して、REDOログ・ファイル内の変更されたレコードを検索するのに役立ちます。
- LogMinerの構成
LogMinerの分析対象オブジェクトについて説明します。また、構成ファイルの例も示します。 - LogMiner操作の指定および分析するデータの取得
LogMiner操作の指定にはPL/SQLパッケージDBMS_LOGMNR
およびDBMS_LOGMNR_D
を、分析するデータの取得にはV$LOGMNR_CONTENTS
ビューを使用します。
親トピック: REDOログ・ファイル分析のためのLogMinerの使用
25.2.1 LogMinerの構成
LogMinerの分析対象オブジェクトについて学習します。また、構成ファイルの例も示します。
- LogMiner構成ファイルのオブジェクト
DataMiner構成ファイルには、ソース・データベース、マイニング・データベース、LogMinerディクショナリおよび注目するデータを格納するREDOログ・ファイルの4つのオブジェクトがあります。 - LogMinerの構成例
この例では、あるOracle Databaseリリースのある場所にREDOログを生成して、そのログをリリースが異なる別のOracle Databaseの別の場所に送信する方法を示します。 - LogMinerの要件
LogMinerでマイニングするデータベースのソースおよびマイニング・データベース、データ・ディクショナリ、REDOログ・ファイルおよび表と列の名前制限の要件について説明します。
親トピック: LogMinerの概要
25.2.1.1 LogMiner構成ファイルのオブジェクト
DataMiner構成ファイルには、ソース・データベース、マイニング・データベース、LogMinerディクショナリおよび注目するデータを格納するREDOログ・ファイルの4つのオブジェクトがあります。
-
ソース・データベースは、LogMinerで分析するすべてのREDOログ・ファイルを生成するデータベースです。
-
マイニング・データベースは、分析実行時にLogMinerにより使用されるデータベースです。
-
LogMinerディクショナリを使用すると、LogMinerがユーザーの要求したREDOログ・データを表すときに、内部オブジェクトIDではなく表名と列名を提供できます。
LogMinerでディクショナリを使用して、内部オブジェクト識別子およびデータ型を、オブジェクト名および外部データ・フォーマットに変換します。ディクショナリがない場合、LogMinerから内部オブジェクトIDが返され、データはバイナリ・データとして表されます。
たとえば、次のSQL文について検討します。
INSERT INTO HR.JOBS(JOB_ID, JOB_TITLE, MIN_SALARY, MAX_SALARY) VALUES('IT_WT','Technical Writer', 4000, 11000);
LogMinerがLogMinerディクショナリなしで結果を配信するときには、LogMinerは次の出力を表示します。
insert into "UNKNOWN"."OBJ# 45522"("COL 1","COL 2","COL 3","COL 4") values (HEXTORAW('45465f4748'),HEXTORAW('546563686e6963616c20577269746572'), HEXTORAW('c229'),HEXTORAW('c3020b'));
-
REDOログ・ファイルには、データベースまたはデータベース・ディクショナリに対して行われた変更が含まれます。
親トピック: LogMinerの構成
25.2.1.2 LogMinerの構成例
この例では、あるOracle Databaseリリースのある場所にREDOログを生成して、そのログをリリースが異なる別のOracle Databaseの別の場所に送信する方法を示します。
次の図に、LogMinerの構成例を示します。この図では、ソース・データベースがボストンにあり、ターゲット・データベースがサンフランシスコにあります。
ボストンにあるソース・データベースでREDOログ・ファイルが生成され、アーカイブ後にサンフランシスコにあるデータベースに送られます。LogMinerディクショナリは、これらのREDOログ・ファイルに対して抽出されます。LogMinerが実際にREDOログ・ファイルを分析するマイニング・データベースは、サンフランシスコにあります。ボストンのデータベースでOracle Database 12gが実行され、サンフランシスコのデータベースでOracle Database 19cが実行されています。
この例は、有効なLogMiner構成の1つを示しているにすぎません。その他に有効な構成としては、ソース・データベースとマイニング・データベースの両方に同じデータベースを使用する構成、データ・ディクショナリを別の方法で提供する構成などがあります。
関連トピック
親トピック: LogMinerの構成
25.2.1.3 LogMinerの要件
LogMinerでマイニングするデータベースのソースおよびマイニング・データベース、データ・ディクショナリ、REDOログ・ファイルおよび表と列の名前制限の要件について学習します。
LogMinerには、次のオブジェクトが必要です。
- 次の特性を持つソース・データベースおよびマイニング・データベース。
- ソース・データベースおよびマイニング・データベースは、同一のハードウェア・プラットフォームで稼働している必要があります。
- マイニング・データベースは、ソース・データベースと同一でも、まったく別であってもかまいません。
- マイニング・データベースは、ソース・データベースと同位か、上位のリリースのOracle Databaseを使用して実行する必要があります。
- マイニング・データベースでは、ソース・データベースで使用するものと同じ文字セット(または文字セットのスーパーセット)を使用する必要があります。
-
LogMinerディクショナリ
- ディクショナリは、LogMinerで分析する必要があるREDOログ・ファイルを生成するソース・データベースと同じデータベースで生成されている必要があります。
- すべてのREDOログ・ファイル(次の特性があるもの)。
- REDOログ・ファイルは、同じソース・データベースで生成する必要があります。
- REDOログ・ファイルは、同じデータベースの
RESETLOGS SCN
に関連付ける必要があります。 - REDOログ・ファイルは、リリース8.0以降のOracle Databaseのものであることが必要です。ただし、リリース9.0.1で導入されたLogMiner機能の一部は、Oracle9i以降のデータベースで生成されたREDOログ・ファイルでのみ機能します。
- マイニング用に選択する表または列の名前は、30文字以内にする必要があります。
ノート:
JSON形式の拡張varchar2列および拡張varchar列名など、30文字を超える拡張列形式を使用するOracle Database 12cリリース2 (12.2)の後に追加されたデータ型および機能は、DBMS_ROLLING
PL/SQLパッケージ、Oracle GoldenGateおよびXStreamからのみサポートされます。30文字を超える仮想列名は、v$logmnr_contents
(dba_logstdby_unsupported
およびdba_rolling_unsupported
ビュー)のUNSUPPORTED
です。
LogMinerでは、異なるデータベースからのREDOログ・ファイルを混在させること、また分析する必要があるREDOログ・ファイルを生成したデータベース以外からのディクショナリを使用することはできません。LogMinerには、30文字以下の表名または列名が必要です。
ノート:
LogMinerで分析するログ・ファイルを生成するには、その前にサプリメンタル・ロギングを有効にする必要があります。
サプリメンタル・ロギングが有効な場合、REDOログ・ファイルの情報を役立てるために必要な補足情報がREDOストリームに記録されます。したがって、次のSQL文で示すように、少なくとも最小サプリメンタル・ロギングは有効にする必要があります。
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
サプリメンタル・ロギングが有効であるかどうかを確認するには、次のSQL文で示すように、V$DATABASE
ビューを問い合せます。
SELECT SUPPLEMENTAL_LOG_DATA_MIN FROM V$DATABASE;
問合せからYES
またはIMPLICIT
の値が返された場合、最小サプリメンタル・ロギングは有効です。
サプリメンタル・ロギングが有効な場合、LogMinerユーティリティ(DBMS_LOGMNR
)では長い表名または列名はサポートされないことに注意してください。オンライン・ディクショナリを使用していて、サプリメンタル・ロギングが有効になっていない場合、v$logmnr_contents
にはすべての名前と、関連オブジェクトのsql_undo
またはsql_redo
が表示されます。ただし、LogMinerユーティリティを使用するには、少なくとも最小サプリメンタル・ロギングを有効にする必要があります。表名または列名が30文字を超える表をマイニングすると、v$logmnr_contents
に次のようなエントリが表示されます。
select sql_redo , operation, seg_name, info from v$logmnr_contents where seg_name = upper('my_table_with_a_very_very_long_name_for_test') or seg_name = upper('table_with_long_col_name') ; SQL_REDO --- OPERATION -- SEG_NAME ----------------------- INFO -------------------------- Unsupported UNSUPPORTED MY_TABLE_W_A_VERY_VERY_LONG_NAME Object or Data type Unsupported Unsupported UNSUPPORTED TABLE_WITH_LONG_COL_NAME Object or Data type Unsupported
したがって、30文字以下の名前を持つ表および列でLogMinerを使用します。
25.2.2 LogMiner操作の指定および分析するデータの取得
LogMiner操作の指定にはPL/SQLパッケージDBMS_LOGMNR
およびDBMS_LOGMNR_D
を、分析するデータの取得にはV$LOGMNR_CONTENTS
ビューを使用します。
たとえば:
V$LOGMNR_CONTENTS
ビューを問い合せて、LogMiner PL/SQLパッケージを使用するには、EXECUTE_CATALOG_ROLE
ロールおよびLOGMINING
権限を持っている必要があります。
ノート:
Oracle RACデータベースで生成されたアーカイブ・ログ内で、指定された分析する時間範囲またはSCN範囲のマイニングを行う場合、指定の時間範囲またはSCN範囲でアクティブであった、すべてのREDOスレッドのすべてのアーカイブ・ログが指定されていることを確認する必要があります。指定されていない場合、V$LOGMNR_CONTENTS
という問合せによって、(DBMS_LOGMNR.ADD_LOGFILE
プロシージャを使用してLogMinerに指定されたアーカイブ・ログに基づき)部分的な結果のみが返されます。
dbms_logmnr.start_logmnr
パッケージのCONTINUOUS_MINE
オプションは、Oracle Database 19c (19.1)ではサポートされなくなり、使用できなくなりました。
関連項目:
LogMinerの使用例は、「一般的なLogMinerセッションのステップ」を参照してください。
親トピック: LogMinerの概要
25.3 CDBのLogMinerの使用
LogMinerセッションの確認に使用するビューと、ログのマイニングに使用する構文について学習します。
ルート・コンテナにすべてのPDBのスーパーセットの文字セットが含まれている場合、LogMinerでは異なる文字セットのPDBを含むCDBがサポートされます。
マルチテナント環境を管理するには、CDB_DBA
ロールを持っている必要があります。
ノート:
Oracle Database 21c以降、非CDB Oracle Databaseアーキテクチャのインストールはサポートされなくなりました。
非CDBアーキテクチャはOracle Database 12cで非推奨になりました。Oracle Database 21cではサポートが終了しました。Oracle Universal Installerを非CDB Oracle Databaseインスタンスの作成に使用することはできなくなりました。
- CDBでのLogMiner V$ビューおよびDBAビュー
CDBでは、システムで実行されているLogMinerセッションの情報を表示するためにLogMinerによって使用されるビューに、CON_ID
という追加の列が含まれます。 - CDBのV$LOGMNR_CONTENTSビュー
CDBを表示する場合、V$LOGMNR_CONTENTS
を使用してCDBまたは個々のPDBを表示できます。このビューをPDBから問い合せると、そのPDBによって生成されたREDOのみが返されます。 - CDBでのサプリメンタル・ロギングの有効化
CDBでは、データベース全体のサプリメンタル・ロギングを有効化および無効化する構文は、ALTER DATABASE
コマンドです。
親トピック: REDOログ・ファイル分析のためのLogMinerの使用
25.3.1 CDBでのLogMiner V$ビューおよびDBAビュー
CDBでは、システムで実行されているLogMinerセッションの情報を表示するためにLogMinerによって使用されるビューに、CON_ID
という追加の列が含まれます。
CON_ID
列によって、情報が表示されるセッションに関連付けられたコンテナIDを識別します。プラガブル・データベース(PDB)のビューを問い合せると、データベースに関連付けられた情報のみが表示されます。この新しい動作の影響を受けるビューは次のとおりです。
-
V$LOGMNR_DICTIONARY_LOAD
-
V$LOGMNR_LATCH
-
V$LOGMNR_PROCESS
-
V$LOGMNR_SESSION
-
V$LOGMNR_STATS
ノート:
CDBをサポートするため、V$LOGMNR_CONTENTS
ビューには、CON_ID
以外にもいくつかの新しい列が含まれます。
次のDBAビューには、名前がCDBで始まる類似のCDBビューがあります。
ログ・ビューのタイプ | DBAビュー | CDBビュー |
---|---|---|
LogMinerログ・ビュー |
|
|
LogMinerパージ済ログ・ビュー |
|
|
LogMinerセッション・ログ・ビュー |
|
|
DBAビューには、問合せが行われたコンテナで定義されているセッションに関連する情報のみが表示されます。
CDBビューには、特定の行が表すデータを含むコンテナを識別する追加のCON_ID
列が含まれます。ルートからCDBビューを問い合せると、それらのビューを使用してすべてのコンテナに関する情報を参照できます。
親トピック: CDBのLogMinerの使用
25.3.2 CDBでのV$LOGMNR_CONTENTSビュー
CDBを表示する場合、V$LOGMNR_CONTENTS
を使用してCDBまたは個々のPDBを表示できます。このビューをPDBから問い合せると、そのPDBによって生成されたREDOのみが返されます。
CDBでREDOログを問い合せると、SELECT
文がV$LOGMNR_CONTENTS
ビューに対してCDB$ROOT
で実行され、アーカイブREDOログ・ファイルが順次読み取られます。REDOログ・ファイルからの変換済レコードが、V$LOGMNR_CONTENTS
ビューに行として戻されます。この読取りは、起動時に指定されたフィルタ基準(endTime
またはendScn
)が満たされるか、アーカイブ・ログ・ファイルの終わりに達するまで続行されます。
個々のPDBのログを問い合せる場合、実行するマイニングはPDB REDOのアップストリーム(ローカル)マイニングです。ログを問い合せるには、REDOログの時間範囲またはSCN範囲を指定します。これを行うには、DBA_LOGMNR_DICTIONARY_BUILDLOG
を問い合せて、START_SCN
または時間値を識別します。次に、DBMS_LOGMNR.START_LOGMNR
を使用してLogMinerを起動し、問い合せるログのSCN値または時間値を指定します。LogMinerでは、PDBの正しいログ・ファイルのセットが自動的に決定され、分析のためにREDOログがLogMinerセッションに追加されます。
-
CON_ID
—問合せの実行元のコンテナに関連付けられたIDが含まれます。V$LOGMNR_CONTENTS
はルート・データベースに制限されるため、問合せがCDBで実行されると、この列は値1を返します。 -
SRC_CON_NAME
—PDBの名前。この情報は、マイニングがLogMinerディクショナリで実行される場合にのみ使用できます。 -
SRC_CON_ID
—REDOレコードを生成したPDBのコンテナID。この情報は、マイニングがLogMinerディクショナリで実行される場合にのみ使用できます。 -
SRC_CON_DBID
—PDBの識別子。この情報は、マイニングが現在のLogMinerディクショナリで実行される場合にのみ使用できます。 -
SRC_CON_GUID
—PDBに関連付けられたGUIDが含まれます。この情報は、マイニングが現在のLogMinerディクショナリで実行される場合にのみ使用できます。
関連トピック
親トピック: CDBのLogMinerの使用
25.3.3 CDBでのサプリメンタル・ロギングの有効化
CDBでは、データベース全体のサプリメンタル・ロギングを有効または無効にするための構文は、ALTER DATABASE
コマンドです。
たとえば、サプリメンタル・ログ・データを追加または削除する場合は、次の構文を使用します。
ALTER DATABASE [ADD|DROP] SUPPLEMENTAL LOG DATA ...
CREATE TABLE
文およびALTER TABLE
文で始まるサプリメンタル・ロギング操作は、CDBルートまたはPDBから実行できます。これらのサプリメンタル・ロギング操作は、適用先の表にのみ影響します。
Oracle Database 23c以降では、CDBのサプリメンタル・ロギングの動作は、UNDOモードが共有かローカルかで異なります。
共有UNDOモードでは、CDBのサプリメンタル・ロギングの動作は以前のリリースと同じです。
- 少なくとも最小サプリメンタル・ロギングが
CDB$ROOT
で有効になっている場合、追加のサプリメンタル・ロギング・レベルをPDBレベルで有効にできます。 CDB$ROOT
からすべてのサプリメンタル・ロギングを削除した場合は、これにより、PDBレベルでの以前の設定に関係なく、CDB全体ですべてのサプリメンタル・ロギングが無効になります。
ローカルUNDOモードでは、perPDB
(PDBごとのロギング)サプリメンタル・ロギングが有効になります。個々のPDBのレベルでサプリメンタル・ロギングを取得できるようにするためにCDB$ROOT
で最小サプリメンタル・ロギング(ADD SUPPLEMENTAL LOG DATA
)を設定する必要はなくなりました。
CDB$ROOT
で最小サプリメンタル・ロギングを有効にしなくても、PDBのサプリメンタル・ロギング・レベルを有効にできます。CDB$ROOT
からすべてのサプリメンタル・ロギングを削除しても、PDBレベルで有効になっているサプリメンタル・ロギングは無効になりません。
サプリメンタル・ロギング・モードに関係なく、次のルールが適用されます:
- CDBでは、
CDB$ROOT
から有効にしたサプリメンタル・ロギング・レベルは、CDB全体で有効になります。 CDB$ROOT
からCDBレベルで有効にしたサプリメンタル・ロギング・レベルは、PDBレベルでは無効にできません。
UNDOモードを共有UNDOモードからローカルUNDOモードに変更する場合は、CDB$ROOT
で最小サプリメンタル・ロギングが無効になっていると、UNDOモードが変更される前にCDB全体でサプリメンタル・ロギングが無効になります。UNDOモードの変更後、サプリメンタル・ロギングは、PDBレベルのサプリメンタル・ロギングでPDBに対して有効になります。
CDB$ROOT
で最小サプリメンタル・ロギングが無効になっており、一部のPDBでサプリメンタル・ロギングが有効になっている場合は、ローカルUNDOから共有UNDOへのUNDOモードの変更は許可されません。このような場合に変更しようとすると、ORA-60526: 「PDBごと
のサプリメンタル・ロギングが有効な場合、共有UNDOモードには切り替えられません」というエラーが発生します。このエラーは、UNDOモードの変更後にPDBレベルのサプリメンタル・ロギングのデータが失われないようにするために返されます。このエラーを解決するには、CDB$ROOT
でサプリメンタル・ロギングを有効にするか、すべてのPDBでサプリメンタル・ロギング・データを削除し、その後、UNDOを切り替えます。
親トピック: CDBのLogMinerの使用
25.4 Oracle GoldenGateのサプリメンタル・ロギングの構成方法
Oracle Database 21c以降は、個々の表の論理レプリケーションとサプリメンタル・ロギングの有効化をサポートしています。
- ファイングレイン・サプリメンタル・ロギングのためのOracle GoldenGateとOracle Databaseとの統合
ファイングレイン・サプリメンタル・ロギングを使用して、表レベルで論理レプリケーションを有効化または無効化できます。 - LogMinerとOracle GoldenGateによる表の論理レプリケーション
LogMinerの使用時にOracle GoldenGate RDBMSサービスを有効化すると、表レベルで論理レプリケーションを取得できます(autocapture) - Oracle GoldenGate自動取得が有効な表を表示するビュー
自動取得(ENABLE_AUTO_CAPTURE
)が有効な表を検索するには、ビューSYS.DBA_OGG_AUTO_CAPTURED_TABLES
およびSYS.USER_OGG_AUTO_CAPTURED_TABLES
を使用します。
親トピック: REDOログ・ファイル分析のためのLogMinerの使用
25.4.1 ファイングレイン・サプリメンタル・ロギングのためのOracle GoldenGateとOracle Databaseとの統合
ファイングレイン・サプリメンタル・ロギングを使用して、表レベルで論理レプリケーションを有効化または無効化できます。
ADD TRANDATAおよびDELETE TRANDATAでの表レベルのレプリケーション設定の統合
表レベルのレプリケーション設定(表レベルのサプリメンタル・ロギングの有効化または無効化)は、ADD TRANDATA
、DELETE TRANDATA
およびINFO TRANDATA
コマンドに統合されています。これらのコマンドは、Oracle GoldenGate Software Command Interface (GGSCIまたはAdmin Client)を使用して発行します。これらのコマンドの構文は同じままですが、基礎部分の動作がわずかに変更されています。
-
ADD TRANDATA
: このコマンドにより、表の論理レプリケーションが有効になります。 -
DELETE TRANDATA
: このコマンドは、キー列のサプリメンタル・ロギングを削除します。また、表の論理レプリケーションも無効にします。 -
INFO TRANDATA
コマンドは、表の論理レプリケーションが有効化されているか無効化されているかを示します。
論理レプリケーションとファイングレイン・サプリメンタル・ログ設定
ファイングレイン表のサプリメンタル・ロギング設定は、論理レプリケーションが有効であるかどうかによって異なります。この設定には、次の3つのオプションがあります。
-
論理レプリケーションが有効化されている場合、表のサプリメンタル・ロギングの設定は、データベース・レベル、スキーマ・レベルおよび表レベルのサプリメンタル・ログ・データによって決定されます。
-
表に対する論理レプリケーションが無効化されている場合、この表のサプリメンタル・ログの設定は、データベース・レベルのサプリメンタル・ログ・データによってのみ決定されます。スキーマ・レベルのサプリメンタル・ログ・データは無視されます。
-
論理レプリケーション句を有効化または無効化せずに表を作成した場合、その表の論理レプリケーションはデフォルトで有効になります。
25.4.2 LogMinerとOracle GoldenGateによる表の論理レプリケーション
LogMinerの使用時にOracle GoldenGate RDBMSサービスを有効化すると、表レベルで論理レプリケーションを取得できます(autocapture)
Oracle Database 21c以降では、Oracle GoldenGateを使用して自動取得(autocapture)の表を構成できます。
ノート:
この機能を使用するには、Oracle GoldenGateを有効にしておく必要があります。また、Oracle GoldenGateのロギング・プロパティ・コマンドのADD TRANDATA
またはADD SCHEMATRANDATA
を使用して表レベルのレプリケーション設定(表レベルのサプリメンタル・ロギングの有効化または無効化)を構成する必要があります。
Oracle GoldenGateでの論理レプリケーション(autocapture)
Oracle Databaseでサプリメンタル・ロギングを有効にすると、表レベル、スキーマ・レベルまたはデータベース・レベルで有効にできます。表の論理レプリケーションを有効にすると、表に対してすべてのレベルのサプリメンタル・ロギングが実行されます。
表に対する論理レプリケーションを無効にすると、データベースのサプリメンタル・ロギングのみが表に適用されます。つまり、スキーマ・レベルまたは表レベルのサプリメンタル・ロギングは無視されるということです。
表とOracle GoldenGate論理レプリケーション
表のサプリメンタル・ロギング機能は、Oracle GoldenGateのLOGICAL_REPLICATION
句の構成方法によって異なります。
-
LOGICAL_REPLICATION
句を設定せずに表を作成した場合、またはENABLE LOGICAL REPLICATION
句を指定して表を作成または変更した場合、論理レプリケーションは無効ではなく、すべてのレベルのサプリメンタル・ロギングが実行されます。その他のサプリメンタル・ロギング・データは暗黙的に表に追加されません。 -
ENABLE LOGICAL REPLICATION ALL KEYS
句を使用して表を作成または変更すると、Oracle GoldenGate自動取得について、ENABLE_AUTO_CAPTURE
パラメータを使用して、論理レプリケーションのサプリメンタル・ロギングが有効になります。サプリメンタル・ロギング(主キー、一意索引、外部キーおよびすべてのキー)が表に対して暗黙的に追加されます。 ENABLE LOGICAL REPLICATION ALLOW NOVALIDATE KEYS
句を使用して表を作成または変更する場合、ENABLE-AUTO_CAPTURE
パラメータを使用して、Oracle GoldenGate自動取得に対してサプリメンタル・ロギングが有効になり、未検証の主キーを一意の識別子として使用できるようになります。サプリメンタル・ロギング(主キー、一意索引、外部キーおよび、未検証の主キーを持つすべてのキー)が表に対して暗黙的に追加されます。-
表の作成時または変更時に
DISABLE LOGICAL REPLICATION
句が使用されると、表に対して論理レプリケーションが無効化されます。表レベルおよびスキーマ・レベルのサプリメンタル・ロギングは実行されません。
25.4.3 Oracle GoldenGate自動取得で使用可能な表を表示するビュー
自動取得(ENABLE_AUTO_CAPTURE
)が有効な表を調べるには、ビューSYS.DBA_OGG_AUTO_CAPTURED_TABLES
およびSYS.USER_OGG_AUTO_CAPTURED_TABLES
を使用します。
ENABLE_AUTO_CAPTURE
パラメータを使用して論理レプリケーションを管理します。ビューを使用して、Oracle GoldenGateで自動的に取得できる表を確認できます。
DBA_OGG_AUTO_CAPTURED_TABLES
ビューの問合せに使用するユーザー・アカウントには、SELECT_CATALOG_ROLE
権限が必要です。
例25-1 SYS.DBA_AUTO_CAPTURED_TABLES
論理レプリケーションの対象に指定されたすべての表に関するビューについて説明するために、DESCRIBE SYS.DBA_AUTO_CAPTURED_TABLES
と入力します。Oracle GoldenGate自動取得(ENABLE_AUTO_CAPTURE
)が有効化されたすべての表について所有者名、表名、表の論理レプリケーションのステータスを確認できます。
SQL> DESCRIBE SYS.DBA_AUTO_CAPTURED_TABLES Name Null? Type -------------------------------------- -------- ---------------------------- OWNER NOT NULL VARCHAR2(128) NAME NOT NULL VARCHAR2(128) ALLOW_NOVALIDATE_PK VARCHAR2(3)
このビューの説明は、次のとおりです。
OWNER
: Oracle GoldenGateENABLE_AUTO_CAPTURE
が有効化されている表の所有者NAME
: Oracle GoldenGateENABLE_AUTO_CAPTURE
が有効化されている表の名前ALLOW_NOVALIDATE_PK[YES|NO]
: キーのサプリメンタル・ロギングで未検証の主キーが許可されています。YES
は「はい」、NO
は「いいえ」に相当します。結果がNO
である場合、検証される一意キーまたは主キーのみが使用されます。
Oracle GoldenGateビューDBA_OGG_AUTO_CAPTURED_TABLES
は、SYS.DBA_AUTO_CAPTURED_TABLES
ビューのシノニムです。
例25-2 SYS.USER_OGG_AUTO_CAPTURED_TABLES
Oracle GoldenGate自動取得が有効化されたユーザーのすべての表に関するビューについて説明するため、DESCRIBE SYS.USER_OGG_AUTO_CAPTURED_TABLES
と入力します。
SQL> DESCRIBE SYS.USER_OGG_AUTO_CAPTURED_TABLES
Name Null? Type
------------------------------------- -------- ----------------------------
NAME NOT NULL VARCHAR2(128)
ALLOW_NOVALIDATE_PK VARCHAR2(3)
Oracle GoldenGateビューUSER_OGG_AUTO_CAPTURED_TABLES
は、SYS.USER_OGG_AUTO_CAPTURED_TABLES
ビューのシノニムです。
25.5 LogMinerディクショナリ・ファイルとREDOログ・ファイル
正確なログ・マイニング結果を得るには、LogMinerがLogMinerディクショナリとどのように連携するかを学習します。
LogMinerの使用を開始する前に、LogMinerがLogMinerディクショナリ・ファイル(またはファイル)およびOracle Database REDOログ・ファイルとどのように連携するかを理解しておく必要があります。これを知っておくと、正確な結果を取得し、システム・リソースの使用を計画するのに役立ちます。
- LogMinerディクショナリ・オプション
LogMinerは、REDOデータをユーザーに返す際に、オブジェクトIDをオブジェクト名に変換するためにディクショナリを必要とします。 - データ・マイニングの用のREDOログ・ファイルの指定
REDOログ・ファイルにあるデータをマイニングするには、LogMinerは、マイニングするREDOログ・ファイルの情報を必要とします。
親トピック: REDOログ・ファイル分析のためのLogMinerの使用
25.5.1 LogMinerディクショナリ・オプション
LogMinerは、REDOデータをユーザーに返す際に、オブジェクトIDをオブジェクト名に変換するためにディクショナリを必要とします。
LogMinerには、ディクショナリ提供方法として次の3つのオプションがあります。
-
オンライン・カタログの使用
REDOログ・ファイルが作成されたソース・データベースにアクセスでき、分析する表の列定義に変更がないことが見込まれる場合には、このオプションの使用をお薦めします。このオプションは、最も効率的で簡単に使用できます。
-
REDOログ・ファイルへのLogMinerディクショナリの抽出
REDOログ・ファイルが作成されたソース・データベースにアクセスできない場合、または分析する表の列定義が変更される可能性がある場合には、このオプションの使用をお薦めします。
-
フラット・ファイルへのLogMinerディクショナリの抽出
このオプションは、以前のリリースとの下位互換性を保つものです。このオプションは、トランザクションの一貫性を保証しません。オンライン・カタログを使用するか、REDOログ・ファイルにディクショナリを抽出することをお薦めします。
ノート:
プラガブル・データベース(PDB)のフラット・ファイル・ディクショナリ・ダンプを作成する機能は、Oracle Database 21cでサポートが終了しました。
以前のリリースでは、フラット・ファイル・ディクショナリの使用は、データ・ディクショナリがフラット・ファイル内に含まれていた特定のPDBに関連付けられた変更のREDOログをマイニングする手段でした。この機能はサポートされなくなりました。Oracle Database 21c以降、
DBMS_LOGMNR.START_LOGMNR
をコールし、マイニングするシステム変更番号(SCN)または時間範囲を指定することをお薦めします。START_LOGMNR
のSCNまたは時間範囲オプションは、個々のPDBのマイニングをサポートするように拡張されています。
次の図は、状況に応じてLogMinerディクショナリを選択する際に役立つデシジョン・ツリーです。
使用可能なディクショナリ・オプションを指定するには、選択したプロシージャの手順を確認します。
- オンライン・カタログの使用
データベースで現在使用中のディクショナリを使用することをLogMinerに指定するには、LogMiner起動時にディクショナリ・ソースとしてオンライン・カタログを指定します。 - REDOログ・ファイルへのLogMinerディクショナリの抽出
REDOログ・ファイルにLogMinerディクショナリを抽出するには、データベースがオープンしていて、ARCHIVELOG
モードの状態で、アーカイブが有効になっている必要があります。 - フラット・ファイルへのLogMinerディクショナリの抽出
LogMinerディクショナリがフラット・ファイルに存在する場合、REDOログ・ファイルに存在する場合よりもシステム・リソースの消費が少なくなります。
25.5.1.1 オンライン・カタログの使用
データベースで現在使用中のディクショナリを使用することをLogMinerに指定するには、LogMiner起動時にディクショナリ・ソースとしてオンライン・カタログを指定します。
たとえば:
EXECUTE DBMS_LOGMNR.START_LOGMNR(- OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG);
オンライン・カタログは、オンラインREDOログ・ファイルの分析に使用する他にも、アーカイブREDOログ・ファイルが同じシステム上で生成されている場合には、アーカイブREDOログ・ファイルの分析に使用できます。
オンライン・カタログにはデータベースに関する最新情報が含まれており、分析を開始するには最も速い方法です。重要な表を変更するDDL操作は頻繁に行われないため、通常、オンライン・カタログには分析に必要な情報が提供されています。
ただし、オンライン・カタログが再構成できるのは、表の最新バージョンに対して実行されるSQL文のみであることに注意してください。表が変更されると、オンライン・カタログは以前の表のバージョンを反映しなくなります。つまり、LogMinerは、以前の表のバージョンに対して実行されたSQL文を再構築することはできません。かわりに、LogMinerは、次に示すV$LOGMNR_CONTENTS
ビューのSQL_REDO
列で実行不可SQL(バイナリ値のhextoraw書式を含む)を生成します。
insert into HR.EMPLOYEES(col#1, col#2) values (hextoraw('4a6f686e20446f65'), hextoraw('c306'));"
オンライン・カタログ・オプションでは、データベースがオープンしている必要があります。
オンライン・カタログ・オプションは、DBMS_LOGMNR.START_LOGMNR
のDDL_DICT_TRACKING
オプションに対し有効ではありません。
親トピック: LogMinerディクショナリ・オプション
25.5.1.2 REDOログ・ファイルへのLogMinerディクショナリの抽出
REDOログ・ファイルにLogMinerディクショナリを抽出するには、データベースがオープンしていて、ARCHIVELOG
モードの状態で、アーカイブが有効になっている必要があります。
ディクショナリをREDOログ・ストリームに抽出している間は、DDL文を実行できません。したがって、REDOログ・ファイルに抽出されるディクショナリは、一貫性が保証されます(一方、フラット・ファイルに抽出されたディクショナリは一貫性が保証されません)。
ディクショナリ情報をREDOログ・ファイルに抽出するには、STORE_IN_REDO_LOGS
オプションを指定してPL/SQL DBMS_LOGMNR_D.BUILD
プロシージャを実行します。ファイル名や位置を指定しないでください。
EXECUTE DBMS_LOGMNR_D.BUILD( - OPTIONS=> DBMS_LOGMNR_D.STORE_IN_REDO_LOGS);
ディクショナリをREDOログ・ファイルに抽出するプロセスはデータベース・リソースを消費しますが、ピーク時間帯を外して抽出を実行することで問題を解決できます。また、フラット・ファイルに抽出するより高速になります。ディクショナリのサイズに応じて、複数のREDOログ・ファイルを含めることもできます。関係するREDOログ・ファイルがアーカイブされている場合、抽出されたディクショナリの先頭と終わりがどのREDOログ・ファイルにあるかを特定することができます。これを行うには、次のとおりV$ARCHIVED_LOG
ビューを問い合せます。
SELECT NAME FROM V$ARCHIVED_LOG WHERE DICTIONARY_BEGIN='YES'; SELECT NAME FROM V$ARCHIVED_LOG WHERE DICTIONARY_END='YES';
LogMinerセッションの起動を準備するときに、ADD_LOGFILE
プロシージャで、先頭と終わりのREDOログ・ファイル名(およびその間の他のREDOログ)を指定してください。
定期的にREDOログ・ファイルのバックアップを取って情報を保存し、後で利用できるようにしておくことをお薦めします。データベースが適切に管理されている理想的な環境では、アーカイブされたREDOログ・ファイルのバックアップとリストアのためのプロセスがすでに整っているため、そのための特別なステップは必要ありません。バックアップ作業も時間がかかる作業のため、ピークを外した時間帯に実行することをお薦めします。
25.5.1.3 フラット・ファイルへのLogMinerディクショナリの抽出
LogMinerディクショナリがフラット・ファイルに存在する場合、REDOログ・ファイルに存在する場合よりもシステム・リソースの消費が少なくなります。
ノート:
プラガブル・データベース(PDB)のフラット・ファイル・ディクショナリ・ダンプを作成する機能は、Oracle Database 21cでサポートが終了しました。以前のリリースでは、フラット・ファイル・ディクショナリの使用は、データ・ディクショナリがフラット・ファイル内に含まれていた特定のPDBに関連付けられた変更のREDOログをマイニングする手段でした。この機能はサポートされなくなりました。Oracle Database 21c以降、DBMS_LOGMNR.START_LOGMNR
をコールし、マイニングするシステム変更番号(SCN)または時間範囲を指定することをお薦めします。START_LOGMNR
のSCNまたは時間範囲オプションは、個々のPDBのマイニングをサポートするように拡張されています。
データベース・ディクショナリ情報をフラット・ファイルに抽出するには、STORE_IN_FLAT_FILE
オプションを指定してDBMS_LOGMNR_D.BUILD
プロシージャを実行します。古いREDOログ・ファイルを正しく分析できるように、定期的にディクショナリ抽出のバックアップを取ることをお薦めします。
ディクショナリをフラット・ファイルに抽出するステップは、次のとおりです。ステップ1と2は準備のためのステップです。これらは、1回のみの実行で、以後は何回でもディクショナリをフラット・ファイルに抽出できます。
関連トピック
親トピック: LogMinerディクショナリ・オプション
25.5.2 データ・マイニング用のREDOログ・ファイルの指定
REDOログ・ファイルにあるデータをマイニングするには、LogMinerは、マイニングするREDOログ・ファイルの情報を必要とします。
これらのREDOログ・ファイルで検出されたデータベースに対する変更は、V$LOGMNR_CONTENTS
ビューを介してユーザーに表示されます。
次のように、LogMinerが分析するためにREDOログ・ファイルのリストを明示的に指定する必要があります。
LogMinerを起動する前に手動でREDOログ・ファイルのリストを作成するには、DBMS_LOGMNR.ADD_LOGFILE
プロシージャを使用します。最初のREDOログ・ファイルがこのリストに追加された後、それ以降に追加される各REDOログ・ファイルは、同じデータベースからのもので、同じデータベースのRESETLOGS SCN
と関連付けられている必要があります。この方法を使用する場合、LogMinerはソース・データベースに接続されている必要はありません。
たとえば、REDOログ・ファイルの新規リストを開始するには、PL/SQLプロシージャDBMS_LOGMNR.ADD_LOGFILE
のNEW
オプションを指定し、新規リストの開始であることを指定します。たとえば、/oracle/logs/log1.f
を指定するには、次のように入力します。
EXECUTE DBMS_LOGMNR.ADD_LOGFILE( -
LOGFILENAME => '/oracle/logs/log1.f', -
OPTIONS => DBMS_LOGMNR.NEW);
必要に応じて、PL/SQL DBMS_LOGMNR.ADD_LOGFILE
プロシージャのADDFILE
オプションを指定し、さらにREDOログ・ファイルを追加できます。たとえば、/oracle/logs/log2.f
を追加するには、次のように入力します。
EXECUTE DBMS_LOGMNR.ADD_LOGFILE( -
LOGFILENAME => '/oracle/logs/log2.f', -
OPTIONS => DBMS_LOGMNR.ADDFILE);
現在のLogMinerセッションでどのREDOログ・ファイルが分析されているかを確認するには、V$LOGMNR_LOGS
ビューを問い合せます。このビューでは、REDOログ・ファイルごとに1行で構成しています。
ノート:
dbms_logmnr.start_logmnr
パッケージのcontinuous_mine
オプションは、Oracle Database 19c (19.1)以降ではサポートされなくなり、使用できなくなりました。
25.6 LogMinerの起動
DBMS_LOGMNR.START_LOGMNR
プロシージャを呼び出して、LogMinerを起動します。
DBMS_LOGMNR.START_LOGMNR
プロシージャで使用できるオプションは、V$LOGMNR_CONTENTS
ビューに対する出力を制御します。そのためV$LOGMNR_CONTENTS
ビューを問い合せる前に、DBMS_LOGMNR.START_LOGMNR
をコールする必要があります。
LogMiner起動時には、次の項目を指定できます。
-
LogMinerが返すデータをフィルタ処理する方法(たとえば、開始時刻と終了時刻、またはSCN値によるフィルタ処理)
-
LogMinerにより返されるデータを書式設定するためのオプション
-
使用するLogMinerディクショナリ
次のリストに、DBMS_LOGMNR.START_LOGMNR
に対してOPTIONS
パラメータで指定できるLogMiner設定の要約と、詳細情報の参照先を示します。
-
DICT_FROM_ONLINE_CATALOG
-
DICT_FROM_REDO_LOGS
-
COMMITTED_DATA_ONLY
-
SKIP_CORRUPTION
-
NO_SQL_DELIMITER
-
PRINT_PRETTY_SQL
-
NO_ROWID_IN_STMT
-
DDL_DICT_TRACKING
DBMS_LOGMNR.START_LOGMNR
プロシージャの実行時には、指定されたパラメータとオプションの組合せが有効かどうか、指定されたディクショナリとREDOログ・ファイルが使用可能かどうかがLogMinerによりチェックされます。ただし、V$LOGMNR_CONTENTS
ビューは、ビューを問い合せるまで移入されません。
パラメータおよびオプションは、次回のDBMS_LOGMNR.START_LOGMNR
へのコールでは保持されません。DBMS_LOGMNR.START_LOGMNR
をコールするたびに、必要なパラメータおよびオプション(SCN範囲や時間範囲を含む)をすべて指定する必要があります。
親トピック: REDOログ・ファイル分析のためのLogMinerの使用
25.7 分析するREDOデータについてのV$LOGMNR_CONTENTSの問合せ
分析するREDOデータにアクセスするには、V$LOGMNR_CONTENTS
ビューを問い合せます。
- V$LOGMNR_CONTENTSを使用したREDOデータの検索方法
V$LOGMNR_CONTENTS
を使用して、Oracle Databaseに対して行われた変更に関する履歴情報を検索できます。 - V$LOGMNR_CONTENTSビューへの移入方法
V$LOGMNR_CONTENTS
固定ビューは、他のビューと異なり、表に格納されたデータの選択的表示ではありません。ユーザーがREDOログ・ファイルに対して要求したデータのリレーショナルな表示です。 - 列の値に基づいたV$LOGMNR_CONTENTSの問合せ
列値を問い合せるには、Oracle Database LogMinerビューV$LOGMNR_CONTENTS
を使用します。 - XMLType列およびXMLType表に基づいたV$LOGMNR_CONTENTSの問合せ
LogMinerでは、XMLType
列に対して生成されるREDOがサポートされます。CLOB
として格納されるXMLType
データは、11.0.0.0以上の互換性設定で生成されたREDOに対してサポートされます。
親トピック: REDOログ・ファイル分析のためのLogMinerの使用
25.7.1 V$LOGMNR_CONTENTSを使用したREDOデータの検索方法
V$LOGMNR_CONTENTS
を使用して、Oracle Databaseに加えられた変更に関する履歴情報を検索します。
V$LOGMNR_CONTENTS
ビューを問い合せるには、SYSDBA
またはLOGMINING
権限が必要です。V$LOGMNR_CONTENTS
を使用して検索可能な履歴情報には、次のものが含まれます(ただしこれに限定されません)。
-
データベースに対して行われた変更のタイプ:
INSERT
、UPDATE
、DELETE
またはDDL
(OPERATION
列)。 -
変更が行われたSCN(
SCN
列)。 -
変更がコミットされたSCN(
COMMIT_SCN
列)。 -
変更が属するトランザクション(
XIDUSN
列、XIDSLT
列およびXIDSQN
列)。 -
変更されたオブジェクトの表とスキーマの名前(
SEG_NAME
列およびSEG_OWNER
列)。 -
変更を行うためにデータ定義言語(DDL)文またはデータ操作言語(DML)文を発行したユーザーの名前(
USERNAME
列)。 -
SQL DML文による変更の場合では、REDOレコードを生成するために使用されたSQL DMLと等価のSQL DML(必ずしも同一ではない)を表すように再構築されたSQL文(
SQL_REDO
列)。 -
パスワードが
SQL_REDO
列にある文に含まれる場合のパスワードの暗号化。DDL文に対応するSQL_REDO
列の値は、REDOレコードを生成するために使用されるSQL DDLと常に同一です。 -
SQL DML変更による変更の場合では、変更を元に戻すために必要なSQL DML文を示すように再構築されたSQL文(
SQL_UNDO
列)。DDL文に対応する
SQL_UNDO
列は常にNULL
です。一部のデータ型とロールバック操作についても、SQL_UNDO
列はNULL
です。
ノート:
LogMinerは透過的データ暗号化(TDE)をサポートしているため、対象オブジェクト用のメタデータがLogMinerデータ・ディクショナリに含まれ、適切なアクセス・キーがOracleウォレットにある場合は、暗号化された列(更新中の暗号化された列を含む)が含まれる表で実行されたDML操作がV$LOGMNR_CONTENTS
に表示されます。ウォレットはオープンされている必要があります。オープンされていない場合は、V$LOGMNR_CONTENTS
では関連付けられたREDOレコードを解釈することができません。データベースがオープンされていない(読取り専用、または読取り/書込み可能のいずれかの)場合、TDEはサポートされません。
V$LOGMNR_CONTENTSの問合せの例
Ronという名前のユーザーがoe.orders
表で行ったすべての削除操作を調べる場合、次のようなSQL問合せを発行します。
SELECT OPERATION, SQL_REDO, SQL_UNDO
FROM V$LOGMNR_CONTENTS
WHERE SEG_OWNER = 'OE' AND SEG_NAME = 'ORDERS' AND
OPERATION = 'DELETE' AND USERNAME = 'RON';
問合せによって生成される出力は次のとおりです。画面上での書式設定は、ここに示したものと異なる場合があります。
OPERATION SQL_REDO SQL_UNDO
DELETE delete from "OE"."ORDERS" insert into "OE"."ORDERS"
where "ORDER_ID" = '2413' ("ORDER_ID","ORDER_MODE",
and "ORDER_MODE" = 'direct' "CUSTOMER_ID","ORDER_STATUS",
and "CUSTOMER_ID" = '101' "ORDER_TOTAL","SALES_REP_ID",
and "ORDER_STATUS" = '5' "PROMOTION_ID")
and "ORDER_TOTAL" = '48552' values ('2413','direct','101',
and "SALES_REP_ID" = '161' '5','48552','161',NULL);
and "PROMOTION_ID" IS NULL
and ROWID = 'AAAHTCAABAAAZAPAAN';
DELETE delete from "OE"."ORDERS" insert into "OE"."ORDERS"
where "ORDER_ID" = '2430' ("ORDER_ID","ORDER_MODE",
and "ORDER_MODE" = 'direct' "CUSTOMER_ID","ORDER_STATUS",
and "CUSTOMER_ID" = '101' "ORDER_TOTAL","SALES_REP_ID",
and "ORDER_STATUS" = '8' "PROMOTION_ID")
and "ORDER_TOTAL" = '29669.9' values('2430','direct','101',
and "SALES_REP_ID" = '159' '8','29669.9','159',NULL);
and "PROMOTION_ID" IS NULL
and ROWID = 'AAAHTCAABAAAZAPAAe';
この出力は、ユーザーRonがoe.orders
表から2行を削除したことを示しています。再構築されたSQL文は、Ronが発行した実際の文と等価ですが、必ずしも同一とはかぎりません。この違いの理由は、元のWHERE
句の記録がREDOログ・ファイルになく、そのため、LogMinerは、削除(あるいは更新または挿入)された行のみを個別に表示するためです。
したがって、両方の行の削除に1つのDELETE
文のみが関係している場合でも、V$LOGMNR_CONTENTS
の出力にはその事実が反映されません。実際のDELETE
文は、DELETE FROM OE.ORDERS WHERE CUSTOMER_ID ='101
'またはDELETE FROM OE.ORDERS WHERE PROMOTION_ID = NULL
のいずれかです。
25.7.2 V$LOGMNR_CONTENTSビューへの移入方法
V$LOGMNR_CONTENTS
固定ビューは、他のビューと異なり、表に格納されたデータの選択的表示ではありません。ユーザーがREDOログ・ファイルに対して要求したデータのリレーショナルな表示です。
LogMinerがこのビューに移入するのは、このビューに対する問合せに応答する場合のみです。V$LOGMNR_CONTENTS
を問い合せる前に、LogMinerを正常に起動しておく必要があります。
SQL選択操作がV$LOGMNR_CONTENTS
ビューに対して実行された場合、REDOログ・ファイルは順番に読み込まれます。REDOログ・ファイルから変換された情報が、V$LOGMNR_CONTENTS
ビューの行として返されます。これは、起動時に指定されたフィルタ基準を満たすまで、またはREDOログ・ファイルの終わりに達するまで繰り返されます。
V$LOGMNR_CONTENTS
の特定の列が移入されない場合があります。たとえば:
-
TABLE_SPACE
列は、OPERATION
列の値がDDL
の行には移入されません。DDLは、複数の表領域で動作する可能性があるためです。たとえば、表は、複数の表領域にわたる複数のパーティションで作成される可能性があるため、列に正しく移入されません。 -
LogMinerでは、一時表に対するSQLのREDOまたはSQLのUNDOは生成されません。
SQL_REDO
列には「/* No SQL_REDO for temporary tables */」
、SQL_UNDO
列には「/* No SQL_UNDO for temporary tables */」
という文字列が表示されます。
LogMinerでは、COMMITTED_DATA_ONLY
オプションを使用して、コミット済トランザクションのみを取得するように指定しないかぎり、すべての行がSCN順に返されます。SCN順は、メディア・リカバリで通常適用される順序です。
ノート:
LogMinerは、問合せに応答する場合にのみV$LOGMNR_CONTENTS
ビューに移入し、要求したデータをデータベースに格納しないため、次の条件が適用されます。
V$LOGMNR_CONTENTS
を問い合せるたびに、LogMinerは、要求したデータのREDOログ・ファイルを分析します。- 問合せで消費されるメモリー量は、問合せを満たすために返す必要がある行数によっては異なりません。
- 要求したデータを返すためにかかる時間は、そのデータを検出するためにマイニングする必要があるREDOログ・データの量および型によって異なります。
前述の理由から、さらに分析を行うためにデータを保持する必要がある場合、特に問合せによって返されるデータの量が、そのデータを提供するためにLogMinerによって分析されるREDOデータの量と比較して少ない場合は、V$LOGMNR_CONTENTS
という問合せの結果を一時的に格納する表を作成することをお薦めします。
関連トピック
25.7.3 列の値に基づいたV$LOGMNR_CONTENTSの問合せ
Oracle Database LogMinerビューV$LOGMNR_CONTENTS
を使用して、列値を問い合せることができます。
- V$LOGMNR_CONTENTS列値の問合せの例
LOGMINER_CONTENTS
ビューを使用して列値ベースのデータ・マイニングを実行する方法について説明します。 - MINE_VALUE関数によって返されるNULL値の意味
MINE_VALUE
関数によって返されるNULL
値の意味を説明します。 - MINE_VALUE関数およびCOLUMN_PRESENT関数の使用規則
MINE_VALUE
関数およびCOLUMN_PRESENT
関数に適用される使用規則を説明します。 - MINE_VALUEファンクションを使用してNCHAR値を取得する際の制限事項
MINE_VALUE
ファンクションを使用する際の制限事項について説明します。
25.7.3.1 V$LOGMNR_CONTENTS列値の問合せの例
LOGMINER_CONTENTS
ビューを使用して列値ベースのデータ・マイニングを実行する方法について学習します。
Oracle DatabaseのREDOログ・ファイルからデータをマイニングするために実行できる、列ベースの様々な問合せがあります。たとえば、hr.employees
表に対して行われた、salary
を一定額より多く増額するすべての更新を示す問合せを実行できます。このようなデータを使用して、システムの動作を分析したり、監査タスクを実行したりできます。
LogMinerによるREDOログ・ファイルからのデータ抽出は、DBMS_LOGMNR.MINE_VALUE
およびDBMS_LOGMNR.COLUMN_PRESENT
という2つのマイニング関数を使用して実行されます。これらのマイニング関数に対するサポートは、V$LOGMNR_CONTENTS
ビューのREDO_VALUE
列とUNDO_VALUE
列によって提供されます。
次に、MINE_VALUE
関数を使用して、hr.employees
表に対して行われた、salary
列を元の値の2倍より多く増額したすべての更新を選択する例を示します。
SELECT SQL_REDO FROM V$LOGMNR_CONTENTS
WHERE
SEG_NAME = 'EMPLOYEES' AND
SEG_OWNER = 'HR' AND
OPERATION = 'UPDATE' AND
DBMS_LOGMNR.MINE_VALUE(REDO_VALUE, 'HR.EMPLOYEES.SALARY') >
2*DBMS_LOGMNR.MINE_VALUE(UNDO_VALUE, 'HR.EMPLOYEES.SALARY');
この例で示したとおり、MINE_VALUE
関数には2つの引数があります。
-
最初の引数は、データのREDO部分(
REDO_VALUE
)またはUNDO部分(UNDO_VALUE
)のいずれをマイニングするかを指定します。データのREDO部分は、挿入、更新または削除の操作後の列のデータです。データのUNDO部分は、挿入、更新または削除の操作前の列のデータです。このもう1つの見方は、REDO_VALUE
は新しい値、UNDO_VALUE
は古い値と考える見方です。 -
2番目の引数は、マイニングする列の完全修飾名を指定する文字列(この場合は、
hr.employees.salary
)です。MINE_VALUE
関数からは、常に、元のデータ型に戻すことができる文字列が返されます。
25.7.3.2 MINE_VALUE関数によって返されるNULL値の意味
MINE_VALUE
関数によって返されるNULL
値の意味を説明します。
MINE_VALUE
関数がNULL
値を返した場合は、次のいずれかを意味します。
-
指定した列がデータのREDO部分またはUNDO部分に存在していない。
-
指定した列は存在するが、その値がNULL。
この2つの場合を区別するには、DBMS_LOGMNR
.COLUMN_PRESENT
関数を使用します。この関数では、列がデータのREDO部分またはUNDO部分に存在している場合は、1
が返されます。存在していない場合には、0
が返されます。たとえば、salary
列の値の増額および対応するトランザクション識別子を検索するとします。次のSQL問合せを発行します。
SELECT (XIDUSN || '.' || XIDSLT || '.' || XIDSQN) AS XID, (DBMS_LOGMNR.MINE_VALUE(REDO_VALUE, 'HR.EMPLOYEES.SALARY') - DBMS_LOGMNR.MINE_VALUE(UNDO_VALUE, 'HR.EMPLOYEES.SALARY')) AS INCR_SAL FROM V$LOGMNR_CONTENTS WHERE OPERATION = 'UPDATE' AND DBMS_LOGMNR.COLUMN_PRESENT(REDO_VALUE, 'HR.EMPLOYEES.SALARY') = 1 AND DBMS_LOGMNR.COLUMN_PRESENT(UNDO_VALUE, 'HR.EMPLOYEES.SALARY') = 1;
25.7.3.3 MINE_VALUE関数およびCOLUMN_PRESENT関数の使用規則
MINE_VALUE
関数およびCOLUMN_PRESENT
関数に適用される使用規則を説明します。
具体的には次のとおりです。
-
LogMinerセッション内でのみ使用できます。
-
V$LOGMNR_CONTENTS
ビューからの選択操作中に起動する必要があります。 -
LONG
、LONG RAW
、CLOB
、BLOB
、NCLOB
、ADT
またはCOLLECTION
データ型はサポートされません。
25.7.4 XMLType列およびXMLType表に基づいたV$LOGMNR_CONTENTSの問合せ
LogMinerでは、XMLType
列に対して生成されるREDOがサポートされます。CLOB
として格納されるXMLType
データは、11.0.0.0以上の互換性設定で生成されたREDOに対してサポートされます。
- XMLType列およびXMLType表に基づくV$LOGMNR_CONTENTSの問合せ方法
使用するXMLTypeストレージに応じて、LogMinerでは、様々な方法でV$LOGMNR_CONTENTS
にSQL_REDO
が表示されます。 - XMLTypeデータを使用するLogMinerの使用上の制限
XMLTypeデータを使用するLogMinerの使用上の制限を説明します。 - XMLTypeデータを作成するためのPL/SQLプロシージャの例
表外のXMLデータを含む表に対してXML REDOをマイニングおよび作成するのに使用可能なプロシージャについて説明する例。
25.7.4.1 XMLType列およびXMLType表に基づいたV$LOGMNR_CONTENTSの問合せ方法
使用するXMLTypeストレージに応じて、LogMinerは様々な方法でV$LOGMNR_CONTENTS
内のSQL_REDO
を表示します。
オブジェクト・リレーショナルおよびバイナリXMLとして格納されるXMLType
データは、11.2.0.3以上の互換性設定で生成されたREDOに対してサポートされます。
LogMinerでは、XMLType
が何で保存されているかに応じて、V$LOGMNR_CONTENTS
内のSQL_REDO
を別の方法で示します。いずれの場合においても、STATUS
列に加えSQL_REDO
列の内容は、注意深く確認し、変更をREDOするためにSQLまたはPL/SQL文が生成される前に、通常は再アセンブリする必要があります。このような変更の構築に、SQL_REDO
データを使用できない場合があります。次の項の例では、XMLType
は行を完全に変更するための再構築で最も単純なCLOB
として格納されています。
ノート:
CLOB
として格納されたXMLType
データが、Oracle Database 12cリリース1 (12.1)で非推奨になり、サポートされなくなる可能性があります。ADBで使用する予定の既存のアプリケーションでは、多くのXMLスキーマ関連機能がサポートされていないことに注意してください。
XMLType列を使用した表に対して行われた変更についてのV$LOGMNR_CONTENTSの問合せ
この項の例では、次の列を使用したXML_CLOB_COL_TAB
という表について説明します。
- f1
NUMBER
- f2
VARCHAR2(100)
- f3
XMLTYPE
- f4
XMLTYPE
- f5
VARCHAR2(10)
ログおよびCOMMITTED_DATA_ONLY
オプションを使用して、LogMinerセッションを起動したとします。XML_CLOB_COL_TAB
表に対して行われた変更について、V$LOGMNR_CONTENTS
に対して次の問合せが実行されます。
SELECT OPERATION, STATUS, SQL_REDO FROM V$LOGMNR_CONTENTS WHERE SEG_OWNER = 'SCOTT' AND TABLE_NAME = 'XML_CLOB_COL_TAB';
問合せの出力は、次のようになります。
OPERATION STATUS SQL_REDO INSERT 0 insert into "SCOTT"."XML_CLOB_COL_TAB"("F1","F2","F5") values ('5010','Aho40431','PETER') XML DOC BEGIN 5 update "SCOTT"."XML_CLOB_COL_TAB" a set a."F3" = XMLType(:1) where a."F1" = '5010' and a."F2" = 'Aho40431' and a."F5" = 'PETER' XML DOC WRITE 5 XML Data XML DOC WRITE 5 XML Data XML DOC WRITE 5 XML Data XML DOC END 5
XML DOC WRITE
操作のSQL_REDO
列には、XML文書の実際のデータがあります。データは文字列'XML Data'ではありません。
XMLType
列を使用した表に挿入するための一般的なモデルを示すこの出力は、次のようになります。
- すべてのスカラー列を使用した最初の挿入
- バインド変数を使用して、1つの
XMLType
列に値を設定する更新文を使用したXML DOC BEGIN
操作 - XML文書のデータを使用した1回以上の
XML DOC WRITE
操作 - XML文書のすべてのデータが送信されたことを示す
XML DOC END
操作 - 表に複数の
XMLType
列がある場合は、元のDMLによって変更されるそれぞれのXMLType
列に対して、ステップ2から4が繰り返されます。
XML文書が表外の列として格納されていない場合、その列に対してXML DOC BEGIN
、XML DOC WRITE
またはXML DOC END
操作は行われません。文書は、次のような更新文に含まれます。
OPERATION STATUS SQL_REDO UPDATE 0 update "SCOTT"."XML_CLOB_COL_TAB" a set a."F3" = XMLType('<?xml version="1.0"?> <PO pono="1"> <PNAME>Po_99</PNAME> <CUSTNAME>Dave Davids</CUSTNAME> </PO>') where a."F1" = '5006' and a."F2" = 'Janosik' and a."F5" = 'MMM'
XMLType表に対して行われた変更についてのV$LOGMNR_CONTENTSの問合せ
XMLType
表に対するDMLは、XMLType
列に対するDMLとは多少異なります。XML文書では、XMLType
表の行に対する値を表します。XMLType
列の場合とは異なり、最初の挿入に続いてXML文書を含む更新を行うことはできません。データを表に挿入する前に、文書全体を作成する必要があります。
XMLType
表のもう1つの相違点は、OBJECT_ID
列の存在です。オブジェクト識別子は、オブジェクト表の各オブジェクトを一意に識別するために使用されます。XMLType
表については、表に行が挿入されると、Oracle Databaseによってこの値が生成されます。OBJECT_ID
の値は、SQLを使用して表に直接挿入することはできません。したがって、LogMinerでは、この値を含む実行可能なSQL_REDO
を生成できません。
V$LOGMNR_CONTENTS
ビューには、XMLType
表に対して行われた変更に対して移入される新しいOBJECT_ID
列があります。この値は、元の表のオブジェクト識別子です。ただし、この同じXML文書が同じXMLType
表に挿入されても、新しいオブジェクト識別子が生成されます。XMLType
表における更新や削除などの次のDMLのSQL_REDO
には、WHERE
句に元の表の行を一意に識別するためのオブジェクト識別子が含まれます。
25.7.4.2 XMLTypeデータを使用するLogMinerの使用上の制限
XMLTypeデータを使用するLogMinerの使用上の制限を説明します。
XMLType
データのマイニングは、DBMS_LOGMNR.COMMITTED_DATA_ONLY
オプションを使用している場合にのみ行う必要があります。そうしないと、一部の行の変更が不足しているために、不完全な変更が表示されたり、XMLとして表示されるはずの変更がCLOB
の変更として表示される可能性があります。このために、これらのSQL DML文に対するSQL_REDO
が不完全かつ無効になってしまいます。
SQL_UNDO
列は、XMLType
データへの変更に対して移入されません。
25.7.4.3 XMLTypeデータを作成するためのPL/SQLプロシージャの例
表外のXMLデータを含む表に対してXML REDOをマイニングおよび作成するのに使用可能なプロシージャについて説明する例。
この例では、一時LOBを使用してXMLデータを作成する方法を示します。XML文書を一度作成すると、その文書を有効に使用できます。この例では、EmployeeName
要素に対して作成された文書を問い合せて、EMPLOYEE_XML_DOCS
表の元のDMLに対して返された名前、XML文書およびSQL_REDO
を格納します。
ノート:
このプロシージャでは、簡単な例のみを示します。この例は、LogMinerを使用して、XMLType
データを含む表に対するDMLのマイニングおよび作成が可能であることの説明のみを目的としています。
このプロシージャをコールする前に、関連するすべてのログをLogMinerセッションに追加し、COMMITTED_DATA_ONLY
オプションを使用して、DBMS_LOGMNR.START_LOGMNR()
をコールする必要があります。その後、マイニング対象のXMLデータを含む表のスキーマ名と表名を使用して、MINE_AND_ASSEMBLE()
プロシージャをコールすることができます。
-- table to store assembled XML documents create table employee_xml_docs ( employee_name varchar2(100), sql_stmt varchar2(4000), xml_doc SYS.XMLType); -- procedure to assemble the XML documents create or replace procedure mine_and_assemble( schemaname in varchar2, tablename in varchar2) AS loc_c CLOB; row_op VARCHAR2(100); row_status NUMBER; stmt VARCHAR2(4000); row_redo VARCHAR2(4000); xml_data VARCHAR2(32767 CHAR); data_len NUMBER; xml_lob clob; xml_doc XMLType; BEGIN -- Look for the rows in V$LOGMNR_CONTENTS that are for the appropriate schema -- and table name but limit it to those that are valid sql or that need assembly -- because they are XML documents. For item in ( SELECT operation, status, sql_redo FROM v$logmnr_contents where seg_owner = schemaname and table_name = tablename and status IN (DBMS_LOGMNR.VALID_SQL, DBMS_LOGMNR.ASSEMBLY_REQUIRED_SQL)) LOOP row_op := item.operation; row_status := item.status; row_redo := item.sql_redo; CASE row_op WHEN 'XML DOC BEGIN' THEN BEGIN -- save statement and begin assembling XML data stmt := row_redo; xml_data := ''; data_len := 0; DBMS_LOB.CreateTemporary(xml_lob, TRUE); END; WHEN 'XML DOC WRITE' THEN BEGIN -- Continue to assemble XML data xml_data := xml_data || row_redo; data_len := data_len + length(row_redo); DBMS_LOB.WriteAppend(xml_lob, length(row_redo), row_redo); END; WHEN 'XML DOC END' THEN BEGIN -- Now that assembly is complete, we can use the XML document xml_doc := XMLType.createXML(xml_lob); insert into employee_xml_docs values (extractvalue(xml_doc, '/EMPLOYEE/NAME'), stmt, xml_doc); commit; -- reset xml_data := ''; data_len := 0; xml_lob := NULL; END; WHEN 'INSERT' THEN BEGIN stmt := row_redo; END; WHEN 'UPDATE' THEN BEGIN stmt := row_redo; END; WHEN 'INTERNAL' THEN DBMS_OUTPUT.PUT_LINE('Skip rows marked INTERNAL'); ELSE BEGIN stmt := row_redo; DBMS_OUTPUT.PUT_LINE('Other - ' || stmt); IF row_status != DBMS_LOGMNR.VALID_SQL then DBMS_OUTPUT.PUT_LINE('Skip rows marked non-executable'); ELSE dbms_output.put_line('Status : ' || row_status); END IF; END; END CASE; End LOOP; End; / show errors;
次に、このプロシージャをコールして、SCOTT.XML_DATA_TAB
への変更をマイニングし、DMLを適用できます。
EXECUTE MINE_AND_ASSEMBLE ('SCOTT', 'XML_DATA_TAB');
このプロシージャの結果、EMPLOYEE_XML_DOCS
表には、変更されたXMLの表外の列それぞれに対する行が含まれます。EMPLOYEE_NAME
列には、XML文書から抽出された値が含まれ、SQL_STMT
列とXML_DOC
列には、元の行の変更が反映されます。
次に、従業員名とSQL文のみが表示される結果表への問合せの例を示します。
SELECT EMPLOYEE_NAME, SQL_STMT FROM EMPLOYEE_XML_DOCS; EMPLOYEE_NAME SQL_STMT Scott Davis update "SCOTT"."XML_DATA_TAB" a set a."F3" = XMLType(:1) where a."F1" = '5000' and a."F2" = 'Chen' and a."F5" = 'JJJ' Richard Harry update "SCOTT"."XML_DATA_TAB" a set a."F4" = XMLType(:1) where a."F1" = '5000' and a."F2" = 'Chen' and a."F5" = 'JJJ' Margaret Sally update "SCOTT"."XML_DATA_TAB" a set a."F4" = XMLType(:1) where a."F1" = '5006' and a."F2" = 'Janosik' and a."F5" = 'MMM'
25.8 V$LOGMNR_CONTENTSに返されるデータのフィルタ処理および書式設定
V$LOGMNR_CONTENTS
ビューのフィルタリング機能と書式設定機能を使用して、表示されるデータおよび表示する方法を管理し、データが返される速度を制御する方法を学習します。
Oracle DatabaseのREDOログからデータを抽出すると、LogMinerで大量の情報を処理できる可能性があります。データのフィルタ方法とフォーマット方法を学習すると、データ・マイニング・プロジェクトを支援する上で役に立ちます。これらのフィルタ処理機能および書式設定機能は、DBMS_LOGMNR.START_LOGMNR
プロシージャのパラメータまたはオプションを使用して要求します。
- コミット済トランザクションのみの表示
DBMS_LOGMNR.START_LOGMNR
に対してCOMMITTED_DATA_ONLY
オプションを使用した場合、コミット済トランザクションに属する行のみがV$LOGMNR_CONTENTS
ビューに表示されます。 - REDO破損のスキップ
DBMS_LOGMNR.START_LOGMNR
に対してSKIP_CORRUPTION
オプションを使用した場合、V$LOGMNR_CONTENTS
ビューからの選択操作中、REDOログ・ファイル内の破損はすべてスキップされます。 - 時刻によるデータのフィルタ処理
データを時刻でフィルタ処理するには、DBMS_LOGMNR.START_LOGMNR
プロシージャにSTARTTIME
パラメータおよびENDTIME
パラメータを設定します。 - SCNによるデータのフィルタ処理
データをSCN(システム変更番号)でフィルタ処理するには、PL/SQLDBMS_LOGMNR.START_LOGMNR
プロシージャに対してSTARTSCN
パラメータおよびENDSCN
パラメータを使用します。 - 再処理のために再構築されたSQL文の書式設定
LogMinerが再構築されたSQL文を再処理する場合、LogMinerオプションを使用して、それらの文のデフォルトの構造を変更できます。 - 返されるデータの可読性向上のための表示方法の書式設定
LogMinerには、読みやすくするために返されたデータの外観を書式設定するPRINT_PRETTY_SQL
オプションが用意されています。
親トピック: REDOログ・ファイル分析のためのLogMinerの使用
25.8.1 コミット済トランザクションのみの表示
DBMS_LOGMNR.START_LOGMNR
に対してCOMMITTED_DATA_ONLY
オプションを使用した場合、コミット済トランザクションに属する行のみがV$LOGMNR_CONTENTS
ビューに表示されます。
このオプションを使用すると、ロールバックされたトランザクション、進行中のトランザクションおよび内部操作をフィルタ処理して除外できます。
COMMITTED_DATA_ONLY
オプションを有効にするには、LogMinerの起動時に指定します。
EXECUTE DBMS_LOGMNR.START_LOGMNR(OPTIONS => - DBMS_LOGMNR.COMMITTED_DATA_ONLY);
COMMITTED_DATA_ONLY
オプションを指定した場合、LogMinerは、同じトランザクションに属するすべてのDML操作をグループ化します。トランザクションはコミットされた順序で返されます。
ノート:
COMMITTED_DATA_ONLY
オプションを指定して問合せを発行した場合、LogMinerは、1つのトランザクションのコミット・レコードを検出するまで、そのトランザクション内のすべてのREDOレコードをメモリーにステージングします。したがって、メモリーを使い果たして、「メモリー不足」エラーが返される場合があります。このエラーが発生した場合は、COMMITTED_DATA_ONLY
オプションを指定せずにLogMinerを再起動し、問合せを再発行する必要があります。
LogMinerのデフォルトでは、すべてのトランザクションに対応する行が表示され、その行がREDOログ・ファイルで検出された順序で返されます。
たとえば、COMMITTED_DATA_ONLY
オプションを指定せずにLogMinerを起動し、次の問合せを実行したとします。
SELECT (XIDUSN || '.' || XIDSLT || '.' || XIDSQN) AS XID, USERNAME, SQL_REDO FROM V$LOGMNR_CONTENTS WHERE USERNAME != 'SYS' AND SEG_OWNER IS NULL OR SEG_OWNER NOT IN ('SYS', 'SYSTEM');
出力は次のようになります。コミット済トランザクションとコミットされていないトランザクションの両方が返され、異なるトランザクションからの行が混在しています。
XID USERNAME SQL_REDO 1.15.3045 RON set transaction read write; 1.15.3045 RON insert into "HR"."JOBS"("JOB_ID","JOB_TITLE", "MIN_SALARY","MAX_SALARY") values ('9782', 'HR_ENTRY',NULL,NULL); 1.18.3046 JANE set transaction read write; 1.18.3046 JANE insert into "OE"."CUSTOMERS"("CUSTOMER_ID", "CUST_FIRST_NAME","CUST_LAST_NAME", "CUST_ADDRESS","PHONE_NUMBERS","NLS_LANGUAGE", "NLS_TERRITORY","CREDIT_LIMIT","CUST_EMAIL", "ACCOUNT_MGR_ID") values ('9839','Edgar', 'Cummings',NULL,NULL,NULL,NULL, NULL,NULL,NULL); 1.9.3041 RAJIV set transaction read write; 1.9.3041 RAJIV insert into "OE"."CUSTOMERS"("CUSTOMER_ID", "CUST_FIRST_NAME","CUST_LAST_NAME","CUST_ADDRESS", "PHONE_NUMBERS","NLS_LANGUAGE","NLS_TERRITORY", "CREDIT_LIMIT","CUST_EMAIL","ACCOUNT_MGR_ID") values ('9499','Rodney','Emerson',NULL,NULL,NULL,NULL, NULL,NULL,NULL); 1.15.3045 RON commit; 1.8.3054 RON set transaction read write; 1.8.3054 RON insert into "HR"."JOBS"("JOB_ID","JOB_TITLE", "MIN_SALARY","MAX_SALARY") values ('9566', 'FI_ENTRY',NULL,NULL); 1.18.3046 JANE commit; 1.11.3047 JANE set transaction read write; 1.11.3047 JANE insert into "OE"."CUSTOMERS"("CUSTOMER_ID", "CUST_FIRST_NAME","CUST_LAST_NAME", "CUST_ADDRESS","PHONE_NUMBERS","NLS_LANGUAGE", "NLS_TERRITORY","CREDIT_LIMIT","CUST_EMAIL", "ACCOUNT_MGR_ID") values ('8933','Ronald', 'Frost',NULL,NULL,NULL,NULL,NULL,NULL,NULL); 1.11.3047 JANE commit; 1.8.3054 RON commit;
次に、COMMITTED_DATA_ONLY
オプションを指定してLogMinerを起動したとします。前の例の問合せを再度実行すると、出力は次のようになります。
1.15.3045 RON set transaction read write; 1.15.3045 RON insert into "HR"."JOBS"("JOB_ID","JOB_TITLE", "MIN_SALARY","MAX_SALARY") values ('9782', 'HR_ENTRY',NULL,NULL); 1.15.3045 RON commit; 1.18.3046 JANE set transaction read write; 1.18.3046 JANE insert into "OE"."CUSTOMERS"("CUSTOMER_ID", "CUST_FIRST_NAME","CUST_LAST_NAME", "CUST_ADDRESS","PHONE_NUMBERS","NLS_LANGUAGE", "NLS_TERRITORY","CREDIT_LIMIT","CUST_EMAIL", "ACCOUNT_MGR_ID") values ('9839','Edgar', 'Cummings',NULL,NULL,NULL,NULL, NULL,NULL,NULL); 1.18.3046 JANE commit; 1.11.3047 JANE set transaction read write; 1.11.3047 JANE insert into "OE"."CUSTOMERS"("CUSTOMER_ID", "CUST_FIRST_NAME","CUST_LAST_NAME", "CUST_ADDRESS","PHONE_NUMBERS","NLS_LANGUAGE", "NLS_TERRITORY","CREDIT_LIMIT","CUST_EMAIL", "ACCOUNT_MGR_ID") values ('8933','Ronald', 'Frost',NULL,NULL,NULL,NULL,NULL,NULL,NULL); 1.11.3047 JANE commit; 1.8.3054 RON set transaction read write; 1.8.3054 RON insert into "HR"."JOBS"("JOB_ID","JOB_TITLE", "MIN_SALARY","MAX_SALARY") values ('9566', 'FI_ENTRY',NULL,NULL); 1.8.3054 RON commit;
1.15.3045トランザクションのCOMMIT
文は、1.18.3046トランザクションのCOMMIT
文の前に発行されたため、1.15.3045トランザクション全体が先に返されます。これは、1.18.3046トランザクションが1.15.3045トランザクションの前に開始されていた場合でも同様です。1.9.3041トランザクションではCOMMIT
文が発行されなかったため、このトランザクションは返されません。
関連トピック
関連項目:
COMMITTED_DATA_ONLY
オプションの使用例の詳細は、「LogMinerの使用例」を参照してください
25.8.2 REDO破損のスキップ
DBMS_LOGMNR.START_LOGMNR
に対してSKIP_CORRUPTION
オプションを使用した場合、V$LOGMNR_CONTENTS
ビューからの選択操作中、REDOログ・ファイル内の破損はすべてスキップされます。
破損したREDOレコードが検出されるたびに、OPERATION
列にCORRUPTED_BLOCKS
、STATUS
列に1343
、INFO
列にスキップしたブロック数の入った行が返されます。
スキップされたレコード内には、破損したブロックで進行中のトランザクションに対する変更が含まれる場合がありますが、そのような変更は、V$LOGMNR_CONTENTS
ビューから返されるデータには反映されません。
デフォルトでは、選択操作は、REDOログ・ファイルで最初に破損が検出された時点で終了します。
次のSQLの例で、このオプションの動作を示します。
-- Add redo log files of interest. -- EXECUTE DBMS_LOGMNR.ADD_LOGFILE(- logfilename => '/usr/oracle/data/db1arch_1_16_482701534.log' - options => DBMS_LOGMNR.NEW); -- Start LogMiner -- EXECUTE DBMS_LOGMNR.START_LOGMNR(); -- Select from the V$LOGMNR_CONTENTS view. This example shows corruptions are -- in the redo log files. -- SELECT rbasqn, rbablk, rbabyte, operation, status, info FROM V$LOGMNR_CONTENTS; ERROR at line 3: ORA-00368: checksum error in redo log block ORA-00353: log corruption near block 6 change 73528 time 11/06/2011 11:30:23 ORA-00334: archived log: /usr/oracle/data/dbarch1_16_482701534.log -- Restart LogMiner. This time, specify the SKIP_CORRUPTION option. -- EXECUTE DBMS_LOGMNR.START_LOGMNR(- options => DBMS_LOGMNR.SKIP_CORRUPTION); -- Select from the V$LOGMNR_CONTENTS view again. The output indicates that -- corrupted blocks were skipped: CORRUPTED_BLOCKS is in the OPERATION -- column, 1343 is in the STATUS column, and the number of corrupt blocks -- skipped is in the INFO column. -- SELECT rbasqn, rbablk, rbabyte, operation, status, info FROM V$LOGMNR_CONTENTS; RBASQN RBABLK RBABYTE OPERATION STATUS INFO 13 2 76 START 0 13 2 76 DELETE 0 13 3 100 INTERNAL 0 13 3 380 DELETE 0 13 0 0 CORRUPTED_BLOCKS 1343 corrupt blocks 4 to 19 skipped 13 20 116 UPDATE 0
25.8.3 時刻によるデータのフィルタ処理
データを時刻でフィルタ処理するには、DBMS_LOGMNR.START_LOGMNR
プロシージャにSTARTTIME
パラメータおよびENDTIME
パラメータを設定します。
PL/SQL DBMS_LOGMNR.START_LOGMNR
プロシージャへのコールで日付書式を指定する必要がないように、最初にSQL ALTER SESSION SET NLS_DATE_FORMAT
文を使用します。次に例を示します。
ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YYYY HH24:MI:SS';
EXECUTE DBMS_LOGMNR.START_LOGMNR( -
DICTFILENAME => '/oracle/database/dictionary.ora', -
STARTTIME => '01-Jan-2019 08:30:00', -
ENDTIME => '01-Jan-2019 08:45:00'-
);
タイムスタンプは、REDOレコードの順序の推測には使用しないでください。REDOレコードの順序は、SCNを使用して推測できます。
ノート:
フィルタリングする前にログ・ファイルを追加する必要があります。連続ロギングはサポートされなくなりました。指定した時間またはSCNに一致するログ・ファイルが追加されていない場合、DBMS_LOGMNR.START_LOGMNR
はエラー1291 ORA-01291: missing logfile
で失敗します。
25.8.4 SCNによるデータのフィルタ処理
データをSCN(システム変更番号)でフィルタ処理するには、PL/SQL DBMS_LOGMNR.START_LOGMNR
プロシージャに対してSTARTSCN
パラメータおよびENDSCN
パラメータを使用します。
たとえば:
EXECUTE DBMS_LOGMNR.START_LOGMNR(-
STARTSCN => 621047, -
ENDSCN => 625695, -
OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG + -
);
STARTSCN
パラメータおよびENDSCN
パラメータは、すべてのパラメータを指定した場合、STARTTIME
パラメータおよびENDTIME
パラメータより優先されます。
ノート:
以前のリリースでは、フラット・ファイル・ディクショナリの使用は、データ・ディクショナリがフラット・ファイル内に含まれていた特定のPDBに関連付けられた変更のREDOログをマイニングする手段でした。この機能はサポートされなくなりました。Oracle Database 21c以降、DBMS_LOGMNR.START_LOGMNR
をコールし、マイニングするシステム変更番号(SCN)または時間範囲を指定することをお薦めします。START_LOGMNR
のSCNまたは時間範囲オプションは、個々のPDBのマイニングをサポートするように拡張されています。
フィルタリングする前にログ・ファイルを追加する必要があります。連続ロギングはサポートされなくなりました。指定した時間またはSCNに一致するログ・ファイルが追加されていない場合、DBMS_LOGMNR.START_LOGMNR
はエラー1291 ORA-01291: missing logfile
で失敗します。
25.8.5 再処理のために再構築されたSQL文の書式設定
LogMinerが再構築されたSQL文を再処理する場合、LogMinerオプションを使用して、それらの文のデフォルトの構造を変更できます。
デフォルトでは、再構築されるSQL_REDO
文およびSQL_UNDO
文にはROWID
句が含まれ、それらの文はセミコロンで終わります。ただし、次のようにこのデフォルト設定を上書きできます。
-
LogMiner起動時に
NO_ROWID_IN_STMT
オプションを指定します。NO_ROWID_IN_STMT
オプションによって、再構築される文からROWID
句が除外されます。行IDはデータベース間で一貫性がないため、最初に実行したデータベースと異なるデータベースに対してSQL_REDO
文またはSQL_UNDO
文を再処理する場合は、LogMiner起動時にNO_ROWID_IN_STMT
オプションを指定してこの問題に対処します。 -
LogMiner起動時に
NO_SQL_DELIMITER
オプションを指定します。NO_SQL_DELIMITER
オプションでは、再構築された文からセミコロンが削除されます。セミコロンの削除は、カーソルを開き、再構築された文を実行するアプリケーションで役立ちます。
V$LOGMNR_CONTENTS
ビューのSTATUS
フィールドに値2
(invalid sql
)が含まれている場合、関連付けられたSQL文は処理できません。
25.8.6 返されるデータの可読性向上のための表示方法の書式設定
LogMinerには、読みやすくするために返されたデータの外観を書式設定するPRINT_PRETTY_SQL
オプションが用意されています。
問合せの結果、再構築されたSQL文を含む列が多数返され、表示内容が繁雑になり読みにくくなる場合があります。LogMinerでは、この問題に対応するためにPRINT_PRETTY_SQL
オプションが用意されています。DBMS_LOGMNR.START_LOGMNR
プロシージャに対してPRINT_PRETTY_SQL
オプションを指定すると、再構築されたSQL文が次のように書式設定され、読みやすくなります。
insert into "HR"."JOBS" values "JOB_ID" = '9782', "JOB_TITLE" = 'HR_ENTRY', "MIN_SALARY" IS NULL, "MAX_SALARY" IS NULL; update "HR"."JOBS" set "JOB_TITLE" = 'FI_ENTRY' where "JOB_TITLE" = 'HR_ENTRY' and ROWID = 'AAAHSeAABAAAY+CAAX'; update "HR"."JOBS" set "JOB_TITLE" = 'FI_ENTRY' where "JOB_TITLE" = 'HR_ENTRY' and ROWID = 'AAAHSeAABAAAY+CAAX'; delete from "HR"."JOBS" where "JOB_ID" = '9782' and "JOB_TITLE" = 'FI_ENTRY' and "MIN_SALARY" IS NULL and "MAX_SALARY" IS NULL and ROWID = 'AAAHSeAABAAAY+CAAX';
PRINT_PRETTY_SQL
オプションが有効な状態で再構築されたSQL文は、標準SQL構文を使用していないため、実行されません。
関連トピック
25.9 V$LOGMNR_CONTENTSに返されたDDL文の再適用
LogMinerを使用して1つ以上のDDL文を実行する場合は、V$LOGMNR_CONTENTS
INFO
列を問い合せ、USER_DDL
としてマークされたSQL DDLのみを実行します。
注意:
Oracle Databaseによって内部的に実行されたDDL文を実行すると、データベースが破損する場合があります。
V$LOGMNR_CONTENTS
ビューのSQL_REDO
列またはSQL_UNDO
列から、データベースに対して最初に適用したときと同様にSQL DDLを再適用する場合は、Oracle Databaseによって内部的に実行された文は実行しないでください。
ユーザーによって発行されたDDL文と、Oracle Databaseによって内部的に発行されたDDL文を区別するには、V$LOGMNR_CONTENTS
のINFO
列を問い合せます。INFO
列の値は、DDLがユーザーによって実行されたか、Oracle Databaseによって実行されたかを示します。
最初に適用したときと同様にSQL DDLを再適用する場合は、INFO
列に値USER_DDL
が含まれる場合に、V$LOGMNR_CONTENTS
のSQL_REDO
列またはSQL_UNDO
列に含まれるDDL SQLのみを実行します。
25.10 DBMS_LOGMNR.START_LOGMNRの複数回のコール
DBMS_LOGMNR.START_LOGMNR
のコールに成功し、V$LOGMNR_CONTENTS
ビューから選択した後でも、現在のLogMinerセッションを終了せずにDBMS_LOGMNR.START_LOGMNR
を再度コールし、異なるオプションおよび時間範囲またはSCN範囲を指定できます。
次の場合にコールを複数回行います。
-
LogMinerが分析するREDOデータの量を制限する。
-
異なるオプションを指定する。たとえば、
PRINT_PRETTY_SQL
オプションを指定する場合、コミット済トランザクションのみを表示する場合(COMMITTED_DATA_ONLY
オプションを指定)などがあります。 -
分析する時間範囲またはSCN範囲を変更する。
例: DBMS_LOGMNR.START_LOGMNRの複数回のコール
次に、DBMS_LOGMNR.START_LOGMNR
を複数回コールすると有効な例を示します。
例1: REDOログ・ファイルのデータのサブセットのみのマイニング
LogMinerがマイニングするREDOログ・ファイルのリストに、1週間の間に生成されたログ・ファイルが含まれているとします。ただし、それぞれの日の12:00から1:00の間に生成されたログ・ファイルのみを分析します。これを最も効率的に行う方法は次のとおりです。
-
月曜日に、この時間範囲を指定して、
DBMS_LOGMNR.START_LOGMNR
をコールします。 -
V$LOGMNR_CONTENTS
ビューから変更を選択します。 -
一週間のそれぞれの日に対して、ステップ1と2を繰り返します。
この方法では、その週のREDOデータの合計量が多い場合、リスト内の各REDOログ・ファイルの小さなサブセットのみがLogMinerによって読み込まれるため、全体の分析が非常に速く行われます。
例2: 時間範囲またはSCN範囲の調整
REDOログ・ファイル・リストを指定し、LogMiner起動時に時間範囲(またはSCN範囲)を指定するとします。V$LOGMNR_CONTENTS
ビューを問い合せると、指定した時間範囲には、必要なデータの一部のみが含まれます。時間範囲を1時間拡張するために、またはSCN範囲を調整するためにDBMS_LOGMNR.START_LOGMNR
を再度コールできます。
例3: リモート・データベースで受信された場合のREDOログ・ファイルの分析
変更を分析またはデータベース間で変更をレプリケートするためのアプリケーションを作成したとします。ソース・データベースは、そのREDOログ・ファイルをマイニング・データベースに送信し、オペレーティング・システム・ディレクトリに格納します。アプリケーションは、次の手順を実行します。
-
現在ディレクトリにあるすべてのREDOログ・ファイルをREDOログ・ファイル・リストに追加します。
-
適切な設定で
DBMS_LOGMNR.START_LOGMNR
をコールし、V$LOGMNR_CONTENTS
ビューから選択します。 -
ディレクトリに新しく受信されたREDOログ・ファイルを追加します。
-
必要に応じて、ステップ2と3を繰り返します。
親トピック: REDOログ・ファイル分析のためのLogMinerの使用
25.11 LogMinerおよびサプリメンタル・ロギング
LogMinerのサプリメンタル・ロギング機能の使用方法について学習します
- サプリメンタル・ロギングおよびLogMinerの理解
サプリメンタル・ロギングは、データ・マイニングを容易にするためにREDOログ・ファイルに列を追加するプロセスです。 - データベース・レベルのサプリメンタル・ロギング
LogMinerには、これらの項で説明するとおり、最小サプリメンタル・ロギング、識別キー・ロギングおよびプロシージャ型サプリメンタル・ロギングの異なるタイプのデータベース・レベルのサプリメンタル・ロギングがあります。 - データベース・レベルのサプリメンタル・ロギングの無効化
データベース・レベルのサプリメンタル・ロギングを無効にするには、DROP SUPPLEMENTAL LOGGING
句を指定してSQLALTER DATABASE
文を使用します。 - 表レベルのサプリメンタル・ロギング
表レベルのサプリメンタル・ロギングでは、補助的に記録する列を表レベルで指定します。 - LogMinerディクショナリでのDDL文の追跡
LogMinerでは、LogMiner起動時に指定したLogMinerディクショナリ(オンライン・カタログ、REDOログ・ファイルのディクショナリまたはフラット・ファイルのいずれか)から独自の内部ディクショナリが自動的に作成されます。 - DDL_DICT_TRACKINGおよびサプリメンタル・ロギングの設定
ディクショナリ追跡とサプリメンタル・ロギングの各種設定を組み合せた場合に発生する相互作用を説明します。 - DDL_DICT_TRACKINGおよび指定された時間範囲またはSCN範囲
LogMinerは、LogMinerディクショナリの一貫性を維持するためにDDL文が必要なため、DDL_DICT_TRACKING
オプションが有効な場合、要求した開始時刻またはSCN(DBMS_LOGMNR.START_LOGMNR
で指定)より前に、REDOログ・ファイルの読取りを開始する場合があります。
親トピック: REDOログ・ファイル分析のためのLogMinerの使用
25.11.1 サプリメンタル・ロギングおよびLogMinerの理解
サプリメンタル・ロギングは、データ・マイニングを容易にするためにREDOログ・ファイルに列を追加するプロセスです。
Oracle DatabaseのREDOログ・ファイルは通常、インスタンス・リカバリおよびメディア・リカバリに使用されます。これらの操作に必要なデータは、REDOログ・ファイルに自動的に記録されます。ただし、REDOベースのアプリケーションでは、追加の列をREDOログ・ファイルに記録する必要がある場合があります。これらの追加の列を記録するプロセスは、サプリメンタル・ロギングと呼ばれます。
デフォルトでは、Oracle Databaseでサプリメンタル・ロギングは提供されません。つまり、デフォルトでは、LogMinerは使用できません。したがって、LogMinerで分析できるログ・ファイルを生成する前に、少なくとも最小サプリメンタル・ロギングは有効にする必要があります。
サプリメンタル・ロギングのユースケースの例
次に、アプリケーションで使用可能な追加のREDOログ・ファイル列を持つ必要があるかどうかを確認できる例のリストを示します。
-
再構築されたSQL文を別のデータベースに適用するアプリケーションでは、行を一意に識別する列(主キーなど)で更新文を識別する必要があります。
ROWID
はデータベースごとに異なり、他のデータベースでは意味を持たないため、V$LOGMNR_CONTENTS
ビューによって返される再構築されたSQLに示されるROWID
では識別できません。 -
アプリケーションは、行変更の追跡をより効率的にするために、変更された列のみでなく、行全体のビフォア・イメージを記録する必要がある場合があります。
サプリメンタル・ログ・グループ
サプリメンタル・ログ・グループは、サプリメンタル・ロギングが有効な場合に記録する一連の追加の列です。サプリメンタル・ログ・グループは2種類あり、これらによって、ログ・グループの列を記録する時期が決定されます。
-
無条件のサプリメンタル・ログ・グループ: 指定した列に更新が影響したかどうかに関係なく、行が更新されるたびに指定した列のビフォア・イメージが記録されます。これは、ALWAYSログ・グループと呼ばれる場合もあります。
-
条件付きのサプリメンタル・ログ・グループ: ログ・グループの1つ以上の列が更新された場合にのみ、指定したすべての列のビフォア・イメージが記録されます。
サプリメンタル・ログ・グループは、システムで生成することも、ユーザーが定義することもできます。
サプリメンタル・ロギングには、2つの種類に加えて、問合せることができる2つのレベルがあります。
関連トピック
親トピック: LogMinerおよびサプリメンタル・ロギング
25.11.2 データベースレベルのサプリメンタル・ロギング
LogMinerには、これらの項で説明するとおり、最小サプリメンタル・ロギング、識別キー・ロギングおよびプロシージャ型サプリメンタル・ロギングの異なるタイプのデータベース・レベルのサプリメンタル・ロギングがあります。
最小サプリメンタル・ロギングでは、REDOログ・ファイルを生成するデータベースに大きなオーバーヘッドが発生しません。ただし、データベース全体の識別キー・ロギングを有効にすると、REDOログ・ファイルを生成するデータベースにオーバーヘッドが発生する場合があります。LogMinerに対しては、少なくとも最小サプリメンタル・ロギングを有効にすることをお薦めします。
- 最小サプリメンタル・ロギング
最小サプリメンタル・ロギングは、LogMinerでDML変更と関連付けられたREDO操作を識別、グループ化およびマージするために必要な最小限の情報を記録します。 - データベース・レベルの識別キー・ロギング
識別キー・ロギングは、REDOログ・ファイルがソース・データベース・インスタンスでマイニングされない場合(REDOログ・ファイルがロジカル・スタンバイ・データベースでマイニングされる場合など)に必要です。 - プロシージャ型サプリメンタル・ロギング
プロシージャ型サプリメンタル・ロギングを有効にすると、ローリング・アップグレードまたはOracle GoldenGateでレプリケートできるように、LogMinerによって特定のプロシージャ起動がREDOに記録されます。
親トピック: LogMinerおよびサプリメンタル・ロギング
25.11.2.1 最小サプリメンタル・ロギング
最小サプリメンタル・ロギングは、LogMinerでDML変更と関連付けられたREDO操作を識別、グループ化およびマージするために必要な最小限の情報を記録します。
また、LogMiner(およびLogMinerテクノロジに基づいた他の製品)に、連鎖行や様々な記憶域構成(クラスタ表、索引構成表など)のサポートに十分な情報を確保します。最小サプリメンタル・ロギングを有効にするには、次のSQL文を実行します。
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
親トピック: データベース・レベルのサプリメンタル・ロギング
25.11.2.2 データベース・レベルの識別キー・ロギング
識別キー・ロギングは、REDOログ・ファイルがソース・データベース・インスタンスでマイニングされない場合(REDOログ・ファイルがロジカル・スタンバイ・データベースでマイニングされる場合など)に必要です。
データベース識別キー・ロギングを使用すると、次のオプションの1つ以上をSQLのALTER DATABASE ADD SUPPLEMENTAL LOG
文に指定して、すべての更新に対してデータベース全体のビフォア・イメージ・ロギングを有効にできます。
-
ALL
: システムによって生成される無条件のサプリメンタル・ログ・グループこのオプションを指定すると、行が更新された場合、その行のすべての列(LOB、
LONGS
、ADT
を除く)がREDOログ・ファイルに格納されます。データベース・レベルですべての列ロギングを有効にするには、次の文を実行します。
SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;
-
PRIMARY KEY
: システムによって生成される無条件のサプリメンタル・ログ・グループこのオプションを指定すると、主キーを含む行が更新された場合(主キーの値に変更がない場合も)、データベースによって行の主キーのすべての列がREDOログ・ファイルに格納されます。
表に主キーが存在せず、1つ以上の非NULLの一意索引キー制約または索引キーが存在する場合は、一意索引キーのいずれかが、更新された行を一意に識別する手段としてロギング用に選択されます。
表に主キーと非NULLの一意索引キーのいずれも存在しない場合は、
LONG
とLOBを除くすべての列が補助的に記録されます。これは、その行に対してALL
サプリメンタル・ロギングを指定することと同様です。したがって、データベース・レベルの主キー・サプリメンタル・ロギングを使用する場合は、すべての表またはほとんどの表に主キーまたは一意索引キーが含まれるように定義しておくことをお薦めします。データベース・レベルで主キー・ロギングを有効にするには、次の文を実行します。
SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;
-
UNIQUE
システムによって生成される条件付きのサプリメンタル・ログ・グループこのオプションを指定すると、コンポジット一意キーまたはビットマップ索引に属する列が変更された場合、データベースによって、行のコンポジット一意キーまたはビットマップ索引のすべての列がREDOログ・ファイルに格納されます。一意キーは、一意制約または一意索引のいずれかが原因である可能性があります。
データベース・レベルで一意索引キーおよびビットマップ索引のロギングを有効にするには、次の文を実行します。
SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (UNIQUE) COLUMNS;
-
FOREIGN KEY
: システムによって生成される条件付きのサプリメンタル・ログ・グループこのオプションを指定すると、データベースによって、外部キーに属する列が変更された場合、行の外部キーのすべての列がREDOログ・ファイルに格納されます。
データベース・レベルで外部キー・ロギングを有効にするには、次のSQL文を実行します。
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (FOREIGN KEY) COLUMNS;
ノート:
識別キー・ロギングが有効であるかどうかに関係なく、常に、LogMinerによって返されるSQL文には
ROWID
句が含まれます。DBMS_LOGMNR.START_LOGMNR
プロシージャ・コールに対してNO_ROWID_IN_STMT
オプションを使用すると、フィルタ処理でROWID
句を除外できます。詳細は、「再実行のために再構築されたSQL文の書式設定」を参照してください。
識別キー・ロギングを使用する場合は、次のことに注意してください。
-
識別キー・ロギングが有効な場合にデータベースがオープンしていると、カーソル・キャッシュ内のすべてのDMLカーソルが無効になります。したがって、カーソル・キャッシュに再移入を行うまで、パフォーマンスに影響する場合があります。
-
データベース・レベルで識別キー・ロギングを有効にすると、最小サプリメンタル・ロギングが暗黙で有効になります。
- 主キーに
ENABLE NOVALIDATE
を指定した場合、主キーは有効な識別キーとはみなされません。有効な一意制約がない場合、すべてのスカラー列が記録されます。行外の列(LOB、XML、32k varcharなど)が補足的にログに記録されることはありません。 -
サプリメンタル・ロギング文は累積的に実行されます。次のSQL文を発行すると、主キー・サプリメンタル・ロギングと一意キー・サプリメンタル・ロギングの両方が有効になります。
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS; ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (UNIQUE) COLUMNS;
親トピック: データベース・レベルのサプリメンタル・ロギング
25.11.2.3 プロシージャ型サプリメンタル・ロギング
プロシージャ型サプリメンタル・ロギングを有効にすると、ローリング・アップグレードまたはOracle GoldenGateでレプリケートできるように、LogMinerによって特定のプロシージャ起動がREDOに記録されます。
プロシージャ型サプリメンタル・ロギングは、AQキュー表、階層対応表およびSDO_TOPO_GEOMETRY
列またはSDO_GEORASTER
列がある表のレプリケーションをサポートするために、ローリング・アップグレードおよびOracle GoldenGateに対して有効にする必要があります。プロシージャ型サプリメンタル・ロギングを有効にするには、次のSQL文を使用します。
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA FOR PROCEDURAL REPLICATION END SUBHEADING
プロシージャ型サプリメンタル・ロギングが有効になっている場合、プロシージャ型サプリメンタル・ロギングを先に削除しないかぎり、最小サプリメンタル・ロギングを削除できません。
親トピック: データベース・レベルのサプリメンタル・ロギング
25.11.3 データベース・レベルのサプリメンタル・ロギングの無効化
データベース・レベルのサプリメンタル・ロギングを無効にするには、DROP SUPPLEMENTAL LOGGING
句を指定してSQL ALTER DATABASE
文を使用します。
サプリメンタル・ロギング属性は段階的に削除できます。たとえば、次のSQL文を次の順序で発行したとします。
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (UNIQUE) COLUMNS
;ALTER DATABASE DROP SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS;
ALTER DATABASE DROP SUPPLEMENTAL LOG DATA;
この文には、次のような効果があります。
-
最初の文の後、主キー・サプリメンタル・ロギングが有効になります。
-
2番目の文の後、主キー・サプリメンタル・ロギングおよび一意キー・サプリメンタル・ロギングが有効になります。
-
3番目の文の後、一意キー・サプリメンタル・ロギングのみが有効になります。
-
4番目の文の後、すべてのサプリメンタル・ロギングが無効になりません。次に示すエラーが返されます。
ORA-32589: 最小限のサプリメンタル・ロギングは削除できません
すべてのデータベース・サプリメンタル・ロギングを無効にするには、最初に、有効になっている識別キー・ロギングをすべて無効にしてから、最小サプリメンタル・ロギングを無効にする必要があります。次の例に、正しい順序を示します。
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS; ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (UNIQUE) COLUMNS; ALTER DATABASE DROP SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS; ALTER DATABASE DROP SUPPLEMENTAL LOG DATA (UNIQUE) COLUMNS; ALTER DATABASE DROP SUPPLEMENTAL LOG DATA;
最小サプリメンタル・ログ・データは、データベース・レベルの他のサプリメンタル・ロギングが有効になっていない場合にのみ削除できます。
親トピック: LogMinerおよびサプリメンタル・ロギング
25.11.4 表レベルのサプリメンタル・ロギング
表レベルのサプリメンタル・ロギングでは、補助的に記録する列を表レベルで指定します。
識別キー・ロギングまたはユーザー定義の条件付きのサプリメンタル・ログ・グループまたは無条件のサプリメンタル・ログ・グループを使用して、次の項で説明するとおり、補助情報を記録できます。
- 表レベルの識別キー・ロギング
表レベルでの識別キー・ロギングでは、データベース・レベルの場合と同じオプション(すべて、主キー、外部キー、一意キー)が提供されます。 - 表レベルのユーザー定義サプリメンタル・ログ・グループ
表レベルの識別キー・ロギングに加えて、ユーザー定義のサプリメンタル・ログ・グループもサポートされています。 - ユーザー定義のサプリメンタル・ログ・グループを使用する場合のノート
ユーザー定義のサプリメンタル・ログ・グループを使用するためのヒント。
親トピック: LogMinerおよびサプリメンタル・ロギング
25.11.4.1 表レベルの識別キー・ロギング
表レベルでの識別キー・ロギングでは、データベース・レベルの場合と同じオプション(すべて、主キー、外部キー、一意キー)が提供されます。
ただし、表レベルで識別キー・ロギングを指定すると、指定した表のみが影響を受けます。たとえば、次のSQL文(データベース・レベルのサプリメンタル・ロギングの指定)を入力すると、データベース表の列が変更された場合は常に、その列を含む行全体(LOB、LONG
、ADT
の列を除く)がREDOログ・ファイルに格納されます。
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;
ただし、次のSQL文(表レベルのサプリメンタル・ロギングの指定)を入力すると、employees
表の列が変更された場合にのみ、行全体(LOB、LONG
、ADT
を除く)がREDOログ・ファイルに格納されます。departments
表の列が変更されると、変更された列のみがREDOログ・ファイルに格納されます。
ALTER TABLE HR.EMPLOYEES ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;
表レベルの識別キー・ロギングを使用する場合は、次のことに注意してください。
-
表で識別キー・ロギングが有効な場合にデータベースがオープンしていると、カーソル・キャッシュ内のその表のすべてのDMLカーソルが無効になります。したがって、カーソル・キャッシュに再移入を行うまで、パフォーマンスに影響する場合があります。
-
サプリメンタル・ロギング文は累積的に実行されます。次のSQL文を発行すると、主キー・サプリメンタル・ロギングと一意索引キーの表レベルのサプリメンタル・ロギングの両方が有効になります。
ALTER TABLE HR.EMPLOYEES ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS; ALTER TABLE HR.EMPLOYEES ADD SUPPLEMENTAL LOG DATA (UNIQUE) COLUMNS;
ノート:
LONG
データ型(LONG
、LONG RAW
、LONG VARCHAR
、LONG VARRAW
)のすべての形式は、Oracle8iリリース8.1.6で非推奨になりました。以降のリリースでは、LONG
データ型は既存のアプリケーションとの下位互換性のために提供されていました。以降のリリースで開発された新しいアプリケーションでは、大量の文字データにCLOB
およびNCLOB
データ型を使用することをお薦めします。
各識別キー・ロギング・オプションの詳細は、「データベース・レベルの識別キー・ロギング」を参照してください。
親トピック: 表レベルのサプリメンタル・ロギング
25.11.4.2 表レベルのユーザー定義サプリメンタル・ログ・グループ
表レベルの識別キー・ロギングによって、ユーザー定義のサプリメンタル・ログ・グループもサポートされています。
ユーザー定義サプリメンタル・ログ・グループによって、補助的に記録する列を指定できます。条件付きログ・グループまたは無条件ログ・グループは、次のとおり指定できます。
-
ユーザー定義の無条件ログ・グループ
ユーザー定義の無条件ログ・グループを使用するサプリメンタル・ロギングを有効にするには、次の例に示すとおり、
ALWAYS
句を使用します。ALTER TABLE HR.EMPLOYEES ADD SUPPLEMENTAL LOG GROUP emp_parttime (EMPLOYEE_ID, LAST_NAME, DEPARTMENT_ID) ALWAYS;
この例では、
hr.employees
表でemp_parttime
という名前のログ・グループが作成されます。このグループは、employee_id
列、last_name
列、department_id
列で構成されます。これらの列は、UPDATE
文がhr.employees
表で実行されるたびに、その更新がこれらの列に影響するかどうかに関係なく記録されます。(更新が行われるたびに行イメージ全体を記録する場合は、前述のとおり、表レベルのALL
識別キー・ロギングを使用します。)ノート:
LOB列、
LONG
列およびADT
列は補助的に記録できません。 -
ユーザー定義の条件付きログ・グループ
ユーザー定義の条件付きログ・グループを使用するサプリメンタル・ロギングを有効にするには、次の例に示すとおり、SQL
ALTER
TABLE
文からALWAYS
句を削除します。ALTER TABLE HR.EMPLOYEES ADD SUPPLEMENTAL LOG GROUP emp_fulltime (EMPLOYEE_ID, LAST_NAME, DEPARTMENT_ID);
この例では、表
hr.employees
でemp_fulltime
という名前のログ・グループが作成されます。前述の例と同様に、このグループは、employee_id
列、last_name
列およびdepartment_id
列で構成されます。ただし、ALWAYS
句が省略されたため、列のビフォア・イメージは、1つ以上の列が更新された場合にのみ記録されます。
無条件および条件付きのいずれのユーザー定義サプリメンタル・ログ・グループでも、NO LOG
オプションを指定して、ログ・グループ内の列をサプリメンタル・ロギングから除外することを明示的に指定できます。ログ・グループを指定し、NO LOG
オプションを使用する場合は、次の例に示すとおり、NO LOG
オプションが接続されていない列をログ・グループで1つ以上指定する必要があります。
ALTER TABLE HR.EMPLOYEES ADD SUPPLEMENTAL LOG GROUP emp_parttime( DEPARTMENT_ID NO LOG, EMPLOYEE_ID);
これによって、NO LOG
列に変更を行うと、サプリメンタル・ログ・グループ内の他の列がREDOログ・ファイルに格納されるように、指定されたサプリメンタル・ログ・グループ内の他の列とこの列とを関連付けることができます。この方法は、たとえば、LONG
列の変更時にグループの特定の列を記録する場合に有効です。LONG
列自体は補助的に記録できませんが、この列に対して行った変更を使用して、同じ行の他の列のサプリメンタル・ロギングをトリガーすることはできます。
親トピック: 表レベルのサプリメンタル・ロギング
25.11.4.3 ユーザー定義のサプリメンタル・ログ・グループを使用する場合のノート
ユーザー定義のサプリメンタル・ログ・グループを使用するためのヒント。
ユーザー定義のサプリメンタル・ログ・グループを指定する場合は、次の点に注意してください。
-
1つの列を複数のサプリメンタル・ログ・グループに含めることができます。ただし、その列のビフォア・イメージの記録は1回のみです。
-
条件付きと無条件の両方で同じ列を記録することを指定した場合、その列は無条件に記録されます。
親トピック: 表レベルのサプリメンタル・ロギング
25.11.5 LogMinerディクショナリでのDDL文の追跡
LogMinerでは、LogMiner起動時に指定したLogMinerディクショナリ(オンライン・カタログ、REDOログ・ファイルのディクショナリまたはフラット・ファイルのいずれか)から独自の内部ディクショナリが自動的に作成されます。
このディクショナリでは、データベース・オブジェクトとその定義のスナップショットが提供されます。
LogMinerディクショナリがREDOログ・ファイルにある場合またはフラット・ファイルである場合は、PL/SQL DBMS_LOGMNR.START_LOGMNR
プロシージャに対してDDL_DICT_TRACKING
オプションを使用して、LogMinerでデータ定義言語(DDL)文を追跡することができます。DDL追跡によって、LogMinerは、表での列の追加や削除など、データベース・オブジェクトに対して行われた構造上の変更を問題なく追跡できます。たとえば:
EXECUTE DBMS_LOGMNR.START_LOGMNR(OPTIONS => - DBMS_LOGMNR.DDL_DICT_TRACKING + DBMS_LOGMNR.DICT_FROM_REDO_LOGS);
例の詳細は、「例5: 内部ディクショナリでのDDL文の追跡」を参照してください。
このオプションが設定されている場合、LogMinerは、REDOログ・ファイルで検出されたDDL文をその内部ディクショナリに適用します。
ノート:
サプリメンタル・ロギングおよびDDL追跡機能が有効でない場合にDDLイベントが発生すると、LogMinerによってREDOデータの一部がバイナリ・データとして返されるため、通常、これらの機能を有効にしておくことをお薦めします。また、メタデータ・バージョンの不一致が発生する可能性もあります。
DDL_DICT_TRACKING
を有効にすると、LogMinerディクショナリの抽出後に作成された表で実行されたデータ操作言語(DML)操作を正常に表示できます。
たとえば、employees
表が、1回目の操作でgender
列が追加され、次の操作でcommission_pct
列が削除されるように、連続する2つのDDL操作で更新された場合、LogMinerによって、これらの変更のそれぞれに対するemployees
についての情報がバージョン化されます。つまり、これらのDDLの変更前と変更後のREDOログ・ファイルは、LogMinerによって正常にマイニングできるため、SQL_REDO
列またはSQL_UNDO
列にバイナリ・データは表示されません。
LogMinerは、データベース・メタデータに対して自動的にバージョンを割り当てるため、内部ディクショナリとREDOログ・ファイル内のディクショナリとの間で不一致を検出して通知します。LogMinerによって不一致が検出されると、V$LOGMNR_CONTENTS
ビューのSQL_REDO
列でバイナリ・データが生成され、INFO
列に「ディクショナリのバージョンの不一致」という文字列、STATUS
列に値2
が入力されます。
ノート:
LogMiner内部ディクショナリが、フラット・ファイル、REDOログ・ファイルまたはオンライン・カタログに含まれているLogMinerディクショナリとは異なることを理解しておいてください。LogMinerは、LogMiner内部ディクショナリは更新しますが、フラット・ファイル、REDOログ・ファイルまたはオンライン・カタログに含まれているディクショナリは更新しません。
次に、DBMS_LOGMNR.START_LOGMNR
プロシージャでDDL_DICT_TRACKING
オプションを指定するための要件を説明します。
-
DDL_DICT_TRACKING
オプションは、DICT_FROM_ONLINE_CATALOG
オプションとは併用できません。 -
DDL_DICT_TRACKING
オプションでは、データベースがオープンしている必要があります。 -
サプリメンタル・ロギングをデータベース全体で有効にするか、または対象となる表のログ・グループを作成しておく必要があります。
親トピック: LogMinerおよびサプリメンタル・ロギング
25.11.6 DDL_DICT_TRACKINGおよびサプリメンタル・ロギングの設定
ディクショナリ追跡とサプリメンタル・ロギングの各種設定を組み合せた場合に発生する相互作用を説明します。
次の点に注意してください。
-
DDL_DICT_TRACKING
が有効で、サプリメンタル・ロギングが有効でない場合は、次のようになります。-
REDOログ・ファイルでDDLトランザクションが検出された場合、
V$LOGMNR_CONTENTS
の問合せはORA-01347エラーを返して終了します。 -
REDOログ・ファイルでDMLトランザクションが検出された場合、LogMinerディクショナリ内の表(そのDMLの基礎となる表)の現在のバージョンがLogMinerによって正しいとは認識されず、
V$LOGMNR_CONTENTS
の列が次のように設定されます。-
SQL_REDO
列にバイナリ・データが含まれます。 -
STATUS
列に値2
が含まれます(SQLが有効でないことを示します)。 -
INFO
列に「ディクショナリの不一致」という文字列が含まれます。
-
-
-
DDL_DICT_TRACKING
およびサプリメンタル・ロギングが有効ではない場合、DML操作で参照された列がLogMinerディクショナリ内の列と一致すると、LogMinerディクショナリの最新バージョンがLogMinerによって正しいと認識され、V$LOGMNR_CONTENTS
の列が次のように設定されます。-
LogMinerは、LogMinerディクショナリ内のオブジェクトの定義を使用して、
SQL_REDO
列とSQL_UNDO
列の値を生成します。 -
STATUS列に値
3
が含まれます(SQLが正しいと保証できないことを示します)。 -
INFO
列には、「サプリメンタル・ログ・データが見つかりません」という文字列が含まれます。
-
-
DDL_DICT_TRACKING
およびサプリメンタル・ロギングが有効ではない場合に、表のLogMinerディクショナリ定義で定義された列より、表のREDOログ・ファイル内の変更された列の方が多いときは、次のようになります。-
SQL_REDO
列とSQL_UNDO
列に「ディクショナリのバージョンの不一致」という文字列が含まれます。 -
STATUS
列に値2
が含まれます(SQLが有効でないことを示します)。 -
INFO
列に「ディクショナリの不一致」という文字列が含まれます。
また、列のディクショナリ定義で定義されている型とその列の実際の型が異なる場合は、予期しない動作が発生する可能性があります。
-
親トピック: LogMinerおよびサプリメンタル・ロギング
25.11.7 DDL_DICT_TRACKINGおよび指定された時間範囲またはSCN範囲
LogMinerは、LogMinerディクショナリの一貫性を維持するためにDDL文が必要なため、DDL_DICT_TRACKING
オプションが有効な場合、要求した開始時刻またはSCN(DBMS_LOGMNR.START_LOGMNR
で指定)より前に、REDOログ・ファイルの読取りを開始する場合があります。
LogMinerがREDOログ・ファイルの読取りを開始する実際の時刻またはSCNは、必須開始時刻または必須開始SCNと呼ばれます。
欠落REDOログ・ファイル(順序番号に基づく)は、必須開始時刻または必須開始SCNから読取りを開始できません。
LogMinerでは、REDOログ・データの読取りを開始する位置を次のとおり決定します。
-
ディクショナリのロード後、
DBMS_LOGMNR.START_LOGMNR
を初めてコールする場合、LogMinerは、次のいずれかの値の早い方を基準に読取りを開始します。-
ユーザーが要求した開始時刻またはSCN値
-
ディレクトリ・ダンプのコミットSCN
-
-
DBMS_LOGMNR.START_LOGMNR
に対するこれ以降のコールでは、LogMinerは、次のいずれかの値の最も早いものを基準に読取りを開始します。-
ユーザーが要求した開始時刻またはSCN値
-
COMMIT
文がLogMinerによって読み込まれていない最も早いDDLトランザクションの開始時 -
LogMinerによって読み込まれた最高のSCN
-
次に、前述の内容の使用例を示します。
5つのREDOログ・ファイルを含むREDOログ・ファイル・リストを作成するとします。ディクショナリは、最初のREDOファイルに含まれ、確認対象として指定した変更(DBMS_LOGMNR.START_LOGMNR
を使用)は、3番目のREDOログ・ファイルに記録されているとします。ここで、次の手順を実行します。
-
DBMS_LOGMNR.START_LOGMNR
をコールします。LogMinerによって、次のものが読み込まれます。-
ディクショナリをロードするための最初のログ・ファイル
-
その中に含まれている可能性があるDDLをすべて取得するための2番目のREDOログ・ファイル
-
必要なデータを取得するための3番目のログ・ファイル
-
-
同じ要求範囲で、再度
DBMS_LOGMNR.START_LOGMNR
をコールします。LogMinerは、REDOログ・ファイル3から読取りを開始します。REDOログ・ファイル2に含まれているDDL文はすでに処理されているため、REDOログ・ファイル2を読み込む必要はありません。
-
DBMS_LOGMNR.START_LOGMNR
を再度コールします。今回は、REDOログ・ファイル5からデータを読み込む必要があるパラメータを指定します。LogMinerは、REDOログ・ファイル4から読取りを開始し、その中に含まれているすべてのDDL文を取得します。
LogMinerが実際に読取りを開始する位置を確認するには、V$LOGMNR_PARAMETERS
ビューのREQUIRED_START_DATE
列またはREQUIRED_START_SCN
列を問い合せます。LogMinerが読取りを開始する位置に関係なく、要求した範囲内の行のみがV$LOGMNR_CONTENTS
ビューから返されます。
親トピック: LogMinerおよびサプリメンタル・ロギング
25.12 ビューでのLogMiner操作情報へのアクセス
LogMiner操作情報(REDOデータではなく)は、ビューに含まれています。
- LogMiner操作情報を表示するオプション
LogMiner操作を確認するには、他のビューと同様に、SQLを使用してLogMinerビューを問い合せられます。 - V$LOGMNR_LOGSの問合せ
LogMinerで分析するREDOログ・ファイルのリストに手動または自動で追加されたREDOログ・ファイルを特定するには、V$LOGMNR_LOGS
ビューを問い合せます。 - サプリメンタル・ロギング設定のビューの問合せ
サプリメンタル・ロギングの現在の設定を確認するには、複数の異なるビューを問い合せられます。 - LogMinerを使用した個々のPDBの問合せ
時間別またはSCN別にディクショナリ・ビルドを検索するには(たとえば、PDBごとのマイニングを開始する場合)、ソース・データベースでSYS.DBA_LOGMNR_DICTIONARY_BUILDLOG
ビューを使用できます。
親トピック: REDOログ・ファイル分析のためのLogMinerの使用
25.12.1 LogMiner操作情報を表示するためのオプション
LogMiner操作を確認するには、他のビューと同様に、SQLを使用してLogMinerビューを問い合せられます。
V$LOGMNR_CONTENTS
に加えて、他のビューとその表示内容のリストを次に示します。
-
V$LOGMNR_DICTIONARY
DBMS_LOGMNR.START_LOGMNR
に対してSTORE_IN_FLAT_FILE
オプションを使用して作成されたLogMinerディクショナリ・ファイルに関する情報を表示します。LogMinerディクショナリ作成の基礎となったデータベースに関する情報などが表示されます。 -
V$LOGMNR_LOGS
指定したREDOログ・ファイルに関する情報を表示します。
-
V$LOGMNR_PARAMETERS
オプションのLogMinerパラメータに関する情報を表示します。開始システム変更番号(SCN)と終了SCN、開始時刻と終了時刻などの情報が含まれます。
-
V$DATABASE
,DBA_LOG_GROUPS
,ALL_LOG_GROUPS
,USER_LOG_GROUPS
,DBA_LOG_GROUP_COLUMNS
,ALL_LOG_GROUP_COLUMNS
,USER_LOG_GROUP_COLUMN
サプリメンタル・ロギングの現在の設定に関する情報を表示します。
-
SYS.DBA_LOGMNR_DICTIONARY_BUILDLOG
ディクショナリ・ビルドを時間またはSCNのいずれかで検索します。このビューは、
CDB$ROOT
ログ・マイニングとPDBごとのログ・マイニングの両方で、Oracle Database 19c (リリース更新10以降)で使用できます。たとえば、PDBごとのログ・マイニングを取得する場合は、START_LOGMNRの実行時に時間またはSCNを指定する必要があります。
親トピック: ビューでのLogMiner操作情報へのアクセス
25.12.2 V$LOGMNR_LOGSの問合せ
LogMinerで分析するREDOログ・ファイルのリストに手動または自動で追加されたREDOログ・ファイルを特定するには、V$LOGMNR_LOGS
ビューを問い合せられます。
V$LOGMNR_LOGS
には、REDOログ・ファイルごとに行が含まれます。このビューでは、各REDOログ・ファイルに関する重要な情報(ファイル名、SCN範囲、時間範囲、LogMinerディクショナリのすべてを含むか一部を含むかなど)が提供されます。
DBMS_LOGMNR.START_LOGMNR
に対するコールが成功すると、V$LOGMNR_LOGS
ビューのSTATUS
列には、次のいずれかの値が含まれます。
-
0
REDOログ・ファイルが、
V$LOGMNR_CONTENTS
ビューの問合せ中に処理されることを示します。 -
1
対象のREDOログ・ファイルが、
V$LOGMNR_CONTENTS
ビューに対する選択操作中にLogMinerによって処理される、最初のREDOログ・ファイルとなることを示します。 -
2
REDOログ・ファイルが除外されたため、
V$LOGMNR_CONTENTS
ビューの問合せ中にLogMinerによって処理されないことを示します。REDOログ・ファイルは、要求した時間範囲またはSCN範囲を満たすには不要なため、除外されました。 -
4
LogMiner REDOログ・ファイル・リストから、REDOログ・ファイル(順序番号に基づく)が欠落していることを示します。
V$LOGMNR_LOGS
ビューには、次のように、リストから欠落している各REDOログ・ファイルに対する行が1行含まれます。
-
FILENAME
列には、順序番号の連続する範囲とSCN範囲の差異の合計が含まれます。たとえば:
スレッド番号1、順序番号100から102の欠落ログ・ファイル
。 -
INFO
列には、MISSING_LOGFILE
という文字列が含まれます。
REDOログ・ファイル・リストから欠落しているファイルの情報は、次の場合に有効な場合があります。
-
DBMS_LOGMNR.START_LOGMNR
のコール時に指定可能なDDL_DICT_TRACKING
オプションによって、要求した時間範囲またはSCN範囲に対するLogMiner REDOログ・ファイル・リストから、REDOログ・ファイルが欠落しなくなります。DBMS_LOGMNR.START_LOGMNR
に対するコールが失敗した場合、V$LOGMNR_LOGS
ビューのSTATUS
列を問い合せることによって、リストから欠落しているREDOログ・ファイルを判別できます。その後、欠落しているREDOログ・ファイルを検索して、手動で追加すると、再度DBMS_LOGMNR.START_LOGMNR
をコールできます。ノート:
dbms_logmnr.start_logmnr
パッケージのcontinuous_mine
オプションは、Oracle Database 19c (19.1)ではサポートされなくなり、使用できなくなりました。 -
DBMS_LOGMNR.START_LOGMNR
へのコール時に指定可能なその他のオプションでは、LogMiner REDOログ・ファイル・リストからファイルが欠落する場合がありますが、ファイルの欠落は、可能なかぎり回避する必要があります。V$LOGMNR_CONTENTS
ビューを問い合せる前に、V$LOGMNR_LOGS
ビューを問い合せて、必要なすべてのファイルがリストにあることを確認できます。リストに欠落ファイルがある場合にV$LOGMNR_CONTENTS
ビューを問い合せると、次の列の値を持つ行がV$LOGMNR_CONTENTS
に返されます。-
OPERATION
列の値MISSING_SCN -
STATUS
列の値1291
-
INFO
列で、欠落しているSCN範囲を示す文字列。たとえば:SCN 100から200がありません
-
親トピック: ビューでのLogMiner操作情報へのアクセス
25.12.3 サプリメンタル・ロギング設定に関するビューの問合せ
サプリメンタル・ロギングの現在の設定を確認するには、様々なビューを問い合せます。
必要な情報に応じて、複数のビューのいずれかを使用できます。
-
V$DATABASE
ビュー-
SUPPLEMENTAL_LOG_DATA_FK
列この列には次のいずれかの値が入ります。
-
NO
-FOREIGN KEY
オプションを指定したデータベース・レベルの識別キー・ロギングが有効でない場合 -
YES
-FOREIGN KEY
オプションを指定したデータベース・レベルの識別キー・ロギングが有効な場合
-
-
SUPPLEMENTAL_LOG_DATA_ALL
列この列には次のいずれかの値が入ります。
-
NO
-ALL
オプションを指定したデータベース・レベルの識別キー・ロギングが有効でない場合 -
YES
-ALL
オプションを指定したデータベース・レベルの識別キー・ロギングが有効な場合
-
-
SUPPLEMENTAL_LOG_DATA_UI
列-
NO
-UNIQUE
オプションを指定したデータベース・レベルの識別キー・ロギングが有効でない場合 -
YES
-UNIQUE
オプションを指定したデータベース・レベルの識別キー・ロギングが有効な場合
-
-
SUPPLEMENTAL_LOG_DATA_MIN
列この列には次のいずれかの値が入ります。
-
NO
- データベース・レベルのサプリメンタル・ロギングが有効でない場合 -
IMPLICIT
- データベース・レベルの識別キー・ロギング・オプションが有効なため、最小サプリメンタル・ロギングが有効な場合 -
YES
-SQL ALTER DATABASE ADD SUPPLEMENTAL LOG DATA
文が発行されているため、最小サプリメンタル・ロギングが有効な場合
-
-
-
DBA_LOG_GROUPS
、ALL_LOG_GROUPS
、USER_LOG_GROUPS
の各ビュー-
ALWAYS
列この列には次のいずれかの値が入ります。
-
ALWAYS
- このログ・グループの列は、関連付けられた行の列が更新された場合に補助的に記録されることを示します。 -
CONDITIONAL
- このグループの列は、ログ・グループの列が更新された場合にのみ補助的に記録されることを示します。
-
-
GENERATED
列この列には次のいずれかの値が入ります。
-
GENERATED NAME
-LOG_GROUP
名がシステムによって生成された場合です。 -
USER NAME
-LOG_GROUP
名がユーザーによって定義された場合です。
-
-
LOG_GROUP_TYPE
列この列には、次のいずれかの値が入り、このログ・グループで定義されたロギングの種類を示します。
USER LOG GROUP
は、ログ・グループがユーザー定義である(システム生成ではない)ことを示します。-
ALL COLUMN LOGGING
-
FOREIGN KEY LOGGING
-
PRIMARY KEY LOGGING
-
UNIQUE KEY LOGGING
-
USER LOG GROUP
-
-
-
DBA_LOG_GROUP_COLUMNS
、ALL_LOG_GROUP_COLUMNS
、USER_LOG_GROUP_COLUMNS
の各ビュー-
LOGGING_PROPERTY
列この列には次のいずれかの値が入ります。
-
LOG
- ログ・グループのこの列が補助的に記録されることを示します。 -
NO
LOG
- ログ・グループのこの列が補助的に記録されないことを示します。
-
-
親トピック: ビューでのLogMiner操作情報へのアクセス
25.12.4 LogMinerを使用した個々のPDBの問合せ
ディクショナリ・ビルドを時間またはSCNで検索するには(たとえば、PDBごとのマイニングを開始する場合)、ソース・データベースでSYS.DBA_LOGMNR_DICTIONARY_BUILDLOG
ビューを使用できます。
Oracle Database 19c (リリース更新10以降)以降では、CDB$ROOT
または個々のPDBのどちらに接続するかを選択できます。
従来のオンプレミス・ログ・マイニング・セッションでは、CDB$ROOT
に接続すると、CDB$ROOT
およびPDBを含むマルチテナント・アーキテクチャ全体に対して問合せが実行されます。PDBごとのログ・マイニング・セッションでは、特定のPDBに接続すると、LogMinerは接続したPDBの行のみを返します。この方法は、Oracle Autonomous Cloud Platform ServicesでOracle Autonomous DatabaseのREDOログ・ファイルを問い合せる場合に必要です。
PDBのログ履歴情報を表示するには、引き続きV$LOGMNR_CONTENTS
ビューを使用します。ただし、PDBのLogMinerを起動するために、ログ・ファイルを追加しなくなりました。かわりに、DBMS_LOGMNR.START_LOGMNR
をコールし、表示するPDBログ履歴のシステム変更番号(SCN)を指定します。PDBのDBA_LOGMNR_DICTIONARY_BUILDLOG
ビューに表示される任意のSTART_SCN
値を使用できます。
ノート:
LogMinerの起動時に、表示するログ履歴のENDSCN
またはENDTIME
の値がわかっている場合は、これらの終了値のいずれかを指定できます。
例25-3 SYS.DBA_LOGMNR_DICTIONARYの問合せ
次の例では、PDBに接続した後、DBA_LOGMNR_DICTIONARY_BUILDLOG
を問い合せてSTART_SCN
値を特定し、DBMS_LOGMNR.START_LOGMNR
でLogMinerを起動して、問い合せるログのSCN値を指定します。
SQL> execute dbms_logmnr_d.build(options => dbms_logmnr_d.store_in_redo_logs);
PL/SQL procedure successfully completed.
SQL> select date_of_build, start_scn from dba_logmnr_dictionary_buildlog;
DATE_OF_BUILD START_SCN
-------------------- --------------------
09/02/2020 15:58:42 2104064
09/02/2020 19:35:36 3943026
09/02/2020 19:35:54 3943543
09/02/2020 19:35:57 3944009
09/02/2020 19:36:00 3944473
09/10/2020 20:13:22 5902422
09/15/2020 10:03:16 7196131
7 rows selected.
SQL> execute dbms_logmnr.start_logmnr(Options => dbms_logmnr.DDL_DICT_TRACKING + dbms_logmnr.DICT_FROM_REDO_LOGS, startscn=>5902422);
PL/SQL procedure successfully completed.
SQL> select count(sql_redo) from v$logmnr_contents;
COUNT(SQL_REDO)
--------------------
619958
SQL>
親トピック: ビューでのLogMiner操作情報へのアクセス
25.13 一般的なLogMinerセッションのステップ
LogMinerを使用してデータを抽出およびマイニングできる一般的な方法について学習します。
- LogMinerセッションの実行方法の理解
オンプレミスでのLogMinerセッションの実行方法とOracle Autonomous Cloud Platform Servicesは似ていますが、異なるユーザーが必要です。 - 一般的なLogMinerセッション・タスク1: サプリメンタル・ロギングの有効化
REDOログ・ファイルとともにLogMinerを使用できるようにするには、サプリメンタル・ロギングを有効にする必要があります。 - 一般的なLogMinerセッション・タスク2: LogMinerディクショナリの抽出
LogMinerを使用するには、LogMinerにデータベース・ディクショナリを提供するオプションを選択する必要があります。 - 一般的なLogMinerセッション・タスク3: 分析用のREDOログ・ファイルの指定
LogMinerを起動する前にDBMS_LOGMNR_ADD_LOGFILE
を使用して、分析するREDOログ・ファイルを指定する必要があります。 - LogMinerの起動
LogMinerの起動方法、およびREDOログ・ファイル、フィルタ基準、その他のセッション特性の分析に使用できるオプションを確認してください。 - V$LOGMNR_CONTENTSの問合せ
LogMinerを起動した後、Oracle DatabaseのV$LOGMNR_CONTENTS
ビューを問い合せることができます。 - 一般的なLogMinerセッション・タスク6: LogMinerセッションの終了
LogMinerセッションの終了。
親トピック: REDOログ・ファイル分析のためのLogMinerの使用
25.13.1 LogMinerセッションの実行方法の理解
オンプレミスとOracle Autonomous Cloud Platform Services LogMinerセッションは似ていますが、異なるユーザーが必要です。
従来のLogMinerセッションでは、CDB$ROOT
でLogMinerを実行する場合、SYS
が所有するPL/SQLパッケージを使用してLogMinerを実行します。LogMinerを使用するには、LogMinerで使用するユーザー・アカウントに関する要件があります。
オンプレミスOracle DatabaseでLogMinerを実行する場合、CDB$ROOT
取得抽出を作成して複数のPDBからデータを同時に取得するか、Oracle GoldenGateを使用して複数の個別のPDBログをマイニングし、それぞれが単一のPDBからデータを取得できます。ただし、CDB$ROOT
にアクセスできないOracle Autonomous Database Cloud Platform Servicesの場合は、PDBごとの取得方法を使用する必要があります。このモードでは、事前定義済の権限セットを持つローカル・ユーザーを、ログを確認するソースPDBにプロビジョニングします。すべてのLogMiner処理は、このPDBのみに制限されます。
オンプレミスPDBでは、リソースで許可されている数のセッションを開始できます。ただし、クラウド構成では、CDB$ROOT
で多くの同時セッションを開始できますが、LogMiner PL/SQLパッケージを使用して各PDBに対して開始できるセッションは1つのみです。
CDB$ROOT
でLogMinerを実行するには、PL/SQLパッケージDBMS_LOGMNR.ADD_LOGFILE
を使用し、ログ・ファイルを明示的に追加します。また、オンライン・カタログを使用せずにLogMinerディクショナリを抽出することを選択する場合は、DBMS_LOGMNR_D
パッケージも使用できます。
個々のPDBでLogMinerを実行する場合、プロシージャは若干異なります。DBMS_LOGMNR.ADD_LOGFILE
を使用するかわりに、PDBのログ・ファイルを確認する期間を指定します。問い合せるログのSCN値をstartScn
で指定し、endScn
またはstartTime
を選択した場合はendTime
で指定します。次に、DBMS_LOGMNR.START_LOGMNR
を使用してLogMinerを起動します。DBMS_LOGMNR.START_LOGMNR
は、分析するREDOログを自動的に追加します。
DBMS_LOGMNR
パッケージには、LogMinerの初期化および実行に使用するプロシージャ(REDOログ・ファイルの名前、フィルタ基準、セッション特性を指定するためのインタフェースなど)が含まれます。DBMS_LOGMNR_D
パッケージは、現在のデータベースのデータベース・ディクショナリ表を問い合せてLogMinerディクショナリ・ファイルを作成します。
個々のPDBに対してLogMinerを実行するための要件
LogMinerを実行して個々のPDBを問い合せるには、プロシージャ・コールDBMS_GOLDENGATE_AUTH.GRANT_ADMIN_PRIVILEGE
を使用して、必要な権限をローカル・ユーザーにプロビジョニングする必要があります。また、GGADMIN
権限を持つユーザーは、PDBごとの取得抽出を実行できます。
また、個々のPDBでは、マイニングするアーカイブ・ログを指定しません。かわりに、マイニングするPDBに接続し、dbms_logmnr_d.STORE_IN_REDO_LOGS
を実行します。たとえば:
SQL> execute dbms_logmnr_d.build(option=>dbms_logmnr_d.STORE_IN_REDO_LOGS);
その後、PDBに接続してSCNを識別し、dbms_logmnr.start_logmnr
を実行して、表示するPDBログ履歴の開始点システム変更番号(SCN)およびエンド・ポイントSCN (選択した場合)をログ・ファイルに問い合せられます。マイニングは、V$LOGMNR_CONTENTSビューに対する従来のLogMiner問合せと同様に、その時点で続行されます。ただし、使用できるのは、接続しているPDBに対して生成されたREDOのみです
ノート:
ExtractおよびLogMinerプロセスの実行中にPDBを停止すると、これらのプロセスは他のアクティブ・セッションと同様に終了します。PDBを再オープンしたら、Extractマイニングの再起動を通常どおり続行する必要があります。PDBを切断する場合、特別なアクションは必要ありません。ただし、PDBを切断した後に接続すると、PDBに以前存在していたすべてのLogMinerおよびCaptureセッションが削除されます。
SYSとして接続していない場合に従来のLogMinerセッションを実行するための要件
オンプレミス・ログ・マイニングでは、LogMiner PL/SQLパッケージはSYS
スキーマによって所有されます。したがって、ユーザーSYS
として接続していない場合は、次の条件が必要になります。
-
コールに
SYS
を含める必要があります。たとえば:EXECUTE SYS.DBMS_LOGMNR.END_LOGMNR;
-
EXECUTE_CATALOG_ROLE
ロールを付与されている必要があります。
25.13.2 一般的なLogMinerセッション・タスク1: サプリメンタル・ロギングの有効化
REDOログ・ファイルとともにLogMinerを使用できるようにするには、サプリメンタル・ロギングを有効にする必要があります。
REDOベースのアプリケーションでは、追加の列をREDOログ・ファイルに記録する必要がある場合があります。これらの追加の列を記録するプロセスは、サプリメンタル・ロギングと呼ばれますデフォルトでは、Oracle Databaseはサプリメンタル・ロギングが有効になっていません。少なくともLogMinerを使用するには、最小限のサプリメンタル・ロギングを有効にする必要があります。
例25-4 最小サプリメンタル・ロギングの有効化
サプリメンタル・ロギングを有効にするには、次の文を入力します。
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
関連トピック
親トピック: 一般的なLogMinerセッションのステップ
25.13.3 一般的なLogMinerセッション・タスク2: LogMinerディクショナリの抽出
LogMinerを使用するには、LogMinerにデータベース・ディクショナリを提供するオプションを選択する必要があります。
次のいずれかのオプションを選択します。
-
LogMiner起動時に
DICT_FROM_ONLINE_CATALOG
オプションでオンライン・カタログの使用を指定。 -
REDOログ・ファイルにデータベース・ディクショナリ情報を抽出。
-
フラット・ファイルにデータベース・ディクショナリ情報を抽出。
25.13.4 一般的なLogMinerセッション・タスク3: 分析用のREDOログ・ファイルの指定
LogMinerを起動する前にDBMS_LOGMNR_ADD_LOGFILE
を使用して、分析するREDOログ・ファイルを指定する必要があります。
オンプレミスのCDB$ROOT
のログを問い合せるには、LogMinerを起動する前に、分析するREDOログ・ファイルを指定する必要があります。ログ・ファイルを指定するには、次のステップで示すとおり、DBMS_LOGMNR.ADD_LOGFILE
プロシージャを実行します。REDOログ・ファイルは、任意の順序で追加および削除できます。
ノート:
個々のPDBのログを問い合せるには、若干異なる手順を使用します。PDBに接続した後、DBA_LOGMNR_DICTIONARY_BUILDLOG
を問い合せてSTART_SCN
値を特定し、DBMS_LOGMNR.START_LOGMNR
でLogMinerを起動して、確認するログのSCN値を指定します。DBMS_LOGMNR.START_LOGMNR
は、分析するREDOログを自動的に追加します。例は、「LogMinerを使用した個々のPDBの問合せ」を参照してください。
関連トピック
親トピック: 一般的なLogMinerセッションのステップ
25.13.5 LogMinerの起動
LogMinerの起動方法、およびREDOログ・ファイル、フィルタ基準、その他のセッション特性の分析に使用できるオプションを確認してください。
25.13.6 V$LOGMNR_CONTENTSの問合せ
LogMinerを起動した後、Oracle DatabaseのV$LOGMNR_CONTENTS
ビューを問い合せることができます。
たとえば:
SELECT (XIDUSN || '.' || XIDSLT || '.' || XIDSQN) AS XID,
USERNAME, SQL_REDO FROM V$LOGMNR_CONTENTS WHERE USERNAME != 'SYS'
AND SEG_OWNER IS NULL OR SEG_OWNER NOT IN ('SYS', 'SYSTEM');
XID USERNAME SQL_REDO
1.15.3045 RON set transaction read write;
1.15.3045 RON insert into "HR"."JOBS"("JOB_ID","JOB_TITLE",
"MIN_SALARY","MAX_SALARY") values ('9782',
'HR_ENTRY',NULL,NULL);
1.18.3046 JANE set transaction read write;
1.18.3046 JANE insert into "OE"."CUSTOMERS"("CUSTOMER_ID",
"CUST_FIRST_NAME","CUST_LAST_NAME",
"CUST_ADDRESS","PHONE_NUMBERS","NLS_LANGUAGE",
"NLS_TERRITORY","CREDIT_LIMIT","CUST_EMAIL",
"ACCOUNT_MGR_ID") values ('9839','Edgar',
'Cummings',NULL,NULL,NULL,NULL,
NULL,NULL,NULL);
1.9.3041 RAJIV set transaction read write;
1.9.3041 RAJIV insert into "OE"."CUSTOMERS"("CUSTOMER_ID",
"CUST_FIRST_NAME","CUST_LAST_NAME","CUST_ADDRESS",
"PHONE_NUMBERS","NLS_LANGUAGE","NLS_TERRITORY",
"CREDIT_LIMIT","CUST_EMAIL","ACCOUNT_MGR_ID")
values ('9499','Rodney','Emerson',NULL,NULL,NULL,NULL,
NULL,NULL,NULL);
1.15.3045 RON commit;
1.8.3054 RON set transaction read write;
1.8.3054 RON insert into "HR"."JOBS"("JOB_ID","JOB_TITLE",
"MIN_SALARY","MAX_SALARY") values ('9566',
'FI_ENTRY',NULL,NULL);
1.18.3046 JANE commit;
1.11.3047 JANE set transaction read write;
1.11.3047 JANE insert into "OE"."CUSTOMERS"("CUSTOMER_ID",
"CUST_FIRST_NAME","CUST_LAST_NAME",
"CUST_ADDRESS","PHONE_NUMBERS","NLS_LANGUAGE",
"NLS_TERRITORY","CREDIT_LIMIT","CUST_EMAIL",
"ACCOUNT_MGR_ID") values ('8933','Ronald',
'Frost',NULL,NULL,NULL,NULL,NULL,NULL,NULL);
1.11.3047 JANE commit;
1.8.3054 RON commit;
別の例を確認するには、「V$LOGMNR_CONTENTS
に返されるデータのフィルタ処理および書式設定」を参照してください。
25.13.7 一般的なLogMinerセッション・タスク6: LogMinerセッションの終了
LogMinerセッションの終了。
LogMinerセッションを正常に終了するには、次に示すとおり、PL/SQLプロシージャDBMS_LOGMNR.END_LOGMNR
を使用します。
EXECUTE DBMS_LOGMNR.END_LOGMNR;
このプロシージャを実行すると、すべてのREDOログ・ファイルがクローズされ、LogMinerによって割り当てられたすべてのデータベースとシステム・リソースを解放できます。
このプロシージャを実行しない場合、LogMinerは、コールを実行したOracleセッションが終了するまで、割り当てられたすべてのリソースを保持します。DDL_DICT_TRACKING
オプションまたはDICT_FROM_REDO_LOGS
オプションのいずれかを使用した場合は、LogMinerセッションの終了に、このプロシージャを使用する必要があります。
親トピック: 一般的なLogMinerセッションのステップ
25.14 LogMinerの使用例
データ・マイニングにLogMinerを使用する方法を確認するには、示されている例を確認してください。
ノート:
この項のすべての例では、最小サプリメンタル・ロギングが次のように有効にされているとします。
SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
LogMinerのユースケース・シナリオの例を除くすべての例で、NLS_DATE_FORMAT
パラメータが次のように設定されていると想定しています。
SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'dd-mon-yyyy hh24:mi:ss';
LogMinerではユーザー・セッションに対してアクティブなNLS_DATE_FORMAT
パラメータの設定を使用して日付データが表示されるため、このステップはオプションです。ただし、このパラメータを明示的に設定すると、指定した日付書式が使用されます。
- 分析するREDOログ・ファイルの明示的指定によるマイニングの例
例を使用して、REDOログ・ファイルを指定する方法を確認してください。 - LogMinerのユースケース・シナリオ
LogMinerを使用してデータ・マイニング・タスクを実行する方法の一般的な例を確認してください。
関連トピック
親トピック: REDOログ・ファイル分析のためのLogMinerの使用
25.14.1 分析するREDOログ・ファイルの明示的指定によるマイニングの例
例を使用して、REDOログ・ファイルの指定方法を確認してください。
これらの例では、分析対象データが存在するREDOログ・ファイルがわかっている場合のLogMinerの使用方法を示します。それぞれの例は、前の例に基づいて作成されているため、順番に読み進むことをお薦めします。
SQL出力の画面上の書式設定は、この項で示す例とは異なる場合があります。
ノート:
dbms_logmnr.start_logmnr
パッケージのcontinuous_mine
オプションは、Oracle Database 19c (19.1)ではサポートされなくなり、使用できなくなりました。ログ・ファイルを手動で指定する必要があります
- 例1: 最後にアーカイブされたREDOログ・ファイルでのすべての変更の検索
LogMinerのデフォルト動作では、トランザクションがコミット済であるかどうかに関係なく、分析するREDOログ・ファイルで検出されたすべての変更が表示されます。 - 例2: コミット済トランザクションへのDML文のグループ化
LogMinerを使用してREDOログ・トランザクションをグループ化する方法について説明します。 - 例3: 再構築されたSQLの書式設定
視覚的な検査を簡単に行うには、PRINT_PRETTY_SQL
オプションを指定してLogMinerを実行します。 - 例4: REDOログ・ファイル内のLogMinerディクショナリの使用
REDOログ・ファイルに抽出されたディクショナリの使用方法について説明します。 - 例5: 内部ディクショナリでのDDL文の追跡
DBMS_LOGMNR.DDL_DICT_TRACKING
オプションを使用して、REDOログ・ファイル内で発生したDDL文でLogMiner内部ディクショナリを更新する方法について説明します。 - 例6: 時間範囲による出力のフィルタ
時間ごとに一連のREDOログをフィルタするには、時間範囲を指定してログ・ファイルを返す様々な方法について学習してください。
親トピック: LogMinerの使用例
25.14.1.1 例1: 最後にアーカイブされたREDOログ・ファイルでのすべての変更の検索
LogMinerのデフォルト動作では、トランザクションがコミット済であるかどうかに関係なく、分析するREDOログ・ファイルで検出されたすべての変更が表示されます。
データベースの変更履歴を確認する最も簡単な方法は、ソース・データベースでマイニングし、オンライン・カタログを使用してREDOログ・ファイルを変換する方法です。この例では、LogMinerを使用して最も簡単に分析を行う方法を示します。
この例では、最後にアーカイブされたREDOログ・ファイルをマイニングするとします。ここでは、最後にアーカイブされたREDOログ(データベースで生成)に含まれているすべての変更を検索します(データベースは、Oracle Real Application Clusters (Oracle RAC)データベースでないものとします)。
-
最後にアーカイブされたREDOログ・ファイルを判別します。
SELECT NAME FROM V$ARCHIVED_LOG WHERE FIRST_TIME = (SELECT MAX(FIRST_TIME) FROM V$ARCHIVED_LOG); NAME ------------------------------------------- /usr/oracle/data/db1arch_1_16_482701534.dbf
-
分析するREDOログ・ファイルのリストを指定します。この場合は、ステップ1の問合せで返されたREDOログ・ファイルです。
EXECUTE DBMS_LOGMNR.ADD_LOGFILE( - LOGFILENAME => '/usr/oracle/data/db1arch_1_16_482701534.dbf', - OPTIONS => DBMS_LOGMNR.NEW);
-
LogMinerを起動し、使用するディクショナリを指定します。
EXECUTE DBMS_LOGMNR.START_LOGMNR( - OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG);
-
V$LOGMNR_CONTENTS
ビューを問い合せます。4つのトランザクションがあることに注意してください(そのうちの2つは、分析するREDOログ・ファイル内でコミット済であり、2つはコミットされていません)。出力には、実行された順序でDML文が表示されるため、トランザクションは交互に配置されます。
SELECT username AS USR, (XIDUSN || '.' || XIDSLT || '.' || XIDSQN) AS XID, SQL_REDO, SQL_UNDO FROM V$LOGMNR_CONTENTS WHERE username IN ('HR', 'OE'); USR XID SQL_REDO SQL_UNDO ---- --------- ---------------------------------------------------- HR 1.11.1476 set transaction read write; HR 1.11.1476 insert into "HR"."EMPLOYEES"( delete from "HR"."EMPLOYEES" "EMPLOYEE_ID","FIRST_NAME", where "EMPLOYEE_ID" = '306' "LAST_NAME","EMAIL", and "FIRST_NAME" = 'Nandini' "PHONE_NUMBER","HIRE_DATE", and "LAST_NAME" = 'Shastry' "JOB_ID","SALARY", and "EMAIL" = 'NSHASTRY' "COMMISSION_PCT","MANAGER_ID", and "PHONE_NUMBER" = '1234567890' "DEPARTMENT_ID") values and "HIRE_DATE" = TO_DATE('10-JAN-2012 ('306','Nandini','Shastry', 13:34:43', 'dd-mon-yyyy hh24:mi:ss') 'NSHASTRY', '1234567890', and "JOB_ID" = 'HR_REP' and TO_DATE('10-jan-2012 13:34:43', "SALARY" = '120000' and 'dd-mon-yyyy hh24:mi:ss'), "COMMISSION_PCT" = '.05' and 'HR_REP','120000', '.05', "DEPARTMENT_ID" = '10' and '105','10'); ROWID = 'AAAHSkAABAAAY6rAAO'; OE 1.1.1484 set transaction read write; OE 1.1.1484 update "OE"."PRODUCT_INFORMATION" update "OE"."PRODUCT_INFORMATION" set "WARRANTY_PERIOD" = set "WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00') where TO_YMINTERVAL('+01-00') where "PRODUCT_ID" = '1799' and "PRODUCT_ID" = '1799' and "WARRANTY_PERIOD" = "WARRANTY_PERIOD" = TO_YMINTERVAL('+01-00') and TO_YMINTERVAL('+05-00') and ROWID = 'AAAHTKAABAAAY9mAAB'; ROWID = 'AAAHTKAABAAAY9mAAB'; OE 1.1.1484 update "OE"."PRODUCT_INFORMATION" update "OE"."PRODUCT_INFORMATION" set "WARRANTY_PERIOD" = set "WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00') where TO_YMINTERVAL('+01-00') where "PRODUCT_ID" = '1801' and "PRODUCT_ID" = '1801' and "WARRANTY_PERIOD" = "WARRANTY_PERIOD" = TO_YMINTERVAL('+01-00') and TO_YMINTERVAL('+05-00') and ROWID = 'AAAHTKAABAAAY9mAAC'; ROWID ='AAAHTKAABAAAY9mAAC'; HR 1.11.1476 insert into "HR"."EMPLOYEES"( delete from "HR"."EMPLOYEES" "EMPLOYEE_ID","FIRST_NAME", "EMPLOYEE_ID" = '307' and "LAST_NAME","EMAIL", "FIRST_NAME" = 'John' and "PHONE_NUMBER","HIRE_DATE", "LAST_NAME" = 'Silver' and "JOB_ID","SALARY", "EMAIL" = 'JSILVER' and "COMMISSION_PCT","MANAGER_ID", "PHONE_NUMBER" = '5551112222' "DEPARTMENT_ID") values and "HIRE_DATE" = TO_DATE('10-jan-2012 ('307','John','Silver', 13:41:03', 'dd-mon-yyyy hh24:mi:ss') 'JSILVER', '5551112222', and "JOB_ID" ='105' and "DEPARTMENT_ID" TO_DATE('10-jan-2012 13:41:03', = '50' and ROWID = 'AAAHSkAABAAAY6rAAP'; 'dd-mon-yyyy hh24:mi:ss'), 'SH_CLERK','110000', '.05', '105','50'); OE 1.1.1484 commit; HR 1.15.1481 set transaction read write; HR 1.15.1481 delete from "HR"."EMPLOYEES" insert into "HR"."EMPLOYEES"( where "EMPLOYEE_ID" = '205' and "EMPLOYEE_ID","FIRST_NAME", "FIRST_NAME" = 'Shelley' and "LAST_NAME","EMAIL","PHONE_NUMBER", "LAST_NAME" = 'Higgins' and "HIRE_DATE", "JOB_ID","SALARY", "EMAIL" = 'SHIGGINS' and "COMMISSION_PCT","MANAGER_ID", "PHONE_NUMBER" = '515.123.8080' "DEPARTMENT_ID") values and "HIRE_DATE" = TO_DATE( ('205','Shelley','Higgins', '07-jun-1994 10:05:01', and 'SHIGGINS','515.123.8080', 'dd-mon-yyyy hh24:mi:ss') TO_DATE('07-jun-1994 10:05:01', and "JOB_ID" = 'AC_MGR' 'dd-mon-yyyy hh24:mi:ss'), and "SALARY"= '12000' 'AC_MGR','12000',NULL,'101','110'); and "COMMISSION_PCT" IS NULL and "MANAGER_ID" = '101' and "DEPARTMENT_ID" = '110' and ROWID = 'AAAHSkAABAAAY6rAAM'; OE 1.8.1484 set transaction read write; OE 1.8.1484 update "OE"."PRODUCT_INFORMATION" update "OE"."PRODUCT_INFORMATION" set "WARRANTY_PERIOD" = set "WARRANTY_PERIOD" = TO_YMINTERVAL('+12-06') where TO_YMINTERVAL('+20-00') where "PRODUCT_ID" = '2350' and "PRODUCT_ID" = '2350' and "WARRANTY_PERIOD" = "WARRANTY_PERIOD" = TO_YMINTERVAL('+20-00') and TO_YMINTERVAL('+20-00') and ROWID = 'AAAHTKAABAAAY9tAAD'; ROWID ='AAAHTKAABAAAY9tAAD'; HR 1.11.1476 commit;
-
LogMinerセッションを終了します。
SQL> EXECUTE DBMS_LOGMNR.END_LOGMNR();
25.14.1.2 例2: コミット済トランザクションへのDML文のグループ化
LogMinerを使用してREDOログ・トランザクションをグループ化する方法を学習します。
例1に示すように、LogMinerのデフォルト動作では、トランザクションがコミット済であるかどうかに関係なく、分析するREDOログ・ファイルで検出されたすべての変更が表示されます。また、LogMinerでは、実行された順序で変更が表示されます。同じトランザクションに属するDML文がグループにまとめられていないため、出力を目視で簡単に確認することはできません。SQLを使用してトランザクションをグループ化することもできますが、LogMinerでは、より簡単な方法が提供されています。この例では、最後にアーカイブされたREDOログ・ファイルを再度分析しますが、コミット済トランザクションのみが返されます。
-
データベースによって最後にアーカイブされたREDOログ・ファイルを判別します。
SELECT NAME FROM V$ARCHIVED_LOG WHERE FIRST_TIME = (SELECT MAX(FIRST_TIME) FROM V$ARCHIVED_LOG); NAME ------------------------------------------- /usr/oracle/data/db1arch_1_16_482701534.dbf
-
ステップ1の問合せで返されたREDOログ・ファイルを指定します。このリストは、1つのREDOログ・ファイルで構成されます。
EXECUTE DBMS_LOGMNR.ADD_LOGFILE( - LOGFILENAME => '/usr/oracle/data/db1arch_1_16_482701534.dbf', - OPTIONS => DBMS_LOGMNR.NEW);
-
使用するディクショナリと
COMMITTED_DATA_ONLY
オプションを指定して、LogMinerを起動します。EXECUTE DBMS_LOGMNR.START_LOGMNR( - OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG + - DBMS_LOGMNR.COMMITTED_DATA_ONLY);
-
V$LOGMNR_CONTENTS
ビューを問い合せます。トランザクション1.11.1476は、トランザクション1.1.1484 (ステップ1で説明)より前に起動されましたが、これはトランザクション1.1.1484がコミットされた後にコミットされました。したがって、この例では、トランザクション1.1.1484は、その全体がトランザクション1.11.1476より前に示されます。分析中のREDOログ・ファイル内の、コミットされなかった2つのトランザクションは返されません。
SELECT username AS USR, (XIDUSN || '.' || XIDSLT || '.' || XIDSQN) AS XID, SQL_REDO, SQL_UNDO FROM V$LOGMNR_CONTENTS WHERE username IN ('HR', 'OE'); ; USR XID SQL_REDO SQL_UNDO ---- --------- ------------------------------- --------------------------------- OE 1.1.1484 set transaction read write; OE 1.1.1484 update "OE"."PRODUCT_INFORMATION" update "OE"."PRODUCT_INFORMATION" set "WARRANTY_PERIOD" = set "WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00') where TO_YMINTERVAL('+01-00') where "PRODUCT_ID" = '1799' and "PRODUCT_ID" = '1799' and "WARRANTY_PERIOD" = "WARRANTY_PERIOD" = TO_YMINTERVAL('+01-00') and TO_YMINTERVAL('+05-00') and ROWID = 'AAAHTKAABAAAY9mAAB'; ROWID = 'AAAHTKAABAAAY9mAAB'; OE 1.1.1484 update "OE"."PRODUCT_INFORMATION" update "OE"."PRODUCT_INFORMATION" set "WARRANTY_PERIOD" = set "WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00') where TO_YMINTERVAL('+01-00') where "PRODUCT_ID" = '1801' and "PRODUCT_ID" = '1801' and "WARRANTY_PERIOD" = "WARRANTY_PERIOD" = TO_YMINTERVAL('+01-00') and TO_YMINTERVAL('+05-00') and ROWID = 'AAAHTKAABAAAY9mAAC'; ROWID ='AAAHTKAABAAAY9mAAC'; OE 1.1.1484 commit; HR 1.11.1476 set transaction read write; HR 1.11.1476 insert into "HR"."EMPLOYEES"( delete from "HR"."EMPLOYEES" "EMPLOYEE_ID","FIRST_NAME", where "EMPLOYEE_ID" = '306' "LAST_NAME","EMAIL", and "FIRST_NAME" = 'Nandini' "PHONE_NUMBER","HIRE_DATE", and "LAST_NAME" = 'Shastry' "JOB_ID","SALARY", and "EMAIL" = 'NSHASTRY' "COMMISSION_PCT","MANAGER_ID", and "PHONE_NUMBER" = '1234567890' "DEPARTMENT_ID") values and "HIRE_DATE" = TO_DATE('10-JAN-2012 ('306','Nandini','Shastry', 13:34:43', 'dd-mon-yyyy hh24:mi:ss') 'NSHASTRY', '1234567890', and "JOB_ID" = 'HR_REP' and TO_DATE('10-jan-2012 13:34:43', "SALARY" = '120000' and 'dd-mon-yyy hh24:mi:ss'), "COMMISSION_PCT" = '.05' and 'HR_REP','120000', '.05', "DEPARTMENT_ID" = '10' and '105','10'); ROWID = 'AAAHSkAABAAAY6rAAO'; HR 1.11.1476 insert into "HR"."EMPLOYEES"( delete from "HR"."EMPLOYEES" "EMPLOYEE_ID","FIRST_NAME", "EMPLOYEE_ID" = '307' and "LAST_NAME","EMAIL", "FIRST_NAME" = 'John' and "PHONE_NUMBER","HIRE_DATE", "LAST_NAME" = 'Silver' and "JOB_ID","SALARY", "EMAIL" = 'JSILVER' and "COMMISSION_PCT","MANAGER_ID", "PHONE_NUMBER" = '5551112222' "DEPARTMENT_ID") values and "HIRE_DATE" = TO_DATE('10-jan-2012 ('307','John','Silver', 13:41:03', 'dd-mon-yyyy hh24:mi:ss') 'JSILVER', '5551112222', and "JOB_ID" ='105' and "DEPARTMENT_ID" TO_DATE('10-jan-2012 13:41:03', = '50' and ROWID = 'AAAHSkAABAAAY6rAAP'; 'dd-mon-yyyy hh24:mi:ss'), 'SH_CLERK','110000', '.05', '105','50'); HR 1.11.1476 commit;
-
LogMinerセッションを終了します。
EXECUTE DBMS_LOGMNR.END_LOGMNR();
25.14.1.3 例3: 再構築されたSQLの書式設定
視覚的な検査を簡単に行うには、PRINT_PRETTY_SQL
オプションを指定してLogMinerを実行します。
例2で示したとおり、オンラインREDOログ・ファイルのディクショナリでCOMMITTED_DATA_ONLY
オプションを使用する方法は、コミット済トランザクションのみを対象とするための簡単な方法です。ただし、目視で簡単に確認はできません。INSERT
文内の列名とそれに対応する値との間の関連が明白でないためです。PRINT_PRETTY_SQL
オプションを指定することで、この問題に対処できます。このオプションを指定すると、再構築されたSQL文の一部が実行不可能になることに注意してください。
-
最後にアーカイブされたREDOログ・ファイルを判別します。
SELECT NAME FROM V$ARCHIVED_LOG WHERE FIRST_TIME = (SELECT MAX(FIRST_TIME) FROM V$ARCHIVED_LOG); NAME ------------------------------------------- /usr/oracle/data/db1arch_1_16_482701534.dbf
-
ステップ1の問合せで返されたREDOログ・ファイルを指定します。
EXECUTE DBMS_LOGMNR.ADD_LOGFILE( - LOGFILENAME => '/usr/oracle/data/db1arch_1_16_482701534.dbf', - OPTIONS => DBMS_LOGMNR.NEW);
-
使用するディクショナリおよび
COMMITTED_DATA_ONLY
オプションとPRINT_PRETTY_SQL
オプションを指定して、LogMinerを起動します。EXECUTE DBMS_LOGMNR.START_LOGMNR(- OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG + - DBMS_LOGMNR.COMMITTED_DATA_ONLY + - DBMS_LOGMNR.PRINT_PRETTY_SQL);
DBMS_LOGMNR.PRINT_PRETTY_SQL
オプションは、再構築されたSQLの書式のみを変更するため、目視用のレポートを生成する場合に有効です。 -
SQL_REDO
文に対するV$LOGMNR_CONTENTS
ビューを問い合せます。SELECT username AS USR, (XIDUSN || '.' || XIDSLT || '.' || XIDSQN) AS XID, SQL_REDO FROM V$LOGMNR_CONTENTS; USR XID SQL_REDO ---- --------- ----------------------------------------------------- OE 1.1.1484 set transaction read write; OE 1.1.1484 update "OE"."PRODUCT_INFORMATION" set "WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00') where "PRODUCT_ID" = '1799' and "WARRANTY_PERIOD" = TO_YMINTERVAL('+01-00') and ROWID = 'AAAHTKAABAAAY9mAAB'; OE 1.1.1484 update "OE"."PRODUCT_INFORMATION" set "WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00') where "PRODUCT_ID" = '1801' and "WARRANTY_PERIOD" = TO_YMINTERVAL('+01-00') and ROWID = 'AAAHTKAABAAAY9mAAC'; OE 1.1.1484 commit; HR 1.11.1476 set transaction read write; HR 1.11.1476 insert into "HR"."EMPLOYEES" values "EMPLOYEE_ID" = 306, "FIRST_NAME" = 'Nandini', "LAST_NAME" = 'Shastry', "EMAIL" = 'NSHASTRY', "PHONE_NUMBER" = '1234567890', "HIRE_DATE" = TO_DATE('10-jan-2012 13:34:43', 'dd-mon-yyyy hh24:mi:ss', "JOB_ID" = 'HR_REP', "SALARY" = 120000, "COMMISSION_PCT" = .05, "MANAGER_ID" = 105, "DEPARTMENT_ID" = 10; HR 1.11.1476 insert into "HR"."EMPLOYEES" values "EMPLOYEE_ID" = 307, "FIRST_NAME" = 'John', "LAST_NAME" = 'Silver', "EMAIL" = 'JSILVER', "PHONE_NUMBER" = '5551112222', "HIRE_DATE" = TO_DATE('10-jan-2012 13:41:03', 'dd-mon-yyyy hh24:mi:ss'), "JOB_ID" = 'SH_CLERK', "SALARY" = 110000, "COMMISSION_PCT" = .05, "MANAGER_ID" = 105, "DEPARTMENT_ID" = 50; HR 1.11.1476 commit;
-
再構築された
SQL_UNDO
文に対するV$LOGMNR_CONTENTS
ビューを問い合せます。SELECT username AS USR, (XIDUSN || '.' || XIDSLT || '.' || XIDSQN) AS XID, SQL_UNDO FROM V$LOGMNR_CONTENTS; USR XID SQL_UNDO ---- --------- ----------------------------------------------------- OE 1.1.1484 set transaction read write; OE 1.1.1484 update "OE"."PRODUCT_INFORMATION" set "WARRANTY_PERIOD" = TO_YMINTERVAL('+01-00') where "PRODUCT_ID" = '1799' and "WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00') and ROWID = 'AAAHTKAABAAAY9mAAB'; OE 1.1.1484 update "OE"."PRODUCT_INFORMATION" set "WARRANTY_PERIOD" = TO_YMINTERVAL('+01-00') where "PRODUCT_ID" = '1801' and "WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00') and ROWID = 'AAAHTKAABAAAY9mAAC'; OE 1.1.1484 commit; HR 1.11.1476 set transaction read write; HR 1.11.1476 delete from "HR"."EMPLOYEES" where "EMPLOYEE_ID" = 306 and "FIRST_NAME" = 'Nandini' and "LAST_NAME" = 'Shastry' and "EMAIL" = 'NSHASTRY' and "PHONE_NUMBER" = '1234567890' and "HIRE_DATE" = TO_DATE('10-jan-2012 13:34:43', 'dd-mon-yyyy hh24:mi:ss') and "JOB_ID" = 'HR_REP' and "SALARY" = 120000 and "COMMISSION_PCT" = .05 and "MANAGER_ID" = 105 and "DEPARTMENT_ID" = 10 and ROWID = 'AAAHSkAABAAAY6rAAO'; HR 1.11.1476 delete from "HR"."EMPLOYEES" where "EMPLOYEE_ID" = 307 and "FIRST_NAME" = 'John' and "LAST_NAME" = 'Silver' and "EMAIL" = 'JSILVER' and "PHONE_NUMBER" = '555122122' and "HIRE_DATE" = TO_DATE('10-jan-2012 13:41:03', 'dd-mon-yyyy hh24:mi:ss') and "JOB_ID" = 'SH_CLERK' and "SALARY" = 110000 and "COMMISSION_PCT" = .05 and "MANAGER_ID" = 105 and "DEPARTMENT_ID" = 50 and ROWID = 'AAAHSkAABAAAY6rAAP'; HR 1.11.1476 commit;
-
LogMinerセッションを終了します。
EXECUTE DBMS_LOGMNR.END_LOGMNR();
25.14.1.4 例4: REDOログ・ファイル内のLogMinerディクショナリの使用
REDOログ・ファイルに抽出されたディクショナリを使用する方法を学習します。
オンライン・カタログ内のディクショナリを使用する場合は、オンライン・カタログを生成したデータベースと同じデータベース内のREDOログ・ファイルをマイニングする必要があります。REDOログ・ファイルに含まれているディクショナリを使用すると、別のデータベース内のREDOログ・ファイルをマイニングできます。
オンライン・カタログ内のディクショナリを使用する場合は、オンライン・カタログを生成したデータベースと同じデータベース内のREDOログ・ファイルをマイニングする必要があります。REDOログ・ファイルに含まれているディクショナリを使用すると、別のデータベース内のREDOログ・ファイルをマイニングできます。
-
データベースによって最後にアーカイブされたREDOログ・ファイルを判別します。
SELECT NAME, SEQUENCE# FROM V$ARCHIVED_LOG WHERE FIRST_TIME = (SELECT MAX(FIRST_TIME) FROM V$ARCHIVED_LOG); NAME SEQUENCE# -------------------------------------------- -------------- /usr/oracle/data/db1arch_1_210_482701534.dbf 210
-
ディクショナリは、複数のREDOログ・ファイルに含まれている場合があります。したがって、ディクショナリの先頭と終わりが含まれているREDOログ・ファイルを判別する必要があります。次の手順を実行して、
V$ARCHIVED_LOG
ビューを問い合せます。-
ディクショナリ抽出の終わりが含まれているREDOログ・ファイルを検索します。このREDOログ・ファイルは、分析するREDOログ・ファイルより前に作成されている必要がありますが、できるかぎり新しいものを使用します。
SELECT NAME, SEQUENCE#, DICTIONARY_BEGIN d_beg, DICTIONARY_END d_end FROM V$ARCHIVED_LOG WHERE SEQUENCE# = (SELECT MAX (SEQUENCE#) FROM V$ARCHIVED_LOG WHERE DICTIONARY_END = 'YES' and SEQUENCE# <= 210); NAME SEQUENCE# D_BEG D_END -------------------------------------------- ---------- ----- ------ /usr/oracle/data/db1arch_1_208_482701534.dbf 208 NO YES
-
データ・ディクショナリ抽出の先頭(前のステップで検出されたディクショナリの終わりに対応)が含まれているREDOログ・ファイルを検索します。
SELECT NAME, SEQUENCE#, DICTIONARY_BEGIN d_beg, DICTIONARY_END d_end FROM V$ARCHIVED_LOG WHERE SEQUENCE# = (SELECT MAX (SEQUENCE#) FROM V$ARCHIVED_LOG WHERE DICTIONARY_BEGIN = 'YES' and SEQUENCE# <= 208); NAME SEQUENCE# D_BEG D_END -------------------------------------------- ---------- ----- ------ /usr/oracle/data/db1arch_1_207_482701534.dbf 207 YES NO
-
分析するREDOログ・ファイルのリストを指定します。ディクショナリの先頭と終わりが含まれているREDOログ・ファイル、および分析するREDOログ・ファイルを追加します。REDOログ・ファイルは任意の順序で追加できます。
EXECUTE DBMS_LOGMNR.ADD_LOGFILE(- LOGFILENAME => '/usr/oracle/data/db1arch_1_210_482701534.dbf', - OPTIONS => DBMS_LOGMNR.NEW); EXECUTE DBMS_LOGMNR.ADD_LOGFILE(- LOGFILENAME => '/usr/oracle/data/db1arch_1_208_482701534.dbf'); EXECUTE DBMS_LOGMNR.ADD_LOGFILE(- LOGFILENAME => '/usr/oracle/data/db1arch_1_207_482701534.dbf');
-
V$LOGMNR_LOGS
ビューを問い合せて、分析するREDOログ・ファイルのリストをタイムスタンプとともに表示します。出力では、LogMinerによって欠落しているREDOログ・ファイルに指摘フラグが付けられています。正常に機能するために欠落しているREDOログ・ファイルが必要なオプションを指定していない場合は、LogMinerでマイニングを続行できます。
-
-
使用するディクショナリおよび
COMMITTED_DATA_ONLY
オプションとPRINT_PRETTY_SQL
オプションを指定して、LogMinerを起動します。EXECUTE DBMS_LOGMNR.START_LOGMNR(- OPTIONS => DBMS_LOGMNR.DICT_FROM_REDO_LOGS + - DBMS_LOGMNR.COMMITTED_DATA_ONLY + - DBMS_LOGMNR.PRINT_PRETTY_SQL);
-
V$LOGMNR_CONTENTS
ビューを問い合せます。問合せによって返される行数を減らすには、
SYS
スキーマまたはSYSTEM
スキーマで実行されたすべてのDML文を問合せから除外します。(この問合せでは、ディクショナリ抽出に関連したトランザクションを除外するタイムスタンプを指定します。)出力には3つのトランザクションが表示されます。2つのDDLトランザクションと1つのDMLトランザクションです。DDLトランザクション1.2.1594は表
oe.product_tracking
を作成し、1.18.1602は表oe.product_information
でトリガーを作成します。いずれのトランザクションでも、システム表(SYS
によって所有される表)に対して実行されたDML文は、問合せ条件に基づいてフィルタ処理で除外されます。DMLトランザクション1.9.1598は、
oe.product_information
表を更新します。このトランザクションの更新操作は完全に変換されます。ただし、問合せの出力には、変換されない再構築されたSQL文も含まれます。これらの文は、データ・ディクショナリがREDOログ・ファイルに抽出された後で作成されたoe.product_tracking
表で実行された可能性があります。(次に示す例は、すべてのSQL文が完全に変換されるように、
DDL_DICT_TRACKING
を使用したLogMinerの実行例です。バイナリ・データは返されていません。)SELECT USERNAME AS usr, SQL_REDO FROM V$LOGMNR_CONTENTS WHERE SEG_OWNER IS NULL OR SEG_OWNER NOT IN ('SYS', 'SYSTEM') AND TIMESTAMP > '10-jan-2012 15:59:53'; USR XID SQL_REDO --- -------- ----------------------------------- SYS 1.2.1594 set transaction read write; SYS 1.2.1594 create table oe.product_tracking (product_id number not null, modified_time date, old_list_price number(8,2), old_warranty_period interval year(2) to month); SYS 1.2.1594 commit; SYS 1.18.1602 set transaction read write; SYS 1.18.1602 create or replace trigger oe.product_tracking_trigger before update on oe.product_information for each row when (new.list_price <> old.list_price or new.warranty_period <> old.warranty_period) declare begin insert into oe.product_tracking values (:old.product_id, sysdate, :old.list_price, :old.warranty_period); end; SYS 1.18.1602 commit; OE 1.9.1598 update "OE"."PRODUCT_INFORMATION" set "WARRANTY_PERIOD" = TO_YMINTERVAL('+08-00'), "LIST_PRICE" = 100 where "PRODUCT_ID" = 1729 and "WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00') and "LIST_PRICE" = 80 and ROWID = 'AAAHTKAABAAAY9yAAA'; OE 1.9.1598 insert into "UNKNOWN"."OBJ# 33415" values "COL 1" = HEXTORAW('c2121e'), "COL 2" = HEXTORAW('7867010d110804'), "COL 3" = HEXTORAW('c151'), "COL 4" = HEXTORAW('800000053c'); OE 1.9.1598 update "OE"."PRODUCT_INFORMATION" set "WARRANTY_PERIOD" = TO_YMINTERVAL('+08-00'), "LIST_PRICE" = 92 where "PRODUCT_ID" = 2340 and "WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00') and "LIST_PRICE" = 72 and ROWID = 'AAAHTKAABAAAY9zAAA'; OE 1.9.1598 insert into "UNKNOWN"."OBJ# 33415" values "COL 1" = HEXTORAW('c21829'), "COL 2" = HEXTORAW('7867010d110808'), "COL 3" = HEXTORAW('c149'), "COL 4" = HEXTORAW('800000053c'); OE 1.9.1598 commit;
-
必要に応じて、追加の問合せを発行します。
CREATE TABLE
DDL文の一部として実行されたすべてのDML文を表示します。この中には、ユーザーによって実行された文、Oracleによって内部的に実行された文などが含まれます。ノート:
ここで示すような問合せによって、表示された文を再適用する場合は、DDL文のみを再適用します。Oracleによって内部的に実行されたDML文は再適用しないでください。データベースを破損する危険性があります。次の出力では、再適用操作で使用する文は
CREATE TABLE OE.PRODUCT_TRACKING
文のみです。SELECT SQL_REDO FROM V$LOGMNR_CONTENTS WHERE XIDUSN = 1 and XIDSLT = 2 and XIDSQN = 1594; SQL_REDO -------------------------------------------------------------------------------- set transaction read write; insert into "SYS"."OBJ$" values "OBJ#" = 33415, "DATAOBJ#" = 33415, "OWNER#" = 37, "NAME" = 'PRODUCT_TRACKING', "NAMESPACE" = 1, "SUBNAME" IS NULL, "TYPE#" = 2, "CTIME" = TO_DATE('13-jan-2012 14:01:03', 'dd-mon-yyyy hh24:mi:ss'), "MTIME" = TO_DATE('13-jan-2012 14:01:03', 'dd-mon-yyyy hh24:mi:ss'), "STIME" = TO_DATE('13-jan-2012 14:01:03', 'dd-mon-yyyy hh24:mi:ss'), "STATUS" = 1, "REMOTEOWNER" IS NULL, "LINKNAME" IS NULL, "FLAGS" = 0, "OID$" IS NULL, "SPARE1" = 6, "SPARE2" = 1, "SPARE3" IS NULL, "SPARE4" IS NULL, "SPARE5" IS NULL, "SPARE6" IS NULL; insert into "SYS"."TAB$" values "OBJ#" = 33415, "DATAOBJ#" = 33415, "TS#" = 0, "FILE#" = 1, "BLOCK#" = 121034, "BOBJ#" IS NULL, "TAB#" IS NULL, "COLS" = 5, "CLUCOLS" IS NULL, "PCTFREE$" = 10, "PCTUSED$" = 40, "INITRANS" = 1, "MAXTRANS" = 255, "FLAGS" = 1, "AUDIT$" = '--------------------------------------', "ROWCNT" IS NULL, "BLKCNT" IS NULL, "EMPCNT" IS NULL, "AVGSPC" IS NULL, "CHNCNT" IS NULL, "AVGRLN" IS NULL, "AVGSPC_FLB" IS NULL, "FLBCNT" IS NULL, "ANALYZETIME" IS NULL, "SAMPLESIZE" IS NULL, "DEGREE" IS NULL, "INSTANCES" IS NULL, "INTCOLS" = 5, "KERNELCOLS" = 5, "PROPERTY" = 536870912, "TRIGFLAG" = 0, "SPARE1" = 178, "SPARE2" IS NULL, "SPARE3" IS NULL, "SPARE4" IS NULL, "SPARE5" IS NULL, "SPARE6" = TO_DATE('13-jan-2012 14:01:05', 'dd-mon-yyyy hh24:mi:ss'), insert into "SYS"."COL$" values "OBJ#" = 33415, "COL#" = 1, "SEGCOL#" = 1, "SEGCOLLENGTH" = 22, "OFFSET" = 0, "NAME" = 'PRODUCT_ID', "TYPE#" = 2, "LENGTH" = 22, "FIXEDSTORAGE" = 0, "PRECISION#" IS NULL, "SCALE" IS NULL, "NULL$" = 1, "DEFLENGTH" IS NULL, "SPARE6" IS NULL, "INTCOL#" = 1, "PROPERTY" = 0, "CHARSETID" = 0, "CHARSETFORM" = 0, "SPARE1" = 0, "SPARE2" = 0, "SPARE3" = 0, "SPARE4" IS NULL, "SPARE5" IS NULL, "DEFAULT$" IS NULL; insert into "SYS"."COL$" values "OBJ#" = 33415, "COL#" = 2, "SEGCOL#" = 2, "SEGCOLLENGTH" = 7, "OFFSET" = 0, "NAME" = 'MODIFIED_TIME', "TYPE#" = 12, "LENGTH" = 7, "FIXEDSTORAGE" = 0, "PRECISION#" IS NULL, "SCALE" IS NULL, "NULL$" = 0, "DEFLENGTH" IS NULL, "SPARE6" IS NULL, "INTCOL#" = 2, "PROPERTY" = 0, "CHARSETID" = 0, "CHARSETFORM" = 0, "SPARE1" = 0, "SPARE2" = 0, "SPARE3" = 0, "SPARE4" IS NULL, "SPARE5" IS NULL, "DEFAULT$" IS NULL; insert into "SYS"."COL$" values "OBJ#" = 33415, "COL#" = 3, "SEGCOL#" = 3, "SEGCOLLENGTH" = 22, "OFFSET" = 0, "NAME" = 'OLD_LIST_PRICE', "TYPE#" = 2, "LENGTH" = 22, "FIXEDSTORAGE" = 0, "PRECISION#" = 8, "SCALE" = 2, "NULL$" = 0, "DEFLENGTH" IS NULL, "SPARE6" IS NULL, "INTCOL#" = 3, "PROPERTY" = 0, "CHARSETID" = 0, "CHARSETFORM" = 0, "SPARE1" = 0, "SPARE2" = 0, "SPARE3" = 0, "SPARE4" IS NULL, "SPARE5" IS NULL, "DEFAULT$" IS NULL; insert into "SYS"."COL$" values "OBJ#" = 33415, "COL#" = 4, "SEGCOL#" = 4, "SEGCOLLENGTH" = 5, "OFFSET" = 0, "NAME" = 'OLD_WARRANTY_PERIOD', "TYPE#" = 182, "LENGTH" = 5, "FIXEDSTORAGE" = 0, "PRECISION#" = 2, "SCALE" = 0, "NULL$" = 0, "DEFLENGTH" IS NULL, "SPARE6" IS NULL, "INTCOL#" = 4, "PROPERTY" = 0, "CHARSETID" = 0, "CHARSETFORM" = 0, "SPARE1" = 0, "SPARE2" = 2, "SPARE3" = 0, "SPARE4" IS NULL, "SPARE5" IS NULL, "DEFAULT$" IS NULL; insert into "SYS"."CCOL$" values "OBJ#" = 33415, "CON#" = 2090, "COL#" = 1, "POS#" IS NULL, "INTCOL#" = 1, "SPARE1" = 0, "SPARE2" IS NULL, "SPARE3" IS NULL, "SPARE4" IS NULL, "SPARE5" IS NULL, "SPARE6" IS NULL; insert into "SYS"."CDEF$" values "OBJ#" = 33415, "CON#" = 2090, "COLS" = 1, "TYPE#" = 7, "ROBJ#" IS NULL, "RCON#" IS NULL, "RRULES" IS NULL, "MATCH#" IS NULL, "REFACT" IS NULL, "ENABLED" = 1, "CONDLENGTH" = 24, "SPARE6" IS NULL, "INTCOLS" = 1, "MTIME" = TO_DATE('13-jan-2012 14:01:08', 'dd-mon-yyyy hh24:mi:ss'), "DEFER" = 12, "SPARE1" = 6, "SPARE2" IS NULL, "SPARE3" IS NULL, "SPARE4" IS NULL, "SPARE5" IS NULL, "CONDITION" = '"PRODUCT_ID" IS NOT NULL'; create table oe.product_tracking (product_id number not null, modified_time date, old_product_description varchar2(2000), old_list_price number(8,2), old_warranty_period interval year(2) to month); update "SYS"."SEG$" set "TYPE#" = 5, "BLOCKS" = 5, "EXTENTS" = 1, "INIEXTS" = 5, "MINEXTS" = 1, "MAXEXTS" = 121, "EXTSIZE" = 5, "EXTPCT" = 50, "USER#" = 37, "LISTS" = 0, "GROUPS" = 0, "CACHEHINT" = 0, "HWMINCR" = 33415, "SPARE1" = 1024 where "TS#" = 0 and "FILE#" = 1 and "BLOCK#" = 121034 and "TYPE#" = 3 and "BLOCKS" = 5 and "EXTENTS" = 1 and "INIEXTS" = 5 and "MINEXTS" = 1 and "MAXEXTS" = 121 and "EXTSIZE" = 5 and "EXTPCT" = 50 and "USER#" = 37 and "LISTS" = 0 and "GROUPS" = 0 and "BITMAPRANGES" = 0 and "CACHEHINT" = 0 and "SCANHINT" = 0 and "HWMINCR" = 33415 and "SPARE1" = 1024 and "SPARE2" IS NULL and ROWID = 'AAAAAIAABAAAdMOAAB'; insert into "SYS"."CON$" values "OWNER#" = 37, "NAME" = 'SYS_C002090', "CON#" = 2090, "SPARE1" IS NULL, "SPARE2" IS NULL, "SPARE3" IS NULL, "SPARE4" IS NULL, "SPARE5" IS NULL, "SPARE6" IS NULL; commit;
-
LogMinerセッションを終了します。
EXECUTE DBMS_LOGMNR.END_LOGMNR();
25.14.1.5 例5: 内部ディクショナリでのDDL文の追跡
DBMS_LOGMNR.DDL_DICT_TRACKING
オプションを使用して、REDOログ・ファイルで発生したDDL文でLogMinerの内部ディクショナリを更新する方法を学習します。
-
データベースによって最後にアーカイブされたREDOログ・ファイルを判別します。
SELECT NAME, SEQUENCE# FROM V$ARCHIVED_LOG WHERE FIRST_TIME = (SELECT MAX(FIRST_TIME) FROM V$ARCHIVED_LOG); NAME SEQUENCE# -------------------------------------------- -------------- /usr/oracle/data/db1arch_1_210_482701534.dbf 210
-
ディクショナリは複数のREDOログ・ファイルに含まれている場合があるため、データ・ディクショナリの先頭と終わりが含まれているREDOログ・ファイルを判別します。これを行うには、次のとおり
V$ARCHIVED_LOG
ビューを問い合せます。-
データ・ディクショナリ抽出の終わりが含まれているREDOログを検索します。このREDOログ・ファイルは、分析するREDOログ・ファイルより前に作成されている必要がありますが、できるかぎり新しいものを使用します。
SELECT NAME, SEQUENCE#, DICTIONARY_BEGIN d_beg, DICTIONARY_END d_end FROM V$ARCHIVED_LOG WHERE SEQUENCE# = (SELECT MAX (SEQUENCE#) FROM V$ARCHIVED_LOG WHERE DICTIONARY_END = 'YES' and SEQUENCE# < 210); NAME SEQUENCE# D_BEG D_END -------------------------------------------- ---------- ----- ------ /usr/oracle/data/db1arch_1_208_482701534.dbf 208 NO YES
-
データ・ディクショナリ抽出の先頭(前のSQL文で検出されたディクショナリの終わりに対応)が含まれている、REDOログ・ファイルを検索します。
SELECT NAME, SEQUENCE#, DICTIONARY_BEGIN d_beg, DICTIONARY_END d_end FROM V$ARCHIVED_LOG WHERE SEQUENCE# = (SELECT MAX (SEQUENCE#) FROM V$ARCHIVED_LOG WHERE DICTIONARY_BEGIN = 'YES' and SEQUENCE# <= 208); NAME SEQUENCE# D_BEG D_END -------------------------------------------- ---------- ----- ------ /usr/oracle/data/db1arch_1_208_482701534.dbf 207 YES NO
-
-
REDOログ・ファイルの完全なリストがあることを確認します。
REDOログ・ファイルで検出されたDDL文を正しく適用するために、マイニングするREDOログ・ファイルのリストにすべてのファイルが含まれていることを確認します。順序番号209に対応する欠落ログ・ファイルが、このリストに含まれている必要があります。次の問合せを発行して、リストに追加する必要があるREDOログ・ファイルの名前を判別します。
SELECT NAME FROM V$ARCHIVED_LOG WHERE SEQUENCE# >= 207 AND SEQUENCE# <= 210 ORDER BY SEQUENCE# ASC; NAME -------------------------------------------- /usr/oracle/data/db1arch_1_207_482701534.dbf /usr/oracle/data/db1arch_1_208_482701534.dbf /usr/oracle/data/db1arch_1_209_482701534.dbf /usr/oracle/data/db1arch_1_210_482701534.dbf
-
分析するREDOログ・ファイルのリストを指定します。
ディクショナリの先頭と終わりが含まれているREDOログ・ファイル、マイニングするREDOログ・ファイル、および差異のないリストを作成するために必要なすべてのREDOログ・ファイルを含めます。REDOログ・ファイルは任意の順序で追加できます。
EXECUTE DBMS_LOGMNR.ADD_LOGFILE(- LOGFILENAME => '/usr/oracle/data/db1arch_1_210_482701534.dbf', -
OPTIONS => DBMS_LOGMNR.NEW);
EXECUTE DBMS_LOGMNR.ADD_LOGFILE(- LOGFILENAME => '/usr/oracle/data/db1arch_1_209_482701534.dbf'); EXECUTE DBMS_LOGMNR.ADD_LOGFILE(- LOGFILENAME => '/usr/oracle/data/db1arch_1_208_482701534.dbf'); EXECUTE DBMS_LOGMNR.ADD_LOGFILE(- LOGFILENAME => '/usr/oracle/data/db1arch_1_207_482701534.dbf');
-
使用するディクショナリおよび
DDL_DICT_TRACKING
、COMMITTED_DATA_ONLY
、PRINT_PRETTY_SQL
の各オプションを指定して、LogMinerを起動します。EXECUTE DBMS_LOGMNR.START_LOGMNR(- OPTIONS => DBMS_LOGMNR.DICT_FROM_REDO_LOGS + - DBMS_LOGMNR.DDL_DICT_TRACKING + - DBMS_LOGMNR.COMMITTED_DATA_ONLY + - DBMS_LOGMNR.PRINT_PRETTY_SQL);
-
V$LOGMNR_CONTENTS
ビューを問い合せます。返される行数を減らすため、
SYS
スキーマまたはSYSTEM
スキーマで実行されたすべてのDML文を問合せから除外します。(この問合せでは、ディクショナリ抽出に関連したトランザクションを除外するタイムスタンプを指定します。)この問合せは、正常に変換されたすべての再構築SQL文、およびトリガーを実行したため
oe.product_tracking
表に対して実行されたすべての挿入操作を返します。SELECT USERNAME AS usr,(XIDUSN || '.' || XIDSLT || '.' || XIDSQN) as XID, SQL_REDO FROM V$LOGMNR_CONTENTS WHERE SEG_OWNER IS NULL OR SEG_OWNER NOT IN ('SYS', 'SYSTEM') AND TIMESTAMP > '10-jan-2012 15:59:53'; USR XID SQL_REDO ----------- -------- ----------------------------------- SYS 1.2.1594 set transaction read write; SYS 1.2.1594 create table oe.product_tracking (product_id number not null, modified_time date, old_list_price number(8,2), old_warranty_period interval year(2) to month); SYS 1.2.1594 commit; SYS 1.18.1602 set transaction read write; SYS 1.18.1602 create or replace trigger oe.product_tracking_trigger before update on oe.product_information for each row when (new.list_price <> old.list_price or new.warranty_period <> old.warranty_period) declare begin insert into oe.product_tracking values (:old.product_id, sysdate, :old.list_price, :old.warranty_period); end; SYS 1.18.1602 commit; OE 1.9.1598 update "OE"."PRODUCT_INFORMATION" set "WARRANTY_PERIOD" = TO_YMINTERVAL('+08-00'), "LIST_PRICE" = 100 where "PRODUCT_ID" = 1729 and "WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00') and "LIST_PRICE" = 80 and ROWID = 'AAAHTKAABAAAY9yAAA'; OE 1.9.1598 insert into "OE"."PRODUCT_TRACKING" values "PRODUCT_ID" = 1729, "MODIFIED_TIME" = TO_DATE('13-jan-2012 16:07:03', 'dd-mon-yyyy hh24:mi:ss'), "OLD_LIST_PRICE" = 80, "OLD_WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00'); OE 1.9.1598 update "OE"."PRODUCT_INFORMATION" set "WARRANTY_PERIOD" = TO_YMINTERVAL('+08-00'), "LIST_PRICE" = 92 where "PRODUCT_ID" = 2340 and "WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00') and "LIST_PRICE" = 72 and ROWID = 'AAAHTKAABAAAY9zAAA'; OE 1.9.1598 insert into "OE"."PRODUCT_TRACKING" values "PRODUCT_ID" = 2340, "MODIFIED_TIME" = TO_DATE('13-jan-2012 16:07:07', 'dd-mon-yyyy hh24:mi:ss'), "OLD_LIST_PRICE" = 72, "OLD_WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00'); OE 1.9.1598 commit;
-
LogMinerセッションを終了します。
EXECUTE DBMS_LOGMNR.END_LOGMNR();
25.14.1.6 例6: 時間範囲による出力のフィルタ処理
時間ごとに一連のREDOログをフィルタするには、時間範囲を指定してログ・ファイルを返す様々な方法について学習してください。
例4と例5では、問合せにタイムスタンプ・ベースの述語(timestamp > '10-jan-2012 15:59:53'
)を指定して行をフィルタする方法を確認しました。ただし、タイムスタンプ値に基づいてREDOレコードを除外するには、この例で示すとおり、DBMS_LOGMNR.START_LOGMNR
プロシージャ・コールで時間範囲を指定する方法がより効率的です。
-
マイニングするREDOログ・ファイルのリストを作成します。
指定した時刻以降に生成されたREDOログ・ファイルをマイニングするとします。次のプロシージャは、指定した時刻に基づいてREDOログ・ファイルのリストを作成します。その後のSQL
EXECUTE
文は、プロシージャをコールし、開始時刻を2012年1月13日の午後2時に指定します。-- -- my_add_logfiles -- Add all archived logs generated after a specified start_time. -- CREATE OR REPLACE PROCEDURE my_add_logfiles (in_start_time IN DATE) AS CURSOR c_log IS SELECT NAME FROM V$ARCHIVED_LOG WHERE FIRST_TIME >= in_start_time; count pls_integer := 0; my_option pls_integer := DBMS_LOGMNR.NEW; BEGIN FOR c_log_rec IN c_log LOOP DBMS_LOGMNR.ADD_LOGFILE(LOGFILENAME => c_log_rec.name, OPTIONS => my_option); my_option := DBMS_LOGMNR.ADDFILE; DBMS_OUTPUT.PUT_LINE('Added logfile ' || c_log_rec.name); END LOOP; END; / EXECUTE my_add_logfiles(in_start_time => '13-jan-2012 14:00:00');
-
Redoログ・ファイルのリストを表示するには、
V$LOGMNR_LOGS
ビューを問い合せます。この例では、出力にREDOログ・ファイルのサイズを含めます。
SELECT FILENAME name, LOW_TIME start_time, FILESIZE bytes FROM V$LOGMNR_LOGS; NAME START_TIME BYTES ----------------------------------- -------------------- ---------------- /usr/orcl/arch1_310_482932022.dbf 13-jan-2012 14:02:35 23683584 /usr/orcl/arch1_311_482932022.dbf 13-jan-2012 14:56:35 2564096 /usr/orcl/arch1_312_482932022.dbf 13-jan-2012 15:10:43 23683584 /usr/orcl/arch1_313_482932022.dbf 13-jan-2012 15:17:52 23683584 /usr/orcl/arch1_314_482932022.dbf 13-jan-2012 15:23:10 23683584 /usr/orcl/arch1_315_482932022.dbf 13-jan-2012 15:43:22 23683584 /usr/orcl/arch1_316_482932022.dbf 13-jan-2012 16:03:10 23683584 /usr/orcl/arch1_317_482932022.dbf 13-jan-2012 16:33:43 23683584 /usr/orcl/arch1_318_482932022.dbf 13-jan-2012 17:23:10 23683584
-
REDOログ・ファイルのリストを調整します。
午後3時から4時の間に生成されたREDOログ・ファイルのみをマイニングする必要があるとします。
問合せ条件(
timestamp > '13-jan-2012 15:00:00' and timestamp < '13-jan-2012 16:00:00'
)を使用してこれを行います。ただし、問合せ条件はLogMinerによって返される各行で評価されるため、問合せ条件に基づく行のフィルタ処理は、内部マイニング・エンジンでは行われません。したがって、REDOログ・ファイルarch1_311_482932022.dbf
からarch1_315_482932022.dbf
までの行のみを取得する場合でも、この問合せでは、LogMinerセッションに登録されたすべてのREDOログ・ファイルがマイニングされます。また、問合せ条件を使用し、分析する時間範囲外のREDOログ・ファイルを手動で削除することもできますが、最も簡単な解決法は、
DBMS_LOGMNR.START_LOGMNR
プロシージャ・コールで分析する時間範囲を指定する方法です。この方法では、REDOログ・ファイルのリストは変更されませんが、指定した時間範囲内のREDOログ・ファイルのみがLogMinerによってマイニングされます。
EXECUTE DBMS_LOGMNR.START_LOGMNR(- STARTTIME => '13-jan-2012 15:00:00', - ENDTIME => '13-jan-2012 16:00:00', - OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG + - DBMS_LOGMNR.COMMITTED_DATA_ONLY + - DBMS_LOGMNR.PRINT_PRETTY_SQL);
-
V$LOGMNR_CONTENTS
ビューを問い合せます。SELECT TIMESTAMP, (XIDUSN || '.' || XIDSLT || '.' || XIDSQN) AS XID,
SQL_REDO FROM V$LOGMNR_CONTENTS WHERE SEG_OWNER = 'OE'; TIMESTAMP XID SQL_REDO --------------------- ----------- -------------------------------- 13-jan-2012 15:29:31 1.17.2376 update "OE"."PRODUCT_INFORMATION" set "WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00') where "PRODUCT_ID" = 3399 and "WARRANTY_PERIOD" = TO_YMINTERVAL('+02-00') and ROWID = 'AAAHTKAABAAAY9TAAE'; 13-jan-2012 15:29:34 1.17.2376 insert into "OE"."PRODUCT_TRACKING" values "PRODUCT_ID" = 3399, "MODIFIED_TIME" = TO_DATE('13-jan-2012 15:29:34', 'dd-mon-yyyy hh24:mi:ss'), "OLD_LIST_PRICE" = 815, "OLD_WARRANTY_PERIOD" = TO_YMINTERVAL('+02-00'); 13-jan-2012 15:52:43 1.15.1756 update "OE"."PRODUCT_INFORMATION" set "WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00') where "PRODUCT_ID" = 1768 and "WARRANTY_PERIOD" = TO_YMINTERVAL('+02-00') and ROWID = 'AAAHTKAABAAAY9UAAB'; 13-jan-2012 15:52:43 1.15.1756 insert into "OE"."PRODUCT_TRACKING" values "PRODUCT_ID" = 1768, "MODIFIED_TIME" = TO_DATE('13-jan-2012 16:52:43', 'dd-mon-yyyy hh24:mi:ss'), "OLD_LIST_PRICE" = 715, "OLD_WARRANTY_PERIOD" = TO_YMINTERVAL('+02-00');
-
LogMinerセッションを終了します。
EXECUTE DBMS_LOGMNR.END_LOGMNR();
25.14.2 LogMinerのユース・ケースのシナリオ
LogMinerを使用してデータ・マイニング・タスクを実行する方法の一般的な例を確認してください。
- LogMinerを使用した特定のユーザーによる変更の追跡
LogMinerを使用して、単一ユーザーによる特定の時間範囲内にデータベースに対して行われたすべての変更を識別する方法について説明します。 - LogMinerを使用した表アクセス統計の計算
LogMinerを使用して指定の時間範囲にわたる表アクセス統計を計算する方法について説明します。
親トピック: LogMinerの使用例
25.14.2.1 LogMinerを使用した特定のユーザーによる変更の追跡
LogMinerを使用して、単一のユーザーによって特定の時間範囲内にデータベースに対して行われたすべての変更を特定する方法を学習します。
ユーザーjoedevo
が特定の時間範囲内にデータベースに加えたすべての変更を確認するとします。このタスクを実行するには、LogMinerを使用できます。
- データベースへの接続。
-
LogMinerディクショナリ・ファイルを作成します。
LogMinerを使用して
joedevo
のデータを分析するには、joedevo
が使用する表に対して表定義の変更が行われる前にLogMinerディクショナリ・ファイルを作成するか、LogMinerの起動時にオンライン・カタログを使用する必要があります。この例では、REDOログ・ファイルに抽出されたLogMinerディクショナリを使用します。 -
REDOログ・ファイルを追加します。
joedevo
がデータベースに対して変更を行ったとします。分析するREDOログ・ファイルの名前は、次のように指定できます。EXECUTE DBMS_LOGMNR.ADD_LOGFILE( - LOGFILENAME => 'log1orc1.ora', - OPTIONS => DBMS_LOGMNR.NEW);
必要に応じて、次のようにREDOログ・ファイルを追加します。
EXECUTE DBMS_LOGMNR.ADD_LOGFILE( - LOGFILENAME => 'log2orc1.ora', - OPTIONS => DBMS_LOGMNR.ADDFILE);
-
LogMinerを起動し、検索を指定した時間範囲に制限します。
EXECUTE DBMS_LOGMNR.START_LOGMNR( - DICTFILENAME => 'orcldict.ora', - STARTTIME => TO_DATE('01-Jan-1998 08:30:00','DD-MON-YYYY HH:MI:SS'), - ENDTIME => TO_DATE('01-Jan-1998 08:45:00', 'DD-MON-YYYY HH:MI:SS'));
-
V$LOGMNR_CONTENTS
ビューを問い合せます。この時点で、
V$LOGMNR_CONTENTS
ビューを問い合せることが可能です。ユーザーjoedevo
がsalary
表に対して行ったすべての変更を検索します。次のSELECT
文を実行します。SELECT SQL_REDO, SQL_UNDO FROM V$LOGMNR_CONTENTS WHERE USERNAME = 'joedevo' AND SEG_NAME = 'salary';
SQL_REDO
列とSQL_UNDO
列の両方に対して、2つの行が返されます(データ表示の書式は画面では異なる場合があります)。ユーザーjoedevo
が2つの操作を要求したことがわかります。このユーザーは、古い給与を削除した後、新しい昇給後の給与を挿入しました。これらは、この操作を元に戻すために必要なデータです。SQL_REDO SQL_UNDO -------- -------- delete from SALARY insert into SALARY(NAME, EMPNO, SAL) where EMPNO = 12345 values ('JOEDEVO', 12345, 500) and NAME='JOEDEVO' and SAL=500; insert into SALARY(NAME, EMPNO, SAL) delete from SALARY values('JOEDEVO',12345, 2500) where EMPNO = 12345 and NAME = 'JOEDEVO' 2 rows selected and SAL = 2500;
-
LogMinerセッションを終了します。
LogMinerセッションを正常に終了するには、
DBMS_LOGMNR.END_LOGMNR
プロシージャを使用します。DBMS_LOGMNR.END_LOGMNR( );
親トピック: LogMinerのユースケースのシナリオ
25.14.2.2 LogMinerを使用した表アクセス統計の計算
LogMinerを使用して、指定の時間範囲にわたる表アクセス統計を計算する方法を学習します。
この例では、ダイレクト・マーケティング・データベースを管理し、1月の2週間の収益でのカスタマ・コンタクトの有効性を確認するとします。この場合、すでにLogMinerディクショナリを作成し、検索するREDOログ・ファイルを追加していることを前提としています。これらのコンタクトを識別するには、次のように1月の時間範囲でログを検索します。
-
LogMinerを起動し、時間範囲を指定します。
EXECUTE DBMS_LOGMNR.START_LOGMNR( - STARTTIME => TO_DATE('07-Jan-2012 08:30:00','DD-MON-YYYY HH:MI:SS'), - ENDTIME => TO_DATE('21-Jan-2012 08:45:00','DD-MON-YYYY HH:MI:SS'), - DICTFILENAME => '/usr/local/dict.ora');
-
次の
ビューを問い合せて、次の例に示すとおり、指定した時間範囲で変更された表を判別します。(この問合せでは、フィルタ処理で除外されるのは、従来どおり名前に次のV$LOGMNR_CONTENTS
を含むシステム表です。)$
SELECT SEG_OWNER, SEG_NAME, COUNT(*) AS Hits FROM V$LOGMNR_CONTENTS WHERE SEG_NAME NOT LIKE '%$' GROUP BY SEG_OWNER, SEG_NAME ORDER BY Hits DESC;
-
次のデータが表示されます。(画面の書式は異なる場合があります。)
SEG_OWNER SEG_NAME Hits --------- -------- ---- CUST ACCOUNT 384 UNIV EXECDONOR 325 UNIV DONOR 234 UNIV MEGADONOR 32 HR EMPLOYEES 12 SYS DONOR 12
次の
列の値は、問合せで指定した2週間の間に、指定した表に対して挿入、削除、更新の操作が行われた回数を示しています。この例ではHits
表が、指定された2週間の期間中に最も修正され、cust.account
およびhr.employees
表は、同じ期間内に最も少なく変更されました。sys.donor
-
LogMinerセッションを終了します。
次の
プロシージャを使用して、LogMinerセッションを適切に終了します。DBMS_LOGMNR.END_LOGMNR
DBMS_LOGMNR.END_LOGMNR( );
親トピック: LogMinerのユースケースのシナリオ
25.15 サポートされるデータ型、記憶域属性、およびデータベースとREDOログ・ファイルのバージョン
データ型と記憶域属性のサポートに関する情報およびサポートされるデータベースとREDOログ・ファイルのリリースを説明します。
- サポートされるデータ型と表記憶域属性
サポートされるデータ型と表記憶域属性を説明します。 - LogMinerのデータベース互換性の要件
特定のデータ型および表記憶域属性に対するサポートは、Oracle Databaseのリリース互換性要件に依存します。 - サポートされないデータ型および表記憶域属性
マイニング結果から表が除外される結果を回避するには、LogMinerでサポートされないデータ型および表記憶域属性を確認します。 - サポートされるデータベースとREDOログ・ファイルのバージョン
REDOログ・ファイルを作成したOracle Databaseリリースは、そのファイルに対して実行できる操作に影響する場合があります。 - SecureFiles LOBに関する考慮点
SecureFiles LOBは、データベース互換性が11.2以上に設定されている場合にサポートされます。
親トピック: REDOログ・ファイル分析のためのLogMinerの使用
25.15.1 サポートされるデータ型と表記憶域属性
サポートされるデータ型と表記憶域属性を説明します。
データベースの互換性とデータ型のリリース変更
一部のデータ型は特定のリリースでのみサポートされていることに注意してください。
Oracle Database 12cリリース1 (12.1)以降から、VARCHAR2
、NVARCHAR2
およびRAW
データ型の最大サイズが32KBに増加しました(COMPATIBLE
初期化パラメータが12.0以上に設定され、MAX_STRING_SIZE
初期化パラメータがEXTENDED
に設定されている場合)。
サプリメンタル・ロギングの場合、LogMinerでは32KBの列がLOBとして処理されます。
32KBの列は、ALWAYS
サプリメンタル・ロギング・グループの一部にはできません。
LogMinerを使用してサポートされるデータ型
LogMinerでは、次のデータ型がサポートされています。
-
BINARY_DOUBLE
-
BINARY_FLOAT
-
BLOB
-
CHAR
-
CLOB
およびNCLOB
-
DATE
-
INTERVALYEARTOMONTH
-
INTERVALDAYTOSECOND
-
SecureFilesとして格納されるLOB (11.2以上の互換性で動作するデータベースが必要)
-
LONG
-
LONG RAW
-
NCHAR
-
NUMBER
-
NVARCHAR2
-
VARRAY
として格納されるオブジェクト -
オブジェクト(コレクションなしの単純なネストされたADT)
(
SDO_GEOMETRY
やORDIMAGE
などOracle提供の型を含む)オブジェクトがサポートされるようにするには、12.0.0.0以上のREDO互換性が設定されたOracle Database 12c リリース1 (12.1)以上が実行されている必要があります。XMLデータに関連する操作用のSQL_REDO
列の内容は、有効なSQLまたはPL/SQLではありません。 -
Oracle Text
-
RAW
-
TIMESTAMP
-
TIMESTAMP WITH TIMEZONE
-
TIMESTAMP WITH LOCAL TIMEZONE
-
VARCHAR
およびVARCHAR2
-
XDB
-
次のプライマリ・データベース互換性要件を仮定した場合は、すべてのストレージ・モデルの
XMLType
データ。-
CLOB
形式で格納されているXMLType
では、11.0以上の互換性設定でOracle Databaseを実行する必要があります。Oracle Database 12cリリース1 (12.1)から、CLOB
として保存されたXMLType
の使用は非推奨になっています。 -
オブジェクト・リレーショナル形式またはバイナリXMLとして格納される
XMLType
では、11.2.0.3以上の互換性設定および11.2.0.3以上のREDO互換性設定を使用してOracle Databaseを実行する必要があります。XMLデータに関連する操作用のSQL_REDO
列の内容は、有効なSQLまたはPL/SQLではありません。
- Oracle Autonomous Database (ADB)で使用する予定の既存のアプリケーションでは、多くのXMLスキーマ関連機能がサポートされていないことに注意してください。たとえば、XMLスキーマに関連付けられたXML記憶域は使用できません。かわりにトランスポータブル・バイナリXML記憶域を使用してください。オブジェクト・リレーショナルXML記憶域およびスキーマに基づくバイナリXML記憶域は、ADBでも使用できません。XMLTypeの制限の詳細は、『Oracle XML DB開発者ガイド』を参照してください。
-
LogMinerを使用してサポートされる表記憶域タイプ
LogMinerでは、次の表記憶域属性がサポートされます。
-
クラスタ表(索引クラスタおよびヒープ・クラスタを含む)
-
索引構成表(IOT) (オーバーフロー・セグメントを含むパーティション化および非パーティション化)
-
ヒープ構成表(パーティション化および非パーティション化)
-
高度な行圧縮および基本表圧縮。これらのオプションはいずれも、データベースの互換性設定が11.1.0以上である必要があります。
-
SecureFilesとして格納されるLOB列を含む表(Oracle Databaseの互換性が11.2以上に設定されている場合)
-
ハイブリッド列圧縮を使用する表(Oracle Databaseの互換性が11.2.0.2以上に設定されている場合)
関連トピック
25.15.2 LogMinerのデータベース互換性の要件
LogMinerによる一部のデータ型および表記憶域属性のサポートは、Oracle Databaseの互換性要件に依存します。
データ型とデータベースの互換性要件
-
マルチバイトの
CLOB
サポートには、10.1以上の互換性で動作するデータベースが必要です。 -
LOB
およびオーバーフローなしのIOTサポートには、10.1以上の互換性で動作するデータベースが必要です。 -
LOB
およびオーバーフローありのIOTサポートには、10.2以上の互換性で動作するデータベースが必要です。 -
TDEおよびTSEサポートには、11.1以上の互換性で動作するデータベースが必要です。
-
基本圧縮および高度な行圧縮では、11.1以上の互換性で動作するデータベースが必要です。
-
ハイブリッド列圧縮のサポートは、基礎となるストレージ・システムに依存し、11.2以上の互換性で動作するデータベースが必要です。
関連トピック
25.15.3 サポートされないデータ型と表記憶域属性
マイニング結果から表が除外される結果を回避するには、LogMinerでサポートされないデータ型および表記憶域属性を確認します。
LogMinerは、次のデータ型と表記憶域属性をサポートしません。これらのサポートされていないデータ型のいずれかを使用する列が表に含まれる場合、表全体がLogMinerによって無視されます。
-
BFILE
- ネストされた表
- ネストされた表のあるオブジェクト
- アイデンティティ列を含む表
- 時間的な有効性列
PKREF
列PKOID
列- ネストした表属性およびスタンドアロンのネストした表の列
25.15.4 サポートされるデータベースとREDOログ・ファイルのバージョン
REDOログ・ファイルを作成したOracle Databaseリリースは、そのファイルに対して実行できる操作に影響する場合があります。
LogMinerは、Oracle Database 8リリース8.1以上でのみ動作します。LogMinerを使用して、Oracle Database 8以上でREDOログ・ファイルを分析できます。ただし、以前のOracle Databaseリリースで作成されたREDOログ・ファイルからLogMinerが取得できる情報は、ログを使用しているOracle Databaseのリリースではなく、ログのリリース・バージョンによって異なります。たとえば、サプリメンタル・ロギングを拡張にすることにより、Oracle9iのredoログ・ファイルを強化して追加情報を取得できます。Redoログ・ファイルの強化によって、LogMiner機能を最大限に利用できるようになります。以前のリリースのOracle Databaseで作成されたREDOログ・ファイルには、以降のOracle DatabaseリリースのREDOログ・ファイルでのみ有効な情報が欠落している場合があります。この情報の欠落のため、LogMinerが以前のOracle Database REDOログ・ファイルを使用してサポートできる操作およびデータ型が制限される場合があります。
25.15.5 SecureFiles LOBに関する考慮点
SecureFiles LOBは、データベース互換性が11.2以上に設定されている場合にサポートされます。
SecureFiles LOB列には、SQL_REDO
列のみを入力できます。SQL_UNDO
列は入力されません。
透過的データ暗号化(TDE)およびデータ圧縮は、プライマリ・データベースのSecureFiles LOB列で有効化できます。
SecureFiles LOB列の重複除外は完全にサポートされます。フラグメント操作はサポートされません。
LogMinerは、サポートされない操作によって生成されたREDOを検出すると、OPERATION
列がUNSUPPORTED
に設定された行を生成します。これらのREDOレコードには、SQL_REDOまたはSQL_UNDOは生成されません。