26 REDOログ・ファイル分析のためのLogMinerの使用

LogMinerは、Oracle Databaseの一部であり、SQLインタフェースを介してオンラインおよびアーカイブのREDOログ・ファイルを問い合せることができます。

REDOログ・ファイルには、データベースでのアクティビティの履歴情報が含まれています。LogMinerはコマンドラインから使用できます。

ノート:

dbms_logmnr.start_logmnrパッケージのcontinuous_mineオプションは、Oracle Database 19c (19.1)ではサポートされなくなり、使用できなくなりました。

親トピック: その他のユーティリティ

26.1 LogMinerのメリット

ユーザー・データやデータベース・ディクショナリに対するすべての変更は、Oracle REDOログ・ファイルに記録されます。これによってデータベース・リカバリ操作が実行できます。

LogMinerには、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の使用

26.2 LogMinerの概要

DBAとしてのOracleのLogMinerツールは、PL/SQLプロシージャおよびファンクションのセットを使用して、REDOログ・ファイル内の変更されたレコードを検索するのに役立ちます。

親トピック: REDOログ・ファイル分析のためのLogMinerの使用

26.2.1 LogMiner構成

LogMinerの分析対象オブジェクトについて学習します。また、構成ファイルの例も示します。

  • LogMiner構成ファイルのオブジェクト
    DataMiner構成ファイルには、ソース・データベース、マイニング・データベース、LogMinerディクショナリおよび注目するデータを格納するREDOログ・ファイルの4つのオブジェクトがあります。
  • LogMinerの構成例
    この例では、あるOracle Databaseリリースのある場所にREDOログを生成して、そのログをリリースが異なる別のOracle Databaseの別の場所に送信する方法を示します。
  • LogMinerの要件
    LogMinerでマイニングするデータベースのソースおよびマイニング・データベース、データ・ディクショナリ、REDOログ・ファイルおよび表と列の名前制限の要件について説明します。

親トピック: LogMinerの概要

26.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の構成

26.2.1.2 LogMinerの構成例

この例では、あるOracle Databaseリリースのある場所にREDOログを生成して、そのログをリリースが異なる別のOracle Databaseの別の場所に送信する方法を示します。

次の図に、LogMinerの構成例を示します。この図では、ソース・データベースがボストンにあり、ターゲット・データベースがサンフランシスコにあります。

ボストンにあるソース・データベースでREDOログ・ファイルが生成され、アーカイブ後にサンフランシスコにあるデータベースに送られます。LogMinerディクショナリは、これらのREDOログ・ファイルに対して抽出されます。LogMinerが実際にREDOログ・ファイルを分析するマイニング・データベースは、サンフランシスコにあります。ボストンのデータベースでOracle Database 12gが実行され、サンフランシスコのデータベースでOracle Database 19cが実行されています。

図26-1 LogMinerデータベースの構成例

図26-1の説明は次にあります
「図26-1 LogMinerデータベースの構成例」の説明

この例は、有効なLogMiner構成の1つを示しているにすぎません。その他に有効な構成としては、ソース・データベースとマイニング・データベースの両方に同じデータベースを使用する構成、データ・ディクショナリを別の方法で提供する構成などがあります。

26.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を使用します。

26.2.2 LogMiner操作の指定および分析するデータの取得

LogMiner操作の指定にはPL/SQLパッケージDBMS_LOGMNRおよびDBMS_LOGMNR_Dを、分析するデータの取得にはV$LOGMNR_CONTENTSビューを使用します。

たとえば:

  1. LogMinerディクショナリを指定します。

    使用するディクショナリのタイプに応じて、DBMS_LOGMNR_D.BUILDプロシージャを使用するか、LogMiner起動時(ステップ3)にディクショナリを指定するか、その両方を実行します。

  2. 分析するREDOログ・ファイルのリストを指定します。

    DBMS_LOGMNR.ADD_LOGFILEプロシージャを使用するか、LogMiner起動時(ステップ3)に自動的に分析するログ・ファイルのリストをLogMinerが作成するよう指定します。

  3. LogMinerを起動します。

    DBMS_LOGMNR.START_LOGMNRプロシージャを使用します。

  4. 分析するREDOデータを要求します。

    V$LOGMNR_CONTENTSビューを問い合せます。

  5. LogMinerセッションを終了します。

    DBMS_LOGMNR.END_LOGMNRプロシージャを使用します。

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の概要

26.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の使用

26.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ログ・ビュー

DBA_LOGMNR_LOG

CDB_LOGMNR_LOG
LogMinerパージ済ログ・ビュー

DBA_LOGMNR_PURGED_LOG

CDB_LOGMNR_PURGED_LOG
LogMinerセッション・ログ・ビュー

DBA_LOGMNR_SESSION

CDB_LOGMNR_SESSION

DBAビューには、問合せが行われたコンテナで定義されているセッションに関連する情報のみが表示されます。

CDBビューには、特定の行が表すデータを含むコンテナを識別する追加のCON_ID列が含まれます。ルートからCDBビューを問い合せると、それらのビューを使用してすべてのコンテナに関する情報を参照できます。

親トピック: CDBのLogMinerの使用

26.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の使用

26.3.3 CDBでのサプリメンタル・ロギングの有効化

CDBでは、データベース全体のサプリメンタル・ロギングを有効または無効にするための構文は、ALTER DATABASEコマンドです。

たとえば、サプリメンタル・ログ・データを追加または削除する場合は、次の構文を使用します。

ALTER DATABASE [ADD|DROP] SUPPLEMENTAL LOG DATA ...

CREATE TABLE文およびALTER TABLE文で始まるサプリメンタル・ロギング操作は、CDBルートまたはPDBから実行できます。これらのサプリメンタル・ロギング操作は、適用先の表にのみ影響します。

