2 Oracle Streams情報取得
Oracle Streamsでの情報の取得とは、情報を含むメッセージを作成し、そのメッセージをキューにエンキューすることです。取得される情報は、データベースの変更に関する説明の場合もあれば、その他の情報である場合もあります。
次の各項では、Oracle Streamsによる情報の取得の概念について説明します。
関連項目:
2.1 Oracle Streamsで情報を取得する方法
2.1.1 暗黙的取得
暗黙的取得では、取得プロセスまたは同期取得によってデータ定義言語(DDL)とデータ操作言語(DML)の変更が自動的に取得されます。論理変更レコード(LCR)と呼ばれる特殊なタイプのメッセージに、このようなデータベースの変更が記述されています。取得プロセスと同期取得は両方とも、ユーザー定義のルールを使用してデータベース変更をフィルタ処理できます。したがって、指定したオブジェクトに対する変更のみを取得できます。
次の各項では、取得プロセスと同期取得について説明します。
2.1.1.1 取得プロセス
取得プロセスは、オンラインREDOログのマイニングまたは必要であればアーカイブ・ログ・ファイルのマイニングを行って、REDOログから変更データを取り出します。データを取り出したら、取得プロセスはそのデータをLCR形式にフォーマットし、さらに処理するためにエンキューします。
取得プロセスは、データベース変更に関する情報を、LCRを含むメッセージの形式でエンキューします。取得プロセスが取得してエンキューしたLCRを含むメッセージは、取得LCRと呼ばれます。取得プロセスでは、メッセージは常にバッファ・キューにエンキューされます。バッファ・キューは、メモリーへのメッセージの格納にOracle Streamsプールを使用し、メモリーからオーバーフローしたメッセージの格納にキュー表を使用するキューの一部です。
取得プロセスは次の場合に役立ちます。
-
比較的多数の表への変更を取得するとき
-
スキーマまたはデータベース全体への変更を取得するとき
-
DDL変更を取得するとき
-
ダウンストリーム取得を使用してソース・データベース以外のデータベースで変更を取得するとき
関連項目:
2.1.1.2 同期取得
同期取得では、内部メカニズムを使用して、DML変更を発生直後に取得します。DML変更に関する情報は、行LCRを含むメッセージの形式で取得します。これらのLCRは永続キューにエンキューされます。同期取得では、メッセージは常に永続キューにエンキューされます。永続キューは、メッセージをメモリーではなくハード・ディスクのキュー表にのみ格納するキューの一部です。同期取得で取得されるメッセージは、永続LCRです。
同期取得は次の場合に役立ちます。
-
比較的少数の表へのDML変更を取得するとき(最適なパフォーマンスが得られる)
-
表へのDML変更を変更直後に取得するとき
関連項目:
2.1.2 明示的取得
明示的取得では、アプリケーションがメッセージを生成してエンキューします。これらのメッセージはLCRとして書式設定することも、他のアプリケーションでコンシュームするために別の型で書式設定することもできます。また、メッセージは、適用プロセスまたは適用プロセスの適用ハンドラによって明示的にエンキューできます。
明示的取得は次の場合に役立ちます。
-
アプリケーションが生成するメッセージを他のアプリケーションで処理する必要があるとき。
-
異機種レプリケーション環境で、Oracle Databaseの適用プロセスが、Oracle以外のデータベースで行われた変更を適用するとき。この場合、Oracle以外のデータベースでの変更に基づいてアプリケーションがLCRを取得し、それらのLCRはOracle Databaseで適用プロセスによって処理されます。
関連項目:
-
Oracle Streamsでの異機種間の情報共有の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照
2.2 Oracle Streamsで取得される情報のタイプ
Oracle Streamsで取得される情報のタイプは、次のとおりです。
2.2.1 論理変更レコード(LCR)
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の管理の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照
-
LCRタイプの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照
-
SET_ENQUEUE_DESTINATION
プロシージャの詳細は、「ルールを満たすメッセージの宛先キューの設定」を参照
2.2.1.1 行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位置は、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は、ソース・データベースと宛先データベースの間でトランザクションの一貫性を保つために適用プロセスによって内部的に使用されます。
2.2.1.2 DDL 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位置は、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の両方に、変更が発生したデータベースのソース・データベース名が含まれています。取得LCRが伝播によって伝播されるか、適用プロセスによって適用される場合は、伝播と適用に伴う問題を回避するために、取得プロセスによる変更の取得が開始された後はソース・データベースの名前を変更しないことをお薦めします。
関連項目:
-
SQLコマンド・コード表のDDL文のタイプの完全なリストについては、『Oracle Call Interfaceプログラマーズ・ガイド』を参照
2.2.1.3 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つ以上の属性を取得するように取得プロセスまたは同期取得に指定できます。
関連項目:
-
INCLUDE_EXTRA_ATTRIBUTE
プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照 -
現在のユーザーの詳細は、『Oracle Database PL/SQL言語リファレンス』を参照
2.2.2 ユーザー・メッセージ
LCRを含まないメッセージは、ユーザー・メッセージと呼ばれます。ユーザー・メッセージはどのタイプ(LCRタイプを除く)でもかまいません。ユーザー・メッセージは、アプリケーションによって作成され、アプリケーションによってコンシュームされます。たとえば、ビジネス・アプリケーションが各注文に対してユーザー・メッセージを作成し、そのメッセージを別のアプリケーションが処理することができます。
Oracle Streamsでは次のタイプのユーザー・メッセージを取得できます。
-
永続ユーザー・メッセージは、永続キューにエンキューされるユーザー定義型のLCR以外のメッセージです。永続ユーザー・メッセージは次のいずれかの方法でエンキューできます。
-
アプリケーションによる明示的な作成およびエンキュー
-
適用プロセスによるデキュー、および同じ適用プロセスによる
DBMS_APPLY_ADM
パッケージ内のSET_ENQUEUE_DESTINATION
プロシージャを使用したエンキュー
永続ユーザー・メッセージはANYDATAキューまたは型付きキューの永続キュー部分にエンキューできます。
-
-
バッファ・ユーザー・メッセージは、アプリケーションによって明示的に作成され、バッファ・キューにエンキューされるユーザー定義型のLCR以外のメッセージです。バッファ・ユーザー・メッセージは、
ANYDATA
キューまたは型付きキューのバッファ・キュー部分にエンキューできます。
注意:
取得プロセスと同期取得がユーザー・メッセージを取得することはありません。
関連項目:
-
SET_ENQUEUE_DESTINATION
プロシージャの詳細は、「ルールを満たすメッセージの宛先キューの設定」を参照 -
メッセージでの
ANYDATA
キューの使用については、『Oracle Databaseアドバンスト・キューイング・ユーザーズ・ガイド』を参照
2.3 Oracle Streamsでの情報取得オプションのまとめ
表2-6に、Oracle Streamsで使用可能な取得オプションのまとめを示します。
表2-6 Oracle Streamsでの情報取得オプション
取得のタイプ | 取得のメカニズム | メッセージのタイプ | エンキューされるキュー | 使用ケース |
---|---|---|---|---|
REDOログのマイニング |
取得LCR |
バッファ・キュー |
多数の表への変更を取得するとき。 スキーマまたはデータベース全体への変更を取得するとき。 DDL変更を取得するとき。 ダウンストリーム・データベースで変更を取得するとき。 |
|
内部メカニズム |
永続LCR |
永続キュー |
少数の表へのDML変更を取得するとき。 DML変更を直後に取得するとき。 |
|
手動でのメッセージ作成とエンキュー |
バッファLCR 永続LCR バッファ・ユーザー・メッセージ 永続ユーザー・メッセージ |
バッファ・キューまたは永続キュー |
アプリケーションでコンシュームされるユーザー・メッセージを取得するとき。 異機種レプリケーション環境でLCRを取得するとき。 取得プロセスまたは同期取得のかわりにアプリケーションを使用してLCRを作成するとき。 |
注意:
1つのデータベースで、この表の取得オプションを任意に組み合せて使用することができます。
関連項目:
2.4 Oracle Streams環境でのインスタンス化
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 Streamsレプリケーション管理者ガイド』を参照
2.5 Oracle Streams取得プロセスによる暗黙的取得
この項では、Oracle Streamsの取得プロセスに関連する概念について説明します。
この項の内容は次のとおりです。
2.5.1 取得プロセスの概要
各Oracle Databaseには、2つ以上のREDOログ・ファイルが用意されています。データベースのREDOログ・ファイルを総称して、データベースのREDOログと呼びます。REDOログの主要な機能は、データベースに対して行われた変更をすべて記録することです。
REDOログは、人為的エラーやメディア障害が発生した場合のリカバリ能力を保証するために使用されます。取得プロセスはオプションのOracleバックグラウンド・プロセスであり、データベースのREDOログをスキャンし、データベース・オブジェクトに対するデータ操作言語(DML)変更とデータ定義言語(DDL)変更を取得します。取得プロセスがREDOログから変更を取得するように構成されている場合、変更が生成されるデータベースは、その取得プロセスのソース・データベースと呼ばれます。
取得プロセスはデータベースの変更を取得すると、論理変更レコード(LCR)と呼ばれる特殊なメッセージ・フォーマットに変換します。LCRを取得した後、取得プロセスはLCRを含むメッセージをキューにエンキューします。取得プロセスは常に1つのANYDATA
キューと関連付けられており、このキューのみにメッセージをエンキューします。パフォーマンスの向上のため、取得LCRは常にバッファ・キューに格納されます。このキューは、キューに関連付けられているシステム・グローバル領域(SGA)メモリーです。複数のキューを作成して各キューに別の取得プロセスを関連付けることができます。
取得LCRは、伝播によって同じデータベースまたは他のデータベースのキューに送信できます。また、取得LCRは、適用プロセスによってデキューできます。状況によっては、最適化を行って、取得プロセスでLCRを適用プロセスにより効率的に送信することもできます。このような最適化は、取得と適用の複合と呼ばれます。
取得プロセスは、ソース・データベースまたはリモート・データベース上で実行されます。取得プロセスをソース・データベース上で実行する場合、取得プロセスはローカル取得プロセスです。取得プロセスがリモート・データベース上で実行される場合、取得プロセスはダウンストリーム取得プロセスであり、そのリモート・データベースはダウンストリーム・データベースと呼ばれます。
図2-1に、LCRを取得する取得プロセスを示します。
注意:
-
取得プロセスを関連付けることができるのは
ANYDATA
キューのみです。型付きキューに関連付けることはできません。 -
同じ表に対して行われた変更が取得プロセスと同期取得によって取得されないようにする必要があります。
2.5.2 取得プロセスのルール
取得プロセスは、定義したルールに基づいて変更を取得または廃棄します。各ルールによって、TRUE
と評価されるデータベース・オブジェクトおよび変更のタイプを指定します。これらのルールは、取得プロセスのポジティブ・ルール・セットまたはネガティブ・ルール・セットに含めることができます。
ルールが変更をTRUE
と評価し、そのルールが取得プロセスのポジティブ・ルール・セットに含まれる場合、取得プロセスはその変更を取得します。ルールが変更をTRUE
と評価し、そのルールが取得プロセスのネガティブ・ルール・セットに含まれる場合、取得プロセスはその変更を廃棄します。取得プロセスにポジティブ・ルール・セットとネガティブ・ルール・セットの両方がある場合、ネガティブ・ルール・セットが常に最初に評価されます。
取得プロセスのルールは次のレベルで指定できます。
-
表ルールは、特定の表に対するDML変更による行変更またはDDL変更を取得または廃棄します。サブセット・ルールは、特定の表に対する行変更のサブセットを含む表ルールです。
-
スキーマ・ルールは、特定のスキーマのデータベース・オブジェクトに対するDML変更による行変更またはDDL変更を取得または廃棄します。
-
グローバル・ルールは、データベース内のDML変更によるすべての行変更またはすべてのDDL変更を取得または廃棄します。
2.5.3 取得プロセスによって取得されるデータ型
表に対するDML変更による行の変更を取得するとき、取得プロセスは、次のデータ型の列に対して行われる変更を取得できます。
-
VARCHAR2
-
NVARCHAR2
-
FLOAT
-
NUMBER
-
LONG
-
DATE
-
BINARY_FLOAT
-
BINARY_DOUBLE
-
TIMESTAMP
-
TIME
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
注意:
-
これらのデータ型の一部は、以前のリリースのOracle DatabaseのOracle Streamsではサポートされていない場合があります。Oracle Streams環境に旧リリースのOracle Databaseが1つ以上あるときは、サポートしていない行LCRデータ型のあるデータベースに、その行LCRが送られないようにしてください。サポートされるデータ型の詳細は、以前のリリースのOracle Streamsドキュメントを参照してください。
-
取得プロセスでは、データベース互換性レベルが11.2.0以上に設定されている場合のみ、SecureFiles LOB列への変更を取得できます。
-
取得プロセスでは、Oracle Database 12cで導入された拡張データ型はサポートしていません。
-
CLOB
として格納されたXMLType
は、このリリースでは非推奨です。
関連項目:
-
SecureFiles LOBの制限事項を含む、取得プロセスのデータ型の制限事項の詳細は、「取得プロセスではサポートされていないデータ型」を参照
-
データ型の詳細は、『Oracle Database SQL言語リファレンス』を参照
-
データベースの互換性の詳細は、『Oracle Databaseアップグレード・ガイド』を参照
2.5.4 取得プロセスによって取得されるDML変更のタイプ
特定の表に対して行われたDML変更が取得されるように指定した場合、取得プロセスでは、これらの表に対して行われた次のタイプのDML変更が取得されます。
-
INSERT
-
UPDATE
-
DELETE
-
MERGE
-
ピース単位の操作
取得プロセスによって、MERGE
の変更がそれぞれINSERT
またはUPDATE
の変更に変換されます。MERGE
は、行LCRでは無効なコマンド・タイプです。
関連項目:
-
適用プロセスで適用可能な変更のタイプの詳細は、「Oracle Streams情報コンシューム」を参照
2.5.5 Oracle Streams環境内のサプリメンタル・ロギング
サプリメンタル・ロギングでは、操作が実行されるたびにREDOログに列データが追加されます。取得プロセスは、この追加情報を取得してLCRに含めます。サプリメンタル・ロギングは、ソース・データベースに対する変更を取得する取得プロセスの場所に関係なく、常にソース・データベースで構成されます。
通常、Oracle Streamsレプリケーション環境ではサプリメンタル・ロギングが必要です。これらの環境の適用プロセスでは、ソース・データベースから宛先データベースにレプリケートされる変更を適切に適用するために、LCRの追加情報が必要になります。ただし、適用プロセスによって変更がデータベース・オブジェクトに直接適用されない環境でも、サプリメンタル・ロギングが必要な場合があります。このような環境では、適用ハンドラによって、データベース・オブジェクトに適用されることなく変更が処理され、適用ハンドラで補足情報が必要になる場合があります。
関連項目:
-
サプリメンタル・ロギングの詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照
-
ソース・データベースでのサプリメンタル・ロギングを必要とする適用プロセスの動作の詳細は、「表へのDML変更の適用に関する考慮事項」を参照
-
値の依存性の詳細は、「仮想依存性定義」を参照
-
ビットマップ索引列および適用プロセスの並列性の詳細は、「適用プロセスで依存トランザクションを待機しているか」を参照
2.5.6 ローカル取得およびダウンストリーム取得
取得プロセスは、ソース・データベースでローカルに実行されるか、またはダウンストリーム・データベースで実行されるように構成できます。単一のデータベースに、ローカルの変更を取得する1つ以上の取得プロセスおよびリモート・ソース・データベースの変更を取得する他の取得プロセスを含めることができます。つまり、単一のデータベースを構成することによって、ローカル取得およびダウンストリーム取得の両方を実行できます。
次の各項では、ローカル取得およびダウンストリーム取得の詳細を説明します。
2.5.6.1 ローカル取得
ローカル取得とは、取得プロセスがソース・データベースで実行される取得プロセスのことです。図2-1に、ローカル取得を使用するデータベースを示します。
次の各項では、ローカル取得の詳細を説明します。
2.5.6.1.1 ソース・データベースによるすべての変更取得アクションの実行
ローカル取得を構成すると、ソース・データベースで次のアクションが実行されます。
-
DBMS_CAPTURE_ADM.BUILD
プロシージャが実行され、データ・ディクショナリがREDOログに抽出(構築)されます。 -
ソース・データベースでのサプリメンタル・ロギングによって、REDOログに追加情報が記録されます。この情報は、取得された変更が適用プロセスによって適用される際に必要になる場合があります。
-
データベースで取得プロセスが初めて起動される場合、Oracle Databaseでは、REDOログ内の抽出されたデータ・ディクショナリ情報を使用して、LogMinerデータ・ディクショナリが作成されます。LogMinerデータ・ディクショナリは、ソース・データベースのプライマリ・データ・ディクショナリとは別のデータ・ディクショナリです。後続の取得プロセスでは、この既存のLogMinerデータ・ディクショナリを使用するか、または新しいLogMinerデータ・ディクショナリを作成できます。
-
取得プロセスで、LogMinerを使用してREDOログの変更がスキャンされます。
-
取得プロセスで、ルール・セットのルールを満たす変更がローカルの
ANYDATA
キューにエンキューされます。 -
取得された変更が1つ以上の他のデータベースと共有されている場合、1つ以上の伝播によって、これらの変更がソース・データベースから他のデータベースに伝播されます。
-
ソース・データベースのデータベース・オブジェクトを宛先データベースでインスタンス化する必要がある場合は、オブジェクトをインスタンス化のために準備し、エクスポート・ユーティリティなどのメカニズムを使用してデータベース・オブジェクトのコピーを作成する必要があります。
2.5.6.1.2 ローカル取得のメリット
ローカル取得を使用するメリットは次のとおりです。
-
ダウンストリーム取得を使用する場合より、取得プロセスを簡単に構成および管理できます。ローカル取得を使用すると、ダウンストリーム・データベースにコピーされるようにREDOデータを構成する必要がなくなり、取得した変更が行われたデータベースでローカルに取得プロセスを管理できます。
-
ローカル取得プロセスでは、データベースによってオンラインREDOログの変更がアーカイブREDOログ・ファイルに書き込まれる前に、これらの変更をスキャンできます。アーカイブ・ログ・ダウンストリーム取得プロセスを使用すると、ダウンストリーム・データベースへのアーカイブREDOログ・ファイルのコピーは、ソース・データベースによる変更の書込みが終了した後に行われるため、ダウンストリーム・データベースへのREDOログ・ファイルのコピーには時間がかかります。ただし、リアルタイム・ダウンストリーム取得プロセスは、ソース・データベースから送信されたオンラインREDOログの変更を取得できます。
-
REDOデータがダウンストリーム・データベースにコピーされるわけではないため、ネットワークを介して送信されるデータの量が低減されます。取得LCRは、他のデータベースに伝播される場合でも、データベースに対する変更全体のサブセットであることがあり、伝播のルール・セットのルールを満たすLCRのみを伝播できます。
-
REDOデータにアクセスできるのはソース(ローカル)データベースのみのため、セキュリティを向上できます。たとえば、
hr
スキーマの変更のみを取得プロセスで取得する場合にローカル取得を使用すると、REDOログにアクセスし、hr
スキーマに対する変更を取得プロセスのキューにエンキューできるのはソース・データベースのみです。一方、ダウンストリーム取得を使用すると、REDOデータがダウンストリーム・データベースにコピーされ、REDOデータに、hr
スキーマに対する変更のみではなく、データベースに対するすべての変更が含まれます。 -
取得プロセスがローカルのソース・データベースで実行されている場合、一部のタイプのカスタム・ルールベースの変換を簡単に構成できます。たとえば、ローカル取得を使用すると、カスタム・ルールベースの変換で、ソース・データベースに格納されたデータが移入されているPL/SQLセッション変数にキャッシュされた情報を使用できます。
-
メッセージの取得および適用が同じデータベースで行われるOracle Streams環境では、取得された変更およびローカルのデータに関する情報が必要なローカルの問合せおよび計算を簡単に構成でき、使用されるリソースも少なくなります。
2.5.6.2 ダウンストリーム取得
ダウンストリーム取得とは、ソース・データベース以外のデータベースで実行される取得プロセスのことです。構成可能なダウンストリーム取得には、リアルタイム・ダウンストリーム取得およびアーカイブ・ログ・ダウンストリーム取得の2つのタイプがあります。downstream_real_time_mine
取得プロセス・パラメータによって、ダウンストリーム取得プロセスでリアルタイム・ダウンストリーム取得またはアーカイブ・ログ・ダウンストリーム取得のいずれを実行するかが制御されます。ダウンストリーム・データベースには、1つのリアルタイム・ダウンストリーム取得プロセスと1つ以上のアーカイブ・ログ・ダウンストリーム取得プロセスが共存できます。
注意:
-
このマニュアルでは、「ダウンストリーム取得プロセス」とは、リアルタイム・ダウンストリーム取得プロセスとアーカイブ・ログ・ダウンストリーム取得プロセスの両方のことを示します。必要に応じて、これら2つのタイプのダウンストリーム取得プロセスを区別しています。
-
ダウンストリーム取得プロセスでは、単一のソース・データベースからの変更のみを取得できます。ただし、単一のダウンストリーム・データベースで複数のダウンストリーム取得プロセスを使用すると、単一のソース・データベースまたは複数のソース・データベースから変更を取得することができます。
-
ダウンストリーム取得を構成するには、ソース・データベースがOracle Database 10g リリース1以上のデータベースである必要があります。
2.5.6.2.1 リアルタイム・ダウンストリーム取得
リアルタイム・ダウンストリーム取得構成は、次のように機能します。
-
ソース・データベースのREDO転送サービスがREDOデータをダウンストリーム・データベースに同期または非同期に送信します。同時に、ログ・ライター・プロセス(LGWR)は、REDOデータをソース・データベースのオンラインREDOログに記録します。
-
ダウンストリーム・データベースのリモート・ファイル・サーバー・プロセス(RFS)が、ネットワークを介してREDOデータを受信し、スタンバイREDOログにREDOデータを格納します。
-
ソース・データベースでログ・スイッチが発生すると、ダウンストリーム・データベースでもログ・スイッチが発生し、ダウンストリーム・データベースの
ARCH
n
プロセスによって、現行のスタンバイREDOログ・ファイルがアーカイブされます。 -
リアルタイム・ダウンストリーム取得プロセスは、可能な場合は常にスタンバイREDOログからの変更を取得し、必要に応じてアーカイブ済スタンバイREDOログ・ファイルからの変更を取得します。取得プロセスは、遅延が発生すると、アーカイブ済スタンバイREDOログ・ファイルの変更を取得できるようになります。遅延が解消されたら、スタンバイREDOログからの変更の取得を再開します。
アーカイブ・ログ・ダウンストリーム取得と比較すると、リアルタイム・ダウンストリーム取得には、ソース・データベースで行われた変更を短時間で取得できるというメリットがあります。リアルタイム・ダウンストリーム取得プロセスでは、REDOログ・ファイルからデータを取得する前に、REDOログ・ファイルがアーカイブされるまで待機する必要がないため、取得時間が短縮されます。
注意:
同じソース・データベースから変更を取得する複数のリアルタイム・ダウンストリーム取得プロセスを構成できますが、1つのダウンストリーム・データベースで複数のソース・データベースに対してリアルタイム・ダウンストリーム取得を構成することはできません。
2.5.6.2.2 アーカイブ・ログ・ダウンストリーム取得
アーカイブ・ログ・ダウンストリーム取得構成では、ソース・データベースのアーカイブREDOログ・ファイルがダウンストリーム・データベースにコピーされ、取得プロセスによってこれらのアーカイブREDOログ・ファイルの変更が取得されます。アーカイブREDOログ・ファイルをダウンストリーム・データベースにコピーするには、REDO転送サービス、DBMS_FILE_TRANSFER
パッケージ、ファイル転送プロトコル(FTP)などのメカニズムを使用します。
リアルタイム・ダウンストリーム取得と比較すると、アーカイブ・ログ・ダウンストリーム取得には、1つのダウンストリーム・データベースで複数のソース・データベースからダウンストリーム取得プロセスを実行できるというメリットがあります。REDOログ・ファイルを複数のソース・データベースから単一のダウンストリーム・データベースにコピーし、それらのREDOログ・ファイル内の変更を複数のアーカイブ・ログ・ダウンストリーム取得プロセスで取得するように構成できます。
関連項目:
REDO転送サービスの詳細は、『Oracle Data Guard概要および管理』を参照
2.5.6.2.3 ダウンストリーム・データベースによるほとんどの変更取得アクションの実行
リアルタイム・ダウンストリーム取得またはアーカイブ・ログ・ダウンストリーム取得のいずれかを構成すると、ダウンストリーム・データベースで次のアクションが実行されます。
-
ダウンストリーム・データベースでダウンストリーム取得プロセスが初めて起動される場合、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ログ・ファイルをダウンストリーム・データベースにコピーします。
関連項目:
Oracle Streamsクライアントのルール・セット、およびメッセージがルール・セットを満たす仕組みの詳細は、「Oracle Streamsでのルールの使用方法」を参照
2.5.6.2.4 ダウンストリーム取得のメリット
ダウンストリーム取得を使用するメリットは次のとおりです。
-
必要なほとんどの作業がダウンストリーム・データベースで実行されるため、ソース・データベースで、変更の取得に使用されるリソースが少なくなります。
-
複数のソース・データベースで行われた変更を取得する場合、複数のソース・データベースに対する複数のアーカイブ・ログ・ダウンストリーム取得プロセスを1つのダウンストリーム・データベースで実行することによって、取得プロセスを簡単に管理できます。つまり、1つのダウンストリーム・データベースが、複数のソースからの変更を取得するための中心の場所として機能します。このような構成では、アーカイブ・ログ・ダウンストリーム取得プロセスに加えて、1つのリアルタイム・ダウンストリーム取得プロセスもダウンストリーム・データベースで実行できます。
-
REDOデータを1つ以上のダウンストリーム・データベースにコピーすることによって、データ損失に対する保護が強化されます。たとえば、状況によっては、ダウンストリーム・データベースのREDOログ・ファイルをソース・データベースのリカバリに使用できます。
-
1つ以上のダウンストリーム・データベースに、単一のソース・データベースから変更を取得する複数の取得プロセスを構成できるため、柔軟性およびスケーラビリティが向上します。
2.5.6.2.5 ダウンストリーム・データベースからソース・データベースへのオプションのデータベース・リンク
ダウンストリーム取得プロセスを作成または変更する場合は、オプションで、ダウンストリーム・データベースからソース・データベースへのデータベース・リンクが使用されるように指定できます。このデータベース・リンクには、ソース・データベースのグローバル名と同じ名前を付ける必要があります。このようなデータベース・リンクを使用すると、ダウンストリーム取得プロセスを簡単に作成および管理できます。ダウンストリーム取得プロセスでデータベース・リンクが使用されるように指定するには、ダウンストリーム取得プロセスで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
に設定する必要があります。そうでない場合は、エラーが発生します。
関連項目:
ダウンストリーム取得プロセスでデータベース・リンクが使用されている場合、取得プロセスの作成時にDBMS_CAPTURE_ADM.BUILD
プロシージャが自動的に実行されるタイミングの詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照
2.5.6.2.6 ダウンストリーム取得の操作要件
ダウンストリーム取得を使用する場合の操作要件は次のとおりです。
-
ソース・データベースでOracle Database 10g以上が実行されており、ダウンストリーム取得データベースで、ソース・データベースのリリース以上のOracle Databaseが実行されている必要があります。
-
リアルタイム・ダウンストリーム取得を構成するには、ダウンストリーム・データベースでOracle Database 10gリリース2以上が実行されている必要があります。この場合、ソース・データベースでOracle Database 10gリリース1以上が実行されている必要があります。
-
ソース・サイトおよびダウンストリーム取得サイトのオペレーティング・システムは同じである必要があります。ただし、オペレーティング・システムのリリースが同じである必要はありません。また、ダウンストリーム・サイトでは、ソース・サイトと異なるディレクトリ構造を使用できます。
-
ソース・サイトおよびダウンストリーム取得サイトのハードウェア・アーキテクチャが同じである必要があります。たとえば、ダウンストリーム取得構成では、ソース・データベースが32ビットのSunシステム上に構成されている場合、ダウンストリーム・データベースが32ビットのSunシステム上に構成されている必要があります。CPUの数、メモリー・サイズ、記憶域構成などのその他のハードウェア要素は、ソース・サイトとダウンストリーム・サイトで同じである必要はありません。
2.5.7 取得プロセスに関連するSCN値
ここでは、取得プロセスで重要となるシステム変更番号(SCN)値を説明します。1つ以上の取得プロセスのシステム変更番号を表示するには、DBA_CAPTURE
データ・ディクショナリ・ビューを問い合せます。
2.5.7.2 先頭SCNおよび開始SCN
次の各項では、取得プロセスの先頭SCNおよび開始SCNについて説明します。
2.5.7.2.1 先頭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は、このデータ・ディクショナリ・ビルドに対応します。
2.5.7.2.2 開始SCN
開始SCNは、取得プロセスで変更の取得を開始するSCNです。取得プロセスの作成時に先頭SCNとは別に開始SCNを指定するか、または取得プロセスを変更して開始SCNを設定できます。取得プロセスの通常の操作については開始SCNを変更する必要はありません。一般的に、取得プロセスの開始SCNをリセットするのは、取得プロセスから変更を受け取る宛先データベースのいずれかでPoint-in-Timeリカバリを実行する必要がある場合です。このような場合は、取得プロセスを使用して、Point-in-Timeリカバリの後にソース・データベースで行われた変更を取得することができます。
注意:
開始SCNを設定する前に、既存の取得プロセスを停止する必要があります。
2.5.7.2.3 開始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の詳細は、「取得プロセスの作成」を参照
2.5.7.2.4 インスタンス化の準備以前の時間への開始SCNの設定
データベース・オブジェクトに対する変更を取得し、適用プロセスを使用してこれらの変更を適用する場合は、データベース・オブジェクトがインスタンス化のために準備された後に発生した変更のみを適用できます。このため、取得プロセスの開始SCNを、データベース・オブジェクトがインスタンス化のために準備された時間に対応するSCNより小さい番号に設定すると、準備SCN以前に取得されたこのデータベース・オブジェクトに対する変更は、適用プロセスでは適用できません。
この制限は、取得プロセスの作成時に問題となる場合があります。取得プロセスの作成時より前に、データベース・オブジェクトがインスタンス化のために準備されなかった場合、取得プロセスの作成時より前に行われたオブジェクトに対する変更は、適用プロセスでは適用できません。
新しい取得プロセスの作成前に、データベース・オブジェクトがインスタンス化のために準備されている場合があります。たとえば、1つ以上の既存の取得プロセスで取得されている変更を含むソース・データベースの取得プロセスを作成する場合、一部またはすべてのデータベース・オブジェクトが新しい取得プロセスの作成前にインスタンス化のために準備されていることがあります。新しい取得プロセスで、この新しい取得プロセスの作成時より前に特定のデータベースに対して行われた変更を取得した場合、適用プロセスでこれらの取得された変更を適用するには、次の条件を満たしている必要があります。
-
新しい取得プロセスの作成時より前に、データベース・オブジェクトがインスタンス化のために準備されている必要があります。
-
新しい取得プロセスの開始SCNが、データベース・オブジェクトがインスタンス化のために準備された時間より前の時間に対応している必要があります。
-
指定した開始SCNに対応する時間のREDOログが使用可能である必要があります。また、開始SCNより前に追加のREDOログが必要な場合もあります。
注意:
-
データベース・オブジェクトをインスタンス化のために準備する方法の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照
2.5.8 Oracle Streamsの取得プロセスおよびRESTRICTED SESSION
システム起動時にSTARTUP
RESTRICT
文を発行して制限付きセッションを有効にすると、データベースの停止時に取得プロセスを実行していた場合でも、取得プロセスは起動されません。ALTER
SYSTEM
文を使用して制限付きセッションを無効にすると、データベースの停止時に実行されたいた各取得プロセスが起動されます。
SQL文ALTER
SYSTEM
のENABLE
RESTRICTED
SESSION
句によって実行中のデータベースで制限付きセッションを有効にしても、実行中の取得プロセスには影響がありません。これらの取得プロセスは引き続き実行され、変更の取得が行われます。停止している取得プロセスを制限付きセッションで起動しても、この取得プロセスは、制限付きセッションを無効にするまで実際には起動されません。
2.5.9 取得プロセスのサブコンポーネント
取得プロセスはオプションのOracleバックグラウンド・プロセスであり、プロセス名はCP
nn
(nn
は文字または数字)です。取得プロセスは、LogMinerのインフラストラクチャを使用してREDOログから変更を取得します。LogMinerは、Oracle Streamsによって自動的に構成されます。基礎となるLogMinerプロセス名はMS
nn
(nn
は文字または数字)です。取得プロセスの作成、変更、起動、停止および削除を行うことができます。また、取得プロセスで取得される変更を制御する取得プロセスのルールを定義できます。
取得プロセスのサブコンポーネントは、次のとおりです。
-
1つのリーダー・サーバー。REDOログを読み取って複数の領域に分割します。
-
1つ以上のプリペアラ・サーバー。リーダー・サーバーによって定義された領域をパラレルでスキャンし、REDOログ内で検出された変更の事前フィルタ処理を実行します。事前フィルタ処理では、変更に関する部分的な情報(変更のスキーマ名やオブジェクト名など)が評価のためにルール・エンジンに送信され、評価の結果が受信されます。
parallelism
取得プロセス・パラメータを使用してプリペアラ・サーバーの数を制御できます。 -
1つのビルダー・サーバー。プリペアラ・サーバーからのREDOレコードをマージします。これらのREDOレコードには、部分評価の実行中に
TRUE
と評価されたものと、部分評価で結果が生成されていないものがあります。ビルダー・サーバーは、これらのREDOレコードのシステム変更番号(SCN)の順序を保持し、マージされたREDOログ・レコードを取得プロセスに渡します。 -
取得プロセス(
CP
nn
)。マージされたREDOレコードをビルダー・サーバーから受信すると、各変更に対して次のアクションを実行します。-
変更をLCR形式でフォーマットします
-
プリペアラ・サーバーによって実行された部分評価で、LCRの変更に対する結果が生成されていない場合は、LCRを完全評価のためにルール・エンジンに送信します
-
LCRの完全評価が実行された場合は、その結果を受信します
-
LCRが取得プロセスのネガティブ・ルール・セットのルールを満たすか、ポジティブ・ルール・セットのルールを満たさない場合は、LCRを廃棄します。
-
LCRが取得プロセスのポジティブ・ルール・セットのルールを満たす場合は、取得プロセスに関連付けられたキューにLCRをエンキューします。
-
リーダー・サーバー、プリペアラ・サーバーおよびビルダー・サーバーはそれぞれが1つのプロセスである。
関連項目:
2.5.10 取得ユーザー
変更は、取得プロセスの取得ユーザーのセキュリティ・ドメインで取得されます。取得ユーザーは、取得プロセスのルール・セットを満たすすべての変更を取得します。また、取得ユーザーは、これらのルール・セット内のルールで指定されたカスタム・ルールベースの変換をすべて実行します。取得ユーザーは、アクションの実行に必要な権限(取得プロセスで使用されるルール・セットのEXECUTE
権限、ポジティブ・ルール・セットのルールに指定されたすべてのカスタム・ルールベースの変換ファンクションのEXECUTE
権限、取得プロセス・キューへのメッセージのエンキュー権限など)を持っている必要があります。1つの取得プロセスは1ユーザーにしか関連付けできませんが、1ユーザーは複数の取得プロセスに関連付けることができます。
関連項目:
-
必要な権限の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照
2.5.11 取得プロセスの状態
取得プロセスの状態は、取得プロセスが現在行っている処理を示します。取得プロセスの状態は、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
- 強制終了中。
関連項目:
-
取得プロセスの状態を表示する問合せの詳細は、「各取得プロセスに関する変更取得情報の表示」を参照
-
分割とマージの詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照
2.5.12 取得プロセス・パラメータ
作成後の取得プロセスは、最初に起動する前に環境に合わせて取得プロセス・パラメータを設定できるように無効になっています。取得プロセス・パラメータによって、取得プロセスの動作が制御されます。たとえば、parallelism
取得プロセス・パラメータによって、取得プロセスで使用されるプリペアラ・サーバーの数が制御され、time_limit
取得プロセス・パラメータによって、適用プロセスが自動的に停止されるまでの実行時間が指定されます。DBMS_CAPTURE_ADM.SET_PARAMETER
プロシージャを使用して取得プロセス・パラメータを設定します。
関連項目:
-
プリペアラ・サーバーの詳細は、「取得プロセスのサブコンポーネント」を参照
-
すべての取得プロセス・パラメータの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照
2.6 同期取得による暗黙的取得
この項では、同期取得に関連する概念について説明します。
このセクションのトピックは次のとおりです:
関連項目:
-
同期取得の構成の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照
-
「同期取得の管理」
-
「同期取得の監視」
2.6.1 同期取得の概要
同期取得は、表へのデータ操作言語(DML)の変更を取得する、オプションのOracle Streamsクライアントです。同期取得は、内部メカニズムを使用して指定の表へのDML変更を取得します。同期取得は表への変更を取得するように構成されますが、そのような表を含むデータベースがソース・データベースと呼ばれます。
表へのDML変更が行われると、表の1つ以上の行が変更されます。同期取得は、各行の変更を取得し、行論理変更レコード(行LCR)と呼ばれる特殊なメッセージ・フォーマットに変換します。行LCRを取得した後、同期取得は行LCRを含むメッセージをキューにエンキューします。同期取得によって作成される行LCRには、変更によって変更されていない行であっても、常に行のすべての列の値が含まれます。
図2-4に、LCRを取得する同期取得を示します。
注意:
同じ表に対して行われた変更が同期取得と取得プロセスによって取得されないようにする必要があります。
2.6.2 同期取得およびキュー
同期取得は、常に、単一のANYDATA
キューに関連付けられており、このキューにのみメッセージをエンキューします。同期取得で使用されるキューは、コミット時間キューである必要があります。コミット時間キューによって、メッセージがトランザクションにグループ化され、トランザクション・グループがコミット・システム変更番号(CSCN)順に配置されます。同期取得では、常に、行LCRを永続キューにエンキューします。永続キューは、メモリーではなくハード・ディスクのキュー表にのみメッセージを格納するキューの一部分です。複数のキューを作成し、各キューに異なる同期取得を関連付けることができます。
同期取得ではコミット時間キューにメッセージをエンキューする必要がありますが、同期取得で取得されたメッセージは、コミット時間キュー以外のキューに伝播することができます。したがって、同期取得で取得されたメッセージを格納する中間キューがコミット時間キューである必要はありません。また、同期取得で取得されたメッセージを適用する適用プロセスでは、コミット時間キュー以外のキューを使用できます。
注意:
-
同期取得を関連付けることができるのは
ANYDATA
キューのみです。型付きキューに関連付けることはできません。 -
取得プロセスで使用されるメッセージが同期取得によってエンキューされないようにする必要があります。
2.6.3 同期取得のルール
同期取得は、定義したルールに基づいて、変更を取得または廃棄します。各ルールによって、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
プロシージャを使用して、同期取得を作成することもできます。
注意:
関連項目:
-
同期取得の構成の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照
2.6.4 同期取得によって取得されるデータ型
表に対するDML変更による行の変更を取得するとき、同期取得は、次のデータ型の列に対して行われる変更を取得できます。
-
VARCHAR2
-
NVARCHAR2
-
NUMBER
-
FLOAT
-
DATE
-
BINARY_FLOAT
-
BINARY_DOUBLE
-
TIMESTAMP
-
TIME
WITH
TIME
ZONE
-
TIMESTAMP
WITH
LOCAL
TIME
ZONE
-
INTERVAL
YEAR
TO
MONTH
-
INTERVAL
DAY
TO
SECOND
-
RAW
-
CHAR
-
NCHAR
-
UROWID
注意:
同期取得では、Oracle Database 12cで導入された拡張データ型はサポートしていません。
関連項目:
-
取得プロセスによって適用できるデータ型の詳細は、「適用されるデータ型」を参照
-
データ型の詳細は、『Oracle Database SQL言語リファレンス』を参照
2.6.5 同期取得によって取得されるDML変更のタイプ
特定の表に対して行われたDML変更を取得するように指定した場合、同期取得では、これらの表に対して行われた次のタイプのDML変更が取得されます。
-
INSERT
-
UPDATE
-
DELETE
-
MERGE
同期取得では、MERGE
の変更がそれぞれINSERT
またはUPDATE
の変更に変換されます。MERGE
は、行LCRでは無効なコマンド・タイプです。
関連項目:
-
適用プロセスで適用可能な変更のタイプの詳細は、「Oracle Streams情報コンシューム」を参照
2.6.6 同期取得の取得ユーザー
変更は、同期取得の取得ユーザーのセキュリティ・ドメインで取得されます。取得ユーザーは、同期取得のルール・セットを満たすすべての変更を取得します。また、取得ユーザーは、これらのルール・セット内のルールで指定されたカスタム・ルールベースの変換をすべて実行します。取得ユーザーは、アクションの実行に必要な権限(同期取得で使用されるルール・セットのEXECUTE
権限、ルール・セットのルールに指定されたすべてのカスタム・ルールベースの変換ファンクションのEXECUTE
権限、同期取得キューへのメッセージのエンキュー権限など)を持っている必要があります。1つの同期取得に関連付けることができるのは1ユーザーのみですが、1ユーザーには複数の同期取得を関連付けることができます。
関連項目:
必要な権限の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照
2.7 アプリケーションによる明示的取得
アプリケーションによるメッセージの手動エンキューは明示的取得と呼ばれます。エンキューの後、Oracle Streamsの伝播によって、これらのメッセージを同じデータベース内または他のデータベースに伝播できます。また、アプリケーション、適用プロセスおよびメッセージ・クライアントによってこれらのメッセージをコンシュームすることもできます。メッセージをエンキューするには、DBMS_STREAMS_MESSAGING
パッケージまたはDBMS_AQADM
パッケージを使用します。
次の各項では、メッセージのエンキューの概念について説明します。
関連項目:
-
メッセージのエンキューに関する主なドキュメントは、『Oracle Databaseアドバンスト・キューイング・ユーザーズ・ガイド』を参照
2.7.1 明示的にエンキューできるメッセージのタイプ
Oracle Streams環境では、アプリケーションによって、様々なタイプのメッセージを様々な目的のために作成してエンキューできます。これらのメッセージは、ユーザー・メッセージと呼ばれるユーザー定義型のメッセージ、またはLCRです。
この項の内容は次のとおりです。
2.7.1.1 ユーザー・メッセージ
アプリケーションは、ユーザー定義型のメッセージを作成して、エンキューすることができます。エンキューできるキューは、メッセージと同じタイプのキューまたはANYDATAキューです。通常、このようなユーザー・メッセージはアプリケーションまたは適用プロセスによってコンシュームされます。
バッファ・キューにエンキューされるユーザー・メッセージはバッファ・ユーザー・メッセージと呼ばれます。バッファ・ユーザー・メッセージはアプリケーションでのみデキューできます。アプリケーションではデキュー後にメッセージを処理します。
永続キューにエンキューされるユーザー・メッセージは永続ユーザー・メッセージと呼ばれます。永続ユーザー・メッセージは次の方法でデキューできます。
-
メッセージ・クライアント: メッセージ・クライアントは、メッセージの処理のためにメッセージ・クライアントを起動したアプリケーションにメッセージを渡します。
-
アプリケーション: アプリケーションはメッセージをデキューした後で処理します。
-
適用プロセス: 適用プロセスは、処理のためにメッセージ・ハンドラにメッセージを渡します。適用プロセスがメッセージをデキューするためには、キューが
ANYDATA
キューであることが必要です。
2.7.1.2 論理変更レコード(LCR)とメッセージ
アプリケーションはLCRを作成して、ANYDATA
キューにエンキューすることができます。行LCRはDML変更の結果を記述し、DDL LCRはDDL変更について記述します。通常、LCRは適用プロセスによってコンシュームされますが、メッセージ・クライアントやアプリケーションによってコンシュームされることもあります。異機種レプリケーション環境では、LCRの明示的エンキューを使用して、データベースの変更をOracle以外のデータベースからOracle Databaseにレプリケートすることができます。
バッファ・キューに明示的にエンキューされるLCRはバッファLCRと呼ばれます。バッファLCRはアプリケーションでのみデキューできます。アプリケーションではデキュー後にバッファLCRを処理します。
永続キューに明示的にエンキューされるLCRは永続LCRと呼ばれます。永続LCRは次の方法でデキューできます。
-
メッセージ・クライアント: メッセージ・クライアントは、メッセージの処理のためにメッセージ・クライアントを起動したアプリケーションにメッセージを渡します。
-
アプリケーション: アプリケーションはメッセージをデキューした後で処理します。
-
適用プロセス: 適用プロセスは、LCRを直接適用するか、処理のために適用ハンドラに渡すことができます。
関連項目:
2.7.2 エンキュー機能
Oracle Databaseアドバンスト・キューイングのエンキューでは、次のような機能を利用できます。
-
バッファ・キューまたは永続キューへのエンキュー
-
エンキュー時間またはコミット時間に基づくメッセージの順序付け
-
メッセージの配列エンキュー
-
相関識別子
-
メッセージのグループ分け
-
送信者の識別
-
時間指定とスケジュール設定
関連項目:
-
これらの機能およびOracle Databaseアドバンスト・キューイングで利用できるその他の機能の詳細は、『Oracle Databaseアドバンスト・キューイング・ユーザーズ・ガイド』を参照