| Oracle® Databaseユーティリティ 11gリリース2 (11.2) B56303-08 |
|
 前 |
 次 |
Oracle LogMinerは、Oracle Databaseの一部で、SQLインタフェースを介してREDOログ・ファイル(オンラインおよびアーカイブ)を問い合せることができます。REDOログ・ファイルには、データベースでのアクティビティの履歴情報が含まれています。
この章の内容は、次のとおりです。
この章では、コマンドラインからLogMinerを使用する方法について説明します。LogMinerには、Oracle LogMinerビューアGraphical User Interfaceからもアクセスできます。Oracle LogMinerビューアは、Oracle Enterprise Managerの一部です。Oracle LogMinerビューアの詳細は、Oracle Enterprise Managerオンライン・ヘルプを参照してください。
ユーザー・データやデータベース・ディクショナリに対するすべての変更は、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管理者ガイド』を参照してください。
次の各項では、LogMinerの概要を説明します。
この章の後半では、これらの概念と関連トピックを詳しく説明します。
LogMiner構成には、よく理解しておく必要がある次の4つの基本オブジェクトがあります。ソース・データベース、マイニング・データベース、LogMinerディクショナリ、分析対象のデータが含まれるREDOログ・ファイルです。
LogMinerディクショナリは、LogMinerがユーザーの要求したREDOログ・データを表すときに、内部オブジェクトIDではなく表名と列名を提供するために使用されます。
LogMinerは、内部オブジェクトIDとデータ型をオブジェクト名と外部データ書式に変換するためにもディクショナリを使用します。ディクショナリがない場合、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ログ・ファイルには、データベースまたはデータベース・ディクショナリに対して行われた変更が含まれます。
図19-1にサンプルLogMiner構成を示します。この図では、ボストンにあるソース・データベースでREDOログ・ファイルが生成され、アーカイブ後にサンフランシスコにあるデータベースに送られます。LogMinerディクショナリは、これらのREDOログ・ファイルに対して抽出されます。LogMinerが実際にREDOログ・ファイルを分析するマイニング・データベースは、サンフランシスコにあります。ボストンのデータベースはOracle9iを実行しており、サンフランシスコのデータベースではOracle Database 10gを実行しています。
図19-1は、有効なLogMiner構成の一例です。その他に有効な構成としては、ソース・データベースとマイニング・データベースの両方に同じデータベースを使用する構成、データ・ディクショナリを別の方法で提供する構成などがあります。他のデータ・ディクショナリ・オプションの詳細は、「LogMinerディクショナリ・オプション」を参照してください。
次に、ソース・データベース、マイニング・データベース、データ・ディクショナリ、およびLogMinerがマイニングするREDOログ・ファイルの要件を示します。
ソース・データベースおよびマイニング・データベースは、同一のハードウェア・プラットフォームで稼働している必要があります。
マイニング・データベースは、ソース・データベースと同一でも、まったく別であってもかまいません。
マイニング・データベースは、ソース・データベースと同じか上位のリリースのOracle Databaseを実行する必要があります。
マイニング・データベースでは、ソース・データベースで使用するものと同じキャラクタ・セット(またはキャラクタ・セットのスーパーセット)を使用する必要があります。
ディクショナリは、LogMinerが分析するREDOログ・ファイルを生成するソース・データベースと同じデータベースにより生成される必要があります。
同じソース・データベースで生成される必要があります。
同じデータベースRESETLOGS SCNと関連付けられている必要があります。
リリース8.0以上のOracle Databaseである必要があります。ただし、リリース9.0.1で導入されたLogMiner機能の一部は、Oracle9i以上のデータベースで生成されたREDOログ・ファイルでのみ機能します。詳細は、「サポートされるデータベースとREDOログ・ファイルのバージョン」を参照してください。
LogMinerでは、異なるデータベースからのREDOログ・ファイルを混在させること、また分析対象のREDOログ・ファイルを生成したデータベース以外からのディクショナリを使用することはできません。
|
注意: LogMinerで分析するログ・ファイルを生成するには、その前にサプリメンタル・ロギングを有効にする必要があります。サプリメンタル・ロギングが有効な場合、REDOログ・ファイルの情報を役立てるために必要な補足情報がREDOストリームに記録されます。したがって、次のSQL文で示すように、少なくとも最小サプリメンタル・ロギングは有効にする必要があります。 ALTER DATABASE ADD SUPPLEMENTAL LOG DATA; サプリメンタル・ロギングが有効であるかどうかを確認するには、次のSQL文で示すように、 SELECT SUPPLEMENTAL_LOG_DATA_MIN FROM V$DATABASE; 問合せから |
LogMiner操作の指定にはDBMS_LOGMNRおよびDBMS_LOGMNR_D PL/SQLパッケージを、分析するデータの取得にはV$LOGMNR_CONTENTS ビューを、それぞれ次のように使用します。
LogMinerディクショナリを指定します。
使用するディクショナリのタイプに応じて、DBMS_LOGMNR_D.BUILDプロシージャを使用するか、LogMiner起動時(手順3)にディクショナリを指定するか、その両方を実行します。
分析するREDOログ・ファイルのリストを指定します。
DBMS_LOGMNR.ADD_LOGFILEプロシージャを使用するか、LogMiner起動時(手順3)に自動的に分析するログ・ファイルのリストをLogMinerが作成するよう指定します。
LogMinerを起動します。
分析するREDOデータを要求します。
V$LOGMNR_CONTENTSビューを問い合せます。(このビューを問い合せるには、SELECT ANY TRANSACTION権限が必要です。)
LogMinerセッションを終了します。
LogMiner PL/SQLパッケージの使用およびV$LOGMNR_CONTENTSビューの問合せでは、EXECUTE_CATALOG_ROLEロールが付与されている必要があります。
|
注意: Oracle RACデータベースで生成されたアーカイブ・ログ内で、指定された分析する時間範囲またはSCN範囲のマイニングを行う場合、指定の時間範囲またはSCN範囲でアクティブであった、すべてのREDOスレッドのすべてのアーカイブ・ログが指定されていることを確認する必要があります。指定されていない場合、V$LOGMNR_CONTENTSという問合せによって、(DBMS_LOGMNR.ADD_LOGFILEプロシージャを使用してLogMinerに指定されたアーカイブ・ログに基づき)部分的な結果のみが返されます。この制限事項は、CONTINUOUS_MINEオプションを使用して、ソース・データベースでアーカイブ・ログをマイニングする場合にも適用されます。有効または無効なスレッドがない場合にのみ、Oracle RACデータベースでCONTINUOUS_MINEオプションを使用する必要があります。 |
LogMinerを使用する前に、LogMinerがLogMinerディクショナリ・ファイルおよびREDOログ・ファイルとともにどのように動作するかを理解しておくことが重要です。これは、正確な結果の取得と、システム・リソースの使用計画の作成に役立ちます。
この項では、次の概念について説明します。
LogMinerは、REDOデータをユーザーに返す際に、オブジェクトIDをオブジェクト名に変換するためにディクショナリを必要とします。LogMinerには、ディクショナリ提供方法として次の3つのオプションがあります。
REDOログ・ファイルが作成されたソース・データベースにアクセスでき、分析する表の列定義に変更がないことが見込まれる場合には、このオプションの使用をお薦めします。このオプションは、最も効率的で簡単に使用できます。
REDOログ・ファイルへのLogMinerディクショナリの抽出
REDOログ・ファイルが作成されたソース・データベースにアクセスできない場合、または分析する表の列定義が変更される可能性がある場合には、このオプションの使用をお薦めします。
このオプションは、以前のリリースとの下位互換性を保つものです。このオプションは、トランザクションの一貫性を保証しません。オンライン・カタログを使用するか、REDOログ・ファイルからディクショナリを抽出することをお薦めします。
図19-2に、状況に合わせたLogMinerディクショナリの選択方法を示します。
次の項では、使用可能な各ディクショナリ・オプションの指定方法を説明します。
データベースで現在使用中のディクショナリを使用することを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オプションに対し有効ではありません。
REDOログ・ファイルにLogMinerディクショナリを抽出するには、データベースがオープンしていて、ARCHIVELOGモードの状態で、アーカイブが有効になっている必要があります。ディクショナリをREDOログ・ストリームに抽出している間は、DDL文を実行できません。したがって、REDOログ・ファイルに抽出されるディクショナリは、一貫性が保証されます(一方、フラット・ファイルに抽出されたディクショナリは一貫性が保証されません)。
ディクショナリ情報をREDOログ・ファイルに抽出するには、STORE_IN_REDO_LOGSオプションを指定してPL/SQL DBMS_LOGMNR_D.BUILDプロシージャを実行します。ファイル名や位置を指定しないでください。
EXECUTE DBMS_LOGMNR_D.BUILD( - OPTIONS=> DBMS_LOGMNR_D.STORE_IN_REDO_LOGS);
|
参照:
|
ディクショナリをREDOログ・ファイルに抽出するプロセスはデータベース・リソースを消費しますが、ピーク時間帯を外して抽出を実行することで問題を解決できます。また、フラット・ファイルに抽出するより高速になります。ディクショナリのサイズに応じて、複数のREDOログ・ファイルを含めることもできます。関係するREDOログ・ファイルがアーカイブされている場合、抽出されたディクショナリの先頭と終わりがどのREDOログ・ファイルにあるかを特定することができます。これを行うには、次のとおりV$ARCHIVED_LOGビューを問い合せます。
SELECT NAME FROM V$ARCHIVED_LOG WHERE DICTIONARY_BEGIN='YES'; SELECT NAME FROM V$ARCHIVED_LOG WHERE DICTIONARY_END='YES';
LogMinerセッションの起動を準備するときに、ADD_LOGFILEプロシージャで、先頭と終わりのREDOログ・ファイル名を(必要であればその間の他のログも)指定してください。
定期的にREDOログ・ファイルのバックアップを取って情報を保存し、後で利用できるようにしておくことをお薦めします。データベースが適切に管理されている理想的な環境では、アーカイブされたREDOログ・ファイルのバックアップとリストアのためのプロセスがすでに整っているため、そのための特別な手順は必要ありません。バックアップ作業も時間がかかる作業のため、ピークを外した時間帯に実行することをお薦めします。
LogMinerディクショナリがフラット・ファイルに存在する場合、REDOログ・ファイルに存在する場合よりもシステム・リソースの消費が少なくなります。古いREDOログ・ファイルを正しく分析できるように、定期的にディクショナリ抽出のバックアップを取ることをお薦めします。
データベース・ディクショナリ情報をフラット・ファイルに抽出するには、STORE_IN_FLAT_FILEオプションを指定してDBMS_LOGMNR_D.BUILDプロシージャを実行します。
ディクショナリの作成中にDDL操作が発生しないように注意してください。
ディクショナリをフラット・ファイルに抽出する手順は、次のとおりです。手順1と2は準備のための手順です。これらは、1回のみの実行で、以後は何回でもディクショナリをフラット・ファイルに抽出できます。
DBMS_LOGMNR_D.BUILDプロシージャは、ディクショナリ・ファイルが置かれたディレクトリにアクセスする必要があります。通常、PL/SQLプロシージャは、ユーザー・ディレクトリにアクセスしないため、DBMS_LOGMNR_D.BUILDプロシージャが使用するディレクトリを指定する必要があります。ディレクトリを指定しない場合、プロシージャの実行は失敗します。ディレクトリを指定するには、初期化パラメータ・ファイルでUTL_FILE_DIR初期化パラメータを設定します。
たとえば、ディクショナリ・ファイルを置くディレクトリとして/oracle/databaseを使用するようにUTL_FILE_DIRを設定するには、次の内容を初期化パラメータ・ファイルに記述します。
UTL_FILE_DIR = /oracle/database
初期化パラメータ・ファイルに対する変更を有効にするには、データベースの停止と再起動が必要であることに注意してください。
データベースがクローズされている場合、SQL*Plusを使用してマウントしてから、分析するREDOログ・ファイルが含まれるデータベースをオープンします。たとえば、SQL STARTUPコマンドを入力すると、データベースがマウントされ、オープンします。
STARTUP
DBMS_LOGMNR_D.BUILD PL/SQLプロシージャを実行します。ディクショナリのファイル名およびこのファイルのディレクトリ・パス名を指定します。このプロシージャにより、ディクショナリ・ファイルが作成されます。たとえば、/oracle/databaseでdictionary.oraファイルを作成するには、次のとおり入力します。
EXECUTE DBMS_LOGMNR_D.BUILD('dictionary.ora', -
'/oracle/database/', -
DBMS_LOGMNR_D.STORE_IN_FLAT_FILE);
STORE_IN_FLAT_FILEオプションを指定せずに、ファイル名と位置を指定することもできます。結果は同じになります。
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オプションでは、データベースがマウントされ、アーカイブが使用可能である必要があります。 |
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-2003 08:30:00', - ENDTIME => '01-Jan-2003 08:45:00', - OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG + - DBMS_LOGMNR.CONTINUOUS_MINE);
(この例では、DBMS_LOGMNR.START_LOGMNRプロシージャに対するPL/SQLコールで日付書式を指定する必要がないように、最初にSQL ALTER 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行で構成しています。
LogMinerを起動するには、DBMS_LOGMNR.START_LOGMNRプロシージャをコールします。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データにアクセスするには、V$LOGMNR_CONTENTSビューを問い合せます。(V$LOGMNR_CONTENTSを問い合せるには、SELECT ANY TRANSACTION権限が必要なことに注意してください。)このビューは、データベースに対して行われた変更に関する次のような履歴情報を提供します(次に示す以外の情報もあります)。
データベースに対して行われた変更のタイプ: 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です。
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固定ビューは、他のビューと異なり、表に格納されたデータの選択的表示ではありません。ユーザーがREDOログ・ファイルに対して要求したデータのリレーショナルな表示です。LogMinerがこのビューに移入するのは、このビューに対する問合せに応答する場合のみです。V$LOGMNR_CONTENTSを問い合せる前に、LogMinerを正常に起動しておく必要があります。
SQL選択操作がV$LOGMNR_CONTENTSビューに対して実行された場合、REDOログ・ファイルは順番に読み込まれます。REDOログ・ファイルから変換された情報が、V$LOGMNR_CONTENTSビューの行として返されます。これは、起動時に指定されたフィルタ基準を満たすまで、またはREDOログ・ファイルの終わりに達するまで繰り返されます。
V$LOGMNR_CONTENTSの特定の列が移入されない場合があります。次に例を示します。
TABLE_SPACE列は、OPERATION列の値がDDLの行には移入されません。DDLは、複数の表領域で動作する可能性があるためです。たとえば、表は、複数の表領域にわたる複数のパーティションで作成される可能性があるため、列に正しく移入されません。
LogMinerでは、一時表に対するSQLのREDOまたはSQLのUNDOは生成されません。SQL_REDO列には「/* No SQL_REDO for temporary tables */」、SQL_UNDO列には「/* No SQL_UNDO for temporary tables */」という文字列が表示されます。
LogMinerでは、COMMITTED_DATA_ONLYオプションを使用して、コミット済トランザクションのみを取得するように指定しないかぎり、すべての行がSCN順に返されます。SCN順は、メディア・リカバリで通常適用される順序です。
前述の理由から、さらに分析を行うためにデータを保持する必要がある場合、特に問合せによって返されるデータの量が、そのデータを提供するためにLogMinerによって分析されるREDOデータの量と比較して少ない場合は、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値を返した場合は、次のいずれかを意味します。
指定した列がデータの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;
MINE_VALUE関数およびCOLUMN_PRESENT関数には、次の使用規則が適用されます。
LogMinerセッション内でのみ使用できます。
V$LOGMNR_CONTENTSビューからの選択操作中に呼び出す必要があります。
LONG、LONG RAW、CLOB、BLOB、NCLOB、ADTまたはCOLLECTIONの各データ型はサポートしていません。
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として格納されています。
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列の存在です。オブジェクト識別子は、オブジェクト表の各オブジェクトを一意に識別するために使用されます。CLOBとして格納されるXMLType表については、表に行が挿入されると、Oracle Databaseによってこの値が生成されます。OBJECT_IDの値は、SQLを使用して表に直接挿入することはできません。したがって、LogMinerでは、この値を含む実行可能なSQL_REDOを生成できません。
V$LOGMNR_CONTENTSビューには、XMLType表に対して行われた変更に対して移入される新しいOBJECT_ID列があります。この値は、元の表のオブジェクト識別子です。ただし、この同じXML文書が同じXMLType表に挿入されても、新しいオブジェクト識別子が生成されます。XMLType表における更新や削除などの次のDMLのSQL_REDOには、WHERE句に元の表の行を一意に識別するためのオブジェクト識別子が含まれます。
次に、CLOBとして格納されるXMLType表に対する変更のマイニングの例を示します。
select operation, status, object_id, sql_redo from v$logmnr_contents where seg_owner = 'SCOTT' and table_name = 'XML_TYPE_CLOB_TAB';
OPERATION STATUS OBJECT_ID SQL_REDO
INSERT 2 300A9394B0F7B2D0E040578CF5025CC3 insert into "SCOTT"."XML_TYPE_CLOB_TAB"
values(EMPTY_CLOB())
XML DOC BEGIN 5 300A9394B0F7B2D0E040578CF5025CC3 insert into "SCOTT"."XML_TYPE_CLOB_TAB"
values (XMLType(:1)
XML DOC WRITE 5 300A9394B0F7B2D0E040578CF5025CC3 XML Data
XML DOC WRITE 5 300A9394B0F7B2D0E040578CF5025CC3 XML Data
XML DOC WRITE 5 300A9394B0F7B2D0E040578CF5025CC3 XML Data
XML DOC END 5
全体的なパターンは、XMLType列に非常に類似しています。ただし、いくつかの主な違いがあります。1つは、OBJECT_ID列が移入されている点です。2つ目の相違点は、最初の挿入にもかかわらず、INVALID_SQLの状態が2である点です。このことは、このレコードが行われる変更に対するプレースフォルダとしてREDOで発生するにもかかわらず、この変更に対して生成されたSQLが適用できないことを示しています。XML DOC BEGIN操作のSQL_REDOには、作成されたXML文書とともに使用する際に、行に対して行われた変更が反映されます。
XML文書が表外の列として格納されていない場合、その文書に対してXML DOC BEGIN、XML DOC WRITEまたはXML DOC END操作は行われません。文書は次のようなINSERT文に含まれます。
OPERATION STATUS OBJECT_ID SQL_REDO
INSERT 2 300AD8CECBA75ACAE040578CF502640C insert into "SCOTT"."XML_TYPE_CLOB_TAB"
values (EMPTY_CLOB())
INSERT 0 300AD8CECBA75ACAE040578CF502640C insert into "SCOTT"."XML_TYPE_CLOB_TAB"
values (XMLType(
'<?xml version="1.0"?>
<PO pono="1">
<PNAME>Po_99</PNAME>
<CUSTNAME>
Dave Davids
</CUSTNAME>
</PO>'))
XMLTypeデータのマイニングは、DBMS_LOGMNR.COMMITTED_DATA_ONLYオプションを使用している場合にのみ行う必要があります。そうしないと、一部の行の変更が不足しているために、不完全な変更が表示されたり、XMLとして表示されるはずの変更がCLOBの変更として表示される可能性があります。このために、これらのSQL DML文に対するSQL_REDOが不完全かつ無効になってしまいます。
SQL_UNDO列は、XMLTypeデータへの変更に対して移入されません。
この項の例では、表外の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'
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ビューに表示されます。このオプションを使用すると、ロールバックされたトランザクション、進行中のトランザクションおよび内部操作をフィルタ処理して除外できます。
このオプションを有効にするには、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文が発行されなかったため、このトランザクションは返されません。
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/2002 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
データを時刻でフィルタ処理するには、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-2008 08:30:00', - ENDTIME => '01-Jan-2008 08:45:00'- OPTIONS => DBMS_LOGMNR.CONTINUOUS_MINE);
タイムスタンプは、REDOレコードの順序の推測には使用しないでください。REDOレコードの順序は、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パラメータより優先されます。
|
参照:
|
デフォルトでは、再構築される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文は実行できません。
問合せの結果、再構築された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構文を使用していないため、実行されません。
ユーザーが発行した一部の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を再適用する場合は、V$LOGMNR_CONTENTSのINFO列に値USER_DDLが含まれる場合にのみ、SQL_REDO列またはSQL_UNDO列に含まれるDDL SQLを再実行する必要があります。
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を複数回コールすると有効な例を示します。
LogMinerがマイニングするREDOログ・ファイルのリストに、1週間の間に生成されたログ・ファイルが含まれているとします。ただし、それぞれの日の12:00から1:00の間に生成されたログ・ファイルのみを分析します。これを最も効率的に行う方法は次のとおりです。
月曜日に、この時間範囲を指定して、DBMS_LOGMNR.START_LOGMNRをコールします。
V$LOGMNR_CONTENTSビューから変更を選択します。
一週間のそれぞれの日に対して、手順1と2を繰り返します。
この方法では、その週のREDOデータの合計量が多い場合、リスト内の各REDOログ・ファイルの小さなサブセットのみがLogMinerによって読み込まれるため、全体の分析が非常に速く行われます。
REDOログ・ファイル・リストを指定し、LogMiner起動時に時間範囲(またはSCN範囲)を指定するとします。V$LOGMNR_CONTENTSビューを問い合せると、指定した時間範囲には、必要なデータの一部のみが含まれます。時間範囲を1時間拡張するために、またはSCN範囲を調整するためにDBMS_LOGMNR.START_LOGMNRを再度コールできます。
変更を分析またはデータベース間で変更をレプリケートするためのアプリケーションを作成したとします。ソース・データベースは、そのREDOログ・ファイルをマイニング・データベースに送信し、オペレーティング・システム・ディレクトリに格納します。アプリケーションは、次の手順を実行します。
現在ディレクトリにあるすべてのREDOログ・ファイルをREDOログ・ファイル・リストに追加します。
適切な設定でDBMS_LOGMNR.START_LOGMNRをコールし、V$LOGMNR_CONTENTSビューから選択します。
ディレクトリに新しく受信されたREDOログ・ファイルを追加します。
必要に応じて、手順2と3を繰り返します。
一般に、REDOログ・ファイルは、インスタンス・リカバリおよびメディア・リカバリに使用されます。これらの操作に必要なデータは、REDOログ・ファイルに自動的に記録されます。ただし、REDOベースのアプリケーションでは、追加の列をREDOログ・ファイルに記録する必要がある場合があります。これらの追加の列を記録するプロセスは、サプリメンタル・ロギングと呼ばれます。
デフォルトでは、Oracle Databaseでサプリメンタル・ロギングは提供されません。つまり、デフォルトでは、LogMinerは使用できません。したがって、LogMinerで分析するログ・ファイルを生成する前に、少なくとも最小サプリメンタル・ロギングは有効にする必要があります。
次に、追加の列が必要な例を示します。
再構築されたSQL文を別のデータベースに適用するアプリケーションでは、行を一意に識別する列(主キーなど)で更新文を識別する必要があります。ROWIDはデータベースごとに異なり、他のデータベースでは意味を持たないため、V$LOGMNR_CONTENTSビューによって返される再構築されたSQLに示されるROWIDでは識別できません。
アプリケーションは、行変更の追跡をより効率的にするために、変更された列のみでなく、行全体のビフォア・イメージを記録する必要がある場合があります。
サプリメンタル・ログ・グループは、サプリメンタル・ロギングが有効な場合に記録される追加の列です。サプリメンタル・ログ・グループは2種類あり、これらによって、ログ・グループの列を記録する時期が決定されます。
無条件のサプリメンタル・ログ・グループ: 指定した列に更新が影響したかどうかに関係なく、行が更新されるたびに指定した列のビフォア・イメージが記録されます。これは、ALWAYSログ・グループと呼ばれる場合もあります。
条件付きのサプリメンタル・ログ・グループ: ログ・グループの1つ以上の列が更新された場合にのみ、指定したすべての列のビフォア・イメージが記録されます。
サプリメンタル・ログ・グループは、システムで生成することも、ユーザーが定義することもできます。
次の項で説明するとおり、サプリメンタル・ロギングには、2つの種類に加えて2つのレベルがあります。
データベース・レベルのサプリメンタル・ロギングには、次の項で説明するとおり、最小サプリメンタル・ロギングと識別キー・ロギングがあります。最小サプリメンタル・ロギングでは、REDOログ・ファイルを生成するデータベースに大きなオーバーヘッドが発生しません。ただし、データベース全体の識別キー・ロギングを有効にすると、REDOログ・ファイルを生成するデータベースにオーバーヘッドが発生する場合があります。LogMinerに対しては、少なくとも最小サプリメンタル・ロギングを有効にすることをお薦めします。
最小サプリメンタル・ロギングは、LogMinerでDML変更と関連付けられたREDO操作を識別、グループ化およびマージするために必要な最小限の情報を記録します。また、LogMiner(およびLogMinerテクノロジに基づいた他の製品)に、連鎖行や様々な記憶域構成(クラスタ表、索引構成表など)のサポートに十分な情報を確保します。最小サプリメンタル・ロギングを有効にするには、次のSQL文を実行します。
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
|
注意: Oracle Databaseのリリース9.0.1では、最小サプリメンタル・ロギングがLogMinerのデフォルト動作でした。リリース9.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カーソルが無効になります。したがって、カーソル・キャッシュに再移入を行うまで、パフォーマンスに影響する場合があります。
データベース・レベルで識別キー・ロギングを有効にすると、最小サプリメンタル・ロギングが暗黙で有効になります。
サプリメンタル・ロギング文は累積的に実行されます。次のSQL文を発行すると、主キー・サプリメンタル・ロギングと一意キー・サプリメンタル・ロギングの両方が有効になります。
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (PRIMARY KEY) COLUMNS; ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (UNIQUE) COLUMNS;
データベース・レベルのサプリメンタル・ロギングを無効にするには、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;
最小サプリメンタル・ログ・データは、データベース・レベルの他のサプリメンタル・ロギングが有効になっていない場合にのみ削除できます。
表レベルのサプリメンタル・ロギングでは、補助的に記録する列を表レベルで指定します。識別キー・ロギングまたはユーザー定義の条件付きのサプリメンタル・ログ・グループまたは無条件のサプリメンタル・ログ・グループを使用して、次の項で説明するとおり、補助情報を記録できます。
表レベルでの識別キー・ロギングでは、データベース・レベルの場合と同じオプション(すべて、主キー、外部キー、一意キー)が提供されます。ただし、表レベルで識別キー・ロギングを指定すると、指定した表のみが影響を受けます。たとえば、次の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;
各識別キー・ロギング・オプションの詳細は、「データベース・レベルの識別キー・ロギング」を参照してください。
表レベルの識別キー・ロギングによって、ユーザー定義のサプリメンタル・ログ・グループもサポートされています。ユーザー定義サプリメンタル・ログ・グループによって、補助的に記録する列を指定できます。条件付きログ・グループまたは無条件ログ・グループは、次のとおり指定できます。
ユーザー定義の無条件ログ・グループ
ユーザー定義の無条件ログ・グループを使用するサプリメンタル・ロギングを有効にするには、次の例に示すとおり、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列自体は補助的に記録できませんが、この列に対して行った変更を使用して、同じ行の他の列のサプリメンタル・ロギングをトリガーすることはできます。
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オプションでは、データベースがオープンしている必要があります。
サプリメンタル・ロギングをデータベース全体で有効にするか、または対象となる表のログ・グループを作成しておく必要があります。
ディクショナリ追跡とサプリメンタル・ロギングの各種設定を組み合せた場合に発生する次の相互作用に注意してください。
DDL_DICT_TRACKINGが有効で、サプリメンタル・ロギングが有効でない場合は、次のようになります。
REDOログ・ファイルでDDLトランザクションが検出された場合、V$LOGMNR_CONTENTSの問合せはORA-01347エラーを返して終了します。
REDOログ・ファイルでDMLトランザクションが検出された場合、LogMinerディクショナリ内の表(そのDMLの基礎となる表)の現在のバージョンがLogMinerによって正しいとは認識されず、V$LOGMNR_CONTENTSの列が次のように設定されます。
SQL_REDO列にバイナリ・データが含まれます。
STATUS列に値2が含まれます(SQLが有効でないことを示します)。
INFO列に「ディクショナリの不一致」という文字列が含まれます。
DDL_DICT_TRACKINGおよびサプリメンタル・ロギングが有効ではない場合、DML操作で参照された列がLogMinerディクショナリ内の列と一致すると、LogMinerディクショナリの最新バージョンがLogMinerによって正しいと認識され、V$LOGMNR_CONTENTSの列が次のように設定されます。
LogMinerは、LogMinerディクショナリ内のオブジェクトの定義を使用して、SQL_REDO列とSQL_UNDO列の値を生成します。
STATUS列に値3が含まれます(SQLが正しいと保証できないことを示します)。
INFO列には、「サプリメンタル・ログ・データが見つかりません」という文字列が含まれます。
DDL_DICT_TRACKINGおよびサプリメンタル・ロギングが有効ではない場合に、表のLogMinerディクショナリ定義で定義された列より、表のREDOログ・ファイル内の変更された列の方が多いときは、次のようになります。
SQL_REDO列とSQL_UNDO列に「ディクショナリのバージョンの不一致」という文字列が含まれます。
STATUS列に値2が含まれます(SQLが有効でないことを示します)。
INFO列に「ディクショナリの不一致」という文字列が含まれます。
また、列のディクショナリ定義で定義されている型とその列の実際の型が異なる場合は、予期しない動作が発生する可能性があります。
LogMinerは、LogMinerディクショナリの一貫性を維持するためにDDL文が必要なため、DDL_DICT_TRACKINGオプションが有効な場合、要求した開始時刻またはSCN(DBMS_LOGMNR.START_LOGMNRで指定)より前に、REDOログ・ファイルの読取りを開始する場合があります。LogMinerがREDOログ・ファイルの読取りを開始する実際の時刻またはSCNは、必須開始時刻または必須開始SCNと呼ばれます。
欠落REDOログ・ファイル(順序番号に基づく)は、必須開始時刻または必須開始SCNから読取りを開始できません。
LogMinerでは、REDOログ・データの読取りを開始する位置を次のとおり決定します。
ディクショナリのロード後、DBMS_LOGMNR.START_LOGMNRを初めてコールする場合、LogMinerは、次のいずれかの値の早い方を基準に読取りを開始します。
ユーザーが要求した開始時刻またはSCN値
ディレクトリ・ダンプのコミットSCN
DBMS_LOGMNR.START_LOGMNRに対するこれ以降のコールでは、LogMinerは、次のいずれかの値の最も早いものを基準に読取りを開始します。
ユーザーが要求した開始時刻またはSCN値
COMMIT文がLogMinerによって読み込まれていない最も早いDDLトランザクションの開始時
LogMinerによって読み込まれた最高のSCN
次に、前述の内容の使用例を示します。
5つのREDOログ・ファイルを含むREDOログ・ファイル・リストを作成するとします。ディクショナリは、最初のREDOファイルに含まれ、確認対象として指定した変更(DBMS_LOGMNR.START_LOGMNRを使用)は、3番目のREDOログ・ファイルに記録されているとします。ここで、次の手順を実行します。
DBMS_LOGMNR.START_LOGMNRをコールします。LogMinerによって、次のログ・ファイルが読み込まれます。
ディクショナリをロードするための最初のログ・ファイル
その中に含まれている可能性があるDDLをすべて取得するための2番目のREDOログ・ファイル
必要なデータを取得するための3番目のログ・ファイル
同じ要求範囲で、再度DBMS_LOGMNR.START_LOGMNRをコールします。
LogMinerは、REDOログ・ファイル3から読取りを開始します。REDOログ・ファイル2に含まれているDDL文はすでに処理されているため、REDOログ・ファイル2を読み込む必要はありません。
DBMS_LOGMNR.START_LOGMNRを再度コールします。今回は、REDOログ・ファイル5からデータを読み込む必要があるパラメータを指定します。
LogMinerは、REDOログ・ファイル4から読取りを開始し、その中に含まれているすべてのDDL文を取得します。
LogMinerが実際に読取りを開始する位置を確認するには、V$LOGMNR_PARAMETERSビューのREQUIRED_START_DATE列またはREQUIRED_START_SCN列を問い合せます。LogMinerが読取りを開始する位置に関係なく、要求した範囲内の行のみがV$LOGMNR_CONTENTSビューから返されます。
LogMiner操作情報(REDOデータではなく)は、次のビューに含まれています。他のビューと同様に、SQLを使用してこれらのビューを問い合せることができます。
DBMS_LOGMNR.START_LOGMNRに対してSTORE_IN_FLAT_FILEオプションを使用して作成されたLogMinerディクショナリ・ファイルに関する情報を表示します。LogMinerディクショナリ作成の基礎となったデータベースに関する情報などが表示されます。
指定したREDOログ・ファイルに関する情報を表示します。詳細は、「V$LOGMNR_LOGSの問合せ」を参照してください。
オプションの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_COLUMSNS
サプリメンタル・ロギングの現在の設定に関する情報を表示します。詳細は、「サプリメンタル・ロギング設定に関するビューの問合せ」を参照してください。
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をコールできます。
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」など)
次のリストに示すように、複数のビューを問い合せてサプリメンタル・ロギングの現在の設定を確認できます。
V$DATABASEビュー
SUPPLEMENTAL_LOG_DATA_FK列
この列には次のいずれかの値が入ります。
NO: FOREIGN KEYオプションを指定したデータベース・レベルの識別キー・ロギングが有効でない場合
YES: FOREIGN KEYオプションを指定したデータベース・レベルの識別キー・ロギングが有効な場合
SUPPLEMENTAL_LOG_DATA_ALL列
この列には次のいずれかの値が入ります。
NO: ALLオプションを指定したデータベース・レベルの識別キー・ロギングが有効でない場合
YES: ALLオプションを指定したデータベース・レベルの識別キー・ロギングが有効な場合
SUPPLEMENTAL_LOG_DATA_UI列
NO: UNIQUEオプションを指定したデータベース・レベルの識別キー・ロギングが有効でない場合
YES: UNIQUEオプションを指定したデータベース・レベルの識別キー・ロギングが有効な場合
SUPPLEMENTAL_LOG_DATA_MIN列
この列には次のいずれかの値が入ります。
NO: データベース・レベルのサプリメンタル・ロギングが有効でない場合
IMPLICIT: データベース・レベルの識別キー・ロギング・オプションが有効なため、最小サプリメンタル・ロギングが有効な場合
YES: SQL ALTER DATABASE ADD SUPPLEMENTAL LOG DATA文が発行されているため、最小サプリメンタル・ロギングが有効な場合
DBA_LOG_GROUPS、ALL_LOG_GROUPS、USER_LOG_GROUPSの各ビュー
ALWAYS列
この列には次のいずれかの値が入ります。
ALWAYS: このログ・グループの列は、関連付けられた行の列が更新された場合に補助的に記録されることを示します。
CONDITIONAL :このグループの列は、ログ・グループの列が更新された場合にのみ補助的に記録されることを示します。
GENERATED列
この列には次のいずれかの値が入ります。
GENERATED NAME: LOG_GROUP名がシステムによって生成された場合です。
USER NAME: LOG_GROUP名がユーザーによって定義された場合です。
LOG_GROUP_TYPES列
この列には、次のいずれかの値が入り、このログ・グループで定義されたロギングの種類を示します。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セッションの手順について説明します。各手順の詳細は、該当する後述の項を参照してください。
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ロールを付与されている必要があります。
|
参照:
|
使用する種類のサプリメンタル・ロギングを有効にします。最低限、次のように最小サプリメンタル・ロギングを有効にする必要があります。
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
詳細は、「サプリメンタル・ロギング」を参照してください。
LogMinerを使用するには、次のいずれかの方法でディクショナリを含める必要があります。
LogMiner起動時にDICT_FROM_ONLINE_CATALOGオプションでオンライン・カタログの使用を指定。詳細は、「オンライン・カタログの使用」を参照してください。
REDOログ・ファイルにデータベース・ディクショナリ情報を抽出。詳細は、「REDOログ・ファイルへのLogMinerディクショナリの抽出」を参照してください。
フラット・ファイルにデータベース・ディクショナリ情報を抽出。詳細は、「フラット・ファイルへのLogMinerディクショナリの抽出」を参照してください。
LogMinerを起動する前に、分析するREDOログ・ファイルを指定する必要があります。この指定を行うには、次の手順で示すとおり、DBMS_LOGMNR.ADD_LOGFILEプロシージャを実行します。REDOログ・ファイルは、任意の順序で追加および削除できます。
|
注意: REDOログ・ファイルを生成するデータベース・インスタンスでマイニングを行う場合は、LogMinerの起動時にCONTINUOUS_MINEオプションおよび次のいずれかのパラメータを指定する必要があります。
詳細は、「REDOログ・ファイル・オプション」を参照してください。 |
データベースをマウントした状態またはマウントしていない状態で、SQL*Plusを使用してOracleインスタンスを起動します。たとえば、SQLプロンプトでSTARTUP文を入力します。
STARTUP
REDOログ・ファイルのリストを作成します。PL/SQLプロシージャDBMS_LOGMNR.ADD_LOGFILEのNEWオプションを指定して、新規リストの開始であることを指定します。たとえば、REDOログ・ファイル/oracle/logs/log1.fを指定するには、次のように入力します。
EXECUTE DBMS_LOGMNR.ADD_LOGFILE( - LOGFILENAME => '/oracle/logs/log1.f', - OPTIONS => DBMS_LOGMNR.NEW);
必要に応じて、PL/SQLプロシージャDBMS_LOGMNR.ADD_LOGFILEのADDFILEオプションを指定し、さらにREDOログ・ファイルを追加します。たとえば、REDOログ・ファイル/oracle/logs/log2.fを追加するには、次のように入力します。
EXECUTE DBMS_LOGMNR.ADD_LOGFILE( - LOGFILENAME => '/oracle/logs/log2.f', - OPTIONS => DBMS_LOGMNR.ADDFILE);
REDOログ・ファイルを追加する場合、OPTIONSパラメータの指定はオプションです。たとえば、次のように入力できます。
EXECUTE DBMS_LOGMNR.ADD_LOGFILE( - LOGFILENAME=>'/oracle/logs/log2.f');
必要に応じて、PL/SQLプロシージャDBMS_LOGMNR.REMOVE_LOGFILEを使用してREDOログ・ファイルを削除します。たとえば、REDOログ・ファイル/oracle/logs/log2.fを削除するには、次のように入力します。
EXECUTE DBMS_LOGMNR.REMOVE_LOGFILE( - LOGFILENAME => '/oracle/logs/log2.f');
LogMinerディクショナリ・ファイルを作成し、分析するREDOログ・ファイルを指定した後、LogMinerを起動する必要があります。次の手順を実行します。
DBMS_LOGMNR.START_LOGMNRプロシージャを実行して、LogMinerを起動します。
LogMinerディクショナリ・オプションを指定することをお薦めします。このオプションを指定していない場合、LogMinerでは、内部オブジェクトの識別子とデータ型を、オブジェクト名と外部データ書式に変換できません。したがって、内部オブジェクトIDが返され、データはバイナリ・データとして提供されます。また、ディクショナリがない場合、MINE_VALUE機能およびCOLUMN_PRESENT機能は使用できません。
フラット・ファイルのLogMinerディクショナリの名前を指定する場合は、そのディクショナリ・ファイルに完全修飾されたファイル名を指定する必要があります。たとえば、/oracle/database/dictionary.oraを使用してLogMinerを起動するには、次の文を発行します。
EXECUTE DBMS_LOGMNR.START_LOGMNR( - DICTFILENAME =>'/oracle/database/dictionary.ora');
フラット・ファイルのディクショナリ名を指定しない場合は、OPTIONSパラメータを使用して、DICT_FROM_REDO_LOGSオプションまたはDICT_FROM_ONLINE_CATALOGオプションのいずれかを指定します。
DICT_FROM_REDO_LOGSを指定した場合、LogMinerでは、DBMS_LOGMNR.ADD_LOGFILEプロシージャで指定したREDOログ・ファイルに、ディクショナリが含まれていると認識されます。ディクショナリが含まれているREDOログ・ファイルを判別するには、V$ARCHIVED_LOGビューを使用します。例については、「REDOログ・ファイルへのLogMinerディクショナリの抽出」を参照してください。
|
注意: LogMinerの起動後にREDOログ・ファイルを追加した場合は、LogMinerを再起動する必要があります。LogMinerは、DBMS_LOGMNR.START_LOGMNRに対する前回のコールに含まれていたオプションを保持しないため、使用するオプションを再度指定する必要があります。ただし、DBMS_LOGMNR.START_LOGMNRに対する現在のコールでディクショナリを指定しない場合は、前回のコールで指定したディクショナリ仕様を保持します。 |
DICT_FROM_ONLINE_CATALOGオプションの詳細は、「オンライン・カタログの使用」を参照してください。
オプションで、時刻またはSCNによって問合せをフィルタ処理できます。詳細は、「時刻によるデータのフィルタ処理」または「SCNによるデータのフィルタ処理」を参照してください。
OPTIONSパラメータを使用して、LogMinerセッションの特性を追加指定することもできます。たとえば、オンライン・カタログをLogMinerディクショナリとして使用して、V$LOGMNR_CONTENTSビューにコミット済トランザクションのみを表示できます。次のように入力します。
EXECUTE DBMS_LOGMNR.START_LOGMNR(OPTIONS => - DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG + - DBMS_LOGMNR.COMMITTED_DATA_ONLY);
DBMS_LOGMNR.START_LOGMNRオプションの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
DBMS_LOGMNR.START_LOGMNRプロシージャは、毎回異なるオプションを指定して、複数回実行できます。この機能は、たとえば、V$LOGMNR_CONTENTSの問合せから必要な結果を取得できず、他のオプションを指定してLogMinerを再起動する場合に有効です。LogMinerディクショナリを再指定する必要がないかぎり、DBMS_LOGMNR.START_LOGMNRに対する前回のコールでREDOログ・ファイルがすでに追加されている場合は、再度追加する必要はありません。
この時点で、LogMinerは起動され、V$LOGMNR_CONTENTSビューに対して問合せを実行できます。この例については、「V$LOGMNR_CONTENTSに返されるデータのフィルタ処理および書式設定」を参照してください。
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の使用例を示します。
|
注意: この項のすべての例では、最小サプリメンタル・ロギングが次のように有効にされているとします。SQL> ALTER DATABASE ADD SUPPLEMENTAL LOG DATA; 詳細は、「サプリメンタル・ロギング」を参照してください。 「例2: 指定したSCN範囲でのREDOログ・ファイルのマイニング」と「使用例」以外のすべての例では、 SQL> ALTER SESSION SET NLS_DATE_FORMAT = 'dd-mon-yyyy hh24:mi:ss'; LogMinerではユーザー・セッションに対してアクティブな |
次の例では、分析対象データが存在するREDOログ・ファイルがわかっている場合のLogMinerの使用方法を示します。この項は、次に示す例で構成されています。それぞれの例は、前の例に基づいて作成されているため、順番に読み進むことをお薦めします。
SQL出力の画面上の書式設定は、この項で示す例とは異なる場合があります。
データベースの変更履歴を確認する最も簡単な方法は、ソース・データベースでマイニングし、オンライン・カタログを使用してREDOログ・ファイルを変換する方法です。この例では、LogMinerを使用して最も簡単に分析を行う方法を示します。
この例では、最後にアーカイブされた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
手順1の問合せで返された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);
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-2003
('306','Nandini','Shastry', 13:34:43', 'dd-mon-yyyy hh24:mi:ss')
'NSHASTRY', '1234567890', and "JOB_ID" = 'HR_REP' and
TO_DATE('10-jan-2003 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-2003
('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-2003 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;
SQL> EXECUTE DBMS_LOGMNR.END_LOGMNR();
最初の例(「例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.START_LOGMNR( - OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG + - DBMS_LOGMNR.COMMITTED_DATA_ONLY);
「例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-2003
('306','Nandini','Shastry', 13:34:43', 'dd-mon-yyyy hh24:mi:ss')
'NSHASTRY', '1234567890', and "JOB_ID" = 'HR_REP' and
TO_DATE('10-jan-2003 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-2003
('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-2003 13:41:03', = '50' and ROWID = 'AAAHSkAABAAAY6rAAP';
'dd-mon-yyyy hh24:mi:ss'),
'SH_CLERK','110000', '.05',
'105','50');
HR 1.11.1476 commit;
EXECUTE DBMS_LOGMNR.END_LOGMNR();
「例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ログ・ファイルを指定します。このリストは、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の書式のみを変更するため、目視用のレポートを生成する場合に有効です。
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-2003 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-2003 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;
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-2003 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-2003 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;
EXECUTE DBMS_LOGMNR.END_LOGMNR();
この例では、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でマイニングを続行できます。
SQL> SELECT FILENAME AS name, LOW_TIME, HIGH_TIME FROM V$LOGMNR_LOGS; NAME LOW_TIME HIGH_TIME ------------------------------------- -------------------- -------------------- /usr/data/db1arch_1_207_482701534.dbf 10-jan-2003 12:01:34 10-jan-2003 13:32:46 /usr/data/db1arch_1_208_482701534.dbf 10-jan-2003 13:32:46 10-jan-2003 15:57:03 Missing logfile(s) for thread number 1, 10-jan-2003 15:57:03 10-jan-2003 15:59:53 sequence number(s) 209 to 209 /usr/data/db1arch_1_210_482701534.dbf 10-jan-2003 15:59:53 10-jan-2003 16:07:41
使用するディクショナリおよび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);
問合せによって返される行数を減らすには、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-2003 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-2003 14:01:03', 'dd-mon-yyyy hh24:mi:ss'),
"MTIME" = TO_DATE('13-jan-2003 14:01:03', 'dd-mon-yyyy hh24:mi:ss'),
"STIME" = TO_DATE('13-jan-2003 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-2003 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-2003 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;
EXECUTE DBMS_LOGMNR.END_LOGMNR();
この例では、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ログ・ファイルで検出された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ログ・ファイルは任意の順序で追加できます。
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);
返される行数を減らすため、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-2003 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-2003 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-2003 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;
EXECUTE DBMS_LOGMNR.END_LOGMNR();
前の2つの例では、問合せにタイムスタンプ・ベースの条件(TIMESTAMP > '10-jan-2003 15:59:53')を指定して、行をフィルタ処理しました。ただし、タイムスタンプ値に基づいてREDOレコードを除外するには、この例で示すとおり、DBMS_LOGMNR.START_LOGMNRプロシージャ・コールで時間範囲を指定する方法がより効率的です。
指定した時刻以降に生成されたREDOログ・ファイルをマイニングするとします。次のプロシージャは、指定した時刻に基づいてREDOログ・ファイルのリストを作成します。その後のSQL EXECUTE文は、プロシージャをコールし、開始時刻を2003年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-2003 14:00:00');
この例では、出力に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-2003 14:02:35 23683584
/usr/orcl/arch1_311_482932022.dbf 13-jan-2003 14:56:35 2564096
/usr/orcl/arch1_312_482932022.dbf 13-jan-2003 15:10:43 23683584
/usr/orcl/arch1_313_482932022.dbf 13-jan-2003 15:17:52 23683584
/usr/orcl/arch1_314_482932022.dbf 13-jan-2003 15:23:10 23683584
/usr/orcl/arch1_315_482932022.dbf 13-jan-2003 15:43:22 23683584
/usr/orcl/arch1_316_482932022.dbf 13-jan-2003 16:03:10 23683584
/usr/orcl/arch1_317_482932022.dbf 13-jan-2003 16:33:43 23683584
/usr/orcl/arch1_318_482932022.dbf 13-jan-2003 17:23:10 23683584
午後3時から4時の間に生成されたREDOログ・ファイルのみをマイニングする必要があるとします。
問合せ条件(TIMESTAMP > '13-jan-2003 15:00:00'およびTIMESTAMP < '13-jan-2003 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-2003 15:00:00', -
ENDTIME => '13-jan-2003 16:00:00', -
OPTIONS => DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG + -
DBMS_LOGMNR.COMMITTED_DATA_ONLY + -
DBMS_LOGMNR.PRINT_PRETTY_SQL);
SELECT TIMESTAMP, (XIDUSN || '.' || XIDSLT || '.' || XIDSQN) AS XID,
SQL_REDO FROM V$LOGMNR_CONTENTS WHERE SEG_OWNER = 'OE';
TIMESTAMP XID SQL_REDO
--------------------- ----------- --------------------------------
13-jan-2003 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-2003 15:29:34 1.17.2376 insert into "OE"."PRODUCT_TRACKING"
values
"PRODUCT_ID" = 3399,
"MODIFIED_TIME" = TO_DATE('13-jan-2003 15:29:34',
'dd-mon-yyyy hh24:mi:ss'),
"OLD_LIST_PRICE" = 815,
"OLD_WARRANTY_PERIOD" = TO_YMINTERVAL('+02-00');
13-jan-2003 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-2003 15:52:43 1.15.1756 insert into "OE"."PRODUCT_TRACKING"
values
"PRODUCT_ID" = 1768,
"MODIFIED_TIME" = TO_DATE('13-jan-2003 16:52:43',
'dd-mon-yyyy hh24:mi:ss'),
"OLD_LIST_PRICE" = 715,
"OLD_WARRANTY_PERIOD" = TO_YMINTERVAL('+02-00');
EXECUTE DBMS_LOGMNR.END_LOGMNR();
前述の例では、マイニングするREDOログ・ファイルを明示的に指定しました。この例では、REDOログ・ファイルを生成したデータベースと同じデータベースでマイニングする場合、分析する時間(またはSCN)範囲を指定するのみで適切なREDOログ・ファイルのリストをマイニングできる方法を示します。REDOログ・ファイルを明示的に指定せずにマイニングするには、DBMS_LOGMNR.START_LOGMNRプロシージャに対してDBMS_LOGMNR.CONTINUOUS_MINEオプションを使用し、分析する時間範囲またはSCN範囲のいずれかを指定します。
この項は、次の例で構成されています。それぞれの例は、前の例に基づいて作成されているため、順番に読み進むことをお薦めします。
SQL出力の画面上の書式設定は、この項で示す例とは異なる場合があります。
この例は、「例4: REDOログ・ファイル内のLogMinerディクショナリの使用」と同様ですが、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-2003 12:01:34
この手順は必須ではありませんが、手順4に示すとおり、CONTINUOUS_MINEオプションが予期したとおりに機能することを示すために含めています。
SELECT FILENAME name FROM V$LOGMNR_LOGS WHERE LOW_TIME > '10-jan-2003 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-2003 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);
この手順は、予期したとおり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
問合せによって返される行数を減らすため、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-2003 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-2003 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-2003 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;
EXECUTE DBMS_LOGMNR.END_LOGMNR();
この例では、分析するSCN範囲を指定する方法、およびその範囲を満たすREDOログ・ファイルをマイニングする方法を示します。LogMinerを使用して、データ・ファイルで影響がまだ永続的になっていないすべてのコミット済DML文を表示できます。
この例では(他の例と異なり)、NLS_DATE_FORMATパラメータを設定していないことに注意してください。
SELECT CHECKPOINT_CHANGE#, CURRENT_SCN FROM V$DATABASE;
CHECKPOINT_CHANGE# CURRENT_SCN
------------------ ---------------
56453576 56454208
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);
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
次の問合せは、トランザクション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');
EXECUTE DBMS_LOGMNR.END_LOGMNR();
所定の時刻になるまでまたはSCNに到達するまで問合せが終了しないように指定するには、DBMS_LOGMNR.START_LOGMNRプロシージャへのコールで、CONTINUOUS_MINEオプションを使用し、ENDTIMEオプションまたはENDSCNオプションのいずれかを、将来の時刻またはまだ到達していないSCN値に設定します。
この例では、現在から5時間後までの間に表hr.employeesに対して行われたすべての変更を監視するとします。また、オンライン・カタログ内のディクショナリを使用するとします。
EXECUTE DBMS_LOGMNR.START_LOGMNR(-
STARTTIME => SYSDATE, -
ENDTIME => SYSDATE + 5/24, -
OPTIONS => DBMS_LOGMNR.CONTINUOUS_MINE + -
DBMS_LOGMNR.DICT_FROM_ONLINE_CATALOG);
この選択操作は、分析する時間範囲(現在から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';
EXECUTE DBMS_LOGMNR.END_LOGMNR();
この項では、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( );
この例では、ダイレクト・マーケティング・データベースを管理し、1月の2週間の収益でのカスタマ・コンタクトの有効性を確認するとします。すでにLogMinerディクショナリを作成済で、検索するREDOログ・ファイルを追加してあるとします(前述の例と同様)。次の手順を実行します。
LogMinerを起動し、時間範囲を指定します。
EXECUTE DBMS_LOGMNR.START_LOGMNR( -
STARTTIME => TO_DATE('07-Jan-2003 08:30:00','DD-MON-YYYY HH:MI:SS'), -
ENDTIME => TO_DATE('21-Jan-2003 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( );
次の項では、データ型と記憶域属性のサポートに関する情報およびサポートされるデータベースとREDOログ・ファイルのリリースを示します。
LogMinerは、次のデータ型と表記憶域属性をサポートします。このリストの後の情報に記載するように、一部のデータ型は特定のリリースのみでサポートされています。
CHAR
NCHAR
VARCHAR2およびVARCHAR
NVARCHAR2
NUMBER
DATE
TIMESTAMP
TIMESTAMP WITH TIME ZONE
TIMESTAMP WITH LOCAL TIME ZONE
INTERVAL YEAR TO MONTH
INTERVAL DAY TO SECOND
RAW
CLOB
NCLOB
BLOB
LONG
LONG RAW
BINARY_FLOAT
BINARY_DOUBLE
索引構成表(IOT)(オーバーフローまたはLOB列がある索引構成表を含む)
関数ベースの索引
基本的な表圧縮とOLTP表圧縮を使用する表
CLOB形式で格納されるXMLTypeデータ
オブジェクト・リレーショナル形式で格納されるXMLTypeデータ。XMLデータに関連する操作用のSQL_REDO列の内容は、有効なSQLまたはPL/SQLではありません。
バイナリXMLとして格納されているXMLTypeデータ。XMLデータに関連する操作用のSQL_REDO列の内容は、有効なSQLまたはPL/SQLではありません。
ハイブリッド列圧縮(サポートは、基礎となるストレージ・システムに依存します。ハイブリッド列圧縮の詳細は、『Oracle Database概要』を参照してください。互換性は11.2に設定する必要があります。)
マルチバイトのCLOBは、互換性が10.1以上に設定されているデータベースによって生成されたREDOログの場合のみサポートされます。
LOBデータ型およびLONGデータ型は、互換性が9.2.0.0以上に設定されているデータベースによって生成されたREDOログの場合のみサポートされます。
オーバーフロー・セグメントまたはLOB列を含まない索引構成表は、互換性が10.0.0.0以上に設定されているデータベースによって生成されたREDOログの場合のみサポートされます。オーバーフロー・セグメントまたはLOB列を含む索引構成表は、互換性が10.2.0.0以上に設定されているデータベースによって生成されたREDOログの場合のみサポートされます。
バイナリXMLとして格納されたXMLTypeデータは、REDO互換性が11.2.0.3以上に設定されている、Oracle Database 11g リリース2(11.2.0.3)以上でのみサポートされます。
オブジェクト・リレーショナル形式で格納されたXMLTypeデータは、REDO互換性が11.2.0.3以上に設定されている、Oracle Database 11g リリース2(11.2.0.3)以上でのみサポートされます。
LogMinerは、次のデータ型と表記憶域属性をサポートしません。これらのサポートされていないデータ型のいずれかを使用する列が表に含まれる場合、表全体がLogMinerによって無視されます。
BFILEデータ型
単純およびネストされた抽象データ型(ADT)
コレクション(ネストされた表およびVARRAY)
オブジェクト参照
SecureFiles(データベース互換性が11.2以上に設定されていない場合)
LogMinerは、リリース8.1以上のデータベースでのみ実行されますが、リリース8.0のデータベースからのREDOログ・ファイルの分析に使用することができます。ただし、LogMinerでREDOログ・ファイルから取得することができる情報は、使用中のデータベースのリリースではなく、ログのバージョンに依存します。たとえば、サプリメンタル・ロギングが有効な場合は、Oracle9iのREDOログ・ファイルを拡張して追加情報を取得できます。これによって、LogMinerの機能を最大限使用できます。旧リリースのOracleで作成されたREDOログ・ファイルには、追加データが含まれていないため、LogMinerによってサポートされる操作およびデータ型が制限される場合があります。
SecureFiles LOBは、データベース互換性が11.2以上に設定されている場合にサポートされます。SecureFiles LOB列には、SQL_REDO列のみを入力できます。SQL_UNDO列は入力されません。
プライマリ・データベースでは、SecureFiles LOB列で透過的なデータ暗号化およびデータ圧縮を使用できます。
SecureFiles LOB列の重複除外、SecureFiles LOB列でのフラグメントベースの操作、およびSecureFiles Database File System(DBFS)操作はサポートされていません。特に、DBMS_LOB PL/SQLパッケージに含まれている次の操作はSecureFiles LOB列でサポートされません。
FRAGMENT_DELETE、FRAGMENT_INSERT、FRAGMENT_MOVE、FRAGMENT_REPLACE, COPY_FROM_DBFS_LINK、MOVE_TO_DBFS_LINK、SET_DBFS_LINK、COPY_DBFS_LINKおよびSETCONTENTTYPE。
LogMinerは、これらの操作によって生成されたREDOを検出すると、OPERATION列がUNSUPPORTEDに設定された行を生成します。これらのREDOレコードには、SQL_REDOまたはSQL_UNDOは生成されません。