Oracle Database 23ai以降では、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の使用

26.4 Oracle GoldenGateのサプリメンタル・ロギングの構成方法

Oracle Database 21c以降は、個々の表の論理レプリケーションとサプリメンタル・ロギングの有効化をサポートしています。

このデータベースでは、JSONリレーショナル二面性ビューの論理レプリケーションもサポートされています。二面性ビュー・レプリケーションを使用するには、サプリメンタル・ロギングを有効にしておく必要があります。

親トピック: REDOログ・ファイル分析のためのLogMinerの使用

26.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つのオプションがあります。

  1. 論理レプリケーションが有効化されている場合、表のサプリメンタル・ロギングの設定は、データベース・レベル、スキーマ・レベルおよび表レベルのサプリメンタル・ログ・データによって決定されます。

  2. 表に対する論理レプリケーションが無効化されている場合、この表のサプリメンタル・ログの設定は、データベース・レベルのサプリメンタル・ログ・データによってのみ決定されます。スキーマ・レベルのサプリメンタル・ログ・データは無視されます。

  3. 論理レプリケーション句を有効化または無効化せずに表を作成した場合、その表の論理レプリケーションはデフォルトで有効になります。

親トピック: Oracle GoldenGateのサプリメンタル・ロギングの構成方法

26.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句が使用されると、表に対して論理レプリケーションが無効化されます。表レベルおよびスキーマ・レベルのサプリメンタル・ロギングは実行されません。

親トピック: Oracle GoldenGateのサプリメンタル・ロギングの構成方法

26.4.3 Oracle GoldenGate自動取得で使用可能な表を表示するビュー

自動取得(ENABLE_AUTO_CAPTURE)が有効な表を調べるには、ビューSYS.DBA_OGG_AUTO_CAPTURED_TABLESおよびSYS.USER_OGG_AUTO_CAPTURED_TABLESを使用します。

Oracle GoldenGateでは、ENABLE_AUTO_CAPTUREパラメータを使用して論理レプリケーションを管理します。ビューを使用して、Oracle GoldenGateで自動的に取得できる表を確認できます。

DBA_OGG_AUTO_CAPTURED_TABLESビューの問合せに使用するユーザー・アカウントには、SELECT_CATALOG_ROLE権限が必要です。

例26-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 GoldenGate ENABLE_AUTO_CAPTUREが有効化されている表の所有者
  • NAME: Oracle GoldenGate ENABLE_AUTO_CAPTUREが有効化されている表の名前
  • ALLOW_NOVALIDATE_PK[YES|NO]: キーのサプリメンタル・ロギングで未検証の主キーが許可されています。YESは「はい」、NOは「いいえ」に相当します。結果がNOである場合、検証される一意キーまたは主キーのみが使用されます。

Oracle GoldenGateビューDBA_OGG_AUTO_CAPTURED_TABLESは、SYS.DBA_AUTO_CAPTURED_TABLESビューのシノニムです。

例26-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ビューのシノニムです。

親トピック: Oracle GoldenGateのサプリメンタル・ロギングの構成方法

26.5 LogMinerディクショナリ・ファイルとREDOログ・ファイル

正確なログ・マイニング結果を得るには、LogMinerがLogMinerディクショナリとどのように連携するかを学習します。

LogMinerの使用を開始する前に、LogMinerがLogMinerディクショナリ・ファイル(またはファイル)およびOracle Database REDOログ・ファイルとどのように連携するかを理解しておく必要があります。これを知っておくと、正確な結果を取得し、システム・リソースの使用を計画するのに役立ちます。

親トピック: REDOログ・ファイル分析のためのLogMinerの使用

26.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ディクショナリを選択する際に役立つデシジョン・ツリーです。

図26-2 LogMinerディクショナリの選択方法

図26-2の説明が続きます
「図26-2 LogMinerディクショナリの選択方法」の説明

使用可能なディクショナリ・オプションを指定するには、選択したプロシージャの手順を確認します。

親トピック: LogMinerディクショナリ・ファイルとREDOログ・ファイル

26.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オプションに対し有効ではありません。

26.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ログ・ファイルのバックアップとリストアのためのプロセスがすでに整っているため、そのための特別なステップは必要ありません。バックアップ作業も時間がかかる作業のため、ピークを外した時間帯に実行することをお薦めします。

26.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回のみの実行で、以後は何回でもディクショナリをフラット・ファイルに抽出できます。

  1. DBMS_LOGMNR_D.BUILDプロシージャは、ディクショナリ・ファイルが置かれたディレクトリにアクセスする必要があります。通常、PL/SQLプロシージャは、ユーザー・ディレクトリにアクセスしないため、ディレクトリの場所を指定する必要があります。ディレクトリを指定しない場合、プロシージャの実行は失敗します。ディレクトリの場所はディレクトリ・オブジェクトである必要があります。次に、SQL CREATE DIRECTORY文を使用してパス/oracle/databaseのmy_dictionary_dirというディクショナリ・オブジェクトを作成する例を示します。
    SQL> CREATE DIRECTORY "my_dictionary_dir" AS '/oracle/database';

    ノート:

    Oracle Database 12cリリース2 (12.2)より前には、UTL_FILE_DIR初期化パラメータを使用してディレクトリの場所を指定しました。ただし、Oracle Database 18cからは、UTL_FILE_DIR初期化パラメータはサポート対象外になりました。これは下位互換性のために引き続きサポートされていますが、かわりにディレクトリ・オブジェクトを使用することをお薦めします。
  2. データベースがクローズされている場合、SQL*Plusを使用してマウントしてから、分析するREDOログ・ファイルが含まれるデータベースをオープンします。たとえば、SQL STARTUPコマンドを入力すると、データベースがマウントされ、オープンします。
    SQL> STARTUP
  3. DBMS_LOGMNR_D.BUILD PL/SQLプロシージャを実行します。次の例では、ステップ1で作成したディレクトリ・オブジェクトmy_dictionary_dir内のdictionary.oraという名前のフラット・ファイルにLogMinerディレクトリ・ファイルを抽出します。
    SQL> EXECUTE dbms_logmnr_d.build(dictionary_location=>'my_dictionary_dir', - 
                                 dictionary_filename=>'dictionary.ora', -
                                 options => dbms_logmnr_d.store_in_flat_file);

    STORE_IN_FLAT_FILEオプションを指定せずに、ファイル名と位置を指定することもできます。結果は同じになります。

