22 REDOログ・ファイル分析のためのLogMinerの使用
Oracle Databaseの一部であるOracle LogMinerを使用すると、SQLインタフェースを介してオンラインおよびアーカイブのREDOログ・ファイルを問い合せることができます。
REDOログ・ファイルには、データベースでのアクティビティの履歴情報が含まれています。
次のトピックを参照してください。
LogMinerは、コマンドラインから使用するか、またはOracle LogMinerビューアのグラフィカル・ユーザー・インタフェースを介してアクセスできます。Oracle LogMinerビューアは、Oracle Enterprise Managerの一部です。Oracle LogMinerビューアの詳細は、Oracle Enterprise Managerオンライン・ヘルプを参照してください。
ノート:
この項の多くの例で、LogMinerCONTINUOUS_MINE
オプションを利用します。Oracle Database 12c リリース2 (12.2.0.1)からは、LogMiner CONTINUOUS_MINE
オプションが非推奨になりました。これは下位互換性の理由から引き続きサポートされていますが、使用しないことをお薦めします。かわりとなる機能はありません。
- LogMinerのメリット
ユーザー・データまたはデータベース・ディクショナリに対して行われたすべての変更は、データベースのリカバリ操作を実行できるように、Oracle REDOログ・ファイルに記録されます。 - LogMinerの概要
これらのトピックでは、LogMinerの概要について次のトピックを説明します。 - CDBのLogMinerの使用
LogMinerは、マルチテナント・コンテナ・データベース(CDB)で使用できます。 - LogMinerディクショナリ・ファイルとREDOログ・ファイル
LogMinerを使用する前に、LogMinerがLogMinerディクショナリ・ファイルおよびREDOログ・ファイルとともにどのように動作するかを理解しておくことが重要です。これは、正確な結果の取得と、システム・リソースの使用計画の作成に役立ちます。 - LogMinerの起動
LogMinerを起動するには、DBMS_LOGMNR.START_LOGMNR
プロシージャをコールします。 - 分析するREDOデータについてのV$LOGMNR_CONTENTSの問合せ
分析するREDOデータにアクセスするには、V$LOGMNR_CONTENTS
ビューを問い合せます。 - V$LOGMNR_CONTENTSに返されるデータのフィルタ処理および書式設定
LogMinerは、大量の情報を処理できます。V$LOGMNR_CONTENTS
ビューに返される情報、および情報が返される速度を制限できます。 - V$LOGMNR_CONTENTSに返されるDDL文の再適用
ユーザーが発行する一部のDDL文によって、1つ以上の他のDDL文がOracleによって内部的に実行される場合があります。 - DBMS_LOGMNR.START_LOGMNRの複数回のコール
DBMS_LOGMNR.START_LOGMNR
のコールに成功し、V$LOGMNR_CONTENTS
ビューから選択した後でも、現在のLogMinerセッションを終了せずにDBMS_LOGMNR.START_LOGMNR
を再度コールし、異なるオプションおよび時間範囲またはSCN範囲を指定できます。 - サプリメンタル・ロギング
サプリメンタル・ロギングについて説明します。 - ビューでのLogMiner操作情報へのアクセス
LogMiner操作情報(REDOデータではない)は、ビューに含まれています。 - 一般的なLogMinerセッションのステップ
一般的なLogMinerセッションのステップを説明します。 - LogMinerの使用例
LogMinerの使用例。 - サポートされるデータ型、記憶域属性、およびデータベースとREDOログ・ファイルのバージョン
データ型と記憶域属性のサポートに関する情報およびサポートされるデータベースとREDOログ・ファイルのリリースについて説明します。
親トピック: その他のユーティリティ
22.1 LogMinerのメリット
ユーザー・データやデータベース・ディクショナリに対するすべての変更は、Oracle REDOログ・ファイルに記録されます。これによってデータベース・リカバリ操作が実行できます。
LogMinerには、REDOログ・ファイルに対して適切に定義された使いやすい包括的なリレーショナル・インタフェースが用意されているため、強力なデータ監査ツールとしても、高度なデータ分析ツールとしても使用できます。次に、LogMinerの主要機能の一部を示します。
-
アプリケーション・レベルで発生したエラーなど、データベースの論理的破損が発生した時期を特定します。
WHERE
句の値に誤りがあったために不適切な行を削除した、不適切な値で行を更新した、不適切な索引を消去したなどのエラーがこれに含まれます。たとえば、ユーザー・アプリケーションで、すべての社員の給与を10%増額するところを100%増額するように誤ってデータベースを更新してしまったり、データベース管理者(DBA)が誤って重要なシステム表を削除してしまったりすることがあります。エラーが発生した時期を正確に知ることは、時刻ベースまたは変更ベースのリカバリの開始時期の特定に役立ちます。この情報から、破損する直前の状態にデータベースをリストアできます。LogMinerを使用したこのような処理方法の詳細は、「列の値に基づいたV$LOGMNR_CONTENTSの問合せ」を参照してください。 -
トランザクション・レベルでファイングレインなリカバリを行うために必要な処置を特定します。既存の依存性についての正しい理解と認識があれば、表固有のundo操作を実行し、表を元の状態に戻すことができます。そのために、LogMinerは、元のSQL文の発行順序を逆にたどる表固有の再構築されたSQL文を適用します。例については、「使用例1: LogMinerを使用した特定のユーザーによる変更の追跡」を参照してください。
通常は、表を以前の状態にリストアしてから、アーカイブされたREDOログ・ファイルを適用して、表をロールフォワードします。
-
傾向分析により、パフォーマンス・チューニングとキャパシティ・プランニングを実行します。どの表で更新や挿入が最も多いかを判断できます。その情報は、ディスク・アクセス統計に関する履歴的観点を提供するため、チューニングに使用できます。例については、「使用例2: LogMinerを使用した表アクセス統計の計算」を参照してください。
-
事後監査を実行します。LogMinerを使用して、データベースで実行されたデータ操作言語(DML)文およびデータ定義言語(DDL)文、これらの文が実行された順序、および文の実行者を追跡できます。(ただし、LogMinerをそのような目的に使用するには、そのイベントが発生した時期を知り、分析に適したログを指定できる必要があります。そうでない場合、多数のREDOログ・ファイルのマイニングが必要となり、時間がかかる場合があります。LogMinerの使用は、データベース使用の監査のための補助と考えてください。データベースの監査の詳細は、『Oracle Database管理者ガイド』を参照してください。
親トピック: REDOログ・ファイル分析のためのLogMinerの使用
22.2 LogMinerの概要
これらのトピックでは、LogMinerの概要を説明します。
- LogMinerの構成
LogMinerの構成の4つの基本オブジェクトについて説明します。 - LogMiner操作の指定および分析するデータの取得
LogMiner操作の指定にはPL/SQLパッケージDBMS_LOGMNR
およびDBMS_LOGMNR_D
を、分析するデータの取得にはV$LOGMNR_CONTENTS
ビューを使用します。
親トピック: REDOログ・ファイル分析のためのLogMinerの使用
22.2.1 LogMiner構成
LogMinerの構成の4つの基本オブジェクトについて説明します。
具体的には、ソース・データベース、マイニング・データベース、LogMinerディクショナリ、分析対象のデータが含まれるREDOログ・ファイルについてよく理解しておく必要があります。
-
ソース・データベースは、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は次のように表示します。
insert into "UNKNOWN"."OBJ# 45522"("COL 1","COL 2","COL 3","COL 4") values (HEXTORAW('45465f4748'),HEXTORAW('546563686e6963616c20577269746572'), HEXTORAW('c229'),HEXTORAW('c3020b'));
-
REDOログ・ファイルには、データベースまたはデータベース・ディクショナリに対して行われた変更が含まれます。
- LogMiner構成のサンプル
LogMinerの構成について説明します。 - LogMinerの要件
LogMinerでマイニングするデータベースのソースおよびマイニング・データベース、データ・ディクショナリ、REDOログ・ファイルおよび表と列の名前制限の要件について説明します。
親トピック: LogMinerの概要
22.2.1.1 LogMiner構成のサンプル
LogMinerの構成について説明します。
図22-1にサンプルLogMiner構成を示します。この図では、ボストンにあるソース・データベースでREDOログ・ファイルが生成され、アーカイブ後にサンフランシスコにあるデータベースに送られます。LogMinerディクショナリは、これらのREDOログ・ファイルに対して抽出されます。LogMinerが実際にREDOログ・ファイルを分析するマイニング・データベースは、サンフランシスコにあります。ボストンのデータベースでOracle Database 11gが実行され、サンフランシスコのデータベースでOracle Database 12cが実行されています。
図22-1は、有効なLogMiner構成の一例です。その他に有効な構成としては、ソース・データベースとマイニング・データベースの両方に同じデータベースを使用する構成、データ・ディクショナリを別の方法で提供する構成などがあります。他のデータ・ディクショナリ・オプションの詳細は、LogMinerディクショナリ・オプションを参照してください。
親トピック: LogMinerの構成
22.2.1.2 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文字以内にする必要があります。
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を使用します。
親トピック: LogMinerの構成
22.2.2 LogMiner操作の指定および分析するデータの取得
LogMiner操作の指定にはPL/SQLパッケージDBMS_LOGMNR
およびDBMS_LOGMNR_D
を、分析するデータの取得にはV$LOGMNR_CONTENTS
ビューを使用します。
例:
V$LOGMNR_CONTENTS
ビューを問い合せて、LogMiner PL/SQLパッケージを使用するには、EXECUTE_CATALOG_ROLE
ロールおよびLOGMINING
権限を持っている必要があります。
ノート:
Oracle RACデータベースで生成されたアーカイブ・ログ内で、指定された分析する時間範囲またはSCN範囲のマイニングを行う場合、指定の時間範囲またはSCN範囲でアクティブであった、すべてのREDOスレッドのすべてのアーカイブ・ログが指定されていることを確認する必要があります。指定されていない場合、V$LOGMNR_CONTENTS
という問合せによって、(DBMS_LOGMNR.ADD_LOGFILE
プロシージャを使用してLogMinerに指定されたアーカイブ・ログに基づき)部分的な結果のみが返されます。この制限事項は、CONTINUOUS_MINE
オプションを使用して、ソース・データベースでアーカイブ・ログをマイニングする場合にも適用されます。有効または無効なスレッドがない場合にのみ、Oracle RACデータベースでCONTINUOUS_MINE
オプションを使用する必要があります。
関連項目:
LogMinerの使用例は、「一般的なLogMinerセッションのステップ」を参照してください。
親トピック: LogMinerの概要
22.3 CDBのLogMinerの使用
LogMinerは、マルチテナント・コンテナ・データベース(CDB)で使用できます。
次の項では、CDBと非CDBでLogMinerの使用時に注意する必要がある相違点について説明します。
ルート・コンテナにすべてのPDBのスーパーセットの文字セットが含まれている場合、LogMinerでは異なる文字セットのPDBを含むCDBがサポートされます。
マルチテナント環境を管理するには、CDB_DBA
ロールを持っている必要があります。
- CDBでのLogMiner V$ビューおよびDBAビュー
CDBでは、システムで実行されているLogMinerセッションの情報を表示するためにLogMinerによって使用されるビューに、CON_ID
という追加の列が含まれます。 - CDBでのV$LOGMNR_CONTENTSビュー
CDBでは、V$LOGMNR_CONTENTS
ビューとその関連機能はルート・データベースに制限されています。V$LOGMNR_CONTENTS
には、CDBを支援するいくつかの新しい列が存在します。 - CDBでのサプリメンタル・ロギングの有効化
CDBで、データベース全体のサプリメンタル・ロギングを有効化および無効化する構文は、非CDBデータベースと同じです - CDBでのフラット・ファイル・ディクショナリの使用
単一のフラット・ファイルにCDB全体のディクショナリ・スナップショットを取得することはできません。個々のPDBに接続する必要があり、そのPDB専用のスナップショットをフラット・ファイルに取得できます。
関連項目:
-
CDBの詳細は、『Oracle Multitenant管理者ガイド』を参照してください
-
ビューの詳細は、『Oracle Databaseリファレンス』を参照してください。
親トピック: REDOログ・ファイル分析のためのLogMinerの使用
22.3.1 CDBでのLogMiner V$ビューおよびDBAビュー
CDBでは、システムで実行されているLogMinerセッションの情報を表示するためにLogMinerによって使用されるビューに、CON_ID
という追加の列が含まれます。
CON_ID列によって、情報が表示されるセッションに関連付けられたコンテナIDを識別します。プラガブル・データベース(PDB)のビューを問い合せると、データベースに関連付けられた情報のみが表示されます。この新しい動作の影響を受けるビューは次のとおりです。
-
V$LOGMNR_DICTIONARY_LOAD
-
V$LOGMNR_LATCH
-
V$LOGMNR_PROCESS
-
V$LOGMNR_SESSION
-
V$LOGMNR_STATS
ノート:
CDBをサポートするため、V$LOGMNR_CONTENTS
ビューには、CON_ID
以外にもいくつかの新しい列が含まれます。
次のDBAビューには、名前がCDBで始まる類似のCDBビューがあります。
ログ・ビューのタイプ | DBAビュー | CDBビュー |
---|---|---|
LogMinerログ・ビュー |
|
|
LogMinerパージ済ログ・ビュー |
|
|
LogMinerセッション・ログ・ビュー |
|
|
DBAビューには、問合せが行われたコンテナで定義されているセッションに関連する情報のみが表示されます。
CDBビューには、特定の行が表すデータを含むコンテナを識別する追加のCON_ID
列が含まれます。ルートからCDBビューを問い合せると、それらのビューを使用してすべてのコンテナに関する情報を参照できます。
親トピック: CDBのLogMinerの使用
22.3.2 CDBでのV$LOGMNR_CONTENTSビュー
CDBでは、V$LOGMNR_CONTENTS
ビューとその関連機能はルート・データベースに制限されています。V$LOGMNR_CONTENTS
には、CDBを支援するいくつかの新しい列が存在します。
-
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の使用
22.3.3 CDBでのサプリメンタル・ロギングの有効化
CDBで、データベース全体のサプリメンタル・ロギングを有効化および無効化する構文は、非CDBデータベースと同じです
例:
ALTER DATABASE [ADD|DROP] SUPPLEMENTAL LOG DATA ...
ただし、次のことに注意してください。
-
CDBでは、
CDB$ROOT
から有効にしたサプリメンタル・ロギング・レベルは、CDB全体で有効になります。 -
少なくとも最小サプリメンタル・ロギングが
CDB$ROOT
で有効になっている場合、追加のサプリメンタル・ロギング・レベルをPDBレベルで有効にできます。 -
CDB$ROOT
からCDBレベルで有効にしたサプリメンタル・ロギング・レベルは、PDBレベルでは無効にできません。 -
CDB$ROOT
からすべてのサプリメンタル・ロギングを削除した場合、以前のPDBレベルの設定に関係なく、CDB全体ですべてのサプリメンタル・ロギングが無効になります。
CREATE TABLE
およびALTER TABLE
文で開始するサプリメンタル・ロギング操作は、ルート・データベースまたはPDBから実行可能で、適用先の表のみが影響を受けます。
親トピック: CDBのLogMinerの使用
22.3.4 CDBでのフラット・ファイル・ディクショナリの使用
単一のフラット・ファイルにCDB全体のディクショナリ・スナップショットを取得することはできません。個々のPDBに接続する必要があり、そのPDB専用のスナップショットをフラット・ファイルに取得できます。
したがって、フラット・ファイル・ディクショナリを使用する場合、データ・ディクショナリがフラット・ファイル内に含まれるPDBに関連付けられた変更を対象とするREDOログのみをマイニングできます。
親トピック: CDBのLogMinerの使用
22.4 LogMinerディクショナリ・ファイルとREDOログ・ファイル
LogMinerを使用する前に、LogMinerがLogMinerディクショナリ・ファイルおよびREDOログ・ファイルとともにどのように動作するかを理解しておくことが重要です。これは、正確な結果の取得と、システム・リソースの使用計画の作成に役立ちます。
この項では、次の概念について説明します。
- LogMinerディクショナリ・オプション
LogMinerは、REDOデータをユーザーに返す際に、オブジェクトIDをオブジェクト名に変換するためにディクショナリを必要とします。 - REDOログ・ファイル・オプション
REDOログ・ファイルにあるデータをマイニングするには、LogMinerは、マイニングするREDOログ・ファイルの情報を必要とします。
親トピック: REDOログ・ファイル分析のためのLogMinerの使用
22.4.1 LogMinerディクショナリ・オプション
LogMinerは、REDOデータをユーザーに返す際に、オブジェクトIDをオブジェクト名に変換するためにディクショナリを必要とします。
LogMinerには、ディクショナリ提供方法として次の3つのオプションがあります。
-
REDOログ・ファイルが作成されたソース・データベースにアクセスでき、分析する表の列定義に変更がないことが見込まれる場合には、このオプションの使用をお薦めします。このオプションは、最も効率的で簡単に使用できます。
-
REDOログ・ファイルへのLogMinerディクショナリの抽出
REDOログ・ファイルが作成されたソース・データベースにアクセスできない場合、または分析する表の列定義が変更される可能性がある場合には、このオプションの使用をお薦めします。
-
このオプションは、以前のリリースとの下位互換性を保つものです。このオプションは、トランザクションの一貫性を保証しません。オンライン・カタログを使用するか、REDOログ・ファイルにディクショナリを抽出することをお薦めします。
図22-2に、状況に合わせたLogMinerディクショナリの選択方法を示します。
次の項では、使用可能な各ディクショナリ・オプションの指定方法を説明します。
- オンライン・カタログの使用
データベースで現在使用中のディクショナリを使用することをLogMinerに指定するには、LogMiner起動時にディクショナリ・ソースとしてオンライン・カタログを指定します。 - REDOログ・ファイルへのLogMinerディクショナリの抽出
REDOログ・ファイルにLogMinerディクショナリを抽出するには、データベースがオープンしていて、ARCHIVELOG
モードの状態で、アーカイブが有効になっている必要があります。 - フラット・ファイルへのLogMinerディクショナリの抽出
LogMinerディクショナリがフラット・ファイルに存在する場合、REDOログ・ファイルに存在する場合よりもシステム・リソースの消費が少なくなります。古いREDOログ・ファイルを正しく分析できるように、定期的にディクショナリ抽出のバックアップを取ることをお薦めします。
22.4.1.1 オンライン・カタログの使用
データベースで現在使用中のディクショナリを使用することをLogMinerに指定するには、LogMiner起動時にディクショナリ・ソースとしてオンライン・カタログを指定します。
例:
EXECUTE DBMS_LOGMNR.START_LOGMNR(- OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG);
オンライン・カタログは、オンラインREDOログ・ファイルの分析に使用する他にも、アーカイブREDOログ・ファイルが同じシステム上で生成されている場合には、アーカイブREDOログ・ファイルの分析に使用できます。
オンライン・カタログにはデータベースに関する最新情報が含まれており、分析を開始するには最も速い方法です。重要な表を変更するDDL操作は頻繁に行われないため、通常、オンライン・カタログには分析に必要な情報が提供されています。
ただし、オンライン・カタログが再構成できるのは、表の最新バージョンに対して実行されるSQL文のみであることに注意してください。表が変更されると、オンライン・カタログは以前の表のバージョンを反映しなくなります。つまり、LogMinerは、以前の表のバージョンに対して実行されたSQL文を再構築することはできません。かわりに、LogMinerは、次に示すV$LOGMNR_CONTENTS
ビューのSQL_REDO
列で実行不可SQL(バイナリ値のhextoraw書式を含む)を生成します。
insert into HR.EMPLOYEES(col#1, col#2) values (hextoraw('4a6f686e20446f65'), hextoraw('c306'));"
オンライン・カタログ・オプションでは、データベースがオープンしている必要があります。
オンライン・カタログ・オプションは、DBMS_LOGMNR.START_LOGMNR
のDDL_DICT_TRACKING
オプションに対し有効ではありません。
親トピック: LogMinerディクショナリ・オプション
22.4.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);
関連項目:
-
ARCHIVELOG
モードの詳細は、『Oracle Database管理者ガイド』を参照してください。 -
DBMS_LOGMNR_D.BUILD
の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
ディクショナリを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ログ・ファイルのバックアップとリストアのためのプロセスがすでに整っているため、そのための特別なステップは必要ありません。バックアップ作業も時間がかかる作業のため、ピークを外した時間帯に実行することをお薦めします。
親トピック: LogMinerディクショナリ・オプション
22.4.1.3 フラット・ファイルへのLogMinerディクショナリの抽出
LogMinerディクショナリがフラット・ファイルに存在する場合、REDOログ・ファイルに存在する場合よりもシステム・リソースの消費が少なくなります。古いREDOログ・ファイルを正しく分析できるように、定期的にディクショナリ抽出のバックアップを取ることをお薦めします。
データベース・ディクショナリ情報をフラット・ファイルに抽出するには、STORE_IN_FLAT_FILE
オプションを指定してDBMS_LOGMNR_D.BUILD
プロシージャを実行します。
ディクショナリをフラット・ファイルに抽出するステップは、次のとおりです。ステップ1と2は準備のためのステップです。これらは、1回のみの実行で、以後は何回でもディクショナリをフラット・ファイルに抽出できます。
親トピック: LogMinerディクショナリ・オプション
22.4.2 REDOログ・ファイル・オプション
REDOログ・ファイルにあるデータをマイニングするには、LogMinerは、マイニングするREDOログ・ファイルの情報を必要とします。
これらのREDOログ・ファイルで検出されたデータベースに対する変更は、V$LOGMNR_CONTENTS
ビューを介してユーザーに表示されます。
分析するREDOログ・ファイルのリストを自動的かつ動的に作成するようにLogMinerに対して指定したり、LogMinerが分析するREDOログ・ファイルのリストを明示的に指定することができます。その方法は次のとおりです。
-
自動
LogMinerをソース・データベースで使用する場合、LogMinerに対して、分析するREDOログ・ファイルを自動的に検出し、リストを作成するように指定できます。それには、
DBMS_LOGMNR.START_LOGMNR
プロシージャでLogMinerを起動するときに、CONTINUOUS_MINE
オプションを使用し、時間範囲またはSCN範囲を指定します。この例では、オンライン・カタログからのディクショナリを指定していますが、任意のLogMinerディクショナリを使用できます。(CONTINUOUS_MINE
オプションでは、データベースがマウントされ、アーカイブが使用可能である必要があります。 )ノート:
Oracle Database 12c
リリース2 (12.2.0.1)からは、LogMinerCONTINUOUS_MINE
オプションが非推奨になりました。これは下位互換性の理由から引き続きサポートされていますが、使用しないことをお薦めします。かわりとなる機能はありません。LogMinerは、データベース制御ファイルを使用して、指定された時間範囲またはSCN範囲を満たすREDOログ・ファイルを検出し、LogMiner REDOログ・ファイル・リストに追加します。例:
ALTER SESSION SET NLS_DATE_FORMAT = 'DD-MON-YYYY HH24:MI:SS'; EXECUTE DBMS_LOGMNR.START_LOGMNR( - STARTTIME => '01-Jan-2012 08:30:00', - ENDTIME => '01-Jan-2012 08:45:00', - OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG + - DBMS_LOGMNR.CONTINUOUS_MINE);
(この例では、
DBMS_LOGMNR.START_LOGMNR
プロシージャに対するPL/SQLコールで日付書式を指定する必要がないように、最初にSQLALTER
SESSION SET
NLS_DATE_FORMAT
文を使用しています。)LogMiner起動時に、
DBMS_LOGMNR.ADD_LOGFILE
を使用して1つのREDOログ・ファイルのみを指定し、CONTINUOUS_MINE
オプションを指定しても、分析するREDOログ・ファイルのリストをLogMinerに自動的に作成させることができます。ただし、最初に説明した方法がより一般的です。 -
手動
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行で構成しています。
22.5 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
- 「LogMinerの起動」を参照 -
CONTINUOUS_MINE
- 「REDOログ・ファイル・オプション」を参照 -
COMMITTED_DATA_ONLY
- 「コミット済トランザクションのみの表示」を参照 -
SKIP_CORRUPTION
- 「REDO破損のスキップ」を参照 -
NO_SQL_DELIMITER
- 「再実行のために再構築されたSQL文の書式設定」を参照 -
PRINT_PRETTY_SQL
- 「返されるデータの可読性向上のための表示方法の書式設定」を参照 -
NO_ROWID_IN_STMT
- 「再実行のために再構築されたSQL文の書式設定」を参照 -
DDL_DICT_TRACKING
- 「LogMinerディクショナリでのDDL文の追跡」を参照
DBMS_LOGMNR.START_LOGMNR
プロシージャの実行時には、指定されたパラメータとオプションの組合せが有効かどうか、指定されたディクショナリとREDOログ・ファイルが使用可能かどうかがLogMinerによりチェックされます。ただし、V$LOGMNR_CONTENTS
ビューは、「V$LOGMNR_CONTENTSビューへの移入方法」で説明するとおり、このビューを問い合せるまで移入されません。
パラメータおよびオプションは、次回のDBMS_LOGMNR.START_LOGMNR
へのコールでは保持されません。DBMS_LOGMNR.START_LOGMNR
をコールするたびに、必要なパラメータおよびオプション(SCN範囲や時間範囲を含む)をすべて指定する必要があります。
親トピック: REDOログ・ファイル分析のためのLogMinerの使用
22.6 分析するREDOデータについてのV$LOGMNR_CONTENTSの問合せ
分析するREDOデータにアクセスするには、V$LOGMNR_CONTENTS
ビューを問い合せます。
(V$LOGMNR_CONTENTS
を問い合せるには、SYSDBA
またはLOGMINING
権限が必要なことに注意してください。)このビューは、データベースに対して行われた変更に関する次のような履歴情報を提供します(次に示す以外の情報もあります)。
-
データベースに対して行われた変更のタイプ:
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はサポートされません。
関連項目:
TDEの詳細は、『Oracle Database Advanced Securityガイド』を参照してください。
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
のいずれかです。
- V$LOGMNR_CONTENTSビューへの移入方法
V$LOGMNR_CONTENTS
固定ビューは、他のビューと異なり、表に格納されたデータの選択的表示ではありません。ユーザーがREDOログ・ファイルに対して要求したデータのリレーショナルな表示です。 - 列の値に基づいたV$LOGMNR_CONTENTSの問合せ
LogMinerは、列の値に基づいた問合せを行うことができます。 - XMLType列およびXMLType表に基づいたV$LOGMNR_CONTENTSの問合せ
LogMinerでは、XMLType
列に対して生成されるREDOがサポートされます。CLOB
として格納されるXMLType
データは、11.0.0.0以上の互換性設定で生成されたREDOに対してサポートされます。
親トピック: REDOログ・ファイル分析のためのLogMinerの使用
22.6.1 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順は、メディア・リカバリで通常適用される順序です。
関連項目:
DBMS_LOGMNR.START_LOGMNR
に対するCOMMITTED_DATA_ONLY
オプションの詳細は、「コミット済トランザクションのみの表示」を参照してください。
ノート:
LogMinerは、問合せに応答する場合にのみV$LOGMNR_CONTENTS
ビューに移入し、要求したデータをデータベースに格納しないため、次の条件が適用されます。
-
V$LOGMNR_CONTENTS
を問い合せるたびに、LogMinerは、要求したデータのREDOログ・ファイルを分析します。 -
問合せで消費されるメモリー量は、問合せを満たすために返す必要がある行数によっては異なりません。
-
要求したデータを返すためにかかる時間は、そのデータを検出するためにマイニングする必要があるREDOログ・データの量および型によって異なります。
前述の理由から、さらに分析を行うためにデータを保持する必要がある場合、特に問合せによって返されるデータの量が、そのデータを提供するためにLogMinerによって分析されるREDOデータの量と比較して少ない場合は、V$LOGMNR_CONTENTS
という問合せの結果を一時的に格納する表を作成することをお薦めします。
22.6.2 列の値に基づいたV$LOGMNR_CONTENTSの問合せ
LogMinerは、列の値に基づいた問合せを行うことができます。
たとえば、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部分とは、挿入、更新または削除操作前に列に存在していたデータです。REDO_VALUE
は新しい値、UNDO_VALUE
は古い値と考えてください。 -
2番目の引数は、マイニングする列の完全修飾名を指定する文字列(この場合は、
hr.employees.salary
)です。MINE_VALUE
関数からは、常に、元のデータ型に戻すことができる文字列が返されます。
- MINE_VALUE関数によって返されるNULL値の意味
MINE_VALUE
関数によって返されるNULL
値の意味を説明します。 - MINE_VALUE関数およびCOLUMN_PRESENT関数の使用規則
MINE_VALUE
関数およびCOLUMN_PRESENT
関数に適用される使用規則を説明します。 - MINE_VALUEファンクションを使用してNCHAR値を取得する際の制限事項
MINE_VALUE
ファンクションを使用する際の制限事項について説明します。
22.6.2.1 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;
22.6.2.2 MINE_VALUE関数およびCOLUMN_PRESENT関数の使用規則
MINE_VALUE
関数およびCOLUMN_PRESENT
関数に適用される使用規則を説明します。
具体的には次のとおりです。
-
LogMinerセッション内でのみ使用できます。
-
V$LOGMNR_CONTENTS
ビューからの選択操作中に起動する必要があります。 -
LONG
、LONG RAW
、CLOB
、BLOB
、NCLOB
、ADT
またはCOLLECTION
データ型はサポートされません。
22.6.3 XMLType列およびXMLType表に基づいたV$LOGMNR_CONTENTSの問合せ
LogMinerでは、XMLType
列に対して生成されるREDOがサポートされます。CLOB
として格納されるXMLType
データは、11.0.0.0以上の互換性設定で生成された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)からは非推奨になりました。
XMLType列を使用した表に対して行われた変更についてのV$LOGMNR_CONTENTSの問合せ
この項の例では、次の列を使用したXML_CLOB_COL_TAB
という表について説明します。
-
f1
NUMBER
-
f2
VARCHAR2(100)
-
f3
XMLTYPE
-
f4
XMLTYPE
-
f5
VARCHAR2(10)
ログおよびCOMMITTED_DATA_ONLY
オプションを使用して、LogMinerセッションを起動したとします。XML_CLOB_COL_TAB
表に対して行われた変更について、V$LOGMNR_CONTENTS
に対して次の問合せが実行されます。
SELECT OPERATION, STATUS, SQL_REDO FROM V$LOGMNR_CONTENTS WHERE SEG_OWNER = 'SCOTT' AND TABLE_NAME = 'XML_CLOB_COL_TAB';
問合せの出力は、次のようになります。
OPERATION STATUS SQL_REDO INSERT 0 insert into "SCOTT"."XML_CLOB_COL_TAB"("F1","F2","F5") values ('5010','Aho40431','PETER') XML DOC BEGIN 5 update "SCOTT"."XML_CLOB_COL_TAB" a set a."F3" = XMLType(:1) where a."F1" = '5010' and a."F2" = 'Aho40431' and a."F5" = 'PETER' XML DOC WRITE 5 XML Data XML DOC WRITE 5 XML Data XML DOC WRITE 5 XML Data XML DOC END 5
XML DOC WRITE
操作のSQL_REDO
列には、XML文書の実際のデータがあります。データは文字列'XML Data'ではありません。
XMLType
列を使用した表に挿入するための一般的なモデルを示すこの出力は、次のようになります。
-
すべてのスカラー列を使用した最初の挿入
-
バインド変数を使用して、1つの
XMLType
列に値を設定する更新文を使用したXML DOC BEGIN
操作。 -
XML文書のデータを使用した1回以上の
XML DOC WRITE
操作 -
XML文書のすべてのデータが送信されたことを示す
XML DOC END
操作 -
表に複数の
XMLType
列がある場合は、元のDMLによって変更されるそれぞれのXMLType
列に対して、ステップ2から4が繰り返されます。
XML文書が表外の列として格納されていない場合、その列に対してXML DOC BEGIN
、XML DOC WRITE
またはXML DOC END
操作は行われません。文書は、次のような更新文に含まれます。
OPERATION STATUS SQL_REDO UPDATE 0 update "SCOTT"."XML_CLOB_COL_TAB" a set a."F3" = XMLType('<?xml version="1.0"?> <PO pono="1"> <PNAME>Po_99</PNAME> <CUSTNAME>Dave Davids</CUSTNAME> </PO>') where a."F1" = '5006' and a."F2" = 'Janosik' and a."F5" = 'MMM'
XMLType表に対して行われた変更についてのV$LOGMNR_CONTENTSの問合せ
XMLType
表に対するDMLは、XMLType
列に対するDMLとは多少異なります。XML文書では、XMLType
表の行に対する値を表します。XMLType
列の場合とは異なり、最初の挿入に続いてXML文書を含む更新を行うことはできません。データを表に挿入する前に、文書全体を作成する必要があります。
XMLType
表のもう1つの相違点は、OBJECT_ID
列の存在です。オブジェクト識別子は、オブジェクト表の各オブジェクトを一意に識別するために使用されます。XMLType
表については、表に行が挿入されると、Oracle Databaseによってこの値が生成されます。OBJECT_ID
の値は、SQLを使用して表に直接挿入することはできません。したがって、LogMinerでは、この値を含む実行可能なSQL_REDO
を生成できません。
V$LOGMNR_CONTENTS
ビューには、XMLType
表に対して行われた変更に対して移入される新しいOBJECT_ID
列があります。この値は、元の表のオブジェクト識別子です。ただし、この同じXML文書が同じXMLType
表に挿入されても、新しいオブジェクト識別子が生成されます。XMLType
表における更新や削除などの次のDMLのSQL_REDO
には、WHERE
句に元の表の行を一意に識別するためのオブジェクト識別子が含まれます。
- XMLTypeデータを使用するLogMinerの使用上の制限
XMLTypeデータを使用するLogMinerの使用上の制限を説明します。 - XMLTypeデータを作成するためのPL/SQLプロシージャの例
表外のXMLデータを含む表に対してXML REDOをマイニングおよび作成するのに使用可能なプロシージャについて説明する例。
22.6.3.1 XMLTypeデータを使用するLogMinerの使用上の制限
XMLTypeデータを使用するLogMinerの使用上の制限を説明します。
XMLType
データのマイニングは、DBMS_LOGMNR.COMMITTED_DATA_ONLY
オプションを使用している場合にのみ行う必要があります。そうしないと、一部の行の変更が不足しているために、不完全な変更が表示されたり、XMLとして表示されるはずの変更がCLOB
の変更として表示される可能性があります。このために、これらのSQL DML文に対するSQL_REDO
が不完全かつ無効になってしまいます。
SQL_UNDO
列は、XMLType
データへの変更に対して移入されません。
22.6.3.2 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'
22.7 V$LOGMNR_CONTENTSに返されるデータのフィルタ処理および書式設定
LogMinerは、大量の情報を処理できます。V$LOGMNR_CONTENTS
ビューに返される情報、および情報が返される速度を制限できます。
次の項では、これらの制限を指定する方法、およびV$LOGMNR_CONTENTS
を問い合せた場合に返されるデータへのその制限の影響を示します。
また、LogMinerには、V$LOGMNR_CONTENTS
に返されたデータを書式設定するための機能もあります。この機能については、次の項を参照してください。
これらのフィルタ処理機能および書式設定機能は、DBMS_LOGMNR.START_LOGMNR
プロシージャのパラメータまたはオプションを使用して要求します。
- コミット済トランザクションのみの表示
DBMS_LOGMNR.START_LOGMNR
に対してCOMMITTED_DATA_ONLY
オプションを使用した場合、コミット済トランザクションに属する行のみがV$LOGMNR_CONTENTS
ビューに表示されます。 - REDO破損のスキップ
DBMS_LOGMNR.START_LOGMNR
に対してSKIP_CORRUPTION
オプションを使用した場合、V$LOGMNR_CONTENTS
ビューからの選択操作中、REDOログ・ファイル内の破損はすべてスキップされます。 - 時刻によるデータのフィルタ処理
データを時刻でフィルタ処理するには、DBMS_LOGMNR.START_LOGMNR
プロシージャにSTARTTIME
パラメータおよびENDTIME
パラメータを設定します。 - SCNによるデータのフィルタ処理
データをSCN(システム変更番号)でフィルタ処理するには、PL/SQLDBMS_LOGMNR.START_LOGMNR
プロシージャに対してSTARTSCN
パラメータおよびENDSCN
パラメータを使用します。 - 再実行のために再構築されたSQL文の書式設定
デフォルトでは、再構築されるSQL_REDO
文およびSQL_UNDO
文にはROWID
句が含まれ、それらの文はセミコロンで終わります。 - 返されるデータの可読性向上のための表示方法の書式設定
LogMinerには、読みやすくするために返されたデータの外観を書式設定するPRINT_PRETTY_SQL
オプションが用意されています。
親トピック: REDOログ・ファイル分析のためのLogMinerの使用
22.7.1 コミット済トランザクションのみの表示
DBMS_LOGMNR.START_LOGMNR
に対してCOMMITTED_DATA_ONLY
オプションを使用した場合、コミット済トランザクションに属する行のみがV$LOGMNR_CONTENTS
ビューに表示されます。
このオプションを使用すると、ロールバックされたトランザクション、進行中のトランザクションおよび内部操作をフィルタ処理して除外できます。
このオプションを有効にするには、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の使用例」を参照してください。
22.7.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
22.7.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-2012 08:30:00', - ENDTIME => '01-Jan-2012 08:45:00'- OPTIONS => DBMS_LOGMNR.CONTINUOUS_MINE);
タイムスタンプは、REDOレコードの順序の推測には使用しないでください。REDOレコードの順序は、SCNを使用して推測できます。
関連項目:
-
時刻によるデータのフィルタ処理の例の詳細は、「LogMinerの使用例」を参照してください。
-
開始時刻および終了時刻を指定し、その指定時刻がLogMiner REDOログ・ファイル・リストで検出されなかった場合に発生する状態、およびこれらのパラメータと
CONTINUOUS_MINE
オプションとの相互作用の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
22.7.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 + - DBMS_LOGMNR.CONTINUOUS_MINE);
STARTSCN
パラメータおよびENDSCN
パラメータは、すべてのパラメータを指定した場合、STARTTIME
パラメータおよびENDTIME
パラメータより優先されます。
関連項目:
-
SCNによるデータのフィルタ処理の例の詳細は、「LogMinerの使用例」を参照してください。
-
開始値およびSCN値を指定し、その値がLogMiner REDOログ・ファイル・リストで検出されなかった場合に発生する状態、およびこれらのパラメータと
CONTINUOUS_MINE
オプションとの相互作用の詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
22.7.5 再実行のために再構築されたSQL文の書式設定
デフォルトでは、再構築されるSQL_REDO
文およびSQL_UNDO
文にはROWID
句が含まれ、それらの文はセミコロンで終わります。
ただし、次のようにこのデフォルト設定を上書きできます。
-
LogMiner起動時に
NO_ROWID_IN_STMT
オプションを指定します。この指定によって、再構築される文から
ROWID
句が除外されます。行IDはデータベース間で一貫性がないため、最初に実行したデータベースと異なるデータベースに対してSQL_REDO
文またはSQL_UNDO
文を再実行する場合は、LogMiner起動時にNO_ROWID_IN_STMT
オプションを指定します。 -
LogMiner起動時に
NO_SQL_DELIMITER
オプションを指定します。この指定によって、再構築される文からセミコロンが削除されます。この指定は、カーソルでオープンしてから、再構築された文を実行するアプリケーションに有効です。
V$LOGMNR_CONTENTS
ビューSTATUS
フィールドに値2
(invalid sql
)が含まれている場合、関連付けられたSQL文は実行できません。
22.7.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構文を使用していないため、実行されません。
関連項目:
PRINT_PRETTY_SQL
オプションの使用例の詳細は、「LogMinerの使用例」を参照してください。
22.8 V$LOGMNR_CONTENTSに返されたDDL文の再適用
ユーザーが発行した一部のDDL文によって、1つ以上の他のDDL文がOracleによって内部的に実行される場合があります。
V$LOGMNR_CONTENTS
ビューのSQL_REDO
列またはSQL_UNDO
列から、データベースに対して最初に適用したときと同様にSQL DDLを再適用する場合は、Oracleによって内部的に実行された文は実行しないでください。
ノート:
Oracleによって内部的に実行されたDML文を実行すると、データベースが破損する場合があります。例については、「例4: REDOログ・ファイル内のLogMinerディクショナリの使用」のステップ5を参照してください。
ユーザーによって発行されたDDL文と、Oracleによって内部的に発行されたDDL文を区別するには、V$LOGMNR_CONTENTS
のINFO
列を問い合せます。INFO
列の値は、DDLがユーザーによって実行されたか、Oracleによって実行されたかを示します。
最初に適用したときと同様にSQL DDLを再適用する場合は、INFO
列に値USER_DDL
が含まれる場合にのみ、V$LOGMNR_CONTENTS
のSQL_REDO
列またはSQL_UNDO
列に含まれるDDL SQLを再実行する必要があります。
親トピック: REDOログ・ファイル分析のためのLogMinerの使用
22.9 DBMS_LOGMNR.START_LOGMNRの複数回のコール
DBMS_LOGMNR.START_LOGMNR
のコールに成功し、V$LOGMNR_CONTENTS
ビューから選択した後でも、現在のLogMinerセッションを終了せずにDBMS_LOGMNR.START_LOGMNR
を再度コールし、異なるオプションおよび時間範囲またはSCN範囲を指定できます。
次の場合にコールを複数回行います。
-
LogMinerが分析するREDOデータの量を制限する。
-
異なるオプションを指定する。たとえば、
PRINT_PRETTY_SQL
オプションを指定する場合、コミット済トランザクションのみを表示する場合(COMMITTED_DATA_ONLY
オプションを指定)などがあります。 -
分析する時間範囲またはSCN範囲を変更する。
例: DBMS_LOGMNR.START_LOGMNRの複数回のコール
次に、DBMS_LOGMNR.START_LOGMNR
を複数回コールすると有効な例を示します。
例1: REDOログ・ファイルのデータのサブセットのみのマイニング
LogMinerがマイニングするREDOログ・ファイルのリストに、1週間の間に生成されたログ・ファイルが含まれているとします。ただし、それぞれの日の12:00から1:00の間に生成されたログ・ファイルのみを分析します。これを最も効率的に行う方法は次のとおりです。
-
月曜日に、この時間範囲を指定して、
DBMS_LOGMNR.START_LOGMNR
をコールします。 -
V$LOGMNR_CONTENTS
ビューから変更を選択します。 -
一週間のそれぞれの日に対して、ステップ1と2を繰り返します。
この方法では、その週のREDOデータの合計量が多い場合、リスト内の各REDOログ・ファイルの小さなサブセットのみがLogMinerによって読み込まれるため、全体の分析が非常に速く行われます。
例2: 時間範囲またはSCN範囲の調整
REDOログ・ファイル・リストを指定し、LogMiner起動時に時間範囲(またはSCN範囲)を指定するとします。V$LOGMNR_CONTENTS
ビューを問い合せると、指定した時間範囲には、必要なデータの一部のみが含まれます。時間範囲を1時間拡張するために、またはSCN範囲を調整するためにDBMS_LOGMNR.START_LOGMNR
を再度コールできます。
例3: リモート・データベースで受信された場合のREDOログ・ファイルの分析
変更を分析またはデータベース間で変更をレプリケートするためのアプリケーションを作成したとします。ソース・データベースは、そのREDOログ・ファイルをマイニング・データベースに送信し、オペレーティング・システム・ディレクトリに格納します。アプリケーションは、次の手順を実行します。
-
現在ディレクトリにあるすべてのREDOログ・ファイルをREDOログ・ファイル・リストに追加します。
-
適切な設定で
DBMS_LOGMNR.START_LOGMNR
をコールし、V$LOGMNR_CONTENTS
ビューから選択します。 -
ディレクトリに新しく受信されたREDOログ・ファイルを追加します。
-
必要に応じて、ステップ2と3を繰り返します。
親トピック: REDOログ・ファイル分析のためのLogMinerの使用
22.10 サプリメンタル・ロギング
サプリメンタル・ロギングについて説明します。
一般に、REDOログ・ファイルは、インスタンス・リカバリおよびメディア・リカバリに使用されます。これらの操作に必要なデータは、REDOログ・ファイルに自動的に記録されます。ただし、REDOベースのアプリケーションでは、追加の列をREDOログ・ファイルに記録する必要がある場合があります。これらの追加の列を記録するプロセスは、サプリメンタル・ロギングと呼ばれます。
デフォルトでは、Oracle Databaseでサプリメンタル・ロギングは提供されません。つまり、デフォルトでは、LogMinerは使用できません。したがって、LogMinerで分析するログ・ファイルを生成する前に、少なくとも最小サプリメンタル・ロギングは有効にする必要があります。
次に、追加の列が必要な例を示します。
-
再構築されたSQL文を別のデータベースに適用するアプリケーションでは、行を一意に識別する列(主キーなど)で更新文を識別する必要があります。
ROWID
はデータベースごとに異なり、他のデータベースでは意味を持たないため、V$LOGMNR_CONTENTS
ビューによって返される再構築されたSQLに示されるROWID
では識別できません。 -
アプリケーションは、行変更の追跡をより効率的にするために、変更された列のみでなく、行全体のビフォア・イメージを記録する必要がある場合があります。
サプリメンタル・ログ・グループは、サプリメンタル・ロギングが有効な場合に記録される追加の列です。サプリメンタル・ログ・グループは2種類あり、これらによって、ログ・グループの列を記録する時期が決定されます。
-
無条件のサプリメンタル・ログ・グループ: 指定した列に更新が影響したかどうかに関係なく、行が更新されるたびに指定した列のビフォア・イメージが記録されます。これは、ALWAYSログ・グループと呼ばれる場合もあります。
-
条件付きのサプリメンタル・ログ・グループ: ログ・グループの1つ以上の列が更新された場合にのみ、指定したすべての列のビフォア・イメージが記録されます。
サプリメンタル・ログ・グループは、システムで生成することも、ユーザーが定義することもできます。
次の項で説明するとおり、サプリメンタル・ロギングには、2つの種類に加えて2つのレベルがあります。
- データベース・レベルのサプリメンタル・ロギング
LogMinerには、これらの項で説明するとおり、最小サプリメンタル・ロギング、識別キー・ロギングおよびプロシージャ型サプリメンタル・ロギングの異なるタイプのデータベース・レベルのサプリメンタル・ロギングがあります。 - データベース・レベルのサプリメンタル・ロギングの無効化
データベース・レベルのサプリメンタル・ロギングを無効にするには、DROP SUPPLEMENTAL LOGGING
句を指定してSQLALTER DATABASE
文を使用します。 - 表レベルのサプリメンタル・ロギング
表レベルのサプリメンタル・ロギングでは、補助的に記録する列を表レベルで指定します。 - LogMinerディクショナリでのDDL文の追跡
LogMinerでは、LogMiner起動時に指定したLogMinerディクショナリ(オンライン・カタログ、REDOログ・ファイルのディクショナリまたはフラット・ファイルのいずれか)から独自の内部ディクショナリが自動的に作成されます。 - DDL_DICT_TRACKINGおよびサプリメンタル・ロギングの設定
ディクショナリ追跡とサプリメンタル・ロギングの各種設定を組み合せた場合に発生する相互作用を説明します。 - DDL_DICT_TRACKINGおよび指定された時間範囲またはSCN範囲
LogMinerは、LogMinerディクショナリの一貫性を維持するためにDDL文が必要なため、DDL_DICT_TRACKING
オプションが有効な場合、要求した開始時刻またはSCN(DBMS_LOGMNR.START_LOGMNR
で指定)より前に、REDOログ・ファイルの読取りを開始する場合があります。
親トピック: REDOログ・ファイル分析のためのLogMinerの使用
22.10.1 データベース・レベルのサプリメンタル・ロギング
LogMinerには、これらの項で説明するとおり、最小サプリメンタル・ロギング、識別キー・ロギングおよびプロシージャ型サプリメンタル・ロギングの異なるタイプのデータベース・レベルのサプリメンタル・ロギングがあります。
最小サプリメンタル・ロギングでは、REDOログ・ファイルを生成するデータベースに大きなオーバーヘッドが発生しません。ただし、データベース全体の識別キー・ロギングを有効にすると、REDOログ・ファイルを生成するデータベースにオーバーヘッドが発生する場合があります。LogMinerに対しては、少なくとも最小サプリメンタル・ロギングを有効にすることをお薦めします。
- 最小サプリメンタル・ロギング
最小サプリメンタル・ロギングは、LogMinerでDML変更と関連付けられたREDO操作を識別、グループ化およびマージするために必要な最小限の情報を記録します。 - データベース・レベルの識別キー・ロギング
識別キー・ロギングは、REDOログ・ファイルがソース・データベース・インスタンスでマイニングされない場合(REDOログ・ファイルがロジカル・スタンバイ・データベースでマイニングされる場合など)に必要です。 - プロシージャ型サプリメンタル・ロギング
プロシージャ型サプリメンタル・ロギングを有効にすると、ローリング・アップグレードまたはOracle GoldenGateでレプリケートできるように、LogMinerによって特定のプロシージャ起動がREDOに記録されます。
親トピック: サプリメンタル・ロギング
22.10.1.1 最小サプリメンタル・ロギング
最小サプリメンタル・ロギングは、LogMinerでDML変更と関連付けられたREDO操作を識別、グループ化およびマージするために必要な最小限の情報を記録します。
また、LogMiner(およびLogMinerテクノロジに基づいた他の製品)に、連鎖行や様々な記憶域構成(クラスタ表、索引構成表など)のサポートに十分な情報を確保します。最小サプリメンタル・ロギングを有効にするには、次のSQL文を実行します。
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
親トピック: データベース・レベルのサプリメンタル・ロギング
22.10.1.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;
親トピック: データベース・レベルのサプリメンタル・ロギング
22.10.1.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
プロシージャ型サプリメンタル・ロギングが有効になっている場合、プロシージャ型サプリメンタル・ロギングを先に削除しないかぎり、最小サプリメンタル・ロギングを削除できません。
親トピック: データベース・レベルのサプリメンタル・ロギング
22.10.2 データベース・レベルのサプリメンタル・ロギングの無効化
データベース・レベルのサプリメンタル・ロギングを無効にするには、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;
最小サプリメンタル・ログ・データは、データベース・レベルの他のサプリメンタル・ロギングが有効になっていない場合にのみ削除できます。
親トピック: サプリメンタル・ロギング
22.10.3 表レベルのサプリメンタル・ロギング
表レベルのサプリメンタル・ロギングでは、補助的に記録する列を表レベルで指定します。
識別キー・ロギングまたはユーザー定義の条件付きのサプリメンタル・ログ・グループまたは無条件のサプリメンタル・ログ・グループを使用して、次の項で説明するとおり、補助情報を記録できます。
- 表レベルの識別キー・ロギング
表レベルでの識別キー・ロギングでは、データベース・レベルの場合と同じオプション(すべて、主キー、外部キー、一意キー)が提供されます。 - 表レベルのユーザー定義サプリメンタル・ログ・グループ
表レベルの識別キー・ロギングに加えて、ユーザー定義のサプリメンタル・ログ・グループもサポートされています。 - ユーザー定義のサプリメンタル・ログ・グループを使用する場合のノート
ユーザー定義のサプリメンタル・ログ・グループを使用するためのヒント。
親トピック: サプリメンタル・ロギング
22.10.3.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;
各識別キー・ロギング・オプションの詳細は、「データベース・レベルの識別キー・ロギング」を参照してください。
親トピック: 表レベルのサプリメンタル・ロギング
22.10.3.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
列自体は補助的に記録できませんが、この列に対して行った変更を使用して、同じ行の他の列のサプリメンタル・ロギングをトリガーすることはできます。
親トピック: 表レベルのサプリメンタル・ロギング
22.10.3.3 ユーザー定義のサプリメンタル・ログ・グループを使用する場合のノート
ユーザー定義のサプリメンタル・ログ・グループを使用するためのヒント。
ユーザー定義のサプリメンタル・ログ・グループを指定する場合は、次の点に注意してください。
-
1つの列を複数のサプリメンタル・ログ・グループに含めることができます。ただし、その列のビフォア・イメージの記録は1回のみです。
-
条件付きと無条件の両方で同じ列を記録することを指定した場合、その列は無条件に記録されます。
親トピック: 表レベルのサプリメンタル・ロギング
22.10.4 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
オプションでは、データベースがオープンしている必要があります。 -
サプリメンタル・ロギングをデータベース全体で有効にするか、または対象となる表のログ・グループを作成しておく必要があります。
親トピック: サプリメンタル・ロギング
22.10.5 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
列に「ディクショナリの不一致」という文字列が含まれます。
また、列のディクショナリ定義で定義されている型とその列の実際の型が異なる場合は、予期しない動作が発生する可能性があります。
-
親トピック: サプリメンタル・ロギング
22.10.6 DDL_DICT_TRACKINGおよび指定された時間範囲またはSCN範囲
LogMinerは、LogMinerディクショナリの一貫性を維持するためにDDL文が必要なため、DDL_DICT_TRACKING
オプションが有効な場合、要求した開始時刻またはSCN(DBMS_LOGMNR.START_LOGMNR
で指定)より前に、REDOログ・ファイルの読取りを開始する場合があります。
LogMinerがREDOログ・ファイルの読取りを開始する実際の時刻またはSCNは、必須開始時刻または必須開始SCNと呼ばれます。
欠落REDOログ・ファイル(順序番号に基づく)は、必須開始時刻または必須開始SCNから読取りを開始できません。
LogMinerでは、REDOログ・データの読取りを開始する位置を次のとおり決定します。
-
ディクショナリのロード後、
DBMS_LOGMNR.START_LOGMNR
を初めてコールする場合、LogMinerは、次のいずれかの値の早い方を基準に読取りを開始します。-
ユーザーが要求した開始時刻またはSCN値
-
ディレクトリ・ダンプのコミットSCN
-
-
DBMS_LOGMNR.START_LOGMNR
に対するこれ以降のコールでは、LogMinerは、次のいずれかの値の最も早いものを基準に読取りを開始します。-
ユーザーが要求した開始時刻またはSCN値
-
COMMIT
文がLogMinerによって読み込まれていない最も早いDDLトランザクションの開始時 -
LogMinerによって読み込まれた最高のSCN
-
次に、前述の内容の使用例を示します。
5つのREDOログ・ファイルを含むREDOログ・ファイル・リストを作成するとします。ディクショナリは、最初のREDOファイルに含まれ、確認対象として指定した変更(DBMS_LOGMNR.START_LOGMNR
を使用)は、3番目のREDOログ・ファイルに記録されているとします。ここで、次の手順を実行します。
-
DBMS_LOGMNR.START_LOGMNR
をコールします。LogMinerによって、次のものが読み込まれます。-
ディクショナリをロードするための最初のログ・ファイル
-
その中に含まれている可能性があるDDLをすべて取得するための2番目のREDOログ・ファイル
-
必要なデータを取得するための3番目のログ・ファイル
-
-
同じ要求範囲で、再度
DBMS_LOGMNR.START_LOGMNR
をコールします。LogMinerは、REDOログ・ファイル3から読取りを開始します。REDOログ・ファイル2に含まれているDDL文はすでに処理されているため、REDOログ・ファイル2を読み込む必要はありません。
-
DBMS_LOGMNR.START_LOGMNR
を再度コールします。今回は、REDOログ・ファイル5からデータを読み込む必要があるパラメータを指定します。LogMinerは、REDOログ・ファイル4から読取りを開始し、その中に含まれているすべてのDDL文を取得します。
LogMinerが実際に読取りを開始する位置を確認するには、V$LOGMNR_PARAMETERS
ビューのREQUIRED_START_DATE
列またはREQUIRED_START_SCN
列を問い合せます。LogMinerが読取りを開始する位置に関係なく、要求した範囲内の行のみがV$LOGMNR_CONTENTS
ビューから返されます。
親トピック: サプリメンタル・ロギング
22.11 ビューでのLogMiner操作情報へのアクセス
LogMiner操作情報(REDOデータではなく)は、ビューに含まれています。
他のビューと同様に、SQLを使用してこれらのビューを問い合せることができます。
-
V$LOGMNR_DICTIONARY
DBMS_LOGMNR.START_LOGMNR
に対してSTORE_IN_FLAT_FILE
オプションを使用して作成されたLogMinerディクショナリ・ファイルに関する情報を表示します。LogMinerディクショナリ作成の基礎となったデータベースに関する情報などが表示されます。 -
V$LOGMNR_LOGS
指定したREDOログ・ファイルに関する情報を表示します。詳細は、「V$LOGMNR_LOGSの問合せ」を参照してください。
-
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_COLUMNS
サプリメンタル・ロギングの現在の設定に関する情報を表示します。詳細は、「サプリメンタル・ロギング設定に関するビューの問合せ」を参照してください。
- V$LOGMNR_LOGSの問合せ
V$LOGMNR_LOGS
ビューを問い合せて、LogMinerによる分析のためにREDOログ・ファイルのリストに手動または自動で追加されたREDOログ・ファイルを判別できます。 - サプリメンタル・ロギング設定に関するビューの問合せ
複数のビューを問い合せてサプリメンタル・ロギングの現在の設定を確認する方法について説明します。
親トピック: REDOログ・ファイル分析のためのLogMinerの使用
22.11.1 V$LOGMNR_LOGSの問合せ
V$LOGMNR_LOGS
ビューを問い合せて、LogMinerによる分析のためにREDOログ・ファイルのリストに手動または自動で追加されたREDOログ・ファイルを判別することができます。
このビューでは、REDOログ・ファイルごとに1行が含まれます。各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によって処理されないことを示します。このファイルは、要求した時間範囲または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
オプションおよびCONTINUOUS_MINE
オプションによって、要求した時間範囲またはSCN範囲に対するLogMiner REDOログ・ファイル・リストから、REDOログ・ファイルが欠落しなくなります。DBMS_LOGMNR.START_LOGMNR
に対するコールが失敗した場合、V$LOGMNR_LOGS
ビューのSTATUS
列を問い合せることによって、リストから欠落しているREDOログ・ファイルを判別できます。その後、欠落しているREDOログ・ファイルを検索して、手動で追加すると、再度DBMS_LOGMNR.START_LOGMNR
をコールできます。ノート:
Oracle Database 12c
リリース2 (12.2.0.1)からは、LogMinerCONTINUOUS_MINE
オプションが非推奨になりました。これは下位互換性の理由から引き続きサポートされていますが、使用しないことをお薦めします。かわりとなる機能はありません。 -
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操作情報へのアクセス
22.11.2 サプリメンタル・ロギング設定に関するビューの問合せ
複数のビューを問い合せてサプリメンタル・ロギングの現在の設定を確認する方法について説明します。
具体的には次のとおりです。
-
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
: SQLALTER
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操作情報へのアクセス
22.12 一般的なLogMinerセッションのステップ
一般的なLogMinerセッションのステップを説明します。
各ステップの詳細は、該当する後述の項を参照してください。
- サプリメンタル・ロギングの有効化
- LogMinerディクショナリの抽出(オンライン・カタログを使用する予定でない場合)
- 分析するREDOログ・ファイルの指定
- LogMinerの起動
- 一般的なLogMinerセッション・タスク5: V$LOGMNR_CONTENTSの問合せ
- LogMinerセッションの終了
LogMinerを実行するには、DBMS_LOGMNR
PL/SQLパッケージを使用します。また、オンライン・カタログを使用するのではなく、LogMinerディクショナリを抽出した場合は、DBMS_LOGMNR_D
パッケージも使用します。
DBMS_LOGMNR
パッケージには、LogMinerの初期化および実行に使用するプロシージャ(REDOログ・ファイルの名前、フィルタ基準、セッション特性を指定するためのインタフェースなど)が含まれます。DBMS_LOGMNR_D
パッケージは、現在のデータベースのデータベース・ディクショナリ表を問い合せてLogMinerディクショナリ・ファイルを作成します。
LogMiner PL/SQLパッケージは、SYS
スキーマが所有します。したがって、ユーザーSYS
として接続していない場合は、次の条件が必要になります。
-
コールに
SYS
を含める必要があります。例:EXECUTE SYS.DBMS_LOGMNR.END_LOGMNR
; -
EXECUTE_CATALOG_ROLE
ロールを付与されている必要があります。関連項目:
-
これらのLogMinerパッケージの構文およびパラメータの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
-
PL/SQLパッケージの詳細は、『Oracle Database開発ガイド』を参照してください。
-
- 一般的なLogMinerセッション・タスク1: サプリメンタル・ロギングの有効化
サプリメンタル・ロギングの有効化。 - 一般的なLogMinerセッション・タスク2: LogMinerディクショナリの抽出
LogMinerディクショナリの抽出。 - 一般的なLogMinerセッション・タスク3: 分析用のREDOログ・ファイルの指定
分析用のREDOログ・ファイルの指定。 - 一般的なLogMinerセッション・タスク4: LogMinerの起動
LogMinerの起動。 - 一般的なLogMinerセッション・タスク5: V$LOGMNR_CONTENTSの問合せ
V$LOGMNR_CONTENTS
ビューの問合せ。 - 一般的なLogMinerセッション・タスク6: LogMinerセッションの終了
LogMinerセッションの終了。
親トピック: REDOログ・ファイル分析のためのLogMinerの使用
22.12.1 一般的なLogMinerセッション・タスク1: サプリメンタル・ロギングの有効化
サプリメンタル・ロギングの有効化。
使用する種類のサプリメンタル・ロギングを有効にします。最低限、次のように最小サプリメンタル・ロギングを有効にする必要があります。
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
詳細は、「サプリメンタル・ロギング」を参照してください。
親トピック: 一般的なLogMinerセッションのステップ
22.12.2 一般的なLogMinerセッション・タスク2: LogMinerディクショナリの抽出
LogMinerディクショナリの抽出。
LogMinerを使用するには、次のいずれかの方法でディクショナリを含める必要があります。
-
LogMiner起動時に
DICT_FROM_ONLINE_CATALOG
オプションでオンライン・カタログの使用を指定。詳細は、「オンライン・カタログの使用」を参照してください。 -
REDOログ・ファイルにデータベース・ディクショナリ情報を抽出。詳細は、「REDOログ・ファイルへのLogMinerディクショナリの抽出」を参照してください。
-
フラット・ファイルにデータベース・ディクショナリ情報を抽出。詳細は、「フラット・ファイルへのLogMinerディクショナリの抽出」 を参照してください。
親トピック: 一般的なLogMinerセッションのステップ
22.12.3 一般的なLogMinerセッション・タスク3: 分析用のREDOログ・ファイルの指定
分析するREDOログ・ファイルの指定。
LogMinerを起動する前に、分析するREDOログ・ファイルを指定する必要があります。この指定を行うには、次のステップで示すとおり、DBMS_LOGMNR.ADD_LOGFILE
プロシージャを実行します。REDOログ・ファイルは、任意の順序で追加および削除できます。
ノート:
REDOログ・ファイルを生成するデータベース・インスタンスでマイニングを行う場合は、LogMinerの起動時にCONTINUOUS_MINE
オプションおよび次のいずれかのパラメータを指定する必要があります。
-
STARTSCN
パラメータ -
STARTTIME
パラメータ
詳細は、「REDOログ・ファイル・オプション」を参照してください。
親トピック: 一般的なLogMinerセッションのステップ
22.12.4 一般的なLogMinerセッション・タスク4: LogMinerの起動
LogMinerの起動。
LogMinerディクショナリ・ファイルを作成し、分析するREDOログ・ファイルを指定した後、LogMinerを起動する必要があります。次のステップを実行します。
親トピック: 一般的なLogMinerセッションのステップ
22.12.5 一般的なLogMinerセッション・タスク5: V$LOGMNR_CONTENTSの問合せ
V$LOGMNR_CONTENTS
ビューの問合せ。
この時点で、LogMinerが起動されます。V$LOGMNR_CONTENTS
ビューに対して問合せを実行できます。この例については、「V$LOGMNR_CONTENTSに返されるデータのフィルタ処理および書式設定」を参照してください。
親トピック: 一般的なLogMinerセッションのステップ
22.12.6 一般的な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セッションのステップ
22.13 LogMinerの使用例
LogMinerの使用例。
この項では、LogMinerの使用例をいくつか示します。
ノート:
この項のすべての例では、最小サプリメンタル・ロギングが次のように有効にされているとします。
SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
詳細は、「サプリメンタル・ロギング」を参照してください。
「例2: 指定したSCN範囲でのREDOログ・ファイルのマイニング」と「使用例」以外のすべての例では、NLS_DATE_FORMAT
パラメータが次のように設定されているとみなします。
SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'dd-mon-yyyy hh24:mi:ss';
LogMinerではユーザー・セッションに対してアクティブなNLS_DATE_FORMAT
パラメータの設定を使用して日付データが表示されるため、このステップはオプションです。ただし、このパラメータを明示的に設定すると、指定した日付書式が使用されます。
- 分析するREDOログ・ファイルの明示的指定によるマイニングの例
REDOログ・ファイルを指定する例。 - REDOログ・ファイルのリストを明示的に指定しないマイニングの例
REDOログ・ファイルを指定しない例。 - 使用例
LogMinerの一般的なシナリオの使用方法の例。
親トピック: REDOログ・ファイル分析のためのLogMinerの使用
22.13.1 分析するREDOログ・ファイルの明示的指定によるマイニングの例
REDOログ・ファイルの指定例。
これらの例では、分析対象データが存在するREDOログ・ファイルがわかっている場合のLogMinerの使用方法を示します。それぞれの例は、前の例に基づいて作成されているため、順番に読み進むことをお薦めします。
SQL出力の画面上の書式設定は、この項で示す例とは異なる場合があります。
- 例1: 最後にアーカイブされたREDOログ・ファイルでのすべての変更の検索
- 例2: コミット済トランザクションへのDML文のグループ化
- 例3: 再構築されたSQLの書式設定
- 例4: REDOログ・ファイル内のLogMinerディクショナリの使用
- 例5: 内部ディクショナリでのDDL文の追跡
- 例6: 時間範囲による出力のフィルタ処理
親トピック: LogMinerの使用例
22.13.1.1 例1: 最後にアーカイブされたREDOログ・ファイルでのすべての変更の検索
データベースの変更履歴を確認する最も簡単な方法は、ソース・データベースでマイニングし、オンライン・カタログを使用してREDOログ・ファイルを変換する方法です。この例では、LogMinerを使用して最も簡単に分析を行う方法を示します。
この例では、最後にアーカイブされたREDOログ・ファイルをマイニングするとします。ここでは、最後にアーカイブされたREDOログ(データベースで生成)に含まれているすべての変更を検索します(データベースは、Oracle Real Application Clusters (Oracle RAC)データベースでないものとします)。
-
最後にアーカイブされたREDOログ・ファイルを判別します。
SELECT NAME FROM V$ARCHIVED_LOG WHERE FIRST_TIME = (SELECT MAX(FIRST_TIME) FROM V$ARCHIVED_LOG); NAME ------------------------------------------- /usr/oracle/data/db1arch_1_16_482701534.dbf
-
分析するREDOログ・ファイルのリストを指定します。この場合は、ステップ1の問合せで返されたREDOログ・ファイルです。
EXECUTE DBMS_LOGMNR.ADD_LOGFILE( - LOGFILENAME => '/usr/oracle/data/db1arch_1_16_482701534.dbf', - OPTIONS => DBMS_LOGMNR.NEW);
-
LogMinerを起動し、使用するディクショナリを指定します。
EXECUTE DBMS_LOGMNR.START_LOGMNR( - OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG);
-
V$LOGMNR_CONTENTS
ビューを問い合せます。4つのトランザクションがあることに注意してください(そのうちの2つは、分析するREDOログ・ファイル内でコミット済であり、2つはコミットされていません)。出力には、実行された順序でDML文が表示されるため、トランザクションは交互に配置されます。
SELECT username AS USR, (XIDUSN || '.' || XIDSLT || '.' || XIDSQN) AS XID, SQL_REDO, SQL_UNDO FROM V$LOGMNR_CONTENTS WHERE username IN ('HR', 'OE'); USR XID SQL_REDO SQL_UNDO ---- --------- ---------------------------------------------------- HR 1.11.1476 set transaction read write; HR 1.11.1476 insert into "HR"."EMPLOYEES"( delete from "HR"."EMPLOYEES" "EMPLOYEE_ID","FIRST_NAME", where "EMPLOYEE_ID" = '306' "LAST_NAME","EMAIL", and "FIRST_NAME" = 'Nandini' "PHONE_NUMBER","HIRE_DATE", and "LAST_NAME" = 'Shastry' "JOB_ID","SALARY", and "EMAIL" = 'NSHASTRY' "COMMISSION_PCT","MANAGER_ID", and "PHONE_NUMBER" = '1234567890' "DEPARTMENT_ID") values and "HIRE_DATE" = TO_DATE('10-JAN-2012 ('306','Nandini','Shastry', 13:34:43', 'dd-mon-yyyy hh24:mi:ss') 'NSHASTRY', '1234567890', and "JOB_ID" = 'HR_REP' and TO_DATE('10-jan-2012 13:34:43', "SALARY" = '120000' and 'dd-mon-yyyy hh24:mi:ss'), "COMMISSION_PCT" = '.05' and 'HR_REP','120000', '.05', "DEPARTMENT_ID" = '10' and '105','10'); ROWID = 'AAAHSkAABAAAY6rAAO'; OE 1.1.1484 set transaction read write; OE 1.1.1484 update "OE"."PRODUCT_INFORMATION" update "OE"."PRODUCT_INFORMATION" set "WARRANTY_PERIOD" = set "WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00') where TO_YMINTERVAL('+01-00') where "PRODUCT_ID" = '1799' and "PRODUCT_ID" = '1799' and "WARRANTY_PERIOD" = "WARRANTY_PERIOD" = TO_YMINTERVAL('+01-00') and TO_YMINTERVAL('+05-00') and ROWID = 'AAAHTKAABAAAY9mAAB'; ROWID = 'AAAHTKAABAAAY9mAAB'; OE 1.1.1484 update "OE"."PRODUCT_INFORMATION" update "OE"."PRODUCT_INFORMATION" set "WARRANTY_PERIOD" = set "WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00') where TO_YMINTERVAL('+01-00') where "PRODUCT_ID" = '1801' and "PRODUCT_ID" = '1801' and "WARRANTY_PERIOD" = "WARRANTY_PERIOD" = TO_YMINTERVAL('+01-00') and TO_YMINTERVAL('+05-00') and ROWID = 'AAAHTKAABAAAY9mAAC'; ROWID ='AAAHTKAABAAAY9mAAC'; HR 1.11.1476 insert into "HR"."EMPLOYEES"( delete from "HR"."EMPLOYEES" "EMPLOYEE_ID","FIRST_NAME", "EMPLOYEE_ID" = '307' and "LAST_NAME","EMAIL", "FIRST_NAME" = 'John' and "PHONE_NUMBER","HIRE_DATE", "LAST_NAME" = 'Silver' and "JOB_ID","SALARY", "EMAIL" = 'JSILVER' and "COMMISSION_PCT","MANAGER_ID", "PHONE_NUMBER" = '5551112222' "DEPARTMENT_ID") values and "HIRE_DATE" = TO_DATE('10-jan-2012 ('307','John','Silver', 13:41:03', 'dd-mon-yyyy hh24:mi:ss') 'JSILVER', '5551112222', and "JOB_ID" ='105' and "DEPARTMENT_ID" TO_DATE('10-jan-2012 13:41:03', = '50' and ROWID = 'AAAHSkAABAAAY6rAAP'; 'dd-mon-yyyy hh24:mi:ss'), 'SH_CLERK','110000', '.05', '105','50'); OE 1.1.1484 commit; HR 1.15.1481 set transaction read write; HR 1.15.1481 delete from "HR"."EMPLOYEES" insert into "HR"."EMPLOYEES"( where "EMPLOYEE_ID" = '205' and "EMPLOYEE_ID","FIRST_NAME", "FIRST_NAME" = 'Shelley' and "LAST_NAME","EMAIL","PHONE_NUMBER", "LAST_NAME" = 'Higgins' and "HIRE_DATE", "JOB_ID","SALARY", "EMAIL" = 'SHIGGINS' and "COMMISSION_PCT","MANAGER_ID", "PHONE_NUMBER" = '515.123.8080' "DEPARTMENT_ID") values and "HIRE_DATE" = TO_DATE( ('205','Shelley','Higgins', '07-jun-1994 10:05:01', and 'SHIGGINS','515.123.8080', 'dd-mon-yyyy hh24:mi:ss') TO_DATE('07-jun-1994 10:05:01', and "JOB_ID" = 'AC_MGR' 'dd-mon-yyyy hh24:mi:ss'), and "SALARY"= '12000' 'AC_MGR','12000',NULL,'101','110'); and "COMMISSION_PCT" IS NULL and "MANAGER_ID" = '101' and "DEPARTMENT_ID" = '110' and ROWID = 'AAAHSkAABAAAY6rAAM'; OE 1.8.1484 set transaction read write; OE 1.8.1484 update "OE"."PRODUCT_INFORMATION" update "OE"."PRODUCT_INFORMATION" set "WARRANTY_PERIOD" = set "WARRANTY_PERIOD" = TO_YMINTERVAL('+12-06') where TO_YMINTERVAL('+20-00') where "PRODUCT_ID" = '2350' and "PRODUCT_ID" = '2350' and "WARRANTY_PERIOD" = "WARRANTY_PERIOD" = TO_YMINTERVAL('+20-00') and TO_YMINTERVAL('+20-00') and ROWID = 'AAAHTKAABAAAY9tAAD'; ROWID ='AAAHTKAABAAAY9tAAD'; HR 1.11.1476 commit;
-
LogMinerセッションを終了します。
SQL> EXECUTE DBMS_LOGMNR.END_LOGMNR();
22.13.1.2 例2: コミット済トランザクションへのDML文のグループ化
最初の例(例1: 最後にアーカイブされたREDOログ・ファイルでのすべての変更の検索)で示したとおり、LogMinerのデフォルト動作では、トランザクションがコミット済であるかどうかに関係なく、分析するREDOログ・ファイルで検出されたすべての変更が表示されます。また、LogMinerでは、実行された順序で変更が表示されます。同じトランザクションに属するDML文がグループにまとめられていないため、出力を目視で簡単に確認することはできません。SQLを使用してトランザクションをグループ化することもできますが、LogMinerでは、より簡単な方法が提供されています。この例では、最後にアーカイブされたREDOログ・ファイルを再度分析しますが、コミット済トランザクションのみが返されます。
-
データベースによって最後にアーカイブされたREDOログ・ファイルを判別します。
SELECT NAME FROM V$ARCHIVED_LOG WHERE FIRST_TIME = (SELECT MAX(FIRST_TIME) FROM V$ARCHIVED_LOG); NAME ------------------------------------------- /usr/oracle/data/db1arch_1_16_482701534.dbf
-
ステップ1の問合せで返されたREDOログ・ファイルを指定します。このリストは、1つのREDOログ・ファイルで構成されます。
EXECUTE DBMS_LOGMNR.ADD_LOGFILE( - LOGFILENAME => '/usr/oracle/data/db1arch_1_16_482701534.dbf', - OPTIONS => DBMS_LOGMNR.NEW);
-
使用するディクショナリと
COMMITTED_DATA_ONLY
オプションを指定して、LogMinerを起動します。EXECUTE DBMS_LOGMNR.ADD_LOGFILE( - LOGFILENAME => '/usr/oracle/data/db1arch_1_16_482701534.dbf', - OPTIONS => DBMS_LOGMNR.NEW);
-
V$LOGMNR_CONTENTS
ビューを問い合せます。「例1: 最後にアーカイブされたREDOログ・ファイルでのすべての変更の検索」に示したとおり、トランザクション1.11.1476は1.1.1484より前に開始されていますが、トランザクション1.1.1484の後にコミットされました。したがって、この例では、トランザクション1.1.1484は、その全体がトランザクション1.11.1476より前に示されます。分析中のREDOログ・ファイル内の、コミットされなかった2つのトランザクションは返されません。
SELECT username AS USR, (XIDUSN || '.' || XIDSLT || '.' || XIDSQN) AS XID, SQL_REDO, SQL_UNDO FROM V$LOGMNR_CONTENTS WHERE username IN ('HR', 'OE'); ; USR XID SQL_REDO SQL_UNDO ---- --------- ------------------------------- --------------------------------- OE 1.1.1484 set transaction read write; OE 1.1.1484 update "OE"."PRODUCT_INFORMATION" update "OE"."PRODUCT_INFORMATION" set "WARRANTY_PERIOD" = set "WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00') where TO_YMINTERVAL('+01-00') where "PRODUCT_ID" = '1799' and "PRODUCT_ID" = '1799' and "WARRANTY_PERIOD" = "WARRANTY_PERIOD" = TO_YMINTERVAL('+01-00') and TO_YMINTERVAL('+05-00') and ROWID = 'AAAHTKAABAAAY9mAAB'; ROWID = 'AAAHTKAABAAAY9mAAB'; OE 1.1.1484 update "OE"."PRODUCT_INFORMATION" update "OE"."PRODUCT_INFORMATION" set "WARRANTY_PERIOD" = set "WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00') where TO_YMINTERVAL('+01-00') where "PRODUCT_ID" = '1801' and "PRODUCT_ID" = '1801' and "WARRANTY_PERIOD" = "WARRANTY_PERIOD" = TO_YMINTERVAL('+01-00') and TO_YMINTERVAL('+05-00') and ROWID = 'AAAHTKAABAAAY9mAAC'; ROWID ='AAAHTKAABAAAY9mAAC'; OE 1.1.1484 commit; HR 1.11.1476 set transaction read write; HR 1.11.1476 insert into "HR"."EMPLOYEES"( delete from "HR"."EMPLOYEES" "EMPLOYEE_ID","FIRST_NAME", where "EMPLOYEE_ID" = '306' "LAST_NAME","EMAIL", and "FIRST_NAME" = 'Nandini' "PHONE_NUMBER","HIRE_DATE", and "LAST_NAME" = 'Shastry' "JOB_ID","SALARY", and "EMAIL" = 'NSHASTRY' "COMMISSION_PCT","MANAGER_ID", and "PHONE_NUMBER" = '1234567890' "DEPARTMENT_ID") values and "HIRE_DATE" = TO_DATE('10-JAN-2012 ('306','Nandini','Shastry', 13:34:43', 'dd-mon-yyyy hh24:mi:ss') 'NSHASTRY', '1234567890', and "JOB_ID" = 'HR_REP' and TO_DATE('10-jan-2012 13:34:43', "SALARY" = '120000' and 'dd-mon-yyy hh24:mi:ss'), "COMMISSION_PCT" = '.05' and 'HR_REP','120000', '.05', "DEPARTMENT_ID" = '10' and '105','10'); ROWID = 'AAAHSkAABAAAY6rAAO'; HR 1.11.1476 insert into "HR"."EMPLOYEES"( delete from "HR"."EMPLOYEES" "EMPLOYEE_ID","FIRST_NAME", "EMPLOYEE_ID" = '307' and "LAST_NAME","EMAIL", "FIRST_NAME" = 'John' and "PHONE_NUMBER","HIRE_DATE", "LAST_NAME" = 'Silver' and "JOB_ID","SALARY", "EMAIL" = 'JSILVER' and "COMMISSION_PCT","MANAGER_ID", "PHONE_NUMBER" = '5551112222' "DEPARTMENT_ID") values and "HIRE_DATE" = TO_DATE('10-jan-2012 ('307','John','Silver', 13:41:03', 'dd-mon-yyyy hh24:mi:ss') 'JSILVER', '5551112222', and "JOB_ID" ='105' and "DEPARTMENT_ID" TO_DATE('10-jan-2012 13:41:03', = '50' and ROWID = 'AAAHSkAABAAAY6rAAP'; 'dd-mon-yyyy hh24:mi:ss'), 'SH_CLERK','110000', '.05', '105','50'); HR 1.11.1476 commit;
-
LogMinerセッションを終了します。
EXECUTE DBMS_LOGMNR.END_LOGMNR();
22.13.1.3 例3: 再構築されたSQLの書式設定
「例2: コミット済トランザクションへのDML文のグループ化」 で示したとおり、オンラインREDOログ・ファイルのディクショナリでCOMMITTED_DATA_ONLY
オプションを使用する方法は、コミット済トランザクションのみを対象とするための簡単な方法です。ただし、目視で簡単に確認はできません。INSERT
文内の列名とそれに対応する値との間の関連が明白でないためです。PRINT_PRETTY_SQL
オプションを指定することで、この問題に対処できます。このオプションを指定すると、再構築されたSQL文の一部が実行不可能になることに注意してください。
-
最後にアーカイブされたREDOログ・ファイルを判別します。
SELECT NAME FROM V$ARCHIVED_LOG WHERE FIRST_TIME = (SELECT MAX(FIRST_TIME) FROM V$ARCHIVED_LOG); NAME ------------------------------------------- /usr/oracle/data/db1arch_1_16_482701534.dbf
-
ステップ1の問合せで返されたREDOログ・ファイルを指定します。
EXECUTE DBMS_LOGMNR.ADD_LOGFILE( - LOGFILENAME => '/usr/oracle/data/db1arch_1_16_482701534.dbf', - OPTIONS => DBMS_LOGMNR.NEW);
-
使用するディクショナリおよび
COMMITTED_DATA_ONLY
オプションとPRINT_PRETTY_SQL
オプションを指定して、LogMinerを起動します。EXECUTE DBMS_LOGMNR.START_LOGMNR(- OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG + - DBMS_LOGMNR.COMMITTED_DATA_ONLY + - DBMS_LOGMNR.PRINT_PRETTY_SQL);
DBMS_LOGMNR.PRINT_PRETTY_SQL
オプションは、再構築されたSQLの書式のみを変更するため、目視用のレポートを生成する場合に有効です。 -
SQL_REDO
文に対するV$LOGMNR_CONTENTS
ビューを問い合せます。SELECT username AS USR, (XIDUSN || '.' || XIDSLT || '.' || XIDSQN) AS XID, SQL_REDO FROM V$LOGMNR_CONTENTS; USR XID SQL_REDO ---- --------- ----------------------------------------------------- OE 1.1.1484 set transaction read write; OE 1.1.1484 update "OE"."PRODUCT_INFORMATION" set "WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00') where "PRODUCT_ID" = '1799' and "WARRANTY_PERIOD" = TO_YMINTERVAL('+01-00') and ROWID = 'AAAHTKAABAAAY9mAAB'; OE 1.1.1484 update "OE"."PRODUCT_INFORMATION" set "WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00') where "PRODUCT_ID" = '1801' and "WARRANTY_PERIOD" = TO_YMINTERVAL('+01-00') and ROWID = 'AAAHTKAABAAAY9mAAC'; OE 1.1.1484 commit; HR 1.11.1476 set transaction read write; HR 1.11.1476 insert into "HR"."EMPLOYEES" values "EMPLOYEE_ID" = 306, "FIRST_NAME" = 'Nandini', "LAST_NAME" = 'Shastry', "EMAIL" = 'NSHASTRY', "PHONE_NUMBER" = '1234567890', "HIRE_DATE" = TO_DATE('10-jan-2012 13:34:43', 'dd-mon-yyyy hh24:mi:ss', "JOB_ID" = 'HR_REP', "SALARY" = 120000, "COMMISSION_PCT" = .05, "MANAGER_ID" = 105, "DEPARTMENT_ID" = 10; HR 1.11.1476 insert into "HR"."EMPLOYEES" values "EMPLOYEE_ID" = 307, "FIRST_NAME" = 'John', "LAST_NAME" = 'Silver', "EMAIL" = 'JSILVER', "PHONE_NUMBER" = '5551112222', "HIRE_DATE" = TO_DATE('10-jan-2012 13:41:03', 'dd-mon-yyyy hh24:mi:ss'), "JOB_ID" = 'SH_CLERK', "SALARY" = 110000, "COMMISSION_PCT" = .05, "MANAGER_ID" = 105, "DEPARTMENT_ID" = 50; HR 1.11.1476 commit;
-
再構築された
SQL_UNDO
文に対するV$LOGMNR_CONTENTS
ビューを問い合せます。SELECT username AS USR, (XIDUSN || '.' || XIDSLT || '.' || XIDSQN) AS XID, SQL_UNDO FROM V$LOGMNR_CONTENTS; USR XID SQL_UNDO ---- --------- ----------------------------------------------------- OE 1.1.1484 set transaction read write; OE 1.1.1484 update "OE"."PRODUCT_INFORMATION" set "WARRANTY_PERIOD" = TO_YMINTERVAL('+01-00') where "PRODUCT_ID" = '1799' and "WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00') and ROWID = 'AAAHTKAABAAAY9mAAB'; OE 1.1.1484 update "OE"."PRODUCT_INFORMATION" set "WARRANTY_PERIOD" = TO_YMINTERVAL('+01-00') where "PRODUCT_ID" = '1801' and "WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00') and ROWID = 'AAAHTKAABAAAY9mAAC'; OE 1.1.1484 commit; HR 1.11.1476 set transaction read write; HR 1.11.1476 delete from "HR"."EMPLOYEES" where "EMPLOYEE_ID" = 306 and "FIRST_NAME" = 'Nandini' and "LAST_NAME" = 'Shastry' and "EMAIL" = 'NSHASTRY' and "PHONE_NUMBER" = '1234567890' and "HIRE_DATE" = TO_DATE('10-jan-2012 13:34:43', 'dd-mon-yyyy hh24:mi:ss') and "JOB_ID" = 'HR_REP' and "SALARY" = 120000 and "COMMISSION_PCT" = .05 and "MANAGER_ID" = 105 and "DEPARTMENT_ID" = 10 and ROWID = 'AAAHSkAABAAAY6rAAO'; HR 1.11.1476 delete from "HR"."EMPLOYEES" where "EMPLOYEE_ID" = 307 and "FIRST_NAME" = 'John' and "LAST_NAME" = 'Silver' and "EMAIL" = 'JSILVER' and "PHONE_NUMBER" = '555122122' and "HIRE_DATE" = TO_DATE('10-jan-2012 13:41:03', 'dd-mon-yyyy hh24:mi:ss') and "JOB_ID" = 'SH_CLERK' and "SALARY" = 110000 and "COMMISSION_PCT" = .05 and "MANAGER_ID" = 105 and "DEPARTMENT_ID" = 50 and ROWID = 'AAAHSkAABAAAY6rAAP'; HR 1.11.1476 commit;
-
LogMinerセッションを終了します。
EXECUTE DBMS_LOGMNR.END_LOGMNR();
22.13.1.4 例4: REDOログ・ファイル内のLogMinerディクショナリの使用
この例では、REDOログ・ファイルに抽出されたディクショナリを使用する方法を示します。オンライン・カタログ内のディクショナリを使用する場合は、オンライン・カタログを生成したデータベースと同じデータベース内のREDOログ・ファイルをマイニングする必要があります。REDOログ・ファイルに含まれているディクショナリを使用すると、別のデータベース内のREDOログ・ファイルをマイニングできます。
-
データベースによって最後にアーカイブされたREDOログ・ファイルを判別します。
SELECT NAME, SEQUENCE# FROM V$ARCHIVED_LOG WHERE FIRST_TIME = (SELECT MAX(FIRST_TIME) FROM V$ARCHIVED_LOG); NAME SEQUENCE# -------------------------------------------- -------------- /usr/oracle/data/db1arch_1_210_482701534.dbf 210
-
ディクショナリは、複数のREDOログ・ファイルに含まれている場合があります。したがって、ディクショナリの先頭と終わりが含まれているREDOログ・ファイルを判別する必要があります。次の手順を実行して、
V$ARCHIVED_LOG
ビューを問い合せます。-
ディクショナリ抽出の終わりが含まれているREDOログ・ファイルを検索します。このREDOログ・ファイルは、分析するREDOログ・ファイルより前に作成されている必要がありますが、できるかぎり新しいものを使用します。
SELECT NAME, SEQUENCE#, DICTIONARY_BEGIN d_beg, DICTIONARY_END d_end FROM V$ARCHIVED_LOG WHERE SEQUENCE# = (SELECT MAX (SEQUENCE#) FROM V$ARCHIVED_LOG WHERE DICTIONARY_END = 'YES' and SEQUENCE# <= 210); NAME SEQUENCE# D_BEG D_END -------------------------------------------- ---------- ----- ------ /usr/oracle/data/db1arch_1_208_482701534.dbf 208 NO YES
-
データ・ディクショナリ抽出の先頭(前のステップで検出されたディクショナリの終わりに対応)が含まれているREDOログ・ファイルを検索します。
SELECT NAME, SEQUENCE#, DICTIONARY_BEGIN d_beg, DICTIONARY_END d_end FROM V$ARCHIVED_LOG WHERE SEQUENCE# = (SELECT MAX (SEQUENCE#) FROM V$ARCHIVED_LOG WHERE DICTIONARY_BEGIN = 'YES' and SEQUENCE# <= 208); NAME SEQUENCE# D_BEG D_END -------------------------------------------- ---------- ----- ------ /usr/oracle/data/db1arch_1_207_482701534.dbf 207 YES NO
-
分析するREDOログ・ファイルのリストを指定します。ディクショナリの先頭と終わりが含まれているREDOログ・ファイル、および分析するREDOログ・ファイルを追加します。REDOログ・ファイルは任意の順序で追加できます。
EXECUTE DBMS_LOGMNR.ADD_LOGFILE(- LOGFILENAME => '/usr/oracle/data/db1arch_1_210_482701534.dbf', - OPTIONS => DBMS_LOGMNR.NEW); EXECUTE DBMS_LOGMNR.ADD_LOGFILE(- LOGFILENAME => '/usr/oracle/data/db1arch_1_208_482701534.dbf'); EXECUTE DBMS_LOGMNR.ADD_LOGFILE(- LOGFILENAME => '/usr/oracle/data/db1arch_1_207_482701534.dbf');
-
V$LOGMNR_LOGS
ビューを問い合せて、分析するREDOログ・ファイルのリストをタイムスタンプとともに表示します。出力では、LogMinerによって欠落しているREDOログ・ファイルに指摘フラグが付けられています。正常に機能するために欠落しているREDOログ・ファイルが必要なオプションを指定していない場合は、LogMinerでマイニングを続行できます。
-
-
使用するディクショナリおよび
COMMITTED_DATA_ONLY
オプションとPRINT_PRETTY_SQL
オプションを指定して、LogMinerを起動します。EXECUTE DBMS_LOGMNR.START_LOGMNR(- OPTIONS => DBMS_LOGMNR.DICT_FROM_REDO_LOGS + - DBMS_LOGMNR.COMMITTED_DATA_ONLY + - DBMS_LOGMNR.PRINT_PRETTY_SQL);
-
V$LOGMNR_CONTENTS
ビューを問い合せます。問合せによって返される行数を減らすには、
SYS
スキーマまたはSYSTEM
スキーマで実行されたすべてのDML文を問合せから除外します。(この問合せでは、ディクショナリ抽出に関連したトランザクションを除外するタイムスタンプを指定します。)出力には3つのトランザクションが表示されます。2つのDDLトランザクションと1つのDMLトランザクションです。DDLトランザクション1.2.1594は表
oe.product_tracking
を作成し、1.18.1602は表oe.product_information
でトリガーを作成します。いずれのトランザクションでも、システム表(SYS
によって所有される表)に対して実行されたDML文は、問合せ条件に基づいてフィルタ処理で除外されます。DMLトランザクション1.9.1598は、
oe.product_information
表を更新します。このトランザクションの更新操作は完全に変換されます。ただし、問合せの出力には、変換されない再構築されたSQL文も含まれます。これらの文は、データ・ディクショナリがREDOログ・ファイルに抽出された後で作成されたoe.product_tracking
表で実行された可能性があります。(次に示す例は、すべてのSQL文が完全に変換されるように、
DDL_DICT_TRACKING
を使用したLogMinerの実行例です。バイナリ・データは返されていません。)SELECT USERNAME AS usr, SQL_REDO FROM V$LOGMNR_CONTENTS WHERE SEG_OWNER IS NULL OR SEG_OWNER NOT IN ('SYS', 'SYSTEM') AND TIMESTAMP > '10-jan-2012 15:59:53'; USR XID SQL_REDO --- -------- ----------------------------------- SYS 1.2.1594 set transaction read write; SYS 1.2.1594 create table oe.product_tracking (product_id number not null, modified_time date, old_list_price number(8,2), old_warranty_period interval year(2) to month); SYS 1.2.1594 commit; SYS 1.18.1602 set transaction read write; SYS 1.18.1602 create or replace trigger oe.product_tracking_trigger before update on oe.product_information for each row when (new.list_price <> old.list_price or new.warranty_period <> old.warranty_period) declare begin insert into oe.product_tracking values (:old.product_id, sysdate, :old.list_price, :old.warranty_period); end; SYS 1.18.1602 commit; OE 1.9.1598 update "OE"."PRODUCT_INFORMATION" set "WARRANTY_PERIOD" = TO_YMINTERVAL('+08-00'), "LIST_PRICE" = 100 where "PRODUCT_ID" = 1729 and "WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00') and "LIST_PRICE" = 80 and ROWID = 'AAAHTKAABAAAY9yAAA'; OE 1.9.1598 insert into "UNKNOWN"."OBJ# 33415" values "COL 1" = HEXTORAW('c2121e'), "COL 2" = HEXTORAW('7867010d110804'), "COL 3" = HEXTORAW('c151'), "COL 4" = HEXTORAW('800000053c'); OE 1.9.1598 update "OE"."PRODUCT_INFORMATION" set "WARRANTY_PERIOD" = TO_YMINTERVAL('+08-00'), "LIST_PRICE" = 92 where "PRODUCT_ID" = 2340 and "WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00') and "LIST_PRICE" = 72 and ROWID = 'AAAHTKAABAAAY9zAAA'; OE 1.9.1598 insert into "UNKNOWN"."OBJ# 33415" values "COL 1" = HEXTORAW('c21829'), "COL 2" = HEXTORAW('7867010d110808'), "COL 3" = HEXTORAW('c149'), "COL 4" = HEXTORAW('800000053c'); OE 1.9.1598 commit;
-
必要に応じて、追加の問合せを発行します。
CREATE TABLE
DDL文の一部として実行されたすべてのDML文を表示します。この中には、ユーザーによって実行された文、Oracleによって内部的に実行された文などが含まれます。ノート:
ここで示すような問合せによって、表示された文を再適用する場合は、DDL文のみを再適用します。Oracleによって内部的に実行されたDML文は再適用しないでください。データベースを破損する危険性があります。次の出力では、再適用操作で使用する文は
CREATE TABLE OE.PRODUCT_TRACKING
文のみです。SELECT SQL_REDO FROM V$LOGMNR_CONTENTS WHERE XIDUSN = 1 and XIDSLT = 2 and XIDSQN = 1594; SQL_REDO -------------------------------------------------------------------------------- set transaction read write; insert into "SYS"."OBJ$" values "OBJ#" = 33415, "DATAOBJ#" = 33415, "OWNER#" = 37, "NAME" = 'PRODUCT_TRACKING', "NAMESPACE" = 1, "SUBNAME" IS NULL, "TYPE#" = 2, "CTIME" = TO_DATE('13-jan-2012 14:01:03', 'dd-mon-yyyy hh24:mi:ss'), "MTIME" = TO_DATE('13-jan-2012 14:01:03', 'dd-mon-yyyy hh24:mi:ss'), "STIME" = TO_DATE('13-jan-2012 14:01:03', 'dd-mon-yyyy hh24:mi:ss'), "STATUS" = 1, "REMOTEOWNER" IS NULL, "LINKNAME" IS NULL, "FLAGS" = 0, "OID$" IS NULL, "SPARE1" = 6, "SPARE2" = 1, "SPARE3" IS NULL, "SPARE4" IS NULL, "SPARE5" IS NULL, "SPARE6" IS NULL; insert into "SYS"."TAB$" values "OBJ#" = 33415, "DATAOBJ#" = 33415, "TS#" = 0, "FILE#" = 1, "BLOCK#" = 121034, "BOBJ#" IS NULL, "TAB#" IS NULL, "COLS" = 5, "CLUCOLS" IS NULL, "PCTFREE$" = 10, "PCTUSED$" = 40, "INITRANS" = 1, "MAXTRANS" = 255, "FLAGS" = 1, "AUDIT$" = '--------------------------------------', "ROWCNT" IS NULL, "BLKCNT" IS NULL, "EMPCNT" IS NULL, "AVGSPC" IS NULL, "CHNCNT" IS NULL, "AVGRLN" IS NULL, "AVGSPC_FLB" IS NULL, "FLBCNT" IS NULL, "ANALYZETIME" IS NULL, "SAMPLESIZE" IS NULL, "DEGREE" IS NULL, "INSTANCES" IS NULL, "INTCOLS" = 5, "KERNELCOLS" = 5, "PROPERTY" = 536870912, "TRIGFLAG" = 0, "SPARE1" = 178, "SPARE2" IS NULL, "SPARE3" IS NULL, "SPARE4" IS NULL, "SPARE5" IS NULL, "SPARE6" = TO_DATE('13-jan-2012 14:01:05', 'dd-mon-yyyy hh24:mi:ss'), insert into "SYS"."COL$" values "OBJ#" = 33415, "COL#" = 1, "SEGCOL#" = 1, "SEGCOLLENGTH" = 22, "OFFSET" = 0, "NAME" = 'PRODUCT_ID', "TYPE#" = 2, "LENGTH" = 22, "FIXEDSTORAGE" = 0, "PRECISION#" IS NULL, "SCALE" IS NULL, "NULL$" = 1, "DEFLENGTH" IS NULL, "SPARE6" IS NULL, "INTCOL#" = 1, "PROPERTY" = 0, "CHARSETID" = 0, "CHARSETFORM" = 0, "SPARE1" = 0, "SPARE2" = 0, "SPARE3" = 0, "SPARE4" IS NULL, "SPARE5" IS NULL, "DEFAULT$" IS NULL; insert into "SYS"."COL$" values "OBJ#" = 33415, "COL#" = 2, "SEGCOL#" = 2, "SEGCOLLENGTH" = 7, "OFFSET" = 0, "NAME" = 'MODIFIED_TIME', "TYPE#" = 12, "LENGTH" = 7, "FIXEDSTORAGE" = 0, "PRECISION#" IS NULL, "SCALE" IS NULL, "NULL$" = 0, "DEFLENGTH" IS NULL, "SPARE6" IS NULL, "INTCOL#" = 2, "PROPERTY" = 0, "CHARSETID" = 0, "CHARSETFORM" = 0, "SPARE1" = 0, "SPARE2" = 0, "SPARE3" = 0, "SPARE4" IS NULL, "SPARE5" IS NULL, "DEFAULT$" IS NULL; insert into "SYS"."COL$" values "OBJ#" = 33415, "COL#" = 3, "SEGCOL#" = 3, "SEGCOLLENGTH" = 22, "OFFSET" = 0, "NAME" = 'OLD_LIST_PRICE', "TYPE#" = 2, "LENGTH" = 22, "FIXEDSTORAGE" = 0, "PRECISION#" = 8, "SCALE" = 2, "NULL$" = 0, "DEFLENGTH" IS NULL, "SPARE6" IS NULL, "INTCOL#" = 3, "PROPERTY" = 0, "CHARSETID" = 0, "CHARSETFORM" = 0, "SPARE1" = 0, "SPARE2" = 0, "SPARE3" = 0, "SPARE4" IS NULL, "SPARE5" IS NULL, "DEFAULT$" IS NULL; insert into "SYS"."COL$" values "OBJ#" = 33415, "COL#" = 4, "SEGCOL#" = 4, "SEGCOLLENGTH" = 5, "OFFSET" = 0, "NAME" = 'OLD_WARRANTY_PERIOD', "TYPE#" = 182, "LENGTH" = 5, "FIXEDSTORAGE" = 0, "PRECISION#" = 2, "SCALE" = 0, "NULL$" = 0, "DEFLENGTH" IS NULL, "SPARE6" IS NULL, "INTCOL#" = 4, "PROPERTY" = 0, "CHARSETID" = 0, "CHARSETFORM" = 0, "SPARE1" = 0, "SPARE2" = 2, "SPARE3" = 0, "SPARE4" IS NULL, "SPARE5" IS NULL, "DEFAULT$" IS NULL; insert into "SYS"."CCOL$" values "OBJ#" = 33415, "CON#" = 2090, "COL#" = 1, "POS#" IS NULL, "INTCOL#" = 1, "SPARE1" = 0, "SPARE2" IS NULL, "SPARE3" IS NULL, "SPARE4" IS NULL, "SPARE5" IS NULL, "SPARE6" IS NULL; insert into "SYS"."CDEF$" values "OBJ#" = 33415, "CON#" = 2090, "COLS" = 1, "TYPE#" = 7, "ROBJ#" IS NULL, "RCON#" IS NULL, "RRULES" IS NULL, "MATCH#" IS NULL, "REFACT" IS NULL, "ENABLED" = 1, "CONDLENGTH" = 24, "SPARE6" IS NULL, "INTCOLS" = 1, "MTIME" = TO_DATE('13-jan-2012 14:01:08', 'dd-mon-yyyy hh24:mi:ss'), "DEFER" = 12, "SPARE1" = 6, "SPARE2" IS NULL, "SPARE3" IS NULL, "SPARE4" IS NULL, "SPARE5" IS NULL, "CONDITION" = '"PRODUCT_ID" IS NOT NULL'; create table oe.product_tracking (product_id number not null, modified_time date, old_product_description varchar2(2000), old_list_price number(8,2), old_warranty_period interval year(2) to month); update "SYS"."SEG$" set "TYPE#" = 5, "BLOCKS" = 5, "EXTENTS" = 1, "INIEXTS" = 5, "MINEXTS" = 1, "MAXEXTS" = 121, "EXTSIZE" = 5, "EXTPCT" = 50, "USER#" = 37, "LISTS" = 0, "GROUPS" = 0, "CACHEHINT" = 0, "HWMINCR" = 33415, "SPARE1" = 1024 where "TS#" = 0 and "FILE#" = 1 and "BLOCK#" = 121034 and "TYPE#" = 3 and "BLOCKS" = 5 and "EXTENTS" = 1 and "INIEXTS" = 5 and "MINEXTS" = 1 and "MAXEXTS" = 121 and "EXTSIZE" = 5 and "EXTPCT" = 50 and "USER#" = 37 and "LISTS" = 0 and "GROUPS" = 0 and "BITMAPRANGES" = 0 and "CACHEHINT" = 0 and "SCANHINT" = 0 and "HWMINCR" = 33415 and "SPARE1" = 1024 and "SPARE2" IS NULL and ROWID = 'AAAAAIAABAAAdMOAAB'; insert into "SYS"."CON$" values "OWNER#" = 37, "NAME" = 'SYS_C002090', "CON#" = 2090, "SPARE1" IS NULL, "SPARE2" IS NULL, "SPARE3" IS NULL, "SPARE4" IS NULL, "SPARE5" IS NULL, "SPARE6" IS NULL; commit;
-
LogMinerセッションを終了します。
EXECUTE DBMS_LOGMNR.END_LOGMNR();
22.13.1.5 例5: 内部ディクショナリでのDDL文の追跡
この例では、DBMS_LOGMNR.DDL_DICT_TRACKING
オプションを使用して、REDOログ・ファイル内で検出されたDDL文でLogMiner内部ディクショナリを更新する方法を示します。
-
データベースによって最後にアーカイブされたREDOログ・ファイルを判別します。
SELECT NAME, SEQUENCE# FROM V$ARCHIVED_LOG WHERE FIRST_TIME = (SELECT MAX(FIRST_TIME) FROM V$ARCHIVED_LOG); NAME SEQUENCE# -------------------------------------------- -------------- /usr/oracle/data/db1arch_1_210_482701534.dbf 210
-
ディクショナリは複数のREDOログ・ファイルに含まれている場合があるため、データ・ディクショナリの先頭と終わりが含まれているREDOログ・ファイルを判別する必要があります。次の手順を実行して、
V$ARCHIVED_LOG
ビューを問い合せます。-
データ・ディクショナリ抽出の終わりが含まれているREDOログを検索します。このREDOログ・ファイルは、分析するREDOログ・ファイルより前に作成されている必要がありますが、できるかぎり新しいものを使用します。
SELECT NAME, SEQUENCE#, DICTIONARY_BEGIN d_beg, DICTIONARY_END d_end FROM V$ARCHIVED_LOG WHERE SEQUENCE# = (SELECT MAX (SEQUENCE#) FROM V$ARCHIVED_LOG WHERE DICTIONARY_END = 'YES' and SEQUENCE# < 210); NAME SEQUENCE# D_BEG D_END -------------------------------------------- ---------- ----- ------ /usr/oracle/data/db1arch_1_208_482701534.dbf 208 NO YES
-
データ・ディクショナリ抽出の先頭(前のSQL文で検出されたディクショナリの終わりに対応)が含まれている、REDOログ・ファイルを検索します。
SELECT NAME, SEQUENCE#, DICTIONARY_BEGIN d_beg, DICTIONARY_END d_end FROM V$ARCHIVED_LOG WHERE SEQUENCE# = (SELECT MAX (SEQUENCE#) FROM V$ARCHIVED_LOG WHERE DICTIONARY_BEGIN = 'YES' and SEQUENCE# <= 208); NAME SEQUENCE# D_BEG D_END -------------------------------------------- ---------- ----- ------ /usr/oracle/data/db1arch_1_208_482701534.dbf 207 YES NO
-
-
REDOログ・ファイルの完全なリストがあることを確認します。
REDOログ・ファイルで検出されたDDL文を正しく適用するために、マイニングするREDOログ・ファイルのリストにすべてのファイルが含まれていることを確認します。順序番号209に対応する欠落ログ・ファイルが、このリストに含まれている必要があります。次の問合せを発行して、リストに追加する必要があるREDOログ・ファイルの名前を判別します。
SELECT NAME FROM V$ARCHIVED_LOG WHERE SEQUENCE# >= 207 AND SEQUENCE# <= 210 ORDER BY SEQUENCE# ASC; NAME -------------------------------------------- /usr/oracle/data/db1arch_1_207_482701534.dbf /usr/oracle/data/db1arch_1_208_482701534.dbf /usr/oracle/data/db1arch_1_209_482701534.dbf /usr/oracle/data/db1arch_1_210_482701534.dbf
-
分析するREDOログ・ファイルのリストを指定します。
ディクショナリの先頭と終わりが含まれているREDOログ・ファイル、マイニングするREDOログ・ファイル、および差異のないリストを作成するために必要なすべてのREDOログ・ファイルを含めます。REDOログ・ファイルは任意の順序で追加できます。
EXECUTE DBMS_LOGMNR.ADD_LOGFILE(- LOGFILENAME => '/usr/oracle/data/db1arch_1_210_482701534.dbf', -
OPTIONS => DBMS_LOGMNR.NEW);
EXECUTE DBMS_LOGMNR.ADD_LOGFILE(- LOGFILENAME => '/usr/oracle/data/db1arch_1_209_482701534.dbf'); EXECUTE DBMS_LOGMNR.ADD_LOGFILE(- LOGFILENAME => '/usr/oracle/data/db1arch_1_208_482701534.dbf'); EXECUTE DBMS_LOGMNR.ADD_LOGFILE(- LOGFILENAME => '/usr/oracle/data/db1arch_1_207_482701534.dbf');
-
使用するディクショナリおよび
DDL_DICT_TRACKING
、COMMITTED_DATA_ONLY
、PRINT_PRETTY_SQL
の各オプションを指定して、LogMinerを起動します。EXECUTE DBMS_LOGMNR.START_LOGMNR(- OPTIONS => DBMS_LOGMNR.DICT_FROM_REDO_LOGS + - DBMS_LOGMNR.DDL_DICT_TRACKING + - DBMS_LOGMNR.COMMITTED_DATA_ONLY + - DBMS_LOGMNR.PRINT_PRETTY_SQL);
-
V$LOGMNR_CONTENTS
ビューを問い合せます。返される行数を減らすため、
SYS
スキーマまたはSYSTEM
スキーマで実行されたすべてのDML文を問合せから除外します。(この問合せでは、ディクショナリ抽出に関連したトランザクションを除外するタイムスタンプを指定します。)この問合せは、正常に変換されたすべての再構築SQL文、およびトリガーを実行したため
oe.product_tracking
表に対して実行されたすべての挿入操作を返します。SELECT USERNAME AS usr,(XIDUSN || '.' || XIDSLT || '.' || XIDSQN) as XID, SQL_REDO FROM V$LOGMNR_CONTENTS WHERE SEG_OWNER IS NULL OR SEG_OWNER NOT IN ('SYS', 'SYSTEM') AND TIMESTAMP > '10-jan-2012 15:59:53'; USR XID SQL_REDO ----------- -------- ----------------------------------- SYS 1.2.1594 set transaction read write; SYS 1.2.1594 create table oe.product_tracking (product_id number not null, modified_time date, old_list_price number(8,2), old_warranty_period interval year(2) to month); SYS 1.2.1594 commit; SYS 1.18.1602 set transaction read write; SYS 1.18.1602 create or replace trigger oe.product_tracking_trigger before update on oe.product_information for each row when (new.list_price <> old.list_price or new.warranty_period <> old.warranty_period) declare begin insert into oe.product_tracking values (:old.product_id, sysdate, :old.list_price, :old.warranty_period); end; SYS 1.18.1602 commit; OE 1.9.1598 update "OE"."PRODUCT_INFORMATION" set "WARRANTY_PERIOD" = TO_YMINTERVAL('+08-00'), "LIST_PRICE" = 100 where "PRODUCT_ID" = 1729 and "WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00') and "LIST_PRICE" = 80 and ROWID = 'AAAHTKAABAAAY9yAAA'; OE 1.9.1598 insert into "OE"."PRODUCT_TRACKING" values "PRODUCT_ID" = 1729, "MODIFIED_TIME" = TO_DATE('13-jan-2012 16:07:03', 'dd-mon-yyyy hh24:mi:ss'), "OLD_LIST_PRICE" = 80, "OLD_WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00'); OE 1.9.1598 update "OE"."PRODUCT_INFORMATION" set "WARRANTY_PERIOD" = TO_YMINTERVAL('+08-00'), "LIST_PRICE" = 92 where "PRODUCT_ID" = 2340 and "WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00') and "LIST_PRICE" = 72 and ROWID = 'AAAHTKAABAAAY9zAAA'; OE 1.9.1598 insert into "OE"."PRODUCT_TRACKING" values "PRODUCT_ID" = 2340, "MODIFIED_TIME" = TO_DATE('13-jan-2012 16:07:07', 'dd-mon-yyyy hh24:mi:ss'), "OLD_LIST_PRICE" = 72, "OLD_WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00'); OE 1.9.1598 commit;
-
LogMinerセッションを終了します。
EXECUTE DBMS_LOGMNR.END_LOGMNR();
22.13.1.6 例6: 時間範囲による出力のフィルタ処理
前の2つの例では、問合せにタイムスタンプ・ベースの条件(TIMESTAMP > '10-jan-2012 15:59:53')を指定して、行をフィルタ処理しました。ただし、タイムスタンプ値に基づいてREDOレコードを除外するには、この例で示すとおり、DBMS_LOGMNR.START_LOGMNR
プロシージャ・コールで時間範囲を指定する方法がより効率的です。
-
マイニングするREDOログ・ファイルのリストを作成します。
指定した時刻以降に生成されたREDOログ・ファイルをマイニングするとします。次のプロシージャは、指定した時刻に基づいてREDOログ・ファイルのリストを作成します。その後のSQL
EXECUTE
文は、プロシージャをコールし、開始時刻を2012年1月13日の午後2時に指定します。-- -- my_add_logfiles -- Add all archived logs generated after a specified start_time. -- CREATE OR REPLACE PROCEDURE my_add_logfiles (in_start_time IN DATE) AS CURSOR c_log IS SELECT NAME FROM V$ARCHIVED_LOG WHERE FIRST_TIME >= in_start_time; count pls_integer := 0; my_option pls_integer := DBMS_LOGMNR.NEW; BEGIN FOR c_log_rec IN c_log LOOP DBMS_LOGMNR.ADD_LOGFILE(LOGFILENAME => c_log_rec.name, OPTIONS => my_option); my_option := DBMS_LOGMNR.ADDFILE; DBMS_OUTPUT.PUT_LINE('Added logfile ' || c_log_rec.name); END LOOP; END; / EXECUTE my_add_logfiles(in_start_time => '13-jan-2012 14:00:00');
-
V$LOGMNR_LOGS
を問い合せて、REDOログ・ファイルのリストを確認します。この例では、出力にREDOログ・ファイルのサイズを含めます。
SELECT FILENAME name, LOW_TIME start_time, FILESIZE bytes FROM V$LOGMNR_LOGS; NAME START_TIME BYTES ----------------------------------- -------------------- ---------------- /usr/orcl/arch1_310_482932022.dbf 13-jan-2012 14:02:35 23683584 /usr/orcl/arch1_311_482932022.dbf 13-jan-2012 14:56:35 2564096 /usr/orcl/arch1_312_482932022.dbf 13-jan-2012 15:10:43 23683584 /usr/orcl/arch1_313_482932022.dbf 13-jan-2012 15:17:52 23683584 /usr/orcl/arch1_314_482932022.dbf 13-jan-2012 15:23:10 23683584 /usr/orcl/arch1_315_482932022.dbf 13-jan-2012 15:43:22 23683584 /usr/orcl/arch1_316_482932022.dbf 13-jan-2012 16:03:10 23683584 /usr/orcl/arch1_317_482932022.dbf 13-jan-2012 16:33:43 23683584 /usr/orcl/arch1_318_482932022.dbf 13-jan-2012 17:23:10 23683584
-
REDOログ・ファイルのリストを調整します。
午後3時から4時の間に生成されたREDOログ・ファイルのみをマイニングする必要があるとします。
問合せ条件(
timestamp > '13-jan-2012 15:00:00' and timestamp < '13-jan-2012 16:00:00'
)を使用してこれを行います。ただし、問合せ条件はLogMinerによって返される各行で評価されるため、問合せ条件に基づく行のフィルタ処理は、内部マイニング・エンジンでは行われません。したがって、REDOログ・ファイルarch1_311_482932022.dbf
からarch1_315_482932022.dbf
までの行のみを取得する場合でも、この問合せでは、LogMinerセッションに登録されたすべてのREDOログ・ファイルがマイニングされます。また、問合せ条件を使用し、分析する時間範囲外のREDOログ・ファイルを手動で削除することもできますが、最も簡単な解決法は、
DBMS_LOGMNR.START_LOGMNR
プロシージャ・コールで分析する時間範囲を指定する方法です。この方法では、REDOログ・ファイルのリストは変更されませんが、指定した時間範囲内のREDOログ・ファイルのみがLogMinerによってマイニングされます。
EXECUTE DBMS_LOGMNR.START_LOGMNR(- STARTTIME => '13-jan-2012 15:00:00', - ENDTIME => '13-jan-2012 16:00:00', - OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG + - DBMS_LOGMNR.COMMITTED_DATA_ONLY + - DBMS_LOGMNR.PRINT_PRETTY_SQL);
-
V$LOGMNR_CONTENTS
ビューを問い合せます。SELECT TIMESTAMP, (XIDUSN || '.' || XIDSLT || '.' || XIDSQN) AS XID,
SQL_REDO FROM V$LOGMNR_CONTENTS WHERE SEG_OWNER = 'OE'; TIMESTAMP XID SQL_REDO --------------------- ----------- -------------------------------- 13-jan-2012 15:29:31 1.17.2376 update "OE"."PRODUCT_INFORMATION" set "WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00') where "PRODUCT_ID" = 3399 and "WARRANTY_PERIOD" = TO_YMINTERVAL('+02-00') and ROWID = 'AAAHTKAABAAAY9TAAE'; 13-jan-2012 15:29:34 1.17.2376 insert into "OE"."PRODUCT_TRACKING" values "PRODUCT_ID" = 3399, "MODIFIED_TIME" = TO_DATE('13-jan-2012 15:29:34', 'dd-mon-yyyy hh24:mi:ss'), "OLD_LIST_PRICE" = 815, "OLD_WARRANTY_PERIOD" = TO_YMINTERVAL('+02-00'); 13-jan-2012 15:52:43 1.15.1756 update "OE"."PRODUCT_INFORMATION" set "WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00') where "PRODUCT_ID" = 1768 and "WARRANTY_PERIOD" = TO_YMINTERVAL('+02-00') and ROWID = 'AAAHTKAABAAAY9UAAB'; 13-jan-2012 15:52:43 1.15.1756 insert into "OE"."PRODUCT_TRACKING" values "PRODUCT_ID" = 1768, "MODIFIED_TIME" = TO_DATE('13-jan-2012 16:52:43', 'dd-mon-yyyy hh24:mi:ss'), "OLD_LIST_PRICE" = 715, "OLD_WARRANTY_PERIOD" = TO_YMINTERVAL('+02-00');
-
LogMinerセッションを終了します。
EXECUTE DBMS_LOGMNR.END_LOGMNR();
22.13.2 REDOログ・ファイルのリストを明示的に指定しないマイニングの例
REDOログ・ファイルを指定しない例。
前述の例では、マイニングするREDOログ・ファイルを明示的に指定しました。この例では、REDOログ・ファイルを生成したデータベースと同じデータベースでマイニングする場合、分析する時間(またはSCN)範囲を指定するのみで適切なREDOログ・ファイルのリストをマイニングできる方法を示します。REDOログ・ファイルを明示的に指定せずにマイニングするには、DBMS_LOGMNR.START_LOGMNR
プロシージャに対してDBMS_LOGMNR.CONTINUOUS_MINE
オプションを使用し、分析する時間範囲またはSCN範囲のいずれかを指定します。
ノート:
Oracle Database 12c
リリース2 (12.2.0.1)からは、LogMiner CONTINUOUS_MINE
オプションが非推奨になりました。これは下位互換性の理由から引き続きサポートされていますが、使用しないことをお薦めします。かわりとなる機能はありません。
この項は、次の例で構成されています。それぞれの例は、前の例に基づいて作成されているため、順番に読み進むことをお薦めします。
SQL出力の画面上の書式設定は、この項で示す例とは異なる場合があります。
- 例1: 指定した時間範囲でのREDOログ・ファイルのマイニング
- 例2: 指定したSCN範囲でのREDOログ・ファイルのマイニング
- 例3: 問合せに将来の値を含めるCONTINUOUS_MINEオプションの使用
親トピック: LogMinerの使用例
22.13.2.1 例1: 指定した時間範囲でのREDOログ・ファイルのマイニング
この例は、「例4: REDOログ・ファイル内のLogMinerディクショナリの使用」と同様ですが、REDOログ・ファイルを明示的に指定しない点が異なります。この例では、REDOログ・ファイルに対して抽出されたデータ・ディクショナリを使用するものとします。
-
データ・ディクショナリの先頭を含むREDOログ・ファイルのタイムスタンプを判別します。
SELECT NAME, FIRST_TIME FROM V$ARCHIVED_LOG
WHERE SEQUENCE# = (SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG WHERE DICTIONARY_BEGIN = 'YES'); NAME FIRST_TIME -------------------------------------------- -------------------- /usr/oracle/data/db1arch_1_207_482701534.dbf 10-jan-2012 12:01:34
-
その時点までに生成されたすべてのREDOログ・ファイルを表示します。
このステップは必須ではありませんが、ステップ4に示すとおり、
CONTINUOUS_MINE
オプションが予期したとおりに機能することを示すために含めています。SELECT FILENAME name FROM V$LOGMNR_LOGS WHERE LOW_TIME > '10-jan-2012 12:01:34'; 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
-
使用するディクショナリおよび
COMMITTED_DATA_ONLY
、PRINT_PRETTY_SQL
、CONTINUOUS_MINE
の各オプションを指定して、LogMinerを起動します。EXECUTE DBMS_LOGMNR.START_LOGMNR(- STARTTIME => '10-jan-2012 12:01:34', - ENDTIME => SYSDATE, - OPTIONS => DBMS_LOGMNR.DICT_FROM_REDO_LOGS + - DBMS_LOGMNR.COMMITTED_DATA_ONLY + - DBMS_LOGMNR.PRINT_PRETTY_SQL + - DBMS_LOGMNR.CONTINUOUS_MINE);
-
V$LOGMNR_LOGS
ビューを問い合せます。このステップは、予期したとおり
CONTINUOUS_MINE
オプションを指定したDBMS_LOGMNR.START_LOGMNR
プロシージャに、この時点までに生成されたすべてのREDOログ・ファイルが含まれることを示します。(このステップの出力をステップ2の出力と比較してください。)SELECT FILENAME name FROM V$LOGMNR_LOGS; 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
-
V$LOGMNR_CONTENTS
ビューを問い合せます。問合せによって返される行数を減らすため、
SYS
スキーマまたはSYSTEM
スキーマで実行されたすべてのDML文を除外します。(この問合せでは、ディクショナリ抽出に関連したトランザクションを除外するタイムスタンプを指定します。)問合せで返される再構築SQL文は、すべて正しく変換されていることに注意してください。
SELECT USERNAME AS usr,(XIDUSN || '.' || XIDSLT || '.' || XIDSQN) as XID, SQL_REDO FROM V$LOGMNR_CONTENTS WHERE SEG_OWNER IS NULL OR SEG_OWNER NOT IN ('SYS', 'SYSTEM') AND TIMESTAMP > '10-jan-2012 15:59:53'; USR XID SQL_REDO ----------- -------- ----------------------------------- SYS 1.2.1594 set transaction read write; SYS 1.2.1594 create table oe.product_tracking (product_id number not null, modified_time date, old_list_price number(8,2), old_warranty_period interval year(2) to month); SYS 1.2.1594 commit; SYS 1.18.1602 set transaction read write; SYS 1.18.1602 create or replace trigger oe.product_tracking_trigger before update on oe.product_information for each row when (new.list_price <> old.list_price or new.warranty_period <> old.warranty_period) declare begin insert into oe.product_tracking values (:old.product_id, sysdate, :old.list_price, :old.warranty_period); end; SYS 1.18.1602 commit; OE 1.9.1598 update "OE"."PRODUCT_INFORMATION" set "WARRANTY_PERIOD" = TO_YMINTERVAL('+08-00'), "LIST_PRICE" = 100 where "PRODUCT_ID" = 1729 and "WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00') and "LIST_PRICE" = 80 and ROWID = 'AAAHTKAABAAAY9yAAA'; OE 1.9.1598 insert into "OE"."PRODUCT_TRACKING" values "PRODUCT_ID" = 1729, "MODIFIED_TIME" = TO_DATE('13-jan-2012 16:07:03', 'dd-mon-yyyy hh24:mi:ss'), "OLD_LIST_PRICE" = 80, "OLD_WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00'); OE 1.9.1598 update "OE"."PRODUCT_INFORMATION" set "WARRANTY_PERIOD" = TO_YMINTERVAL('+08-00'), "LIST_PRICE" = 92 where "PRODUCT_ID" = 2340 and "WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00') and "LIST_PRICE" = 72 and ROWID = 'AAAHTKAABAAAY9zAAA'; OE 1.9.1598 insert into "OE"."PRODUCT_TRACKING" values "PRODUCT_ID" = 2340, "MODIFIED_TIME" = TO_DATE('13-jan-2012 16:07:07', 'dd-mon-yyyy hh24:mi:ss'), "OLD_LIST_PRICE" = 72, "OLD_WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00'); OE 1.9.1598 commit;
-
LogMinerセッションを終了します。
EXECUTE DBMS_LOGMNR.END_LOGMNR();
22.13.2.2 例2: 指定したSCN範囲でのREDOログ・ファイルのマイニング
この例では、分析するSCN範囲を指定する方法、およびその範囲を満たすREDOログ・ファイルをマイニングする方法を示します。LogMinerを使用して、データ・ファイルで影響がまだ永続的になっていないすべてのコミット済DML文を表示できます。
この例では(他の例と異なり)、NLS_DATE_FORMAT
パラメータを設定していないことに注意してください。
-
最後のチェックポイントが実行されたSCNを判別します。
SELECT CHECKPOINT_CHANGE#, CURRENT_SCN FROM V$DATABASE;
CHECKPOINT_CHANGE# CURRENT_SCN ------------------ --------------- 56453576 56454208
-
LogMinerを起動し、
CONTINUOUS_MINE
オプションを指定します。EXECUTE DBMS_LOGMNR.START_LOGMNR(-
STARTSCN => 56453576, - ENDSCN => 56454208, - OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG + - DBMS_LOGMNR.COMMITTED_DATA_ONLY + - DBMS_LOGMNR.PRINT_PRETTY_SQL + - DBMS_LOGMNR.CONTINUOUS_MINE);
-
LogMinerによって追加されたアーカイブ済REDOログ・ファイルのリストを表示します。
SELECT FILENAME name, LOW_SCN, NEXT_SCN FROM V$LOGMNR_LOGS;
NAME LOW_SCN NEXT_SCN -------------------------------------------- -------- -------- /usr/oracle/data/db1arch_1_215_482701534.dbf 56316771 56453579
LogMinerによって追加されたREDOログ・ファイルには、SCN範囲全体が含まれないことに注意してください。
CONTINUOUS_MINE
オプションを指定した場合にDBMS_LOGMNR.START_LOGMNR
プロシージャをコールすると、アーカイブ済REDOログ・ファイルのみがLogMinerによって追加されます。LogMinerは、問合せ実行中必要に応じて、オンラインREDOログ・ファイルに含まれている残りのSCN範囲を自動的に追加します。追加されたREDOログ・ファイルが生成された最新のアーカイブ済REDOログ・ファイルであるかどうかを確認するには、次の問合せを使用します。SELECT NAME FROM V$ARCHIVED_LOG WHERE SEQUENCE# = (SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG); NAME -------------------------------------------- /usr/oracle/data/db1arch_1_215_482701534.dbf
-
ユーザー表に対して行われた変更に対する
V$LOGMNR_CONTENTS
ビューを問い合せます。次の問合せは、トランザクション1.6.1911と関連付けられた
SET TRANSACTION READ WRITE
文およびCOMMIT
文は返しません。これらの文には、セグメント所有者(SEG_OWNER
)が関連付けられていないためです。デフォルトの
NLS_DATE_FORMAT
であるDD-MON-RRが、DATE
型のMODIFIED_TIME
列の表示に使用されていることに注意してください。SELECT SCN, (XIDUSN || '.' || XIDSLT || '.' || XIDSQN) as XID, SQL_REDO FROM V$LOGMNR_CONTENTS WHERE SEG_OWNER NOT IN ('SYS', 'SYSTEM'); SCN XID SQL_REDO ---------- ---------- ------------- 56454198 1.6.1911 update "OE"."PRODUCT_INFORMATION" set "WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00') where "PRODUCT_ID" = 2430 and "WARRANTY_PERIOD" = TO_YMINTERVAL('+02-00') and ROWID = 'AAAHTKAABAAAY9AAAC'; 56454199 1.6.1911 insert into "OE"."PRODUCT_TRACKING" values "PRODUCT_ID" = 2430, "MODIFIED_TIME" = TO_DATE('17-JAN-03', 'DD-MON-RR'), "OLD_LIST_PRICE" = 175, "OLD_WARRANTY_PERIOD" = TO_YMINTERVAL('+02-00'); 56454204 1.6.1911 update "OE"."PRODUCT_INFORMATION" set "WARRANTY_PERIOD" = TO_YMINTERVAL('+05-00') where "PRODUCT_ID" = 2302 and "WARRANTY_PERIOD" = TO_YMINTERVAL('+02-00') and ROWID = 'AAAHTKAABAAAY9QAAA'; 56454206 1.6.1911 insert into "OE"."PRODUCT_TRACKING" values "PRODUCT_ID" = 2302, "MODIFIED_TIME" = TO_DATE('17-JAN-03', 'DD-MON-RR'), "OLD_LIST_PRICE" = 150, "OLD_WARRANTY_PERIOD" = TO_YMINTERVAL('+02-00');
-
LogMinerセッションを終了します。
EXECUTE DBMS_LOGMNR.END_LOGMNR();
22.13.2.3 例3: 問合せに将来の値を含める連続マイニングの使用
所定の時刻になるまでまたはSCNに到達するまで問合せが終了しないように指定するには、DBMS_LOGMNR.START_LOGMNR
プロシージャへのコールで、CONTINUOUS_MINE
オプションを使用し、ENDTIME
オプションまたはENDSCN
オプションのいずれかを、将来の時刻またはまだ到達していないSCN値に設定します。
この例では、現在から5時間後までの間に表hr.employees
に対して行われたすべての変更を監視するとします。また、オンライン・カタログ内のディクショナリを使用するとします。
-
LogMinerを起動します。
EXECUTE DBMS_LOGMNR.START_LOGMNR(-
STARTTIME => SYSDATE, - ENDTIME => SYSDATE + 5/24, - OPTIONS => DBMS_LOGMNR.CONTINUOUS_MINE + - DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG);
-
V$LOGMNR_CONTENTS
ビューを問い合せます。この選択操作は、分析する時間範囲(現在から5時間)後に生成される最初のREDOログ・ファイル・レコードが検出されるまで完了しません。[Ctrl]キーを押しながら[C]キーを押すと、完了前に選択操作を中止できます。
この例では、
SET
ARRAYSIZE
文を指定して、行がREDOログ・ファイルに入力されたとおりに表示されるように設定しています。SET ARRAYSIZE
文を指定していない場合、SQL内部バッファが一杯になるまで行は返されません。SET ARRAYSIZE 1; SELECT USERNAME AS usr, SQL_REDO FROM V$LOGMNR_CONTENTS WHERE SEG_OWNER = 'HR' AND TABLE_NAME = 'EMPLOYEES';
-
LogMinerセッションを終了します。
EXECUTE DBMS_LOGMNR.END_LOGMNR();
22.13.3 シナリオの例
LogMinerの一般的なシナリオの使用方法の例。
これらの例を使用します。
22.13.3.1 使用例1: LogMinerを使用した特定のユーザーによる変更の追跡
この例では、joedevo
というユーザーによって特定の時間範囲にデータベースに対して行われた変更をすべて表示する方法を示します。データベースに接続した後、次のステップを実行します。
-
LogMinerディクショナリ・ファイルを作成します。
LogMinerを使用して
joedevo
のデータを分析するには、joedevo
が使用する表に対して表定義の変更が行われる前にLogMinerディクショナリ・ファイルを作成するか、またはLogMiner起動時にオンライン・カタログを使用する必要があります。LogMinerディクショナリを作成する例は、「LogMinerディクショナリの抽出」を参照してください。この例では、REDOログ・ファイルに抽出されたLogMinerディクショナリを使用します。 -
REDOログ・ファイルを追加します。
joedevo
がデータベースに対して変更を行ったとします。分析するREDOログ・ファイルの名前は、次のように指定できます。EXECUTE DBMS_LOGMNR.ADD_LOGFILE( - LOGFILENAME => 'log1orc1.ora', - OPTIONS => DBMS_LOGMNR.NEW);
必要に応じて、次のようにREDOログ・ファイルを追加します。
EXECUTE DBMS_LOGMNR.ADD_LOGFILE( - LOGFILENAME => 'log2orc1.ora', - OPTIONS => DBMS_LOGMNR.ADDFILE);
-
LogMinerを起動し、検索を指定した時間範囲に制限します。
EXECUTE DBMS_LOGMNR.START_LOGMNR( - DICTFILENAME => 'orcldict.ora', - STARTTIME => TO_DATE('01-Jan-1998 08:30:00','DD-MON-YYYY HH:MI:SS'), - ENDTIME => TO_DATE('01-Jan-1998 08:45:00', 'DD-MON-YYYY HH:MI:SS'));
-
V$LOGMNR_CONTENTS
ビューを問い合せます。この時点で、
V$LOGMNR_CONTENTS
ビューを問い合せることが可能です。ユーザーjoedevo
がsalary
表に対して行ったすべての変更を検索します。次のSELECT
文を実行します。SELECT SQL_REDO, SQL_UNDO FROM V$LOGMNR_CONTENTS WHERE USERNAME = 'joedevo' AND SEG_NAME = 'salary';
SQL_REDO
列とSQL_UNDO
列の両方に対して、2つの行が返されます(データ表示の書式は画面では異なる場合があります)。joedevo
が2つの操作を要求したことがわかります。joedevoは、古い給与を削除した後、新しい昇給後の給与を挿入しました。これらは、この操作を元に戻すために必要なデータです。SQL_REDO SQL_UNDO -------- -------- delete from SALARY insert into SALARY(NAME, EMPNO, SAL) where EMPNO = 12345 values ('JOEDEVO', 12345, 500) and NAME='JOEDEVO' and SAL=500; insert into SALARY(NAME, EMPNO, SAL) delete from SALARY values('JOEDEVO',12345, 2500) where EMPNO = 12345 and NAME = 'JOEDEVO' 2 rows selected and SAL = 2500;
-
LogMinerセッションを終了します。
LogMinerセッションを正常に終了するには、
DBMS_LOGMNR.END_LOGMNR
プロシージャを使用します。DBMS_LOGMNR.END_LOGMNR( );
親トピック: 使用例
22.13.3.2 使用例2: LogMinerを使用した表アクセス統計の計算
この例では、ダイレクト・マーケティング・データベースを管理し、1月の2週間の収益でのカスタマ・コンタクトの有効性を確認するとします。すでにLogMinerディクショナリを作成済で、検索するREDOログ・ファイルを追加してあるとします(前述の例と同様)。次のステップを実行します。
-
LogMinerを起動し、時間範囲を指定します。
EXECUTE DBMS_LOGMNR.START_LOGMNR( - STARTTIME => TO_DATE('07-Jan-2012 08:30:00','DD-MON-YYYY HH:MI:SS'), - ENDTIME => TO_DATE('21-Jan-2012 08:45:00','DD-MON-YYYY HH:MI:SS'), - DICTFILENAME => '/usr/local/dict.ora');
-
V$LOGMNR_CONTENTS
ビューを問い合せて、次の例に示すとおり、指定した時間範囲で変更された表を判別します。(この問合せでは、従来どおり名前に$
を含むシステム表がフィルタ処理で除外されます。)SELECT SEG_OWNER, SEG_NAME, COUNT(*) AS Hits FROM V$LOGMNR_CONTENTS WHERE SEG_NAME NOT LIKE '%$' GROUP BY SEG_OWNER, SEG_NAME ORDER BY Hits DESC;
-
次のデータが表示されます。(画面の書式は異なる場合があります。)
SEG_OWNER SEG_NAME Hits --------- -------- ---- CUST ACCOUNT 384 UNIV EXECDONOR 325 UNIV DONOR 234 UNIV MEGADONOR 32 HR EMPLOYEES 12 SYS DONOR 12
Hits
列の値は、問合せで指定した2週間の間に、指定した表に対して挿入、削除、更新の操作が行われた回数を示しています。この例では、指定した2週間の間にcust.account
表が最も多く変更され、hr.employees
表とsys.donor
表は同じ期間の変更回数が最小でした。 -
LogMinerセッションを終了します。
LogMinerセッションを正常に終了するには、
DBMS_LOGMNR.END_LOGMNR
プロシージャを使用します。DBMS_LOGMNR.END_LOGMNR( );
親トピック: 使用例
22.14 サポートされるデータ型、記憶域属性、およびデータベースとREDOログ・ファイルのバージョン
データ型と記憶域属性のサポートに関する情報およびサポートされるデータベースとREDOログ・ファイルのリリースを説明します。
- サポートされるデータ型と表記憶域属性
サポートされるデータ型と表記憶域属性を説明します。 - サポートされないデータ型と表記憶域属性
サポートされないデータ型と表記憶域属性を説明します。 - サポートされるデータベースとREDOログ・ファイルのバージョン
サポートされるデータベースのリリースとREDOログ・ファイルのバージョンを説明します。 - SecureFiles LOBに関する考慮点
SecureFiles LOBは、データベース互換性が11.2以上に設定されている場合にサポートされます。
親トピック: REDOログ・ファイル分析のためのLogMinerの使用
22.14.1 サポートされるデータ型と表記憶域属性
サポートされるデータ型と表記憶域属性を説明します。
ノート:
Oracle Database 12c リリース1 (12.1)から、VARCHAR2
、NVARCHAR2
およびRAW
データ型の最大サイズが32KBに増加しました(COMPATIBLE
初期化パラメータが12.0以上に設定され、MAX_STRING_SIZE
初期化パラメータがEXTENDED
に設定されている場合)。
LogMinerでは、サプリメンタル・ロギングの目的で32KBの列がLOBとして扱われます。
32KBの列は、ALWAYSサプリメンタル・ロギング・グループの一部にはできません。
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 12cリリース1 (12.1)からはCLOB
として格納されるXMLType
が非推奨になったため)。 -
オブジェクト・リレーショナル形式またはバイナリXMLで格納される
XMLType
には、11.2.0.3以上のREDO互換性が設定されたOracle Database 11gリリース2 (11.2.0.3)以上でデータベースを実行している必要があります。XMLデータに関連する操作用のSQL_REDO
列の内容は、有効なSQLまたはPL/SQLではありません。
-
表記憶域タイプ
-
クラスタ表(索引クラスタおよびヒープ・クラスタを含む)
-
索引構成表(IOT) (オーバーフロー・セグメントを含むパーティション化および非パーティション化)
-
ヒープ構成表(パーティション化および非パーティション化)
-
高度な行圧縮および基本表圧縮。これらのオプションはいずれも、データベースの互換性設定が11.1.0以上である必要があります。
-
SecureFilesとして格納されるLOB列を含む表(データベース互換性が11.2以上に設定されている場合)
-
ハイブリッド列圧縮を使用する表(データベース互換性が11.2.0.2以上に設定されている場合)
関連項目:
-
ハイブリッド列圧縮の詳細は、『Oracle Database概要』を参照してください。
-
- 互換性要件
LogMinerによる一部のデータ型および表記憶域属性のサポートには、データベース互換性要件があります。
22.14.1.1 互換性要件
LogMinerによる一部のデータ型および表記憶域属性のサポートには、データベース互換性要件があります。
具体的には次のとおりです。
-
マルチバイトの
CLOB
サポートには、10.1以上の互換性で動作するデータベースが必要です。 -
LOB
およびオーバーフローなしのIOTサポートには、10.1以上の互換性で動作するデータベースが必要です。 -
LOB
およびオーバーフローありのIOTサポートには、10.2以上の互換性で動作するデータベースが必要です。 -
TDEおよびTSEサポートには、11.1以上の互換性で動作するデータベースが必要です。
-
基本圧縮および高度な行圧縮では、11.1以上の互換性で動作するデータベースが必要です。
-
ハイブリッド列圧縮のサポートは、基礎となるストレージ・システムに依存し、11.2以上の互換性で動作するデータベースが必要です。
関連項目:
-
ハイブリッド列圧縮の詳細は、『Oracle Database概要』を参照してください。
親トピック: サポートされるデータ型と表記憶域属性
22.14.2 サポートされないデータ型と表記憶域属性
サポートされないデータ型と表記憶域属性を説明します。
LogMinerは、次のデータ型と表記憶域属性をサポートしません。これらのサポートされていないデータ型のいずれかを使用する列が表に含まれる場合、表全体がLogMinerによって無視されます。
-
BFILE
-
ネストされた表
-
ネストされた表のあるオブジェクト
-
アイデンティティ列を含む表
-
時間的な有効性列
-
PKREF列
-
PKOID列
-
ネストした表属性およびスタンドアロンのネストした表の列
22.14.3 サポートされるデータベースとREDOログ・ファイルのバージョン
サポートされるデータベースのリリースとREDOログ・ファイルのバージョンを説明します。
LogMinerは、リリース8.1以上のデータベースでのみ実行されますが、リリース8.0のデータベースからのREDOログ・ファイルの分析に使用することができます。ただし、LogMinerでREDOログ・ファイルから取得することができる情報は、使用中のデータベースのリリースではなく、ログのバージョンに依存します。たとえば、サプリメンタル・ロギングが有効な場合は、Oracle9iのREDOログ・ファイルを拡張して追加情報を取得できます。これによって、LogMinerの機能を最大限使用できます。旧リリースのOracleで作成されたREDOログ・ファイルには、追加データが含まれていないため、LogMinerによってサポートされる操作およびデータ型が制限される場合があります。
22.14.4 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は生成されません。