| Oracle Streams概要および管理 11g リリース1（11.1） E05775-02 |
|
 前へ |
 次へ |
Oracle Streamsでの情報の取得とは、情報を含むメッセージを作成し、そのメッセージをキューにエンキューすることです。取得される情報は、データベースの変更に関する説明の場合もあれば、その他の情報である場合もあります。
次の各項では、Oracle Streamsによる情報の取得の概念について説明します。
Oracle Streamsで情報を取得する方法には、暗黙的取得と明示的取得の2つがあります。
暗黙的取得では、取得プロセスまたは同期取得によってデータ定義言語（DDL）とデータ操作言語（DML）の変更が自動的に取得されます。論理変更レコード（LCR）と呼ばれる特殊なタイプのメッセージに、このようなデータベースの変更が記述されています。取得プロセスと同期取得は両方とも、ユーザー定義のルールを使用してデータベース変更をフィルタ処理できます。したがって、指定したオブジェクトに対する変更のみを取得できます。
次の各項では、取得プロセスと同期取得について説明します。
取得プロセスは、オンラインREDOログのマイニングまたは必要であればアーカイブ・ログ・ファイルのマイニングを行って、REDOログから変更データを取り出します。データを取り出したら、取得プロセスはそのデータをLCR形式にフォーマットし、さらに処理するためにエンキューします。
取得プロセスは、データベース変更に関する情報を、LCRを含むメッセージの形式でエンキューします。取得プロセスが取得してエンキューしたLCRを含むメッセージは、取得LCRと呼ばれます。取得プロセスでは、メッセージは常にバッファ・キューにエンキューされます。バッファ・キューは、メモリーへのメッセージの格納にOracle Streamsプールを使用し、メモリーからオーバーフローしたメッセージの格納にキュー表を使用するキューの一部です。
取得プロセスは次の場合に役立ちます。
比較的多数の表への変更を取得するとき
スキーマまたはデータベース全体への変更を取得するとき
DDL変更を取得するとき
ダウンストリーム取得を使用してソース・データベース以外のデータベースで変更を取得するとき
同期取得では、内部メカニズムを使用して、DML変更を発生直後に取得します。DML変更に関する情報は、行LCRを含むメッセージの形式で取得します。これらのLCRは永続キューにエンキューされます。同期取得では、メッセージは常に永続キューにエンキューされます。永続キューは、メッセージをメモリーではなくハード・ディスクのキュー表にのみ格納するキューの一部です。同期取得で取得されるメッセージは、永続LCRです。
同期取得は次の場合に役立ちます。
比較的少数の表へのDML変更を取得するとき（最適なパフォーマンスのため）
表へのDML変更を変更直後に取得するとき
明示的取得では、アプリケーションがメッセージを生成してエンキューします。これらのメッセージはLCRとして書式設定することも、他のアプリケーションでコンシュームするために別の型で書式設定することもできます。また、メッセージは、適用プロセスまたは適用プロセスの適用ハンドラによって明示的にエンキューできます。
明示的取得は次の場合に役立ちます。
アプリケーションが生成するメッセージを他のアプリケーションで処理する必要があるとき。
異機種レプリケーション環境で、Oracle Databaseの適用プロセスが、Oracle以外のデータベースで行われた変更を適用するとき。この場合、Oracle以外のデータベースでの変更に基づいてアプリケーションがLCRを取得し、それらのLCRはOracle Databaseで適用プロセスによって処理されます。
Oracle Streamsで取得される情報のタイプは、次のとおりです。
LCRとは、データベースの変更を記述する、特定のフォーマットのメッセージです。行LCRとDDL LCRという2種類のLCRがあります。取得プロセス、同期取得またはアプリケーションがLCRを取得できます。
Oracle Streamsでは次のタイプのLCRを取得できます。
取得LCRは、取得プロセスによって暗黙的に取得され、ANYDATAキューのバッファ・キュー部分にエンキューされるLCRです。
永続LCRは、ANYDATAキューの永続キュー部分にエンキューされるLCRです。永続LCRは次のいずれかの方法でエンキューできます。
同期取得による暗黙的な取得およびエンキュー
アプリケーションによる明示的な作成およびエンキュー
適用プロセスによるデキュー、および同じ適用プロセスによるDBMS_APPLY_ADMパッケージ内のSET_ENQUEUE_DESTINATIONプロシージャを使用したエンキュー
いずれの方法でエンキューしても、永続LCRに差異はありません。つまり、同期取得で取得された永続LCRは、アプリケーションで作成されエンキューされた永続LCRと同じです。また、どちらの永続LCRも、適用プロセスでエンキューされた永続LCRと同じです。
バッファLCRは、アプリケーションによって明示的に作成され、ANYDATAキューのバッファ・キュー部分にエンキューされるLCRです。
次の各項では、LCRの情報について説明します。
|
関連項目:
|
行LCRでは、1行のデータに対する変更、あるいは1行の1つのLONG列、LONG RAW列、LOB列、またはCLOB列として格納されたXMLTypeに対する変更が記述されます。この変更は、データ操作言語（DML）文またはLOBのピース単位の更新によるものです。たとえば、1つのDML文で、複数の行を表に挿入またはマージしたり、表の複数の行を更新したり、表から複数の行を削除する場合があります。アプリケーションでLCRを構築して、さらに処理を行うためにエンキューすることもできます。
単一のDML文で複数の行LCRが生成される可能性があります。つまり、取得プロセスではDML文によって変更される行ごとにLCRが作成されます。また、1行のLONG列、LONG RAW列、LOB列、またはCLOB列として格納されたXMLTypeに対する更新によって複数の行LCRが生成されることがあります。
それぞれの行LCRは、LCR$_ROW_RECORDタイプのオブジェクトにカプセル化されます。行LCRには次の属性が含まれます。
source_database_name: 行の変更が発生したソース・データベースの名前。
command_type: 変更を生成したDML文のタイプ（INSERT、UPDATE、DELETE、LOB ERASE、LOB WRITEまたはLOB TRIM）。
object_owner: 行に変更があった表を含むスキーマの名前。
object_name: 変更があった行を含む表の名前。
tag: LCRの追跡に使用できるRAWタグ。
transaction_id: DML文が実行されたトランザクションの識別子。
scn: 変更が行われた時点のシステム変更番号（SCN）。
old_values: 変更に関連する古い列の値。DML変更が行われる前の行の列値です。DML文のタイプがUPDATEまたはDELETEの場合、古い値には、DML文以前の変更対象行の一部またはすべての列が含まれます。DML文のタイプがINSERTの場合、古い値はありません。UPDATE文とDELETE文では、取得プロセスで作成される行LCRには、行の古い列値の一部またはすべてが含まれることがありますが、同期取得で作成される行LCRには、常に行の新しい列値すべてが含まれます。
new_values: 変更に関連する新しい列の値。DML変更が行われた後の行の列値です。DML文のタイプがUPDATEまたはINSERTの場合、新しい値には、DML文の後の変更対象行の一部またはすべての列が含まれます。DML文のタイプがDELETEの場合、新しい値はありません。UPDATE文とINSERT文では、取得プロセスで作成される行LCRには、行の新しい列値の一部またはすべてが含まれることがありますが、同期取得で作成される行LCRには、常に行の新しい列値すべてが含まれます。
取得プロセスまたは同期取得で取得された行LCRには、トランザクション制御文が含まれていることもあります。これらの行LCRには、COMMITやROLLBACKなどのディレクティブが含まれています。このような行LCRは、ソース・データベースと宛先データベースの間でトランザクションの一貫性を保つために適用プロセスによって内部的に使用されます。
DDL LCRでは、データ定義言語（DDL）の変更が記述されます。DDL文は、データベースの構造を変更します。たとえば、DDL文でデータベース・オブジェクトを作成、変更または削除できます。
それぞれのDDL LCRには、次の情報が含まれます。
source_database_name: DDLの変更が発生したソース・データベースの名前。
command_type: 変更を生成したDDL文のタイプ（ALTER TABLE、CREATE INDEXなど）。
object_owner: DDL文が実行されたデータベース・オブジェクトを所有しているユーザーのスキーマ名。
object_name: DDL文が実行されたデータベース・オブジェクトの名前。
object_type: DDL文が実行されたデータベース・オブジェクトのタイプ（TABLE、PACKAGEなど）。
ddl_text: DDL文のテキスト。
logon_user: ログオン・ユーザー。DDL文を実行したセッションのユーザーです。
current_schema: DDLテキストでオブジェクトに対するスキーマが指定されていない場合に使用されるスキーマ。
base_table_owner: 実表の所有者。DDL文が表に依存する場合、実表の所有者は依存先となる表の所有者です。
base_table_name: 実表の名前。DDL文が表に依存する場合、実表の名前は依存先となる表の名前です。
tag: LCRの追跡に使用できるRAWタグ。
transaction_id: DDL文が実行されたトランザクションの識別子。
scn: 変更が行われた時点のSCN。
|
関連項目:
|
前の項で説明した情報の他に、次に示すその他の情報（LCR属性）をオプションとして行LCRとDDL LCRに含めることができます。
row_id: 行LCRの変更された行のROWID。この属性は、索引構成表のDDL LCRまたは行LCRには含まれません。
serial#: LCRに取得された変更を実行したセッションのシリアル番号。
session#: LCRに取得された変更を実行したセッションの識別子。
thread#: LCRに取得された変更を実行したインスタンスのスレッド番号。通常、スレッド番号が使用されるのはOracle Real Application Clusters（Oracle RAC）環境のみです。
tx_name: LCRを含むトランザクションの名前。
username: LCRに取得された変更を実行した現行ユーザーの名前。
DBMS_CAPTURE_ADMパッケージのINCLUDE_EXTRA_ATTRIBUTEプロシージャを使用すると、これらの1つ以上の属性を取得するように取得プロセスまたは同期取得に指定できます。
|
関連項目:
|
LCRを含まないメッセージは、ユーザー・メッセージと呼ばれます。ユーザー・メッセージはLCRタイプを除くすべてのタイプになる可能性があり、アプリケーションによって作成およびコンシュームされます。たとえば、ビジネス・アプリケーションが各注文に対してユーザー・メッセージを作成し、そのメッセージを別のアプリケーションが処理することができます。
Oracle Streamsでは次のタイプのユーザー・メッセージを取得できます。
永続ユーザー・メッセージは、永続キューにエンキューされるユーザー定義型のLCR以外のメッセージです。永続ユーザー・メッセージは次のいずれかの方法でエンキューできます。
アプリケーションによる明示的な作成およびエンキュー
適用プロセスによるデキュー、および同じ適用プロセスによるDBMS_APPLY_ADMパッケージ内のSET_ENQUEUE_DESTINATIONプロシージャを使用したエンキュー
永続ユーザー・メッセージはANYDATAキューまたは型付きキューの永続キュー部分にエンキューできます。
バッファ・ユーザー・メッセージは、アプリケーションによって明示的に作成され、バッファ・キューにエンキューされるユーザー定義型のLCR以外のメッセージです。バッファ・ユーザー・メッセージは、ANYDATAキューまたは型付きキューのバッファ・キュー部分にエンキューできます。
|
注意: 取得プロセスと同期取得がユーザー・メッセージを取得することはありません。 |
表2-1に、Oracle Streamsで使用可能な取得オプションのまとめを示します。
表2-1 Oracle Streamsでの情報取得オプション
| 取得のタイプ | 取得のメカニズム | メッセージのタイプ | エンキューされるキュー | 使用ケース |
|---|---|---|---|---|
|
|
REDOログのマイニング |
取得LCR |
バッファ・キュー |
多数の表への変更を取得するとき。 スキーマまたはデータベース全体への変更を取得するとき。 DDL変更を取得するとき。 ダウンストリーム・データベースで変更を取得するとき。 |
|
|
内部メカニズム |
永続LCR |
永続キュー |
少数の表へのDML変更を取得するとき。 DML変更を直後に取得するとき。 |
|
|
手動でのメッセージ作成とエンキュー |
バッファLCR 永続LCR バッファ・ユーザー・メッセージ 永続ユーザー・メッセージ |
バッファ・キューまたは永続キュー |
アプリケーションでコンシュームされるユーザー・メッセージを取得するとき。 異機種レプリケーション環境でLCRを取得するとき。 取得プロセスまたは同期取得のかわりにアプリケーションを使用してLCRを作成するとき。 |
|
注意: 1つのデータベースで、この表の取得オプションを任意に組み合せて使用することができます。 |
Oracle Streams環境では、単一データベース内または複数データベース間でデータベース・オブジェクトを共有できます。データベース・オブジェクトを共有し、暗黙的取得を使用してデータベース・オブジェクトへの変更を取得するOracle Streams環境では、ソース・データベースが変更が行われるデータベースです。ソース・データベースは、使用される暗黙的取得のタイプに応じて次のいずれかになります。
取得プロセスが変更を取得する場合、ソース・データベースは、オブジェクトへの変更がREDOログに生成されるデータベースです。
同期取得が変更を取得する場合、ソース・データベースは、同期取得が構成されているデータベースです。
変更が取得された後は、ローカルに適用されるか、他のデータベースに伝播されて宛先データベースで適用できます。
データベース・オブジェクトを共有するOracle Streams環境では、共有ソース・データベース・オブジェクトをインスタンス化する必要があります。その後、データベース・オブジェクトへの変更を適用プロセスでデキューして処理できるようになります。ソース・データベース・オブジェクトへの変更が適用されるデータベースが、ソース・データベースと異なる場合は、宛先データベースにこれらのデータベース・オブジェクトのコピーが必要です。
Oracle Streamsではデータベース・オブジェクトをインスタンス化するために、一般的には次の手順を実行します。
ソース・データベースでオブジェクトのインスタンス化を準備します。
オブジェクトのコピーが宛先データベースに存在しない場合は、ソース・データベースのオブジェクトに基づいて、宛先データベースでオブジェクトを物理的に作成します。エクスポートとインポート、トランスポータブル表領域またはRecovery Managerを使用してインスタンス化のためにデータベース・オブジェクトをコピーします。データベース・オブジェクトが宛先データベースにすでに存在している場合、この手順は必要ありません。
宛先データベースでデータベース・オブジェクトのインスタンス化SCNを設定します。インスタンス化システム変更番号（SCN）によって、指定SCNの後にソース・データベースでコミットされた変更のみを適用するように、宛先データベースの適用プロセスに指示されます。
場合によっては、手順1と手順3は自動的に行われます。たとえば、DBMS_STREAMS_ADMパッケージのプロシージャを実行してオブジェクトのルールを取得プロセスのポジティブ・ルール・セットに追加すると、オブジェクトのインスタンス化が自動的に準備されます。また、エクスポート/インポートまたはトランスポータブル表領域を使用して、ソース・データベースのデータベース・オブジェクトを宛先データベースにコピーすると、これらのオブジェクトのインスタンス化SCNを自動的に設定できます。インスタンス化は、適用プロセスが取得LCRをデキューするときには常に必要です。適用プロセスがLCRを適用ハンドラに送信し、適用ハンドラがLCRを実行しない場合にも必要です。
|
関連項目:
|
この項では、Oracle Streamsの取得プロセスに関連する概念について説明します。
この項の内容は次のとおりです。
各Oracleデータベースには、複数のREDOログ・ファイルのセットがあります。データベースのREDOログ・ファイルを総称して、データベースのREDOログと呼びます。REDOログの主要な機能は、データベースに対して行われた変更をすべて記録することです。
REDOログは、人為的エラーやメディア障害が発生した場合のリカバリ能力を保証するために使用されます。取得プロセスはオプションのOracleバックグラウンド・プロセスであり、データベースのREDOログをスキャンし、データベース・オブジェクトに対するデータ操作言語（DML）変更とデータ定義言語（DDL）変更を取得します。取得プロセスがREDOログから変更を取得するように構成されている場合、変更が生成されるデータベースは、その取得プロセスのソース・データベースと呼ばれます。
取得プロセスはデータベースの変更を取得すると、論理変更レコード（LCR）と呼ばれる特殊なメッセージ・フォーマットに変換します。LCRを取得した後、取得プロセスはLCRを含むメッセージをキューにエンキューします。取得プロセスは常に1つのANYDATAキューと関連付けられており、このキューのみにメッセージをエンキューします。パフォーマンスの向上のため、取得LCRは常にバッファ・キューに格納されます。このキューは、キューに関連付けられているシステム・グローバル領域（SGA）メモリーです。複数のキューを作成して各キューに別の取得プロセスを関連付けることができます。
取得LCRは、伝播によって同じデータベースまたは他のデータベースのキューに送信できます。また、取得LCRは、適用プロセスによってデキューできます。状況によっては、最適化を行って、取得プロセスでLCRをより効率的に適用プロセスに送信することもできます。このような最適化は、取得と適用の複合と呼ばれます。
取得プロセスは、ソース・データベースまたはリモート・データベース上で実行されます。取得プロセスをソース・データベース上で実行する場合、取得プロセスはローカル取得プロセスです。取得プロセスがリモート・データベース上で実行される場合、取得プロセスはダウンストリーム取得プロセスであり、そのリモート・データベースはダウンストリーム・データベースと呼ばれます。
図2-1に、LCRを取得する取得プロセスを示します。
|
注意:
|
取得プロセスは、定義したルールに基づいて変更を取得または廃棄します。各ルールでTRUEと評価するデータベース・オブジェクトおよび変更のタイプを指定します。これらのルールは、取得プロセスのポジティブ・ルール・セットまたはネガティブ・ルール・セットに含めることができます。
ルールが変更をTRUEと評価し、そのルールが取得プロセスのポジティブ・ルール・セットに含まれる場合、取得プロセスはその変更を取得します。ルールが変更をTRUEと評価し、そのルールが取得プロセスのネガティブ・ルール・セットに含まれる場合、取得プロセスはその変更を廃棄します。取得プロセスにポジティブ・ルール・セットとネガティブ・ルール・セットの両方がある場合、ネガティブ・ルール・セットが常に最初に評価されます。
取得プロセスのルールは次のレベルで指定できます。
表ルールは、特定の表に対するDML変更による行変更またはDDL変更を取得または廃棄します。サブセット・ルールは、特定の表に対する行変更のサブセットを含む表ルールです。
スキーマ・ルールは、特定のスキーマのデータベース・オブジェクトに対するDML変更による行変更またはDDL変更を取得または廃棄します。
グローバル・ルールは、データベース内のDML変更によるすべての行変更またはすべてのDDL変更を取得または廃棄します。
表に対するDML変更による行の変更を取得するとき、取得プロセスは、次のデータ型の列に対して行われる変更を取得できます。
VARCHAR2
NVARCHAR2
FLOAT
NUMBER
LONG
DATE
BINARY_FLOAT
BINARY_DOUBLE
TIMESTAMP
TIMESTAMP WITH TIME ZONE
TIMESTAMP WITH LOCAL TIME ZONE
INTERVAL YEAR TO MONTH
INTERVAL DAY TO SECOND
RAW
LONG RAW
CHAR
NCHAR
UROWID
BASICFILE記憶域を持つCLOB
BASICFILE記憶域を持つNCLOB
BASICFILE記憶域を持つBLOB
|
注意: これらのデータ型の一部は、以前のリリースのOracle DatabaseのOracle Streamsではサポートされていない場合があります。Oracle Streams環境に旧リリースのOracle Databaseが1つ以上あるときは、サポートしていない行LCRデータ型のあるデータベースに、その行LCRが送られないようにしてください。サポートされるデータ型の詳細は、以前のリリースのOracle Streamsドキュメントを参照してください。 |
|
関連項目:
|
特定の表に対して行われたDML変更が取得されるように指定した場合、取得プロセスでは、これらの表に対して行われた次のタイプのDML変更が取得されます。
INSERT
UPDATE
DELETE
MERGE
LOBに対するピース単位の更新
取得プロセスによって、MERGEの変更がそれぞれINSERTまたはUPDATEの変更に変換されます。MERGEは、行LCRでは無効なコマンド・タイプです。
サプリメンタル・ロギングでは、操作が実行されるたびにREDOログに列データが追加されます。取得プロセスは、この追加情報を取得してLCRに含めます。サプリメンタル・ロギングは、ソース・データベースに対する変更を取得する取得プロセスの場所に関係なく、常にソース・データベースで構成されます。
通常、Oracle Streamsレプリケーション環境ではサプリメンタル・ロギングが必要です。これらの環境の適用プロセスでは、ソース・データベースから宛先データベースにレプリケートされるDML変更およびDDL変更を適切に適用するために、LCRの追加情報が必要になります。ただし、適用プロセスによって変更がデータベース・オブジェクトに直接適用されない環境でも、サプリメンタル・ロギングが必要な場合があります。このような環境では、適用ハンドラによって、データベース・オブジェクトに適用されることなく変更が処理され、適用ハンドラで補足情報が必要になる場合があります。
|
関連項目:
|
取得プロセスは、ソース・データベースでローカルに実行されるか、またはダウンストリーム・データベースで実行されるように構成できます。単一のデータベースに、ローカルの変更を取得する1つ以上の取得プロセスおよびリモート・ソース・データベースの変更を取得する他の取得プロセスを含めることができます。つまり、単一のデータベースを構成することによって、ローカル取得およびダウンストリーム取得の両方を実行できます。
ローカル取得とは、取得プロセスがソース・データベースで実行される取得プロセスのことです。図2-1に、ローカル取得を使用するデータベースを示します。
ローカル取得を構成すると、ソース・データベースで次のアクションが実行されます。
DBMS_CAPTURE_ADM.BUILDプロシージャが実行され、データ・ディクショナリがREDOログに抽出（構築）されます。
ソース・データベースでのサプリメンタル・ロギングによって、REDOログに追加情報が記録されます。この情報は、取得された変更が適用プロセスによって適用される際に必要になる場合があります。
データベースで取得プロセスが初めて起動される場合、Oracle Databaseでは、REDOログ内の抽出されたデータ・ディクショナリ情報を使用して、LogMinerデータ・ディクショナリが作成されます。LogMinerデータ・ディクショナリは、ソース・データベースのプライマリ・データ・ディクショナリとは別のデータ・ディクショナリです。後続の取得プロセスでは、この既存のLogMinerデータ・ディクショナリを使用するか、または新しいLogMinerデータ・ディクショナリを作成できます。
取得プロセスで、LogMinerを使用してREDOログの変更がスキャンされます。
取得プロセスで、ルール・セットのルールを満たす変更がローカルのANYDATAキューにエンキューされます。
取得された変更が1つ以上の他のデータベースと共有されている場合、1つ以上の伝播によって、これらの変更がソース・データベースから他のデータベースに伝播されます。
ソース・データベースのデータベース・オブジェクトを宛先データベースでインスタンス化する必要がある場合は、オブジェクトをインスタンス化のために準備し、エクスポート・ユーティリティなどのメカニズムを使用してデータベース・オブジェクトのコピーを作成する必要があります。
ローカル取得を使用するメリットは次のとおりです。
ダウンストリーム取得を使用する場合より、取得プロセスを簡単に構成および管理できます。ローカル取得を使用すると、ダウンストリーム・データベースにコピーされるようにREDOデータを構成する必要がなくなり、取得した変更が行われたデータベースでローカルに取得プロセスを管理できます。
ローカル取得プロセスでは、データベースによってオンラインREDOログの変更がアーカイブREDOログ・ファイルに書き込まれる前に、これらの変更をスキャンできます。アーカイブ・ログ・ダウンストリーム取得プロセスを使用すると、ダウンストリーム・データベースへのアーカイブREDOログ・ファイルのコピーは、ソース・データベースによる変更の書込みが終了した後に行われるため、ダウンストリーム・データベースへのREDOログ・ファイルのコピーには時間がかかります。ただし、リアルタイム・ダウンストリーム取得プロセスは、ソース・データベースから送信されたオンラインREDOログの変更を取得できます。
REDOデータがダウンストリーム・データベースにコピーされるわけではないため、ネットワークを介して送信されるデータの量が低減されます。取得LCRは、他のデータベースに伝播される場合でも、データベースに対する変更全体のサブセットであることがあり、伝播のルール・セットのルールを満たすLCRのみを伝播できます。
REDOデータにアクセスできるのはソース（ローカル）データベースのみのため、セキュリティを向上できます。たとえば、hrスキーマのみの変更を取得する場合にローカル取得を使用すると、REDOログにアクセスし、hrスキーマに対する変更を取得プロセスのキューにエンキューできるのはソース・データベースのみです。一方、ダウンストリーム取得を使用すると、REDOデータがダウンストリーム・データベースにコピーされ、REDOデータに、hrスキーマに対する変更のみではなく、データベースに対するすべての変更が含まれます。
取得プロセスがローカルのソース・データベースで実行されている場合、一部のタイプのカスタム・ルールベースの変換を簡単に構成できます。たとえば、ローカル取得を使用すると、カスタム・ルールベースの変換で、ソース・データベースに格納されたデータが移入されているPL/SQLセッション変数にキャッシュされた情報を使用できます。
メッセージの取得および適用が同じデータベースで行われるOracle Streams環境では、取得された変更およびローカルのデータに関する情報が必要なローカルの問合せおよび計算を簡単に構成でき、使用されるリソースも少なくなります。
ダウンストリーム取得とは、ソース・データベース以外のデータベースで実行される取得プロセスのことです。構成可能なダウンストリーム取得には、リアルタイム・ダウンストリーム取得およびアーカイブ・ログ・ダウンストリーム取得の2つのタイプがあります。downstream_real_time_mine取得プロセス・パラメータによって、ダウンストリーム取得プロセスでリアルタイム・ダウンストリーム取得またはアーカイブ・ログ・ダウンストリーム取得のいずれを実行するかが制御されます。ダウンストリーム・データベースには、1つのリアルタイム・ダウンストリーム取得プロセスと1つ以上のアーカイブ・ログ・ダウンストリーム取得プロセスが共存できます。
|
注意:
|
リアルタイム・ダウンストリーム取得構成は、次のように機能します。
REDO転送サービスが、ソース・データベースでログ・ライター・プロセス（LGWR）を使用して、REDOデータをダウンストリーム・データベースに同期または非同期に送信します。同時に、LGWRは、REDOデータをソース・データベースのオンラインREDOログに記録します。
ダウンストリーム・データベースのリモート・ファイル・サーバー・プロセス（RFS）が、ネットワークを介してREDOデータを受信し、スタンバイREDOログにREDOデータを格納します。
ソース・データベースでログ・スイッチが発生すると、ダウンストリーム・データベースでもログ・スイッチが発生し、ダウンストリーム・データベースのARCHnプロセスによって、現行のスタンバイREDOログ・ファイルがアーカイブされます。
リアルタイム・ダウンストリーム取得プロセスは、可能な場合は常にスタンバイREDOログからの変更を取得し、必要に応じてアーカイブ済スタンバイREDOログ・ファイルからの変更を取得します。取得プロセスは、遅延が発生すると、アーカイブ済スタンバイREDOログ・ファイルの変更を取得できるようになります。遅延が解消されたら、スタンバイREDOログからの変更の取得を再開します。
アーカイブ・ログ・ダウンストリーム取得と比較すると、リアルタイム・ダウンストリーム取得には、ソース・データベースで行われた変更を短時間で取得できるというメリットがあります。リアルタイム・ダウンストリーム取得プロセスでは、REDOログ・ファイルからデータを取得する前に、REDOログ・ファイルがアーカイブされるまで待機する必要がないため、取得時間が短縮されます。
|
注意: 1つのダウンストリーム・データベースで使用可能なリアルタイム・ダウンストリーム取得プロセスは1つのみです。 |
アーカイブ・ログ・ダウンストリーム取得構成では、ソース・データベースのアーカイブREDOログ・ファイルがダウンストリーム・データベースにコピーされ、取得プロセスによってこれらのアーカイブREDOログ・ファイルの変更が取得されます。アーカイブREDOログ・ファイルをダウンストリーム・データベースにコピーするには、REDO転送サービス、DBMS_FILE_TRNSFERパッケージ、ファイル転送プロトコル（FTP）などのメカニズムを使用します。
リアルタイム・ダウンストリーム取得と比較すると、アーカイブ・ログ・ダウンストリーム取得には、1つのダウンストリーム・データベースで複数のダウンストリーム取得プロセスを実行できるというメリットがあります。REDOログ・ファイルを複数のソース・データベースから単一のダウンストリーム・データベースにコピーし、それらのREDOログ・ファイル内の変更を複数のアーカイブ・ログ・ダウンストリーム取得プロセスで取得するように構成できます。
|
関連項目: REDO転送サービスの詳細は、Oracle Data Guard概要および管理を参照 |
リアルタイム・ダウンストリーム取得またはアーカイブ・ログ・ダウンストリーム取得のいずれかを構成すると、ダウンストリーム・データベースで次のアクションが実行されます。
ダウンストリーム・データベースでダウンストリーム取得プロセスが初めて起動される場合、Oracle Databaseでは、ソース・データベースのREDOデータのデータ・ディクショナリ情報を使用して、ダウンストリーム・データベースにLogMinerデータ・ディクショナリが作成されます。ソース・データベースでDBMS_CAPTURE_ADM.BUILDプロシージャが実行され、ソース・データベースのREDOログにソース・データ・ディクショナリ情報が抽出されます。次に、REDOデータがソース・データベースからダウンストリーム・データベースにコピーされます。同じソース・データベースに対する後続のダウンストリーム取得プロセスでは、この既存のLogMinerデータ・ディクショナリを使用するか、または新しいLogMinerデータ・ディクショナリを作成できます。また、リアルタイム・ダウンストリーム取得プロセスでは、1つのLogMinerデータ・ディクショナリを1つ以上のアーカイブ・ログ・ダウンストリーム取得プロセスと共有できます。
取得プロセスで、LogMinerを使用してソース・データベースのREDOデータの変更がスキャンされます。
取得プロセスで、ルール・セットのルールを満たす変更がローカルのANYDATAキューにエンキューされます。この変更は、取得プロセスによってLCRにフォーマットされます。
取得LCRが、1つ以上の他のデータベースと共有されている場合、1つ以上の伝播によって、それらのLCRがダウンストリーム・データベースから他のデータベースに伝播されます。
ダウンストリーム取得を構成すると、ソース・データベースで次のアクションが実行されます。
ソース・データベースでDBMS_CAPTURE_ADM.BUILDプロシージャが実行され、データ・ディクショナリがREDOログに抽出されます。
ソース・データベースでのサプリメンタル・ロギングによって、適用に必要となる可能性がある追加情報がREDOログに記録されます。
ソース・データベースのデータベース・オブジェクトを環境内の他のデータベースでインスタンス化する必要がある場合は、オブジェクトをインスタンス化のために準備し、エクスポート・ユーティリティなどのメカニズムを使用してデータベース・オブジェクトのコピーを作成する必要があります。
また、ソース・データベースを実行しているコンピュータ・システムから、ダウンストリーム・データベースを実行しているコンピュータ・システムにREDOデータをコピーする必要があります。リアルタイム・ダウンストリーム取得構成では、REDO転送サービスがLGWRを使用して、REDOデータをダウンストリーム・データベースに送信します。通常、アーカイブ・ログ・ダウンストリーム取得構成では、REDO転送サービスがアーカイブREDOログ・ファイルをダウンストリーム・データベースにコピーします。
ダウンストリーム取得を使用するメリットは次のとおりです。
必要なほとんどの作業がダウンストリーム・データベースで実行されるため、ソース・データベースで、変更の取得に使用されるリソースが少なくなります。
複数のソース・データベースで行われた変更を取得する場合、複数のソース・データベースに対する複数のアーカイブ・ログ・ダウンストリーム取得プロセスを1つのダウンストリーム・データベースで実行することによって、取得プロセスを簡単に管理できます。つまり、1つのダウンストリーム・データベースが、複数のソースからの変更を取得するための中心の場所として機能します。このような構成では、アーカイブ・ログ・ダウンストリーム取得プロセスに加えて、1つのリアルタイム・ダウンストリーム取得プロセスもダウンストリーム・データベースで実行できます。
REDOデータを1つ以上のダウンストリーム・データベースにコピーすることによって、データ損失に対する保護が強化されます。たとえば、状況によっては、ダウンストリーム・データベースのREDOログ・ファイルをソース・データベースのリカバリに使用できます。
1つ以上のダウンストリーム・データベースに、単一のソース・データベースから変更を取得する複数の取得プロセスを構成できるため、柔軟性およびスケーラビリティが向上します。
ダウンストリーム取得プロセスを作成または変更する場合は、オプションで、ダウンストリーム・データベースからソース・データベースへのデータベース・リンクが使用されるように指定できます。このデータベース・リンクには、ソース・データベースのグローバル名と同じ名前を付ける必要があります。このようなデータベース・リンクを使用すると、ダウンストリーム取得プロセスを簡単に作成および管理できます。ダウンストリーム取得プロセスでデータベース・リンクが使用されるように指定するには、ダウンストリーム取得プロセスでCREATE_CAPTUREまたはALTER_CAPTUREプロシージャを実行する際に、use_database_linkパラメータをTRUEに設定します。
ダウンストリーム取得プロセスでソース・データベースへのデータベース・リンクを使用すると、取得プロセスがソース・データベースに接続され、次の管理アクションが自動的に実行されます。
特定の状況では、ソース・データベースでDBMS_CAPTURE_ADM.BUILDプロシージャが実行され、取得プロセスの作成時にソース・データベースのデータ・ディクショナリがREDOログに抽出されます。
ソース・データベース・オブジェクトがインスタンス化のために準備されます。
取得プロセスの作成時に先頭システム変更番号（SCN）を指定しなかった場合は、ダウンストリーム取得プロセスの先頭SCNが取得されます。取得プロセスを作成するには、先頭SCNが必要です。
ダウンストリーム取得プロセスでデータベース・リンクを使用していない場合は、これらのアクションを手動で実行する必要があります。
|
注意: ダウンストリーム取得プロセスの作成時、CREATE_CAPTUREプロシージャのfirst_scnパラメータがNULLに設定されている場合は、use_database_linkパラメータをTRUEに設定する必要があります。TRUEに設定しないと、エラーが発生します。 |
|
関連項目: ダウンストリーム取得プロセスでデータベース・リンクが使用されている場合、取得プロセスの作成時にDBMS_CAPTURE_ADM.BUILDプロシージャが自動的に実行されるタイミングの詳細は、「リアルタイム・ダウンストリーム取得プロセスの構成」を参照 |
ダウンストリーム取得を使用する場合の操作要件は次のとおりです。
ソース・データベースでOracle Database 10g以上が実行されており、ダウンストリーム取得データベースで、ソース・データベースと同じリリース以上のOracleが実行されている必要があります。
リアルタイム・ダウンストリーム取得を構成するには、ダウンストリーム・データベースでOracle Database 10gリリース2以上が実行されている必要があります。この場合、ソース・データベースでOracle Database 10gリリース1以上が実行されている必要があります。
ソース・サイトおよびダウンストリーム取得サイトのオペレーティング・システムは同じである必要があります。ただし、オペレーティング・システムのリリースが同じである必要はありません。また、ダウンストリーム・サイトでは、ソース・サイトと異なるディレクトリ構造を使用できます。
ソース・サイトおよびダウンストリーム取得サイトのハードウェア・アーキテクチャが同じである必要があります。たとえば、ダウンストリーム取得構成では、ソース・データベースが32ビットのSunシステム上に構成されている場合、ダウンストリーム・データベースが32ビットのSunシステム上に構成されている必要があります。CPUの数、メモリー・サイズ、記憶域構成などのその他のハードウェア要素は、ソース・サイトとダウンストリーム・サイトで同じである必要はありません。
ここでは、取得プロセスで重要となるシステム変更番号（SCN）値を説明します。1つ以上の取得プロセスのシステム変更番号を表示するには、DBA_CAPTUREデータ・ディクショナリ・ビューを問い合せます。
取得済SCNは、取得プロセスによってスキャンされたREDOログの最新の変更に対応するSCNです。取得プロセスの適用済SCNは、関連する適用プロセスにより最後にデキューされたメッセージのSCNです。このSCNより番号が小さいすべてのメッセージは、取得プロセスで取得された変更を適用するすべての適用プロセスによってデキューされています。取得プロセスの適用済SCNは、取得プロセスで取得された変更を適用する適用プロセスの最低水位標SCNと等価です。
次の各項では、取得プロセスの先頭SCNおよび開始SCNについて説明します。
先頭SCNは、取得プロセスで変更を取得できる、REDOログ内の最小SCNです。取得プロセスの作成時に先頭SCNを指定する場合、データベースは、指定したSCN以上のREDOデータにアクセスできる必要があります。
DBMS_CAPTURE_ADM.BUILDプロシージャは、ソース・データベースのデータ・ディクショナリをREDOログに抽出します。取得プロセスを作成する際、REDOログのこのデータ・ディクショナリ・ビルドに対応する先頭SCNを指定できます。特に、作成中の取得プロセスの先頭SCNは、次の問合せで返される任意の値に設定できます。
COLUMN FIRST_CHANGE# HEADING 'First SCN' FORMAT 999999999 COLUMN NAME HEADING 'Log File Name' FORMAT A50 SELECT DISTINCT FIRST_CHANGE#, NAME FROM V$ARCHIVED_LOG WHERE DICTIONARY_BEGIN = 'YES';
NAME列に対して返される値は、先頭SCNに相当するSCNが含まれるREDOログ・ファイルの名前です。このREDOログ・ファイルおよびすべての後続のREDOログ・ファイルは、取得プロセスで使用可能であることが必要です。この問合せでFIRST_CHANGE#に対して複数の異なる値が返される場合、DBMS_CAPTURE_ADM.BUILDプロシージャがソース・データベースに対して2回以上実行されています。この場合、作成する取得プロセスに最も適した先頭SCN値を選択します。
場合によっては、取得プロセスの作成時に、DBMS_CAPTURE_ADM.BUILDプロシージャが自動的に実行されます。このとき、取得プロセスの先頭SCNは、このデータ・ディクショナリ・ビルドに対応します。
開始SCNは、取得プロセスで変更の取得を開始するSCNです。取得プロセスの作成時に先頭SCNとは別に開始SCNを指定するか、または取得プロセスを変更して開始SCNを設定できます。取得プロセスの通常の操作については開始SCNを変更する必要はありません。一般的に、取得プロセスの開始SCNをリセットするのは、取得プロセスから変更を受け取る宛先データベースのいずれかでポイント・イン・タイム・リカバリを実行する必要がある場合です。このような場合は、取得プロセスを使用して、ポイント・イン・タイム・リカバリの後にソース・データベースで行われた変更を取得することができます。
|
注意: 開始SCNを設定する前に、既存の取得プロセスを停止する必要があります。 |
取得プロセスの作成または変更時に開始SCNを指定する場合、指定する開始SCNは、取得プロセスの先頭SCN以上である必要があります。取得プロセスでは、REDOログ・レコードが開始SCNより小さいSCN値を含む場合でも、先頭SCNより大きいSCN値を含む（スキャン済でない）REDOログ・レコードが常にスキャンされます。そのため、先頭SCNより大きい開始SCNを指定すると、取得プロセスは、開始SCNより小さい番号のSCNが含まれるために変更を取得できないREDOログ・レコードをスキャンする場合があります。
開始SCNより前のREDOログ・レコードのスキャンには時間がかかる場合があるため、可能であれば回避する必要があります。そのため、取得プロセスの作成時には、先頭SCNと開始SCNの差をできるかぎり小さくして、取得プロセスの初期起動時間を最小限に抑えることをお薦めします。
|
注意: 取得プロセスを起動または再起動する際、開始SCN未満のFIRST_CHANGE#値が含まれるREDOログ・ファイルをスキャンすることが必要になる場合があります。取得プロセスがスキャンする前に必要なREDOログ・ファイルを削除すると、取得プロセスが強制終了されます。先頭SCN、開始SCNおよび必須チェックポイントSCNを判別するには、DBA_CAPTUREデータ・ディクショナリ・ビューを問い合せます。取得プロセスには、必須チェックポイントSCNが含まれるREDOログ・ファイルおよび後続のすべてのREDOログ・ファイルが必要です。 |
データベース・オブジェクトに対する変更を取得し、適用プロセスを使用してこれらの変更を適用する場合は、データベース・オブジェクトがインスタンス化のために準備された後に発生した変更のみを適用できます。このため、取得プロセスの開始SCNを、データベース・オブジェクトがインスタンス化のために準備された時間に対応するSCNより小さい番号に設定すると、準備SCN以前に行われたこのデータベース・オブジェクトに対する変更は、適用プロセスでは適用できません。
この制限は、取得プロセスの作成時に問題となる場合があります。取得プロセスの作成時より前に、データベース・オブジェクトがインスタンス化のために準備されなかった場合、取得プロセスの作成時より前に行われたオブジェクトに対する変更は、適用プロセスでは適用できません。
新しい取得プロセスの作成前に、データベース・オブジェクトがインスタンス化のために準備されている場合があります。たとえば、1つ以上の既存の取得プロセスで取得されている変更を含むソース・データベースの新しい取得プロセスを作成する場合、一部またはすべてのデータベース・オブジェクトが新しい取得プロセスの作成前にインスタンス化のために準備されていることがあります。新しい取得プロセスで、この新しい取得プロセスの作成時より前に特定のデータベースに対して行われた変更を取得した場合、適用プロセスでこれらの取得された変更を適用するには、次の条件を満たしている必要があります。
新しい取得プロセスの作成時より前に、データベース・オブジェクトがインスタンス化のために準備されている必要があります。
新しい取得プロセスの開始SCNが、データベース・オブジェクトがインスタンス化のために準備された時間より前の時間に対応している必要があります。
指定した開始SCNに対応する時間のREDOログが使用可能である必要があります。また、開始SCNより前に追加のREDOログが必要な場合もあります。
システム起動時にSTARTUP RESTRICT文を発行して制限付きセッションを有効にすると、データベースの停止時に取得プロセスを実行していた場合でも、取得プロセスは起動されません。ALTER SYSTEM文を使用して制限付きセッションを無効にすると、データベースの停止時に実行されたいた各取得プロセスが起動されます。
SQL文ALTER SYSTEMのENABLE RESTRICTED SESSION句によって実行中のデータベースで制限付きセッションを有効にしても、実行中の取得プロセスには影響がありません。これらの取得プロセスは引き続き実行され、変更の取得が行われます。停止している取得プロセスを制限付きセッションで起動しても、この取得プロセスは、制限付きセッションを無効にするまで実際には起動されません。
取得プロセスはオプションのOracleバックグラウンド・プロセスであり、プロセス名はCPnn（nnは文字または数字）です。取得プロセスは、LogMinerのインフラストラクチャを使用してREDOログから変更を取得します。LogMinerは、Oracle Streamsによって自動的に構成されます。基礎となるLogMinerプロセス名はMSnn（nnは文字または数字）です。取得プロセスの作成、変更、起動、停止および削除を行うことができます。また、取得プロセスで取得される変更を制御する取得プロセスのルールを定義できます。
取得プロセスのコンポーネントは次のとおりです。
1つのリーダー・サーバー。REDOログを読み取って複数の領域に分割します。
1つ以上のプリペアラ・サーバー。リーダー・サーバーによって定義された領域をパラレルでスキャンし、REDOログ内で検出された変更の事前フィルタ処理を実行します。事前フィルタ処理では、変更に関する部分的な情報（変更のスキーマ名やオブジェクト名など）が評価のためにルール・エンジンに送信され、評価の結果が受信されます。 parallelism取得プロセス・パラメータを使用してプリペアラ・サーバーの数を制御できます。
1つのビルダー・サーバー。プリペアラ・サーバーからのREDOレコードをマージします。これらのREDOレコードには、部分評価の実行中にTRUEと評価されたものと、部分評価で結果が生成されていないものがあります。ビルダー・サーバーは、これらのREDOレコードのシステム変更番号（SCN）の順序を保持し、マージされたREDOログ・レコードを取得プロセスに渡します。
取得プロセス（CPnn）。マージされたREDOレコードをビルダー・サーバーから受信すると、各変更に対して次のアクションを実行します。
変更をLCR形式でフォーマットします
プリペアラ・サーバーによって実行された部分評価で、LCRの変更に対する結果が生成されていない場合は、LCRを完全評価のためにルール・エンジンに送信します
LCRの完全評価が実行された場合は、その結果を受信します
LCRが取得プロセスのネガティブ・ルール・セットのルールを満たすか、ポジティブ・ルール・セットのルールを満たさない場合は、LCRを廃棄します。
LCRが取得プロセスのポジティブ・ルール・セットのルールを満たす場合は、取得プロセスに関連付けられたキューにLCRをエンキューします。
各リーダー・サーバー、プリペアラ・サーバーおよびビルダー・サーバーはプロセスです。
変更は、取得プロセスの取得ユーザーのセキュリティ・ドメインで取得されます。取得ユーザーは、取得プロセスのルール・セットを満たすすべての変更を取得します。また、取得ユーザーは、これらのルール・セット内のルールで指定されたカスタム・ルールベースの変換をすべて実行します。取得ユーザーは、アクションの実行に必要な権限（取得プロセスで使用されるルール・セットのEXECUTE権限、ポジティブ・ルール・セットのルールに指定されたすべてのカスタム・ルールベースの変換ファンクションのEXECUTE権限、取得プロセス・キューへのメッセージのエンキュー権限など）を持っている必要があります。1つの取得プロセスは1ユーザーにしか関連付けできませんが、1ユーザーは複数の取得プロセスに関連付けることができます。
取得プロセスの状態は、取得プロセスが現在行っている処理を示します。取得プロセスの状態は、V$STREAMS_CAPTURE動的パフォーマンス・ビューのSTATE列を問い合せることによって表示できます。取得プロセスの状態は次のいずれかになります。
INITIALIZING: 起動中。
WAITING FOR DICTIONARY REDO: 先頭SCNに関連するディクショナリ・ビルドを含むREDOログ・ファイルが取得プロセス・セッションに追加されるまで待機しています。このディクショナリ・ビルドを含むすべてのログ・ファイルが追加されるまで、取得プロセスはREDOログ・ファイルのスキャンを開始できません。
DICTIONARY INITIALIZATION: ディクショナリ・ビルドを処理しています。
MINING (PROCESSED SCN = scn_value): SCN（scn_value）でデータ・ディクショナリ・ビルドをマイニングしています。
LOADING (step X of Y): ディクショナリ・ビルドの情報を処理中で、現在、Y個の手順を含むプロセスの手順Xです。XおよびYは数値です。
CAPTURING CHANGES: 取得プロセスのルール・セットを満たす変更についてREDOログをスキャンしています。
WAITING FOR REDO: 新しいREDOログ・ファイルが取得プロセス・セッションに追加されるまで待機しています。取得プロセスは、セッションに追加されたすべてのREDOログ・ファイルの処理を終了しました。ソース・データベースにアクティビティが存在しない場合に、この状態が発生する可能性があります。ダウンストリーム取得プロセスでは、セッションに新しいログ・ファイルが追加されるのを取得プロセスが待機しているときに、この状態が発生する可能性があります。
EVALUATING RULE: 取得プロセスのルール・セットに対して変更を評価しています。
CREATING LCR: 変更を論理変更レコード（LCR）形式に変換しています。
ENQUEUING MESSAGE: 取得プロセスのルール・セットを満たすLCRを取得プロセス・キューにエンキューしています。
PAUSED FOR FLOW CONTROL: メモリー不足、または伝播および適用プロセスでのメッセージのコンシューム速度が取得プロセスでのメッセージの作成速度より遅いことが原因で、LCRをエンキューできません。この状態は、伝播または適用が遅延した場合あるいは処理が行われない場合に、取得LCRのオーバーフローを減らすために、フロー制御が行われていることを示します。
SHUTTING DOWN: 停止しています。
単一データベースで複数の取得プロセスを実行する場合は、各インスタンスのシステム・グローバル領域（SGA）のサイズを増やしてください。SGAサイズを増やすには、SGA_MAX_SIZE初期化パラメータを使用します。また、Oracle Streamsプールのサイズがデータベースで自動管理されていない場合は、取得プロセスの並列性ごとにOracle Streamsプールを 10MB増やす必要があります。たとえば、2つの取得プロセスがデータベースで実行されており、parallelismパラメータが一方の取得プロセスでは4、もう一方の取得プロセスでは1に設定されている場合、Oracle Streamsプールを50MB（並列性は(4+ 1= 5）増やします。
また、取得プロセス、伝播または取得プロセスで使用される各ANYDATAキューには、特定のソース・データベースの最大1つの取得プロセスからの取得LCRを格納することをお薦めします。したがって、特定のソース・データベースで行われた変更を取得する各取得プロセスで個別のキューを使用し、各キューに独自のキュー表があることを確認します。また、同じソース・データベースの2つ以上の取得プロセスからのメッセージが同じキューに伝播されないようにしてください。
|
注意: MEMORY_TARGET、MEMORY_MAX_TARGETまたはSGA_TARGET初期化パラメータが0（ゼロ）以外の値に設定されている場合、Oracle Streamsプールのサイズは自動的に管理されます。 |
チェックポイントは、取得プロセスの現在の状態に関する情報です。この情報は、取得プロセスを実行しているデータベースのデータ・ディクショナリに永続的に格納されます。取得プロセスでは、チェックポイント間隔と呼ばれる定期的な間隔でチェックポイントの記録が試行されます。
取得プロセスでREDOデータが必要となる最小のチェックポイントに対応するシステム変更番号（SCN）は、必須チェックポイントSCNと呼ばれます。必須チェックポイントSCNが含まれているREDOログ・ファイルおよび後続のすべてのREDOログ・ファイルが、取得プロセスで使用可能である必要があります。取得プロセスを停止して再起動すると、REDOログのスキャンは、必須チェックポイントSCNに対応するSCNから開始されます。必須チェックポイントSCNは、データベースが予期せず停止した場合のリカバリで重要となります。また、取得プロセス用に先頭SCNをリセットする場合は、取得プロセスの必須チェックポイントSCN以下の値に設定する必要があります。取得プロセスの必須チェックポイントSCNを確認するには、DBA_CAPTUREデータ・ディクショナリ・ビューのREQUIRED_CHECKPOINT_SCN列を問い合せます。
取得プロセスによって記録された最後のチェックポイントに対応するSCNは、最大チェックポイントSCNと呼ばれます。ソース・データベースから変更を取得する取得プロセスを作成し、同じソース・データベースから変更を取得する別の取得プロセスが存在している場合は、既存の取得プロセスの最大チェックポイントSCNを使用して、新しい取得プロセスで新しいLogMinerデータ・ディクショナリを作成するか、既存のLogMinerデータ・ディクショナリのいずれかを共有するかを決定できます。取得プロセスの最大チェックポイントSCNを確認するには、DBA_CAPTUREデータ・ディクショナリ・ビューのMAX_CHECKPOINT_SCN列を問い合せます。
チェックポイント保存時間とは、チェックポイントが自動的に消去されるまで取得プロセスによって保持される時間（日数）のことです。取得プロセスでは、取得プロセスの必須チェックポイントSCNが含まれているアーカイブREDOログ・ファイルのFIRST_TIMEから、チェックポイントに対応するアーカイブREDOログ・ファイルのNEXT_TIMEを差し引くことによって、チェックポイントの経過時間が定期的に計算されます。計算された値がチェックポイント保存時間より大きい場合、先頭SCN値を進めることによってチェックポイントが自動的に消去されます。計算された値がチェックポイント保存時間より小さい場合、チェックポイントは保持されます。DBA_REGISTERED_ARCHIVED_LOGビューにはアーカイブREDOログ・ファイルのFIRST_TIMEおよびNEXT_TIMEが表示され、DBA_CAPTUREビューのREQUIRED_CHECKPOINT_SCN列には取得プロセスの必須チェックポイントSCNが表示されます。
図2-4に、チェックポイント保存期間が20日に設定されている場合のチェックポイントの消去の例を示します。
図2-4では、チェックポイント保存時間が20日に設定されています。経過時間が21日のSCN 435250のチェックポイントは消去され、経過時間が8日のSCN 479315のチェックポイントは保持されています。
取得プロセスの先頭SCNがリセットされるたびに、取得プロセスによって、新しい先頭SCNより前のアーカイブREDOログ・ファイルに関する情報がLogMinerデータ・ディクショナリから消去されます。この情報が消去された後、アーカイブREDOログ・ファイルはハード・ディスクに残りますが、これらのファイルは取得プロセスでは不要となります。不要となったアーカイブREDOログ・ファイルに対して、DBA_REGISTERED_ARCHIVED_LOGビューのPURGEABLE列にYESが表示されます。これらのファイルをディスクから削除したり、別の場所に移動しても、取得プロセスに影響はありません。
DBMS_CAPTURE_ADMパッケージのCREATE_CAPTUREプロシージャを使用して取得プロセスを作成する場合、checkpoint_retention_timeパラメータを使用して、チェックポイント保存時間（日数）を指定できます。CREATE_CAPTUREプロシージャにcheckpoint_retention_timeパラメータを指定しなかった場合、またはDBMS_STREAMS_ADMパッケージを使用して取得プロセスを作成する場合、デフォルトのチェックポイント保存時間の60日が使用されます。DBA_CAPTUREビューのCHECKPOINT_RETENTION_TIME列に、取得プロセスの現在のチェックポイント保存時間が表示されます。
取得プロセスのチェックポイント保存時間を変更するには、DBMS_CAPTURE_ADMパッケージのALTER_CAPTUREプロシージャで新しい期間を指定します。取得プロセスのチェックポイントが自動的に消去されないようにするには、CREATE_CAPTUREまたはALTER_CAPTUREのcheckpoint_retention_timeパラメータにDBMS_CAPTURE_ADM.INFINITEを指定します。
|
注意: 取得プロセスのチェックポイント保存時間を指定するには、取得プロセスが実行されているデータベースの互換性レベルが10.2.0以上である必要があります。データベースの互換性レベルが10.2.0未満の場合は、データベースで実行されているすべての取得プロセスのチェックポイント保存時間が無期限になります。 |
|
関連項目:
|
既存の取得プロセスに対する先頭SCN値をリセットする場合、またはチェックポイントの消去時に先頭SCNが自動的にリセットされる場合は、新しい先頭SCNの設定前にLogMinerデータ・ディクショナリ情報が自動的に消去されます。取得プロセスの開始SCNが、消去されたREDO情報に対応している場合は、開始SCNが先頭SCNと同じ値に自動的にリセットされます。ただし、開始SCNが新しい先頭SCNの設定より大きい場合、開始SCNは変更されません。
図2-5に、新しい先頭SCNの設定前にLogMinerデータ・ディクショナリ情報が自動的に消去される仕組み、および開始SCNが新しい先頭SCNの設定値より大きい場合に開始SCNが変更されない仕組みを示します。
この例に示されているように、先頭SCNが取得プロセスの開始SCNより大きい値に再度リセットされた場合、開始SCNはLogMinerデータ・ディクショナリ内の既存の情報に対応しなくなります。図2-6に、開始SCNが新しい先頭SCNの設定より小さい場合、開始SCNが自動的にリセットされる仕組みを示します。
この図に示されているように、取得プロセスの先頭SCNおよび開始SCNは、時間の経過に伴い大きくなる場合があります。先頭SCNは、大きくなることによって、DBMS_CAPTURE_ADM.BUILDプロシージャで設定したSCNに対応しなくなる可能性があります。
|
関連項目:
|
次に、異なるタイプの取得プロセスによるREDOデータの読取り方法について説明します。
ローカル取得プロセスでは、可能な場合、REDOログ・バッファを読み取ります。ログ・バッファを読み取ることができない場合は、オンラインREDOログを読み取ります。ログ・バッファまたはオンラインREDOログを読み取ることができない場合は、アーカイブREDOログ・ファイルを読み取ります。このため、ローカル取得プロセスが変更を取得するように構成されている場合は、ソース・データベースをARCHIVELOGモードで実行している必要があります。
リアルタイム・ダウンストリーム取得プロセスでは、可能な場合、ソース・データベースのオンラインREDOデータを読み取ります。これが可能ではない場合は、ソース・データベースからREDOデータが含まれているアーカイブREDOログ・ファイルを読み取ります。この場合、ソース・データベースからのREDOデータはダウンストリーム・データベースのスタンバイREDOログに格納され、スタンバイREDOログのREDOデータはダウンストリーム・データベースのアーカイバによって格納されます。このため、リアルタイム・ダウンストリーム取得プロセスが変更を取得するように構成されている場合は、ソース・データベースとダウンストリーム・データベースの両方をARCHIVELOGモードで実行している必要があります。
アーカイブ・ログ・ダウンストリーム取得プロセスでは、常にソース・データベースからアーカイブREDOログ・ファイルを読み取ります。このため、アーカイブ・ログ・ダウンストリーム取得プロセスが変更を取得するように構成されている場合は、ソース・データベースをARCHIVELOGモードで実行している必要があります。
取得プロセスの必須チェックポイントSCNを判別するには、DBA_CAPTUREデータ・ディクショナリ・ビューのREQUIRED_CHECKPOINT_SCN列を問い合せます。取得プロセスを再起動すると、必須チェックポイントSCN以降のREDOログがスキャンされます。このため、必須チェックポイントSCNが含まれているREDOログ・ファイルおよび後続のすべてのREDOログ・ファイルが取得プロセスに対して使用可能になっている必要があります。
アーカイブREDOログ・ファイルは、アーカイブREDOログ・ファイルを必要とする取得プロセスが存在しなくなるまで使用可能にしておく必要があります。取得プロセスの先頭SCNは、大きい値にリセットすることはできますが、小さい値にリセットすることはできません。このため、取得プロセスでは、先頭SCNより前の情報が含まれているREDOログ・ファイルは必要ありません。いずれの取得プロセスでも必要とされないアーカイブREDOログ・ファイルを判別するには、DBA_LOGMNR_PURGED_LOGデータ・ディクショナリ・ビューを問い合せます。
ローカル取得プロセスで遅延が発生すると、オンラインREDOログの読取りからアーカイブREDOログの読取りへとシームレスに推移し、ローカル取得プロセスで遅延が取り戻されると、アーカイブREDOログの読取りからオンラインREDOログの読取りへとシームレスに推移します。同様に、リアルタイム・ダウンストリーム取得プロセスで遅延が発生すると、スタンバイREDOログの読取りからアーカイブREDOログの読取りへとシームレスに推移し、リアルタイム・ダウンストリーム取得プロセスで遅延が取り戻されると、アーカイブREDOログの読取りからスタンバイREDOログの読取りへとシームレスに推移します。
|
注意: ダウンストリーム取得プロセス構成のダウンストリーム・データベースでは、リモート・ソース・データベースのログ・ファイルを、ローカル・データベースとは別に格納する必要があります。また、ダウンストリーム・データベースに複数のソース・データベースからのログ・ファイルが含まれている場合は、各ソース・データベースからのログ・ファイルを個別に格納する必要があります。 |
|
関連項目:
|
取得プロセスは、DBMS_STREAMS_ADMパッケージまたはDBMS_CAPTURE_ADMパッケージのプロシージャを使用して作成できます。DBMS_STREAMS_ADMパッケージのプロシージャを使用すると、いくつかの構成オプションにデフォルトが自動的に使用されるため、取得プロセスをより簡単に作成できます。また、DBMS_STREAMS_ADMパッケージのプロシージャを使用すると、取得プロセスに対してルール・セットが作成され、このルール・セットに自動的にルールを追加することができます。ルール・セットは、そのプロシージャでinclusion_ruleパラメータがTRUEに設定されている場合（デフォルト）はポジティブ・ルール・セット、inclusion_ruleパラメータがFALSEに設定されている場合はネガティブ・ルール・セットになります。
DBMS_CAPTURE_ADMパッケージのCREATE_CAPTUREプロシージャを使用すると、より柔軟に取得プロセスを作成できます。取得プロセスの作成前または作成後に1つ以上のルール・セットおよびルールを作成します。e DBMS_STREAMS_ADMパッケージまたはDBMS_RULE_ADMパッケージのプロシージャを使用すると、取得プロセスのルール・セットにルールを追加できます。ダウンストリーム・データベースで取得プロセスを作成するには、 DBMS_CAPTURE_ADMパッケージを使用する必要があります。
DBMS_STREAMS_ADMパッケージのプロシージャを使用して取得プロセスを作成し、この取得プロセスのポジティブ・ルール・セットに1つ以上のルールを生成すると、変更を取得されるオブジェクトがインスタンス化のために自動的に準備されます。ただし、この取得プロセスがダウンストリーム取得プロセスで、ダウンストリーム・データベースからソース・データベースへのデータベース・リンクが存在しない場合は除きます。
DBMS_CAPTURE_ADMパッケージのCREATE_CAPTUREプロシージャを使用して取得プロセスを作成する場合は、変更を取得するすべてのオブジェクトのインスタンス化を準備する必要があります。取得プロセスの作成後、できるだけ早く、これらのオブジェクトのインスタンス化を準備してください。オブジェクトのインスタンス化を準備するには、DBMS_CAPTURE_ADMパッケージの次のいずれかのプロシージャを使用します。
PREPARE_TABLE_INSTANTIATION: 単一表をインスタンス化のために準備します。
PREPARE_SCHEMA_INSTANTIATION: スキーマ内のすべてのオブジェクトおよび将来そのスキーマに追加されるすべてのオブジェクトをインスタンス化のために準備します。
PREPARE_GLOBAL_INSTANTIATION: データベース内のすべてのオブジェクトおよび将来そのデータベースに追加されるすべてのオブジェクトをインスタンス化のために準備します。
これらのプロシージャを使用して、インスタンス化のために準備された表のキー列またはすべてのキー列のサプリメンタル・ロギングを有効にすることもできます。
|
関連項目:
|
取得プロセスには、ソース・データベースのプライマリ・データ・ディクショナリとは別個のデータ・ディクショナリが必要です。この別個のデータ・ディクショナリは、LogMinerデータ・ディクショナリと呼ばれます。特定のソース・データベースに対して、複数のLogMinerデータ・ディクショナリが存在する場合があります。ソース・データベースから変更を取得する複数の取得プロセスが存在する場合は、複数の取得プロセスで1つのLogMinerデータ・ディクショナリを共有するか、または取得プロセスごとに独自のLogMinerデータ・ディクショナリを所有できます。取得プロセスに必要なLogMinerデータ・ディクショナリが存在しない場合は、取得プロセスの最初の起動時にREDOログの情報を使用してLogMinerデータ・ディクショナリが移入されます。
データ・ディクショナリ情報は、DBMS_CAPTURE_ADM.BUILDプロシージャによってREDOログに抽出されます。このプロシージャは、ソース・データベースで発生した変更を取得するように構成された任意の取得プロセスが起動される前に、ソース・データベース上で1回以上実行する必要があります。REDOログに抽出されたデータ・ディクショナリ情報には、DBMS_CAPTURE_ADM.BUILDプロシージャの実行時のプライマリ・データ・ディクショナリとの一貫性があります。また、このプロシージャでは、取得プロセスの作成に使用できる有効な先頭SCN値の識別も行われます。
REDOログでのデータ・ディクショナリ情報のビルドは複数回実行できますが、特定のビルドが取得プロセスによるLogMinerデータ・ディクショナリの作成に使用されない場合もあります。BUILDプロシージャの実行時にREDOログに抽出される情報の量は、データベース内のオブジェクトの数によって異なります。通常、BUILDプロシージャでは大量のREDOデータが生成されます。これらのデータは後で取得プロセスでスキャンする必要があります。このため、BUILDプロシージャは、必要な場合にのみ実行する必要があります。
ほとんどの場合、DBMS_STREAMS_ADMまたはDBMS_CAPTURE_ADMパッケージのプロシージャを使用して取得プロセスを作成する際にビルドが必要な場合は、このプロシージャによって自動的にBUILDプロシージャが実行されます。ただし、次の場合は、取得プロセスの作成時にBUILDプロシージャは自動的には実行されません。
CREATE_CAPTUREを使用し、first_scnパラメータにNULL以外の値を指定した場合。この場合、指定した先頭SCNが以前のビルドに対応している必要があります。
データベース・リンクを使用しないダウンストリーム取得プロセスを作成した場合。この場合、ダウンストリーム・データベースのコマンドで、ソース・データベースと通信してBUILDプロシージャを自動的に実行することはできません。このため、ソース・データベースでBUILDプロシージャを手動で実行し、取得プロセス作成時のビルドに対応する先頭SCNを指定する必要があります。
プライマリ・データ・ディクショナリの情報はREDOログから取得される変更に適用できない場合があるため、取得プロセスにはLogMinerデータ・ディクショナリが必要です。このような変更は、取得プロセスによって取得される数分前、数時間前または数日前に発生した可能性があります。たとえば、次の使用例について考えてみます。
取得プロセスは、表に対する変更を取得するように構成されています。
データベース管理者が取得プロセスを停止します。取得プロセスを停止すると、その時点で取得中だった変更のSCNが取得プロセスによって記録されます。
ユーザー・アプリケーションは、取得プロセスの停止中も引き続き表に対する変更を行います。
停止してから3時間後に取得プロセスが再起動されます。
この場合、取得プロセスでは、データ整合性を確保するために、停止された時点からREDOログの変更の取得を開始する必要があります。取得プロセスでは、停止時に記録したSCNから変更の取得が開始されます。
REDOログにはRAWデータが含まれています。REDOログには、データベース・オブジェクト名および表の列名は含まれていません。かわりに、REDOログでは、データベース・オブジェクトおよび列にそれぞれオブジェクト番号および内部列番号が使用されます。したがって、取得プロセスでは、変更を取得する場合、データ・ディクショナリを参照して変更の詳細を確認する必要があります。
取得プロセスの最初の起動時にLogMinerデータ・ディクショナリが移入される場合があるため、変更の取得の開始に時間がかかることがあります。所要時間は、データベース内のデータベース・オブジェクトの数によって異なります。取得プロセスによるデータ・ディクショナリ・ビルドの処理の進捗を監視するには、V$STREAMS_CAPTURE動的パフォーマンス・ビューのSTATE列を問い合せます。
|
関連項目:
|
取得プロセスが、表t1に対する変更を取得するように構成されている場合について考えてみます。この表には列aおよびbがあり、この表に対して3つの異なる時点で次の変更が行われるとします。
時刻1: 値a=7およびb=15の挿入
時刻2: 列cの追加
時刻3: 列bの削除
なんらかの理由で取得プロセスがこれ以前の時点から変更を取得している場合は、プライマリ・データ・ディクショナリとLogMinerデータ・ディクショナリ内の関連バージョンに異なる情報が含まれていることになります。表2-2に、現在の時刻が変更取得時刻とは異なる場合の、LogMinerデータ・ディクショナリ内の情報の使用方法を示します。
表2-2 プライマリ・データ・ディクショナリ内とLogMinerデータ・ディクショナリ内の表t1に関する情報
| 現在の時刻 | 変更取得時刻 | プライマリ・データ・ディクショナリ | LogMinerデータ・ディクショナリ |
|---|---|---|---|
|
1 |
1 |
表 |
表 |
|
2 |
1 |
表 |
表 |
|
3 |
1 |
表 |
表 |
取得プロセスで、実際の時刻が3のときに、時間1に行われた挿入による変更を取得するとします。取得プロセスでプライマリ・データ・ディクショナリが使用されていた場合、列aに値7、列cに値15が挿入されたとみなされる可能性があります。これらの列がプライマリ・データ・ディクショナリ内の時刻 3における表t1の列であるためです。ただし、実際には、値15は、列cではなく列bに挿入されています。
取得プロセスではLogMinerデータ・ディクショナリが使用されるため、このエラーは回避されます。LogMinerデータ・ディクショナリは取得プロセスと同期化され、時刻1の時点で表t1に列aおよびbが存在することを引き続き記録します。このため、取得された変更は、列bに値15が挿入されたことを示します。
1つ以上の取得プロセスでソース・データベースに対する変更を取得しているときに、同じソース・データベースに対する変更を取得する新しい取得プロセスを作成する場合、新しい取得プロセスでは、新しいLogMinerデータ・ディクショナリを作成するか、または他の1つ以上の取得プロセスと既存のLogMinerデータ・ディクショナリの1つを共有することができます。
新しい取得プロセスに対して新しいLogMinerデータ・ディクショナリが作成されるかどうかは、CREATE_CAPTUREを実行して取得プロセスを作成したときのfirst_scnパラメータの設定によって異なります。
複数のLogMinerデータ・ディクショナリが存在し、かつ取得プロセスの作成時にfirst_scnパラメータにNULLを指定した場合、新しい取得プロセスでは、1つ以上のチェックポイントを取得済の既存のいずれかの取得プロセスのLogMinerデータ・ディクショナリの共有が自動的に試行されます。DBA_CAPTUREデータ・ディクショナリ・ビューのMAX_CHECKPOINT_SCN列を問い合せると、すべての既存の取得プロセスに対する最大チェックポイントSCNを表示できます。取得プロセスの作成時に、first_scnパラメータがNULL、start_scnパラメータがNULL以外で、start_scnパラメータ設定がすべての既存の取得プロセスに対するすべての先頭SCN値より小さい場合、エラーが発生します。
複数のLogMinerデータ・ディクショナリが存在し、かつ取得プロセスの作成時にfirst_scnパラメータでNULL以外の値を指定した場合、新しい取得プロセスの最初の起動時に新しいLogMinerデータ・ディクショナリが作成されます。この場合、新しい取得プロセスを作成する前に、データベースでDBMS_CAPTURE_ADMパッケージのBUILDプロシージャを実行する必要があります。BUILDプロシージャによって、対応する有効な先頭SCN値が生成されます。この値は、新しい取得プロセスの作成時に指定できます。
BUILDプロシージャによって生成される先頭SCNを検索するには、次の問合せを実行します。
COLUMN FIRST_CHANGE# HEADING 'First SCN' FORMAT 999999999 COLUMN NAME HEADING 'Log File Name' FORMAT A50 SELECT DISTINCT FIRST_CHANGE#, NAME FROM V$ARCHIVED_LOG WHERE DICTIONARY_BEGIN = 'YES';
BUILDプロシージャを複数回実行すると、この問合せによって複数の行が返される場合があります。
新しい取得プロセスで既存のLogMinerデータ・ディクショナリを共有するか、または新しいLogMinerデータ・ディクショナリを作成するかを決定する際に考慮する最も重要な要素は、既存の取得プロセスの最大チェックポイントSCN値と新しい取得プロセスの開始SCN値の差です。新しい取得プロセスでは、LogMinerデータ・ディクショナリを共有する場合、先頭SCNより前の変更を取得できないにもかかわらず、共有するLogMinerデータ・ディクショナリの最大チェックポイントSCN以降のREDOログをスキャンする必要があります。新しい取得プロセスの開始SCNが既存の取得プロセスの最大チェックポイントSCNより大幅に大きい場合は、開始SCNに達する前に大量のREDOデータをスキャンする必要があります。
取得プロセスの作成時にfirst_scnパラメータにNULL以外の値を指定した場合、取得プロセスでは、新しいLogMinerデータ・ディクショナリが作成されます。新しい取得プロセスで既存のLogMinerデータ・ディクショナリを共有するか、新規作成するかを決定する場合は、次のガイドラインに従ってください。
1つ以上の最大チェックポイントSCN値が、指定する開始SCN値より大きい場合、およびこの開始SCNが1つ以上の既存の取得プロセスの先頭SCNより大きい場合は、既存の取得プロセスのLogMinerデータ・ディクショナリを共有することをお薦めします。この場合、開始SCNより小さいチェックポイントSCNが存在すること、およびこのチェックポイントSCNと開始SCNの差が小さいことを想定できます。新しい取得プロセスは、このチェックポイントSCN以降のREDOログのスキャンを開始し、開始SCNに迅速に到達します。
開始SCN値より大きい最大チェックポイントSCNがない場合、および最大チェックポイントSCNと開始SCNの差が小さい場合は、既存の取得プロセスのLogMinerデータ・ディクショナリを共有することをお薦めします。新しい取得プロセスは、最大チェックポイントSCN以降のREDOログのスキャンを開始しますが、開始SCNに迅速に到達します。
開始SCN値より大きい最大チェックポイントSCNがない場合、および最大チェックポイントSCNと開始SCNの差が大きい場合は、取得プロセスが開始SCNに到達するまでに長い時間かかる可能性があります。この場合は、新しいLogMinerデータ・ディクショナリを作成することをお薦めします。取得プロセスの最初の起動時には新しいLogMinerデータ・ディクショナリの作成に時間がかかりますが、先頭SCNと開始SCNに同じ値を指定すると、大量のREDOデータをスキャンする必要がなくなります。
図2-7に、これらのガイドラインを示します。
|
注意:
|
|
関連項目:
|
伝播および適用プロセスでは、Oracle Streamsデータ・ディクショナリを使用して、特定のソース・データベースのデータベース・オブジェクトが追跡されます。Oracle Streamsデータ・ディクショナリは、ソース・データベースで1つ以上のデータベース・オブジェクトをインスタンス化のために準備するたびに移入されます。具体的には、データベース・オブジェクトをインスタンス化のために準備すると、そのデータベース・オブジェクトがREDOログに記録されます。取得プロセスでは、REDOログのスキャン時に、この情報を使用して、ソース・データベースのローカルのOracle Streamsデータ・ディクショナリが移入されます。ローカル取得の場合、このOracle Streamsデータ・ディクショナリはソース・データベースに存在します。ダウンストリーム取得の場合、このOracle Streamsデータ・ディクショナリはダウンストリーム・データベースに存在します。
データベース・オブジェクトをインスタンス化のために準備すると、伝播（データベース・オブジェクトに対する変更の伝播）および適用プロセス（データベース・オブジェクトに対する変更の適用）で、データベース・オブジェクトに関する情報が必要であることがOracle Streamsに通知されます。これらの変更を伝播または適用するデータベースでは、変更が発生したソース・データベースのOracle Streamsデータ・ディクショナリが必要となります。
オブジェクトをインスタンス化のために準備した後、取得プロセスによってオブジェクトに対するDDL文が処理される際に、ローカルのOracle Streamsデータ・ディクショナリが更新されます。また、このDDL文に関する情報が含まれている内部メッセージが取得され、取得プロセスのキューに配置されます。その後、伝播によって、これらの内部メッセージをデータベースの宛先キューに伝播できます。
Oracle Streamsデータ・ディクショナリはマルチバージョンです。データベースに複数の伝播および適用プロセスが含まれている場合は、これらすべての伝播および適用プロセスで特定のソース・データベースに対して同じOracle Streamsデータ・ディクショナリが使用されます。データベースには、特定のソース・データベースに対するOracle Streamsデータ・ディクショナリを1つのみ含めることができます。ただし、複数のソース・データベースからの変更を伝播または適用する場合は、複数のOracle Streamsデータ・ディクショナリを含めることができます。
|
関連項目:
|
作成後の取得プロセスは、最初に起動する前に環境に合わせて取得プロセス・パラメータを設定できるように無効になっています。取得プロセス・パラメータによって、取得プロセスの動作が制御されます。たとえば、parallelism取得プロセス・パラメータによって、取得プロセスで使用されるプリペアラ・サーバーの数が制御され、time_limit取得プロセス・パラメータによって、適用プロセスが自動的に停止されるまでの実行時間が指定されます。DBMS_CAPTURE_ADM.SET_PARAMETERプロシージャを使用して取得プロセス・パラメータを設定します。
|
関連項目:
|
取得プロセスは、ポジティブ・ルール・セットおよびネガティブ・ルール・セットに対してREDOログ内で検出した変更を評価します。取得プロセスは、まずネガティブ・ルール・セットに対して変更を評価します。ネガティブ・ルール・セットの1つ以上のルールが変更に対してTRUEと評価されると、この変更は廃棄されます。一方、変更に対してTRUEと評価されるルールがネガティブ・ルール・セットに含まれていない場合、この変更はネガティブ・ルール・セットを満たしています。変更が取得プロセスのネガティブ・ルール・セットを満たす場合、取得プロセスは、ポジティブ・ルール・セットに対して変更を評価します。ポジティブ・ルール・セットの1つ以上のルールが変更に対してTRUEと評価される場合、この変更はポジティブ・ルール・セットを満たしています。一方、変更に対してTRUEと評価されるルールがポジティブ・ルール・セットに含まれていない場合、この変更は廃棄されます。取得プロセスにルール・セットが1つのみ含まれている場合は、この1つのルール・セットに対してのみ変更が評価されます。
実行中の取得プロセスは、次の一連のアクションを実行して変更を取得します。
REDOログ内で変更を検索します。
REDOログ内で変更の事前フィルタ処理を実行します。この手順で、取得プロセスは、基本レベルでルール・セット内のルールを評価し、REDOログ内で検出された変更を2つのカテゴリに分類します。一方のカテゴリはLCRに変換する変更で、もう一方はLCRに変換しない変更です。事前フィルタ処理は、2つのフェーズで実行されます。1つ目のフェーズでは、事前フィルタ処理で評価可能な情報に、スキーマ名、オブジェクト名、コマンド・タイプなどが含まれます。変更をLCRに変換する必要があるかどうかの判断に追加の情報が必要な場合、事前フィルタ処理の2つ目のフェーズで評価可能な情報に、可能な場合にタグの値および列値が含まれます。
事前フィルタ処理は、不完全な情報を使用して実行される安全な最適化です。この手順では、これ以後に処理対象となる関連する変更が次のように識別されます。
変更が取得プロセスのルール・セットを満たす場合、取得プロセスは変更をLCRに変換します。この場合、手順3に進みます。
変更が取得プロセスのルール・セットを満たさない場合、取得プロセスは変更をLCRに変換しません。
MAYBE評価の場合、ルール評価は次のとおり行われます。
取得プロセスのポジティブ・ルール・セットおよびネガティブ・ルール・セットの両方に対して変更がMAYBEと評価された場合、この変更が両方のルール・セットを確実に満たすかどうかを判別するための十分な情報が取得プロセスに含まれていない可能性があります。この場合、追加の評価が必要です。手順3に進みます。
取得プロセスのネガティブ・ルール・セットに対して変更がFALSEと評価され、ポジティブ・ルール・セットに対してMAYBEと評価された場合、この変更が両方のルール・セットを確実に満たすかどうかを判別するための十分な情報が取得プロセスに含まれていない可能性があります。この場合、追加の評価が必要です。手順3に進みます。
取得プロセスのネガティブ・ルール・セットに対して変更がMAYBEと評価され、ポジティブ・ルール・セットに対してTRUEと評価された場合、この変更が両方のルール・セットを確実に満たすかどうかを判別するための十分な情報が取得プロセスに含まれていない可能性があります。この場合、追加の評価が必要です。手順3に進みます。
取得プロセスのネガティブ・ルール・セットに対して変更がTRUEと評価され、ポジティブ・ルール・セットに対してMAYBEと評価された場合、取得プロセスはこの変更を廃棄します。
取得プロセスのネガティブ・ルール・セットに対して変更がMAYBEと評価され、ポジティブ・ルール・セットに対してFALSEと評価された場合、取得プロセスはこの変更を廃棄します。
事前フィルタ処理に基づいて、取得プロセスのルール・セットを満たすか、または満たす可能性がある変更をLCRに変換します。
LCRのフィルタ処理を実行します。この手順で、取得プロセスは各LCR内の情報に関するルールを評価して、LCRを2つのカテゴリに分けます。一方のカテゴリはエンキューする必要があるLCRで、もう一方は廃棄する必要があるLCRです。
取得プロセスのルール・セットを満たさなかったためエンキューしないLCRを廃棄します。
たとえば、取得プロセスのポジティブ・ルール・セットに対して、department_idが50であるhr.employees表に対する変更を取得するというルールが定義されているとします。この取得プロセスに他のルールは定義されておらず、そのparallelismパラメータは1に設定されています。
このルールが定義されている場合に、hr.employees表に対するUPDATE文によって表の50行が変更されるとします。この取得プロセスは、行の変更ごとに次の一連のアクションを実行します。
REDOログ内でUPDATE文によって発生する次の変更を検索します。
hr.employees表に対するUPDATE文によって変更が発生しており、取得する必要があると判断します。変更が異なる表に対するものの場合、取得プロセスはその変更を無視します。
変更を取得してLCRに変換します。
LCRをフィルタ処理し、department_idが50である行が関係しているかどうかを判断します。
LCRに含まれている行のdepartment_idが50の場合は、取得プロセスに関連付けられているキューにLCRをエンキューします。または、LCRに含まれている行のdepartment_idが50でないか、またはdepartment_idが含まれていない場合は、LCRを廃棄します。
図2-8に、取得プロセス・ルールの評価をフロー・チャート形式で示します。
この項では、同期取得に関連する概念について説明します。
この項は次のトピックで構成されています。
同期取得は、表へのデータ操作言語（DML）の変更を取得する、オプションのOracle Streamsクライアントです。同期取得は、内部メカニズムを使用して指定の表へのDML変更を取得します。同期取得は表への変更を取得するように構成されますが、そのような表を含むデータベースがソース・データベースと呼ばれます。
表へのDML変更が行われると、表の1つ以上の行が変更されます。同期取得は、各行の変更を取得し、行論理変更レコード（行LCR）と呼ばれる特殊なメッセージ・フォーマットに変換します。行LCRを取得した後、同期取得は行LCRを含むメッセージをキューにエンキューします。同期取得によって作成される行LCRには、変更によって変更されていない行であっても、常に行のすべての列の値が含まれます。
図2-9に、LCRを取得する同期取得を示します。
|
注意: 同じ表に対して行われた変更が同期取得と取得プロセスによって取得されないようにする必要があります。 |
同期取得は、常に、単一のANYDATAキューに関連付けられており、このキューにのみメッセージをエンキューします。同期取得で使用されるキューは、コミット時間キューである必要があります。コミット時間キューによって、メッセージがトランザクションにグループ化され、トランザクション・グループがコミット・システム変更番号（CSCN）順に配置されます。同期取得では、常に、行LCRを永続キューにエンキューします。永続キューは、メモリーではなくハード・ディスクのキュー表にのみメッセージを格納するキューの一部分です。複数のキューを作成し、各キューに異なる同期取得を関連付けることができます。
同期取得ではコミット時間キューにメッセージをエンキューする必要がありますが、同期取得で取得されたメッセージは、コミット時間キュー以外のキューに伝播することができます。したがって、同期取得で取得されたメッセージを格納する中間キューがコミット時間キューである必要はありません。また、同期取得で取得されたメッセージを適用する適用プロセスでは、コミット時間キュー以外のキューを使用できます。
|
注意:
|
同期取得は、定義したルールに基づいて、変更を取得または廃棄します。各ルールによって、TRUEと評価されるデータベース・オブジェクトおよび変更のタイプを指定します。これらのルールは、ポジティブ・ルール・セットに含めることができます。変更がルールによってTRUEと評価され、そのルールがポジティブ・ルール・セットに含まれている場合、同期取得はこの変更を取得します。同期取得では、ネガティブ・ルール・セットは使用されません。
同期取得ルールは、表レベルで指定できます。表ルールには、特定の表に対するDML変更による行変更を取得または廃棄します。サブセット・ルールは、特定の表に対する行変更のサブセットを含む表ルールです。同期取得では、スキーマまたはグローバル・ルールは使用されません。
すべての同期取得ルールは、DBMS_STREAMS_ADMパッケージの次のいずれかのプロシージャを使用して作成する必要があります。
ADD_TABLE_RULES
ADD_SUBSET_RULES
同期取得では、次のタイプのルールに基づいた変更は取得されません。
DBMS_STREAMS_ADMパッケージのADD_TABLE_RULESまたはADD_SUBSET_RULESプロシージャ以外のプロシージャによって同期取得ルール・セットに追加されたルール
DBMS_RULE_ADMパッケージによって作成されたルール
これらのタイプのルールが同期取得ルール・セットに存在する場合、これらのルールは無視されます。
同期取得では、DBMS_RULE_ADMパッケージのCREATE_RULE_SETプロシージャによって作成されたルール・セットを使用できますが、ADD_TABLE_RULESまたはADD_SUBSET_RULESプロシージャを使用してルール・セットにルールを追加する必要があります。
ADD_TABLE_RULESまたはADD_SUBSET_RULESプロシージャの実行時に、指定した同期取得が存在しない場合は、このプロシージャによって自動的に同期取得が作成されます。また、DBMS_CAPTURE_ADMパッケージのCREATE_SYNC_CAPTUREプロシージャを使用して、同期取得を作成することもできます。
表に対するDML変更による行の変更を取得するとき、同期取得は、次のデータ型の列に対して行われる変更を取得できます。
VARCHAR2
NVARCHAR2
NUMBER
FLOAT
DATE
BINARY_FLOAT
BINARY_DOUBLE
TIMESTAMP
TIMESTAMP WITH TIME ZONE
TIMESTAMP WITH LOCAL TIME ZONE
INTERVAL YEAR TO MONTH
INTERVAL DAY TO SECOND
RAW
CHAR
NCHAR
UROWID
特定の表に対して行われたDML変更を取得するように指定した場合、同期取得では、これらの表に対して行われた次のタイプのDML変更が取得されます。
INSERT
UPDATE
DELETE
MERGE
同期取得では、MERGEの変更がそれぞれINSERTまたはUPDATEの変更に変換されます。MERGEは、行LCRでは無効なコマンド・タイプです。
変更は、同期取得の取得ユーザーのセキュリティ・ドメインで取得されます。取得ユーザーは、同期取得のルール・セットを満たすすべての変更を取得します。また、取得ユーザーは、これらのルール・セット内のルールで指定されたカスタム・ルールベースの変換をすべて実行します。取得ユーザーは、アクションの実行に必要な権限（同期取得で使用されるルール・セットのEXECUTE権限、ルール・セットのルールに指定されたすべてのカスタム・ルールベースの変換ファンクションのEXECUTE権限、同期取得キューへのメッセージのエンキュー権限など）を持っている必要があります。1つの同期取得に関連付けることができるのは1ユーザーのみですが、1ユーザーには複数の同期取得を関連付けることができます。
アプリケーションによるメッセージの手動エンキューは明示的取得と呼ばれます。エンキューの後、Oracle Streamsの伝播によって、これらのメッセージを同じデータベース内または他のデータベースに伝播できます。また、アプリケーション、適用プロセスおよびメッセージ・クライアントによってこれらのメッセージをコンシュームすることもできます。メッセージをエンキューするには、DBMS_STREAMS_MESSAGINGパッケージまたはDBMS_AQADMパッケージを使用します。
次の各項では、メッセージのエンキューの概念について説明します。
|
関連項目:
|
Oracle Streams環境では、アプリケーションによって、様々なタイプのメッセージを様々な目的のために作成してエンキューできます。これらのメッセージは、ユーザー・メッセージと呼ばれるユーザー定義型のメッセージ、またはLCRです。
この項は次のトピックで構成されています。
アプリケーションは、ユーザー定義型のメッセージを作成して、エンキューすることができます。エンキューできるキューは、メッセージと同じタイプのキューまたはANYDATAキューです。通常、このようなユーザー・メッセージはアプリケーションまたは適用プロセスによってコンシュームされます。
バッファ・キューにエンキューされるユーザー・メッセージはバッファ・ユーザー・メッセージと呼ばれます。バッファ・ユーザー・メッセージはアプリケーションでのみデキューできます。アプリケーションではデキュー後にメッセージを処理します。
永続キューにエンキューされるユーザー・メッセージは永続ユーザー・メッセージと呼ばれます。永続ユーザー・メッセージは次の方法でデキューできます。
メッセージ・クライアント: メッセージ・クライアントは、メッセージの処理のためにメッセージ・クライアントを起動したアプリケーションにメッセージを渡します。
アプリケーション: アプリケーションはメッセージをデキューした後で処理します。
適用プロセス: 適用プロセスは、処理のためにメッセージ・ハンドラにメッセージを渡します。適用プロセスがメッセージをデキューするためには、キューがANYDATAキューであることが必要です。
アプリケーションはLCRを作成して、ANYDATAキューにエンキューすることができます。行LCRはDML変更の結果を記述し、DDL LCRはDDL変更について記述します。通常、LCRは適用プロセスによってコンシュームされますが、メッセージ・クライアントやアプリケーションによってコンシュームされることもあります。異機種レプリケーション環境では、LCRの明示的エンキューを使用して、データベースの変更をOracle以外のデータベースからOracle Databaseにレプリケートすることができます。
バッファ・キューに明示的にエンキューされるLCRはバッファLCRと呼ばれます。バッファLCRはアプリケーションでのみデキューできます。アプリケーションではデキュー後にバッファLCRを処理します。
永続キューに明示的にエンキューされるLCRは永続LCRと呼ばれます。永続LCRは次の方法でデキューできます。
メッセージ・クライアント: メッセージ・クライアントは、メッセージの処理のためにメッセージ・クライアントを起動したアプリケーションにメッセージを渡します。
アプリケーション: アプリケーションはメッセージをデキューした後で処理します。
適用プロセス: 適用プロセスは、LCRを直接適用するか、処理のために適用ハンドラに渡すことができます。