26.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)以降ではサポートされなくなり、使用できなくなりました。

親トピック: LogMinerディクショナリ・ファイルとREDOログ・ファイル

26.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の使用

26.7 分析するREDOデータについてのV$LOGMNR_CONTENTSの問合せ

分析するREDOデータにアクセスするには、V$LOGMNR_CONTENTSビューを問い合せます。

親トピック: REDOログ・ファイル分析のためのLogMinerの使用

26.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のいずれかです。

関連トピック

親トピック: 分析するREDOデータについてのV$LOGMNR_CONTENTSの問合せ

26.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という問合せの結果を一時的に格納する表を作成することをお薦めします。

関連トピック

親トピック: 分析するREDOデータについてのV$LOGMNR_CONTENTSの問合せ

26.7.3 列の値に基づいたV$LOGMNR_CONTENTSの問合せ

Oracle Database LogMinerビューV$LOGMNR_CONTENTSを使用して、列値を問い合せることができます。

親トピック: 分析するREDOデータについてのV$LOGMNR_CONTENTSの問合せ

26.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関数からは、常に、元のデータ型に戻すことができる文字列が返されます。

26.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;
26.7.3.3 MINE_VALUE関数およびCOLUMN_PRESENT関数の使用規則

MINE_VALUE関数およびCOLUMN_PRESENT関数に適用される使用規則を説明します。

具体的には次のとおりです。

  • LogMinerセッション内でのみ使用できます。

  • V$LOGMNR_CONTENTSビューからの選択操作中に起動する必要があります。

  • LONG、LONG RAW、CLOB、BLOB、NCLOB、ADTまたはCOLLECTIONデータ型はサポートされません。

26.7.3.4 MINE_VALUEファンクションを使用してNCHAR値を取得する際の制限事項

MINE_VALUEファンクションを使用する際の制限事項について説明します。

DBMS_LOGMNR.MINE_VALUEファンクションを使用してデータベース文字セットに存在しない文字を含むNCHAR値を取得する場合、それらの文字は、データベース文字セットの置換文字(逆向きの疑問符など)として返されます。

26.7.4 XMLType列およびXMLType表に基づいたV$LOGMNR_CONTENTSの問合せ

LogMinerでは、XMLType列に対して生成されるREDOがサポートされます。CLOBとして格納されるXMLTypeデータは、11.0.0.0以上の互換性設定で生成されたREDOに対してサポートされます。

親トピック: 分析するREDOデータについてのV$LOGMNR_CONTENTSの問合せ

26.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. すべてのスカラー列を使用した最初の挿入
  2. バインド変数を使用して、1つのXMLType列に値を設定する更新文を使用したXML DOC BEGIN操作
  3. XML文書のデータを使用した1回以上のXML DOC WRITE操作
  4. XML文書のすべてのデータが送信されたことを示すXML DOC END操作
  5. 表に複数の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句に元の表の行を一意に識別するためのオブジェクト識別子が含まれます。

26.7.4.2 XMLTypeデータを使用するLogMinerの使用上の制限

XMLTypeデータを使用するLogMinerの使用上の制限を説明します。

XMLTypeデータのマイニングは、DBMS_LOGMNR.COMMITTED_DATA_ONLYオプションを使用している場合にのみ行う必要があります。そうしないと、一部の行の変更が不足しているために、不完全な変更が表示されたり、XMLとして表示されるはずの変更がCLOBの変更として表示される可能性があります。このために、これらのSQL DML文に対するSQL_REDOが不完全かつ無効になってしまいます。

SQL_UNDO列は、XMLTypeデータへの変更に対して移入されません。

26.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'

26.8 V$LOGMNR_CONTENTSに返されるデータのフィルタ処理および書式設定

V$LOGMNR_CONTENTSビューのフィルタリング機能と書式設定機能を使用して、表示されるデータおよび表示する方法を管理し、データが返される速度を制御する方法を学習します。

Oracle DatabaseのREDOログからデータを抽出すると、LogMinerで大量の情報を処理できる可能性があります。データのフィルタ方法とフォーマット方法を学習すると、データ・マイニング・プロジェクトを支援する上で役に立ちます。これらのフィルタ処理機能および書式設定機能は、DBMS_LOGMNR.START_LOGMNRプロシージャのパラメータまたはオプションを使用して要求します。

親トピック: REDOログ・ファイル分析のためのLogMinerの使用

26.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の使用例」を参照してください

親トピック: V$LOGMNR_CONTENTSに返されるデータのフィルタ処理および書式設定

26.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

親トピック: V$LOGMNR_CONTENTSに返されるデータのフィルタ処理および書式設定

26.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で失敗します。

親トピック: V$LOGMNR_CONTENTSに返されるデータのフィルタ処理および書式設定

26.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で失敗します。

親トピック: V$LOGMNR_CONTENTSに返されるデータのフィルタ処理および書式設定

26.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文は処理できません。

