| Oracle® Streams概要および管理 12cリリース1 (12.1) B71329-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プロシージャを使用したエンキュー
これら3つの方法で取得された各永続LCR間の唯一の違いは、同期取得で取得された永続LCRの方が、アプリケーションによって作成された場合や適用プロセスによってエンキューされた場合よりも、属性が多くなるという点です。
バッファLCRは、アプリケーションによって明示的に作成され、ANYDATAキューのバッファ・キュー部分にエンキューされるLCRです。
次の各項では、LCRの情報について説明します。
|
関連項目:
|
行LCRでは、1行のデータに対する変更、あるいは1行の1つのLOB列、LONG列、LONG RAW列、またはCLOB列として格納されたXMLTypeに対する変更が記述されます。この変更は、データ操作言語(DML)文またはピース単位の操作によるものです。たとえば、1つのDML文で、表への複数行の挿入またはマージ、表の複数行の更新、表からの複数行の削除を実行できます。アプリケーションでLCRを構築して、さらに処理を行うためにエンキューすることもできます。
単一のDML文で複数の行LCRが生成される可能性があります。つまり、取得プロセスではDML文によって変更される行ごとに行LCRが作成されます。また、1つのLOB、LONG列、LONG RAW列、またはCLOB列として格納されたXMLTypeに対する更新によって複数の行LCRが生成されることがあります。
それぞれの行LCRは、LCR$_ROW_RECORDタイプのオブジェクトにカプセル化されます。次の表2-1は、行LCRごとに存在する属性の一覧です。
表2-1 すべての行LCRに含まれる属性
| 属性 | 説明 |
|---|---|
|
|
行の変更が発生したソース・データベースの名前。 |
|
|
変更を生成したDML文のタイプ( |
|
|
行に変更があった表を含むスキーマの名前。 |
|
|
変更があった行を含む表の名前。 |
|
|
LCRの追跡に使用できるRAWタグ。 |
|
|
DML文が実行されたトランザクションの識別子。 |
|
|
変更が行われた時点のシステム変更番号(SCN)。 |
|
|
変更に関連する古い列の値。DML変更が行われる前の行の列値です。DML文のタイプが |
|
|
変更に関連する新しい列の値。DML変更が行われた後の行の列値です。DML文のタイプが |
|
|
各LCRの LCRのpositionは、一般的にXStream構成で使用されます。 『Oracle Database XStreamガイド』を参照してください。 |
取得プロセスまたは同期取得プロセスによって取得された行LCRには、追加の属性が含まれます。表2-2には、それらの追加属性が説明されています。またこの表には、取得プロセスで取得された行LCRと同期取得プロセスで取得された行LCRに、それぞれの属性が含まれるかどうかも示しています。これらの属性は、明示的に取得された行LCRには含まれません。
表2-2 取得された行LCRの追加の属性
| 属性 | 説明 | 取得プロセスの行LCRに含まれるか | 同期取得の行LCRに含まれるか |
|---|---|---|---|
|
|
LCRが属するトランザクションのコミット・システム変更番号(SCN)。 |
はい |
いいえ |
|
|
入力位置によって決定された、トランザクションのコミット・システム変更番号(SCN)。XStreamアウトバウンド・サーバーによって生成される。 |
はい |
いいえ |
|
|
LCRが属するトランザクションのコミット時間。 |
はい |
いいえ |
|
|
そのLCRのサポートに必要なデータベースの最小互換レベル。 |
はい |
はい |
|
|
変更が加えられたデータベース・インスタンスのうち、そのLCR内にカプセル化されたインスタンスの数。通常、インスタンス数はOracle Real Application Clusters(Oracle RAC)の構成に関連する。 |
はい |
はい |
|
|
列のLOB情報( |
はい |
いいえ |
|
|
指定された列のLOBオフセット( |
はい |
いいえ |
|
|
LOB列の操作サイズ( |
はい |
いいえ |
|
|
列の |
はい |
いいえ |
|
|
行LCR内にカプセル化された変更に対応するSQL文。 |
はい |
はい |
|
|
入力位置によって決定された、トランザクションのコミット・システム変更番号(SCN)。XStreamアウトバウンド・サーバーによって生成される。 |
はい |
いいえ |
|
|
取得プロセスによって取得されたLCR内の変更がソース・データベースのREDOログ内に生成された時刻か、または永続LCRが作成された時刻。 |
はい |
はい |
|
|
列のXML情報( |
はい |
いいえ |
取得プロセスまたは同期取得で取得された行LCRには、トランザクション制御文が含まれていることもあります。これらの行LCRには、COMMITやROLLBACKなどのトランザクション制御ディレクティブが含まれています。このような行LCRは、ソース・データベースと宛先データベースの間でトランザクションの一貫性を保つために適用プロセスによって内部的に使用されます。
DDL LCRでは、データ定義言語(DDL)の変更が記述されます。DDL文は、データベースの構造を変更します。たとえば、DDL文でデータベース・オブジェクトを作成、変更または削除できます。
それぞれのDDL LCRは、LCR$_DDL_RECORDタイプのオブジェクトにカプセル化されます。次の表2-3は、DDL LCRごとに存在する属性の一覧です。
表2-3 すべてのDDL LCRに含まれる属性
| 属性 | 説明 |
|---|---|
|
|
行の変更が発生したソース・データベースの名前。 |
|
|
変更を生成したDDL文のタイプ( |
|
|
DDL文が実行されたデータベース・オブジェクトを所有しているユーザーのスキーマ名。 |
|
|
DDL文が実行されたデータベース・オブジェクトの名前。 |
|
|
DDL文が実行されたデータベース・オブジェクトのタイプ( |
|
|
DDL文のテキスト。 |
|
|
ログオン・ユーザー。DDL文を実行したセッションのユーザーです。 |
|
|
DDLテキストでオブジェクトに対するスキーマが指定されていない場合に使用されるスキーマ。 |
|
|
実表の所有者。DDL文が表に依存する場合、実表の所有者は依存先となる表の所有者です。 |
|
|
実表の名前。DDL文が表に依存する場合、実表の名前は依存先となる表の名前です。 |
|
|
LCRの追跡に使用できるRAWタグ。 |
|
|
DDL文が実行されたトランザクションの識別子。 |
|
|
変更が行われた時点のシステム変更番号(SCN)。 |
|
|
各LCRの LCRのpositionは、一般的にXStream構成で使用されます。 『Oracle Database XStreamガイド』を参照してください。 |
|
|
DDL文が実行されたエディションの名前。 |
取得プロセスによって取得されたDDL LCRには、追加の属性が含まれます。表2-2には、それらの追加属性が説明されています。同期取得ではDDLの変更を取得することができないため、これらの属性は、明示的に取得されたDDL LCRには含まれません。
表2-4 取得されたDDL LCRの追加の属性
| 属性 | 説明 |
|---|---|
|
|
LCRが属するトランザクションのコミット・システム変更番号(SCN)。 |
|
|
入力位置によって決定された、トランザクションのコミット・システム変更番号(SCN)。XStreamアウトバウンド・サーバーによって生成される。 |
|
|
LCRが属するトランザクションのコミット時間。 |
|
|
そのLCRのサポートに必要なデータベースの最小互換レベル。 |
|
|
変更が加えられたデータベース・インスタンスのうち、そのLCR内にカプセル化されたインスタンスの数。通常、インスタンス数はOracle Real Application Clusters(Oracle RAC)の構成に関連する。 |
|
|
入力位置によって決定された、トランザクションのコミット・システム変更番号(SCN)。XStreamアウトバウンド・サーバーによって生成される。 |
|
|
取得プロセスによって取得されたLCR内の変更がソース・データベースのREDOログ内に生成された時刻か、または永続LCRが作成された時刻。 |
|
関連項目:
|
行LCRとDDL LCRには、先の各項で説明した情報の他にも、表2-5に示す情報(LCR属性)をオプションとして含めることができます。
表2-5 LCRのその他の属性
| 属性 | 説明 |
|---|---|
|
|
行LCRの変更された行のROWID。この属性は、索引構成表のDDL LCRまたは行LCRには含まれません。 |
|
|
LCRに取得された変更を実行したセッションのシリアル番号。 |
|
|
LCRに取得された変更を実行したセッションの識別子。 |
|
|
LCRに取得された変更を実行したインスタンスの番号。通常、スレッド番号が使用されるのはOracle Real Application Clusters(Oracle RAC)環境のみです。 |
|
|
LCRを含むトランザクションの名前。 |
|
|
LCRに取得された変更を実行した現行ユーザーの名前。 |
DBMS_CAPTURE_ADMパッケージのINCLUDE_EXTRA_ATTRIBUTEプロシージャを使用すると、これらの1つ以上の属性を取得するように取得プロセスまたは同期取得に指定できます。
|
関連項目:
|
LCRを含まないメッセージは、ユーザー・メッセージと呼ばれます。ユーザー・メッセージはどのタイプ(LCRタイプを除く)でもかまいません。ユーザー・メッセージは、アプリケーションによって作成され、アプリケーションによってコンシュームされます。たとえば、ビジネス・アプリケーションが各注文に対してユーザー・メッセージを作成し、そのメッセージを別のアプリケーションが処理することができます。
Oracle Streamsでは次のタイプのユーザー・メッセージを取得できます。
永続ユーザー・メッセージは、永続キューにエンキューされるユーザー定義型のLCR以外のメッセージです。永続ユーザー・メッセージは次のいずれかの方法でエンキューできます。
アプリケーションによる明示的な作成およびエンキュー
適用プロセスによるデキュー、および同じ適用プロセスによるDBMS_APPLY_ADMパッケージ内のSET_ENQUEUE_DESTINATIONプロシージャを使用したエンキュー
永続ユーザー・メッセージはANYDATAキューまたは型付きキューの永続キュー部分にエンキューできます。
バッファ・ユーザー・メッセージは、アプリケーションによって明示的に作成され、バッファ・キューにエンキューされるユーザー定義型のLCR以外のメッセージです。バッファ・ユーザー・メッセージは、ANYDATAキューまたは型付きキューのバッファ・キュー部分にエンキューできます。
|
注意: 取得プロセスと同期取得がユーザー・メッセージを取得することはありません。 |
|
関連項目:
|
表2-6に、Oracle Streamsで使用可能な取得オプションのまとめを示します。
表2-6 Oracle Streamsでの情報取得オプション
| 取得のタイプ | 取得のメカニズム | メッセージのタイプ | エンキューされるキュー | 使用ケース |
|---|---|---|---|---|
|
|
REDOログのマイニング |
取得LCR |
バッファ・キュー |
多数の表への変更を取得するとき。 スキーマまたはデータベース全体への変更を取得するとき。 DDL変更を取得するとき。 ダウンストリーム・データベースで変更を取得するとき。 |
|
|
内部メカニズム |
永続LCR |
永続キュー |
少数の表へのDML変更を取得するとき。 DML変更を直後に取得するとき。 |
|
|
手動でのメッセージ作成とエンキュー |
バッファLCR 永続LCR バッファ・ユーザー・メッセージ 永続ユーザー・メッセージ |
バッファ・キューまたは永続キュー |
アプリケーションでコンシュームされるユーザー・メッセージを取得するとき。 異機種レプリケーション環境でLCRを取得するとき。 取得プロセスまたは同期取得のかわりにアプリケーションを使用してLCRを作成するとき。 |
|
注意: 1つのデータベースで、この表の取得オプションを任意に組み合せて使用することができます。 |
Oracle Streams環境では、単一データベース内または複数データベース間でデータベース・オブジェクトを共有できます。データベース・オブジェクトを共有し、暗黙的取得を使用してデータベース・オブジェクトへの変更を取得するOracle Streams環境では、ソース・データベースが変更が行われるデータベースです。ソース・データベースは、使用される暗黙的取得のタイプに応じて次のいずれかになります。
取得プロセスが変更を取得する場合、ソース・データベースは、オブジェクトへの変更がREDOログに生成されるデータベースです。
同期取得が変更を取得する場合、ソース・データベースは、同期取得が構成されているデータベースです。
変更が取得された後は、ローカルに適用されるか、他のデータベースに伝播されて宛先データベースで適用できます。
データベース・オブジェクトを共有するOracle Streams環境では、共有ソース・データベース・オブジェクトをインスタンス化する必要があります。その後、データベース・オブジェクトへの変更を適用プロセスでデキューして処理できるようになります。ソース・データベース・オブジェクトへの変更が適用されるデータベースが、ソース・データベースと異なる場合は、宛先データベースにこれらのデータベース・オブジェクトのコピーが必要です。
Oracle Streamsではデータベース・オブジェクトをインスタンス化するために、一般的には次の手順を実行します。
ソース・データベースでオブジェクトのインスタンス化を準備します。
オブジェクトのコピーが接続先データベースに存在しない場合は、ソース・データベースのオブジェクトに基づいて、接続先データベースでオブジェクトを物理的に作成します。エクスポートとインポート、トランスポータブル表領域またはRMANを使用してインスタンス化のためにデータベース・オブジェクトをコピーします。データベース・オブジェクトが接続先データベースにすでに存在している場合、この手順は必要ありません。
宛先データベースでデータベース・オブジェクトのインスタンス化SCNを設定します。インスタンス化システム変更番号(SCN)によって、指定SCNの後にソース・データベースでコミットされた変更のみを適用するように、宛先データベースの適用プロセスに指示されます。
場合によっては、手順1と手順3は自動的に行われます。たとえば、DBMS_STREAMS_ADMパッケージのプロシージャを実行してオブジェクトのルールを取得プロセスのポジティブ・ルール・セットに追加すると、オブジェクトのインスタンス化が自動的に準備されます。また、エクスポート/インポートまたはトランスポータブル表領域を使用して、ソース・データベースのデータベース・オブジェクトを宛先データベースにコピーすると、これらのオブジェクトのインスタンス化SCNを自動的に設定できます。インスタンス化は、適用プロセスが取得LCRをデキューするときには常に必要です。適用プロセスがLCRを適用ハンドラに送信し、適用ハンドラがLCRを実行しない場合にも必要です。
|
関連項目:
|
この項では、Oracle Streamsの取得プロセスに関連する概念について説明します。
この項の内容は次のとおりです。
各Oracle Databaseには、複数の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またはSECUREFILE記憶域を持つCLOB
BASICFILEまたはSECUREFILE記憶域を持つNCLOB
BASICFILEまたはSECUREFILE記憶域を持つBLOB
CLOBとして格納されているXMLType
|
注意:
|
|
関連項目:
|
特定の表に対して行われたDML変更が取得されるように指定した場合、取得プロセスでは、これらの表に対して行われた次のタイプのDML変更が取得されます。
INSERT
UPDATE
DELETE
MERGE
ピース単位の操作
取得プロセスによって、MERGEの変更がそれぞれINSERTまたはUPDATEの変更に変換されます。MERGEは、行LCRでは無効なコマンド・タイプです。
サプリメンタル・ロギングでは、操作が実行されるたびにREDOログに列データが追加されます。取得プロセスは、この追加情報を取得してLCRに含めます。サプリメンタル・ロギングは、ソース・データベースに対する変更を取得する取得プロセスの場所に関係なく、常にソース・データベースで構成されます。
通常、Oracle Streamsレプリケーション環境ではサプリメンタル・ロギングが必要です。これらの環境の適用プロセスでは、ソース・データベースから宛先データベースにレプリケートされる変更を適切に適用するために、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転送サービスがREDOデータをダウンストリーム・データベースに同期または非同期に送信します。同時に、ログ・ライター・プロセス(LGWR)は、REDOデータをソース・データベースのオンラインREDOログに記録します。
ダウンストリーム・データベースのリモート・ファイル・サーバー・プロセス(RFS)が、ネットワークを介してREDOデータを受信し、スタンバイREDOログにREDOデータを格納します。
ソース・データベースでログ・スイッチが発生すると、ダウンストリーム・データベースでもログ・スイッチが発生し、ダウンストリーム・データベースのARCHnプロセスによって、現行のスタンバイREDOログ・ファイルがアーカイブされます。
リアルタイム・ダウンストリーム取得プロセスは、可能な場合は常にスタンバイREDOログからの変更を取得し、必要に応じてアーカイブ済スタンバイREDOログ・ファイルからの変更を取得します。取得プロセスは、遅延が発生すると、アーカイブ済スタンバイREDOログ・ファイルの変更を取得できるようになります。遅延が解消されたら、スタンバイREDOログからの変更の取得を再開します。
アーカイブ・ログ・ダウンストリーム取得と比較すると、リアルタイム・ダウンストリーム取得には、ソース・データベースで行われた変更を短時間で取得できるというメリットがあります。リアルタイム・ダウンストリーム取得プロセスでは、REDOログ・ファイルからデータを取得する前に、REDOログ・ファイルがアーカイブされるまで待機する必要がないため、取得時間が短縮されます。
|
注意: 同じソース・データベースから変更を取得する複数のリアルタイム・ダウンストリーム取得プロセスを構成できますが、1つのダウンストリーム・データベースで複数のソース・データベースに対してリアルタイム・ダウンストリーム取得を構成することはできません。 |
アーカイブ・ログ・ダウンストリーム取得構成では、ソース・データベースのアーカイブREDOログ・ファイルがダウンストリーム・データベースにコピーされ、取得プロセスによってこれらのアーカイブREDOログ・ファイルの変更が取得されます。アーカイブREDOログ・ファイルをダウンストリーム・データベースにコピーするには、REDO転送サービス、DBMS_FILE_TRANSFERパッケージ、ファイル転送プロトコル(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転送サービスが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 Streamsレプリケーション管理者ガイド』を参照 |
ダウンストリーム取得を使用する場合の操作要件は次のとおりです。
ソース・データベースでOracle Database 10g以上が実行されており、ダウンストリーム取得データベースで、ソース・データベースのリリース以上のOracle Databaseが実行されている必要があります。
リアルタイム・ダウンストリーム取得を構成するには、ダウンストリーム・データベースで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をリセットするのは、取得プロセスから変更を受け取る宛先データベースのいずれかでPoint-in-Timeリカバリを実行する必要がある場合です。このような場合は、取得プロセスを使用して、Point-in-Timeリカバリの後にソース・データベースで行われた変更を取得することができます。
|
注意: 開始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のオーバーフローを減らすために、フロー制御が行われていることを示します。
WAITING FOR A SUBSCRIBER TO BE ADDED: 取得プロセスのキューのサブスクライバが追加されるのを待機中。サブスクライバは、伝播プロセスまたは適用プロセスのいずれかです。
WAITING FOR THE BUFFERED QUEUE TO SHRINK: バッファ・キュー小さくなるのを待機中。バッファ・キューは、メモリー制限や管理者の操作によってサイズが減らされることがあります。
WAITING FOR n SUBSCRIBER(S) INITIALIZING: 起動するために取得プロセスからLCRを受け取る適用プロセスを待機中。nは適用プロセスの数です。
WAITING FOR TRANSACTION: LogMinerでより多くのトランザクションが提供されるのを待機中。
WAITING FOR INACTIVE DEQUEUERS: 取得プロセスのキュー・サブスクライバが開始するのを待機中。キューに対してアクティブなサブスクライバが存在しない場合は、取得プロセスはLCRのエンキューを停止します。
SUSPENDED FOR AUTO SPLIT/MERGE: マージ操作が完了するのを待機中。
SHUTTING DOWN: 停止しています。
ABORTING: 中断しています。
作成後の取得プロセスは、最初に起動する前に環境に合わせて取得プロセス・パラメータを設定できるように無効になっています。取得プロセス・パラメータによって、取得プロセスの動作が制御されます。たとえば、parallelism取得プロセス・パラメータによって、取得プロセスで使用されるプリペアラ・サーバーの数が制御され、time_limit取得プロセス・パラメータによって、適用プロセスが自動的に停止されるまでの実行時間が指定されます。DBMS_CAPTURE_ADM.SET_PARAMETERプロシージャを使用して取得プロセス・パラメータを設定します。
|
関連項目:
|
取得プロセスを実行しているデータベースが停止され、再起動されても、取得プロセスは永続的状態を保ちます。たとえば、データベースの停止時に取得プロセスを有効にすると、その取得プロセスはデータベースの再起動時に自動的に開始されます。同様に、データベースの停止時に取得プロセスを無効にするか、または強制終了させると、その取得プロセスはデータベースが再起動されても開始されず、無効または強制終了の状態のままとなります。
この項では、同期取得に関連する概念について説明します。
この項の内容は次のとおりです。
同期取得は、表へのデータ操作言語(DML)の変更を取得する、オプションのOracle Streamsクライアントです。同期取得は、内部メカニズムを使用して指定の表へのDML変更を取得します。同期取得は表への変更を取得するように構成されますが、そのような表を含むデータベースがソース・データベースと呼ばれます。
表へのDML変更が行われると、表の1つ以上の行が変更されます。同期取得は、各行の変更を取得し、行論理変更レコード(行LCR)と呼ばれる特殊なメッセージ・フォーマットに変換します。行LCRを取得した後、同期取得は行LCRを含むメッセージをキューにエンキューします。同期取得によって作成される行LCRには、変更によって変更されていない行であっても、常に行のすべての列の値が含まれます。
図2-4に、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
|
注意: 同期取得では、Oracle Database 12cで導入された拡張データ型はサポートしていません。 |
特定の表に対して行われたDML変更を取得するように指定した場合、同期取得では、これらの表に対して行われた次のタイプのDML変更が取得されます。
INSERT
UPDATE
DELETE
MERGE
同期取得では、MERGEの変更がそれぞれINSERTまたはUPDATEの変更に変換されます。MERGEは、行LCRでは無効なコマンド・タイプです。
変更は、同期取得の取得ユーザーのセキュリティ・ドメインで取得されます。取得ユーザーは、同期取得のルール・セットを満たすすべての変更を取得します。また、取得ユーザーは、これらのルール・セット内のルールで指定されたカスタム・ルールベースの変換をすべて実行します。取得ユーザーは、アクションの実行に必要な権限(同期取得で使用されるルール・セットのEXECUTE権限、ルール・セットのルールに指定されたすべてのカスタム・ルールベースの変換ファンクションのEXECUTE権限、同期取得キューへのメッセージのエンキュー権限など)を持っている必要があります。1つの同期取得に関連付けることができるのは1ユーザーのみですが、1ユーザーには複数の同期取得を関連付けることができます。
|
関連項目: 必要な権限の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照 |
アプリケーションによるメッセージの手動エンキューは明示的取得と呼ばれます。エンキューの後、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を直接適用するか、処理のために適用ハンドラに渡すことができます。