親トピック: V$LOGMNR_CONTENTSに返されるデータのフィルタ処理および書式設定

26.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構文を使用していないため、実行されません。

関連トピック

親トピック: V$LOGMNR_CONTENTSに返されるデータのフィルタ処理および書式設定

26.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のみを実行します。

関連トピック

親トピック: REDOログ・ファイル分析のためのLogMinerの使用

26.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の間に生成されたログ・ファイルのみを分析します。これを最も効率的に行う方法は次のとおりです。

  1. 月曜日に、この時間範囲を指定して、DBMS_LOGMNR.START_LOGMNRをコールします。

  2. V$LOGMNR_CONTENTSビューから変更を選択します。

  3. 一週間のそれぞれの日に対して、ステップ1と2を繰り返します。

この方法では、その週のREDOデータの合計量が多い場合、リスト内の各REDOログ・ファイルの小さなサブセットのみがLogMinerによって読み込まれるため、全体の分析が非常に速く行われます。

例2: 時間範囲またはSCN範囲の調整

REDOログ・ファイル・リストを指定し、LogMiner起動時に時間範囲(またはSCN範囲)を指定するとします。V$LOGMNR_CONTENTSビューを問い合せると、指定した時間範囲には、必要なデータの一部のみが含まれます。時間範囲を1時間拡張するために、またはSCN範囲を調整するためにDBMS_LOGMNR.START_LOGMNRを再度コールできます。

例3: リモート・データベースで受信された場合のREDOログ・ファイルの分析

変更を分析またはデータベース間で変更をレプリケートするためのアプリケーションを作成したとします。ソース・データベースは、そのREDOログ・ファイルをマイニング・データベースに送信し、オペレーティング・システム・ディレクトリに格納します。アプリケーションは、次の手順を実行します。

  1. 現在ディレクトリにあるすべてのREDOログ・ファイルをREDOログ・ファイル・リストに追加します。

  2. 適切な設定でDBMS_LOGMNR.START_LOGMNRをコールし、V$LOGMNR_CONTENTSビューから選択します。

  3. ディレクトリに新しく受信されたREDOログ・ファイルを追加します。

  4. 必要に応じて、ステップ2と3を繰り返します。

親トピック: REDOログ・ファイル分析のためのLogMinerの使用

26.11 LogMinerおよびサプリメンタル・ロギング

LogMinerのサプリメンタル・ロギング機能の使用方法について学習します

親トピック: REDOログ・ファイル分析のためのLogMinerの使用

26.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およびサプリメンタル・ロギング

26.11.2 データベースレベルのサプリメンタル・ロギング

LogMinerには、これらの項で説明するとおり、最小サプリメンタル・ロギング、識別キー・ロギングおよびプロシージャ型サプリメンタル・ロギングの異なるタイプのデータベース・レベルのサプリメンタル・ロギングがあります。

最小サプリメンタル・ロギングでは、REDOログ・ファイルを生成するデータベースに大きなオーバーヘッドが発生しません。ただし、データベース全体の識別キー・ロギングを有効にすると、REDOログ・ファイルを生成するデータベースにオーバーヘッドが発生する場合があります。LogMinerに対しては、少なくとも最小サプリメンタル・ロギングを有効にすることをお薦めします。

  • 最小サプリメンタル・ロギング
    最小サプリメンタル・ロギングは、LogMinerでDML変更と関連付けられたREDO操作を識別、グループ化およびマージするために必要な最小限の情報を記録します。
  • データベース・レベルの識別キー・ロギング
    識別キー・ロギングは、REDOログ・ファイルがソース・データベース・インスタンスでマイニングされない場合(REDOログ・ファイルがロジカル・スタンバイ・データベースでマイニングされる場合など)に必要です。
  • プロシージャ型サプリメンタル・ロギング
    プロシージャ型サプリメンタル・ロギングを有効にすると、ローリング・アップグレードまたはOracle GoldenGateでレプリケートできるように、LogMinerによって特定のプロシージャ起動がREDOに記録されます。

親トピック: LogMinerおよびサプリメンタル・ロギング

26.11.2.1 最小サプリメンタル・ロギング

最小サプリメンタル・ロギングは、LogMinerでDML変更と関連付けられたREDO操作を識別、グループ化およびマージするために必要な最小限の情報を記録します。

また、LogMiner(およびLogMinerテクノロジに基づいた他の製品)に、連鎖行や様々な記憶域構成(クラスタ表、索引構成表など)のサポートに十分な情報を確保します。最小サプリメンタル・ロギングを有効にするには、次のSQL文を実行します。

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
26.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;
26.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

プロシージャ型サプリメンタル・ロギングが有効になっている場合、プロシージャ型サプリメンタル・ロギングを先に削除しないかぎり、最小サプリメンタル・ロギングを削除できません。

26.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およびサプリメンタル・ロギング

26.11.4 表レベルのサプリメンタル・ロギング

表レベルのサプリメンタル・ロギングでは、補助的に記録する列を表レベルで指定します。

識別キー・ロギングまたはユーザー定義の条件付きのサプリメンタル・ログ・グループまたは無条件のサプリメンタル・ログ・グループを使用して、次の項で説明するとおり、補助情報を記録できます。

親トピック: LogMinerおよびサプリメンタル・ロギング

26.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データ型を使用することをお薦めします。

各識別キー・ロギング・オプションの詳細は、「データベース・レベルの識別キー・ロギング」を参照してください。

26.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列自体は補助的に記録できませんが、この列に対して行った変更を使用して、同じ行の他の列のサプリメンタル・ロギングをトリガーすることはできます。

26.11.4.3 ユーザー定義のサプリメンタル・ログ・グループを使用する場合のノート

ユーザー定義のサプリメンタル・ログ・グループを使用するためのヒント。

ユーザー定義のサプリメンタル・ログ・グループを指定する場合は、次の点に注意してください。

  • 1つの列を複数のサプリメンタル・ログ・グループに含めることができます。ただし、その列のビフォア・イメージの記録は1回のみです。

  • 条件付きと無条件の両方で同じ列を記録することを指定した場合、その列は無条件に記録されます。

26.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およびサプリメンタル・ロギング

26.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およびサプリメンタル・ロギング

26.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ログ・ファイルに記録されているとします。ここで、次の手順を実行します。

  1. DBMS_LOGMNR.START_LOGMNRをコールします。LogMinerによって、次のものが読み込まれます。

    1. ディクショナリをロードするための最初のログ・ファイル

    2. その中に含まれている可能性があるDDLをすべて取得するための2番目のREDOログ・ファイル

    3. 必要なデータを取得するための3番目のログ・ファイル

  2. 同じ要求範囲で、再度DBMS_LOGMNR.START_LOGMNRをコールします。

    LogMinerは、REDOログ・ファイル3から読取りを開始します。REDOログ・ファイル2に含まれているDDL文はすでに処理されているため、REDOログ・ファイル2を読み込む必要はありません。

  3. 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およびサプリメンタル・ロギング

26.12 ビューでのLogMiner操作情報へのアクセス

LogMiner操作情報(REDOデータではなく)は、ビューに含まれています。

親トピック: REDOログ・ファイル分析のためのLogMinerの使用

26.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操作情報へのアクセス

26.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操作情報へのアクセス

26.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操作情報へのアクセス

26.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の値がわかっている場合は、これらの終了値のいずれかを指定できます。

例26-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操作情報へのアクセス

26.13 一般的なLogMinerセッションのステップ

LogMinerを使用してデータを抽出およびマイニングできる一般的な方法について学習します。

親トピック: REDOログ・ファイル分析のためのLogMinerの使用

26.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ロールを付与されている必要があります。

関連トピック

親トピック: 一般的なLogMinerセッションのステップ

26.13.2 一般的なLogMinerセッション・タスク1: サプリメンタル・ロギングの有効化

REDOログ・ファイルとともにLogMinerを使用できるようにするには、サプリメンタル・ロギングを有効にする必要があります。

REDOベースのアプリケーションでは、追加の列をREDOログ・ファイルに記録する必要がある場合があります。これらの追加の列を記録するプロセスは、サプリメンタル・ロギングと呼ばれますデフォルトでは、Oracle Databaseはサプリメンタル・ロギングが有効になっていません。少なくともLogMinerを使用するには、最小限のサプリメンタル・ロギングを有効にする必要があります。

例26-4 最小サプリメンタル・ロギングの有効化

サプリメンタル・ロギングを有効にするには、次の文を入力します。

ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;

関連トピック

親トピック: 一般的なLogMinerセッションのステップ

26.13.3 一般的なLogMinerセッション・タスク2: LogMinerディクショナリの抽出

LogMinerを使用するには、LogMinerにデータベース・ディクショナリを提供するオプションを選択する必要があります。

次のいずれかのオプションを選択します。

  • LogMiner起動時にDICT_FROM_ONLINE_CATALOGオプションでオンライン・カタログの使用を指定。

  • REDOログ・ファイルにデータベース・ディクショナリ情報を抽出。

  • フラット・ファイルにデータベース・ディクショナリ情報を抽出。

関連トピック

親トピック: 一般的なLogMinerセッションのステップ

26.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の問合せ」を参照してください。
  1. データベースをマウントした状態またはマウントしていない状態で、SQL*Plusを使用してOracle Databaseインスタンスを起動します。たとえば、SQLプロンプトでSTARTUP文を入力します。
    STARTUP
  2. REDOログ・ファイルのリストを作成します。PL/SQLプロシージャDBMS_LOGMNR.ADD_LOGFILEのNEWオプションを指定して、新規リストの開始であることを指定します。たとえば、REDOログ・ファイル/oracle/logs/log1.fを指定するには、次のように入力します。 
    EXECUTE DBMS_LOGMNR.ADD_LOGFILE( -
   LOGFILENAME => '/oracle/logs/log1.f', -
   OPTIONS => DBMS_LOGMNR.NEW);
  3. 必要に応じて、PL/SQLプロシージャDBMS_LOGMNR.ADD_LOGFILEのADDFILEオプションを指定し、さらにREDOログ・ファイルを追加します。たとえば、REDOログ・ファイル/oracle/logs/log2.fを追加するには、次のように入力します。
    EXECUTE DBMS_LOGMNR.ADD_LOGFILE( -
   LOGFILENAME => '/oracle/logs/log2.f', -
   OPTIONS => DBMS_LOGMNR.ADDFILE);

    REDOログ・ファイルを追加する場合、OPTIONSパラメータの指定はオプションです。たとえば、次のように入力できます。 

    EXECUTE DBMS_LOGMNR.ADD_LOGFILE( -
   LOGFILENAME=>'/oracle/logs/log2.f');
  4. 必要に応じて、PL/SQLプロシージャDBMS_LOGMNR.REMOVE_LOGFILEを使用してREDOログ・ファイルを削除します。たとえば、REDOログ・ファイル/oracle/logs/log2.fを削除するには、次のように入力します。
    EXECUTE DBMS_LOGMNR.REMOVE_LOGFILE( -
   LOGFILENAME => '/oracle/logs/log2.f');

関連トピック

親トピック: 一般的なLogMinerセッションのステップ

26.13.5 LogMinerの起動

LogMinerの起動方法、およびREDOログ・ファイル、フィルタ基準、その他のセッション特性の分析に使用できるオプションを確認してください。

LogMinerディクショナリ・ファイルを作成し、分析するREDOログ・ファイルを指定した後、LogMinerを起動し、Oracle Databaseトランザクションを分析できます。
  1. LogMinerを起動するには、DBMS_LOGMNR.START_LOGMNRプロシージャを実行します。

    LogMinerディクショナリ・オプションを指定することをお薦めします。ディクショナリ・オプションを指定していない場合、LogMinerでは、内部オブジェクトの識別子とデータ型を、オブジェクト名と外部データ書式に変換できません。この結果、LogMinerから内部オブジェクトIDが返され、データはバイナリ・データとして表されます。また、ディクショナリがない場合、MINE_VALUE機能およびCOLUMN_PRESENT機能は使用できません。

    フラット・ファイルのLogMinerディクショナリの名前を指定する場合は、そのディクショナリ・ファイルに完全修飾されたファイル名を指定する必要があります。たとえば、/oracle/database/dictionary.oraを使用してLogMinerを起動するには、次の文を発行します。 

    EXECUTE DBMS_LOGMNR.START_LOGMNR( -
   DICTFILENAME =>'/oracle/database/dictionary.ora');

    フラット・ファイルのディクショナリ名を指定しない場合は、OPTIONSパラメータを使用して、DICT_FROM_REDO_LOGSオプションまたはDICT_FROM_ONLINE_CATALOGオプションのいずれかを指定します。

    DICT_FROM_REDO_LOGSを指定した場合、LogMinerでは、DBMS_LOGMNR.ADD_LOGFILEプロシージャで指定したREDOログ・ファイルに、ディクショナリが含まれていると認識されます。ディクショナリが含まれているREDOログ・ファイルを判別するには、V$ARCHIVED_LOGビューを使用します。このタスクの例を確認するには、「REDOログ・ファイルへのLogMinerディクショナリの抽出」を参照してください。

    ノート:

    LogMinerの起動後にREDOログ・ファイルを追加した場合は、LogMinerを再起動する必要があります。LogMinerは、DBMS_LOGMNR.START_LOGMNRに対する前回のコールに含まれていたオプションを保持しないため、使用するオプションを再度指定する必要があります。ただし、DBMS_LOGMNR.START_LOGMNRの現在のコールでディクショナリを指定しない場合、LogMinerは、以前のコールのディクショナリ仕様を保持します。

  2. 必要に応じて、問合せをフィルタ処理またはフォーマットしたり、OPTIONSパラメータを使用してLogMinerセッションの特性を追加指定できます。たとえば、オンライン・カタログをLogMinerディクショナリとして使用して、V$LOGMNR_CONTENTSビューにコミット済トランザクションのみを表示できます。次のように入力します。
    EXECUTE DBMS_LOGMNR.START_LOGMNR(OPTIONS => -
   DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG + -
   DBMS_LOGMNR.COMMITTED_DATA_ONLY);

    DBMS_LOGMNR.START_LOGMNRプロシージャは、毎回異なるオプションを指定して、複数回実行できます。たとえば、V$LOGMNR_CONTENTSの問合せから必要な結果を取得できなかった場合、他のオプションを指定してLogMinerを再起動できます。LogMinerディクショナリを再指定する必要がないかぎり、DBMS_LOGMNR.START_LOGMNRに対する前回のコールでREDOログ・ファイルがすでに追加されている場合は、再度追加する必要はありません。

関連トピック

親トピック: 一般的なLogMinerセッションのステップ

26.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に返されるデータのフィルタ処理および書式設定」を参照してください。

関連トピック

親トピック: 一般的なLogMinerセッションのステップ

26.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セッションのステップ

26.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ログ・ファイル分析のためのLogMinerの使用

26.14.1 分析するREDOログ・ファイルの明示的指定によるマイニングの例

例を使用して、REDOログ・ファイルの指定方法を確認してください。

これらの例では、分析対象データが存在するREDOログ・ファイルがわかっている場合のLogMinerの使用方法を示します。それぞれの例は、前の例に基づいて作成されているため、順番に読み進むことをお薦めします。

SQL出力の画面上の書式設定は、この項で示す例とは異なる場合があります。

ノート:

dbms_logmnr.start_logmnrパッケージのcontinuous_mineオプションは、Oracle Database 19c (19.1)ではサポートされなくなり、使用できなくなりました。ログ・ファイルを手動で指定する必要があります

親トピック: LogMinerの使用例

26.14.1.1 例1: 最後にアーカイブされたREDOログ・ファイルでのすべての変更の検索

LogMinerのデフォルト動作では、トランザクションがコミット済であるかどうかに関係なく、分析するREDOログ・ファイルで検出されたすべての変更が表示されます。

データベースの変更履歴を確認する最も簡単な方法は、ソース・データベースでマイニングし、オンライン・カタログを使用してREDOログ・ファイルを変換する方法です。この例では、LogMinerを使用して最も簡単に分析を行う方法を示します。

この例では、最後にアーカイブされたREDOログ・ファイルをマイニングするとします。ここでは、最後にアーカイブされたREDOログ(データベースで生成)に含まれているすべての変更を検索します(データベースは、Oracle Real Application Clusters (Oracle RAC)データベースでないものとします)。

  1. 最後にアーカイブされた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

  2. 分析するREDOログ・ファイルのリストを指定します。この場合は、ステップ1の問合せで返されたREDOログ・ファイルです。

    EXECUTE DBMS_LOGMNR.ADD_LOGFILE( -
  LOGFILENAME => '/usr/oracle/data/db1arch_1_16_482701534.dbf', -
  OPTIONS => DBMS_LOGMNR.NEW);

  3. LogMinerを起動し、使用するディクショナリを指定します。

    EXECUTE DBMS_LOGMNR.START_LOGMNR( -
   OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG);

  4. 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;

  5. LogMinerセッションを終了します。

    SQL> EXECUTE DBMS_LOGMNR.END_LOGMNR();
26.14.1.2 例2: コミット済トランザクションへのDML文のグループ化

LogMinerを使用してREDOログ・トランザクションをグループ化する方法を学習します。

例1に示すように、LogMinerのデフォルト動作では、トランザクションがコミット済であるかどうかに関係なく、分析するREDOログ・ファイルで検出されたすべての変更が表示されます。また、LogMinerでは、実行された順序で変更が表示されます。同じトランザクションに属するDML文がグループにまとめられていないため、出力を目視で簡単に確認することはできません。SQLを使用してトランザクションをグループ化することもできますが、LogMinerでは、より簡単な方法が提供されています。この例では、最後にアーカイブされたREDOログ・ファイルを再度分析しますが、コミット済トランザクションのみが返されます。

  1. データベースによって最後にアーカイブされた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

  2. ステップ1の問合せで返されたREDOログ・ファイルを指定します。このリストは、1つのREDOログ・ファイルで構成されます。

    EXECUTE DBMS_LOGMNR.ADD_LOGFILE( -
   LOGFILENAME => '/usr/oracle/data/db1arch_1_16_482701534.dbf', -
   OPTIONS => DBMS_LOGMNR.NEW);

  3. 使用するディクショナリとCOMMITTED_DATA_ONLYオプションを指定して、LogMinerを起動します。 

    EXECUTE DBMS_LOGMNR.START_LOGMNR( -
   OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG + -
   DBMS_LOGMNR.COMMITTED_DATA_ONLY);

  4. 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;

  5. LogMinerセッションを終了します。

    EXECUTE DBMS_LOGMNR.END_LOGMNR();
26.14.1.3 例3: 再構築されたSQLの書式設定

視覚的な検査を簡単に行うには、PRINT_PRETTY_SQLオプションを指定してLogMinerを実行します。

例2で示したとおり、オンラインREDOログ・ファイルのディクショナリでCOMMITTED_DATA_ONLYオプションを使用する方法は、コミット済トランザクションのみを対象とするための簡単な方法です。ただし、目視で簡単に確認はできません。INSERT文内の列名とそれに対応する値との間の関連が明白でないためです。PRINT_PRETTY_SQLオプションを指定することで、この問題に対処できます。このオプションを指定すると、再構築されたSQL文の一部が実行不可能になることに注意してください。

  1. 最後にアーカイブされた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

  2. ステップ1の問合せで返されたREDOログ・ファイルを指定します。

    EXECUTE DBMS_LOGMNR.ADD_LOGFILE( -
   LOGFILENAME => '/usr/oracle/data/db1arch_1_16_482701534.dbf', -
   OPTIONS => DBMS_LOGMNR.NEW);

  3. 使用するディクショナリおよび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の書式のみを変更するため、目視用のレポートを生成する場合に有効です。

  4. 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;

  5. 再構築された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;

  6. LogMinerセッションを終了します。

    EXECUTE DBMS_LOGMNR.END_LOGMNR();
26.14.1.4 例4: REDOログ・ファイル内のLogMinerディクショナリの使用

REDOログ・ファイルに抽出されたディクショナリを使用する方法を学習します。

オンライン・カタログ内のディクショナリを使用する場合は、オンライン・カタログを生成したデータベースと同じデータベース内のREDOログ・ファイルをマイニングする必要があります。REDOログ・ファイルに含まれているディクショナリを使用すると、別のデータベース内のREDOログ・ファイルをマイニングできます。

オンライン・カタログ内のディクショナリを使用する場合は、オンライン・カタログを生成したデータベースと同じデータベース内のREDOログ・ファイルをマイニングする必要があります。REDOログ・ファイルに含まれているディクショナリを使用すると、別のデータベース内のREDOログ・ファイルをマイニングできます。

  1. データベースによって最後にアーカイブされた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

  2. ディクショナリは、複数のREDOログ・ファイルに含まれている場合があります。したがって、ディクショナリの先頭と終わりが含まれているREDOログ・ファイルを判別する必要があります。次の手順を実行して、V$ARCHIVED_LOGビューを問い合せます。

    1. ディクショナリ抽出の終わりが含まれている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

    2. データ・ディクショナリ抽出の先頭(前のステップで検出されたディクショナリの終わりに対応)が含まれている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

    3. 分析する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');

    4. V$LOGMNR_LOGSビューを問い合せて、分析するREDOログ・ファイルのリストをタイムスタンプとともに表示します。

      出力では、LogMinerによって欠落しているREDOログ・ファイルに指摘フラグが付けられています。正常に機能するために欠落しているREDOログ・ファイルが必要なオプションを指定していない場合は、LogMinerでマイニングを続行できます。

  3. 使用するディクショナリおよび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);

  4. 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;

  5. 必要に応じて、追加の問合せを発行します。

    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;

  6. LogMinerセッションを終了します。

    EXECUTE DBMS_LOGMNR.END_LOGMNR();
26.14.1.5 例5: 内部ディクショナリでのDDL文の追跡

DBMS_LOGMNR.DDL_DICT_TRACKINGオプションを使用して、REDOログ・ファイルで発生したDDL文でLogMinerの内部ディクショナリを更新する方法を学習します。

  1. データベースによって最後にアーカイブされた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

  2. ディクショナリは複数のREDOログ・ファイルに含まれている場合があるため、データ・ディクショナリの先頭と終わりが含まれているREDOログ・ファイルを判別します。これを行うには、次のとおりV$ARCHIVED_LOGビューを問い合せます。

    1. データ・ディクショナリ抽出の終わりが含まれている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

    2. データ・ディクショナリ抽出の先頭(前の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

  3. 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

  4. 分析する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');

  5. 使用するディクショナリおよび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);

  6. 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;

  7. LogMinerセッションを終了します。

    EXECUTE DBMS_LOGMNR.END_LOGMNR();
26.14.1.6 例6: 時間範囲による出力のフィルタ処理

時間ごとに一連のREDOログをフィルタするには、時間範囲を指定してログ・ファイルを返す様々な方法について学習してください。

例4と例5では、問合せにタイムスタンプ・ベースの述語(timestamp > '10-jan-2012 15:59:53')を指定して行をフィルタする方法を確認しました。ただし、タイムスタンプ値に基づいてREDOレコードを除外するには、この例で示すとおり、DBMS_LOGMNR.START_LOGMNRプロシージャ・コールで時間範囲を指定する方法がより効率的です。

  1. マイニングする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');

  2. 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

  3. 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);

  4. 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');

  5. LogMinerセッションを終了します。

    EXECUTE DBMS_LOGMNR.END_LOGMNR();

26.14.2 LogMinerのユース・ケースのシナリオ

LogMinerを使用してデータ・マイニング・タスクを実行する方法の一般的な例を確認してください。

親トピック: LogMinerの使用例

26.14.2.1 LogMinerを使用した特定のユーザーによる変更の追跡

LogMinerを使用して、単一のユーザーによって特定の時間範囲内にデータベースに対して行われたすべての変更を特定する方法を学習します。

ユーザーjoedevoが特定の時間範囲内にデータベースに加えたすべての変更を確認するとします。このタスクを実行するには、LogMinerを使用できます。

  1. データベースへの接続。

  2. LogMinerディクショナリ・ファイルを作成します。

    LogMinerを使用してjoedevoのデータを分析するには、joedevoが使用する表に対して表定義の変更が行われる前にLogMinerディクショナリ・ファイルを作成するか、LogMinerの起動時にオンライン・カタログを使用する必要があります。この例では、REDOログ・ファイルに抽出されたLogMinerディクショナリを使用します。

  3. 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);

  4. 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'));

  5. 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;

  6. LogMinerセッションを終了します。

    LogMinerセッションを正常に終了するには、DBMS_LOGMNR.END_LOGMNRプロシージャを使用します。 

    DBMS_LOGMNR.END_LOGMNR( );
26.14.2.2 LogMinerを使用した表アクセス統計の計算

LogMinerを使用して、指定の時間範囲にわたる表アクセス統計を計算する方法を学習します。

この例では、ダイレクト・マーケティング・データベースを管理し、1月の2週間の収益でのカスタマ・コンタクトの有効性を確認するとします。この場合、すでにLogMinerディクショナリを作成し、検索するREDOログ・ファイルを追加していることを前提としています。これらのコンタクトを識別するには、次のように1月の時間範囲でログを検索します。

  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');
  2. 次の 
    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;

  3. 次のデータが表示されます。(画面の書式は異なる場合があります。)

    SEG_OWNER          SEG_NAME          Hits
---------          --------          ----
CUST               ACCOUNT            384
UNIV               EXECDONOR          325
UNIV               DONOR              234
UNIV               MEGADONOR           32
HR                 EMPLOYEES           12
SYS                DONOR               12
    次の 
    Hits
    列の値は、問合せで指定した2週間の間に、指定した表に対して挿入、削除、更新の操作が行われた回数を示しています。この例では 
    cust.account
    表が、指定された2週間の期間中に最も修正され、 
    hr.employees
    および 
    sys.donor
    表は、同じ期間内に最も少なく変更されました。

  4. LogMinerセッションを終了します。

    次の 
    DBMS_LOGMNR.END_LOGMNR
    プロシージャを使用して、LogMinerセッションを適切に終了します。
    DBMS_LOGMNR.END_LOGMNR( );

26.15 サポートされるデータ型、記憶域属性、およびデータベースとREDOログ・ファイルのバージョン

データ型と記憶域属性のサポートに関する情報およびサポートされるデータベースとREDOログ・ファイルのリリースを説明します。

親トピック: REDOログ・ファイル分析のためのLogMinerの使用

26.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以上に設定されている場合)

関連トピック

親トピック: サポートされるデータ型、記憶域属性、およびデータベースとREDOログ・ファイルのバージョン

26.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以上の互換性で動作するデータベースが必要です。

関連トピック

親トピック: サポートされるデータ型、記憶域属性、およびデータベースとREDOログ・ファイルのバージョン

26.15.3 サポートされないデータ型と表記憶域属性

マイニング結果から表が除外される結果を回避するには、LogMinerでサポートされないデータ型および表記憶域属性を確認します。

LogMinerは、次のデータ型と表記憶域属性をサポートしません。これらのサポートされていないデータ型のいずれかを使用する列が表に含まれる場合、表全体がLogMinerによって無視されます。

  • BFILE
  • ネストされた表
  • ネストされた表のあるオブジェクト
  • アイデンティティ列を含む表
  • 時間的な有効性列
  • PKREF列
  • PKOID列
  • ネストした表属性およびスタンドアロンのネストした表の列

親トピック: サポートされるデータ型、記憶域属性、およびデータベースとREDOログ・ファイルのバージョン

26.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ログ・ファイルを使用してサポートできる操作およびデータ型が制限される場合があります。

関連トピック

親トピック: サポートされるデータ型、記憶域属性、およびデータベースとREDOログ・ファイルのバージョン

26.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は生成されません。

親トピック: サポートされるデータ型、記憶域属性、およびデータベースとREDOログ・ファイルのバージョン