| Oracle Streams概要および管理 11g リリース1（11.1） E05775-02 |
|
 前へ |
 次へ |
次の各項では、キューでのメッセージのステージングやキュー間でのメッセージの伝播の概要について説明します。
Oracle Streamsでは、キューを使用してメッセージをステージングします。ステージングされたメッセージは、コンシュームまたは伝播（あるいはその両方）の対象になります。ステージングされたメッセージは、適用プロセス、メッセージ・クライアントまたはユーザー・アプリケーションでコンシュームできます。実行中の適用プロセスはメッセージを暗黙的にデキューしますが、メッセージ・クライアントとユーザー・アプリケーションはメッセージを明示的にデキューします。Oracle Streamsの伝播で他の1つ以上のキューへのメッセージの伝播（送信）を構成している場合、またはキューでメッセージの保存が指定されている場合は、メッセージがコンシュームされた後でも、キューに残ることができます。メッセージの保存は、同期取得で取得されたメッセージまたは明示的にエンキューされたメッセージに適用されます。取得プロセスで取得されたメッセージには適用されません。
キューは、メッセージ・システムがメッセージを格納するために使用する抽象的な記憶域単位です。この項の内容は次のとおりです。
ANYDATAタイプのキューは、ほとんどのタイプのメッセージをステージングでき、ANYDATAキューと呼ばれます。型付きキューは特定のタイプのメッセージをステージングできます。Oracle Streamsクライアントは常にANYDATAキューを使用します。
Oracle Streamsレプリケーション環境では、論理変更レコード（LCR）をANYDATAキューにステージングする必要があります。Oracle Streamsメッセージ環境では、ANYDATAキューと型付きキューの両方がメッセージをステージングできます。パブリッシュ・アプリケーションはメッセージを1つのキューにエンキューでき、サブクライブ・アプリケーションがそれらのメッセージをデキューできます。
LCRとユーザー・メッセージという2種類のメッセージをANYDATAオブジェクトにカプセル化してANYDATAキューにステージングできます。LCRはデータベース・オブジェクトに対する変更情報を含むオブジェクトで、ユーザー・メッセージはユーザーまたはアプリケーションが作成するユーザー定義型のメッセージです。どちらのタイプのメッセージも、単一データベース内またはデータベース間で情報を共有するために使用できます。
ANYDATAキューは、ペイロードのタイプがANYDATAのユーザー・メッセージをステージングできます。ANYDATAペイロードは、様々なデータ型のペイロードのラッパーとして使用できます。
メッセージのペイロードにANYDATAラッパーを使用すると、パブリッシュ・アプリケーションが様々なタイプのメッセージを1つのキューにエンキューでき、サブスクライブ・アプリケーションが、メッセージ・クライアントまたはアプリケーションを使用して明示的に、あるいは適用プロセスを使用して暗黙的に、それらのメッセージをデキューできます。サブスクライブ・アプリケーションがリモートの場合、メッセージをリモート・サイトに伝播することができ、サブスクライブ・アプリケーションがリモート・データベースのローカル・キューからメッセージをデキューできます。または、リモート・サブスクライブ・アプリケーションが、様々な標準プロトコル（PL/SQLやOCIなど）を使用してソース・キューからメッセージを直接デキューすることもできます。
ほぼすべての型のペイロードをANYDATAペイロードでラップできます。このためには、ANYDATAタイプのConvertdata_type静的関数を使用します。data_typeはラップするオブジェクトの型です。このような関数は入力としてオブジェクトを取り、ANYDATAオブジェクトを返します。
Oracle StreamsにはOracle Streamsアドバンスト・キューイング（AQ）の機能が含まれ、マルチ・コンシューマ・キュー、パブリッシュおよびサブスクライブ、コンテンツベースのルーティング、インターネット伝播、変換、他のメッセージ・サブシステムへのゲートウェイなど、メッセージ・キューイング・システムの標準機能がすべてサポートされます。
|
関連項目:
|
Oracle Streamsでは、次のメッセージ・モードがサポートされています。
永続メッセージ機能: メッセージは、ディスク上のキュー表と呼ばれるデータベース表に常に格納されます。この記憶域のタイプは、永続キュー記憶域と呼ばれることがあります。
バッファ・メッセージ機能: メッセージは、メモリーに格納されますが、一定の条件でキュー表にあふれることがあります。この記憶域のタイプは、バッファ・キュー記憶域と呼ばれることがあります。このメモリーには、取得プロセスで取得されたメッセージまたはアプリケーションでエンキューされたメッセージを含むキューに関連付けられているOracle Streamsプール・メモリーが含まれます。
バッファ・キューを使用すると、Oracleでは、メッセージを常にキュー表に格納するのではなく、システム・グローバル領域（SGA）に格納することによって、メッセージを最適化できます。バッファ・メッセージ機能は、より高いパフォーマンスを提供しますが、メッセージ保持などの一部のメッセージ機能をサポートしません。メッセージ保持では、デキュー後にメッセージがキュー表に保持される時間を指定できます。
Oracle Streamsプールのサイズが自動的に管理されない場合は、データベースの各バッファ・キューに対してOracle Streamsプールのサイズを10MBずつ増やす必要があります。バッファ・キューによってパフォーマンスは改善されますが、バッファ・キューを含むインスタンスが正常または異常な状態で停止すると、バッファ・キューの一部の情報が失われることがあります。このような場合に、インスタンス上でデータベース全体のリカバリが実行されるとOracle Streamsは自動的にリカバリします。
バッファ・キューのメッセージがメモリーからオーバーフローしてキュー表に格納されるのは、メッセージがバッファ・キューにステージングされてから一定期間デキューされない場合か、すべてのメッセージを保持する十分な領域がメモリーにない場合です。メモリーからオーバーフローしたメッセージは、適切なAQ$_queue_table_name_p表に格納されます。queue_table_nameはキューのキュー表の名前です。また、オーバーフローした各メッセージについては、メッセージの処理に使用できる伝播や適用プロセスに関する情報がAQ$_queue_table_name_d表に格納されます。
取得プロセスで取得されたLCRは常にバッファ・キューに格納されますが、同期取得で取得されたLCRは常に永続キューに格納されます。バッファ・キューには、他のタイプのメッセージが格納されることがあります。アプリケーションがメッセージをエンキューすると、エンキュー操作によって、エンキューされたメッセージがバッファ・キューと永続キューのいずれに格納されるかが指定されます。DBMS_AQ.ENQUEUEプロシージャのenqueue_optionsパラメータのdelivery_mode属性によって、メッセージがバッファ・キューと永続キューのどちらに格納されるかが決まります。具体的には、delivery_mode属性がデフォルトのPERSISTENTの場合、メッセージは永続キューにエンキューされます。この属性をBUFFEREDに設定すると、メッセージはバッファ・キューにエンキューされます。トランザクションがエラー・キューに移動される場合、そのトランザクションのすべてのメッセージはバッファ・キューではなく常にキュー表に格納されます。
|
関連項目:
|
Oracle Streamsクライアントでは、常にANYDATAキューを使用します。次の項では、Oracle Streamsクライアントとキューの対話方法を説明します。
取得プロセスがLCRをエンキューできるのは、バッファ・キューにのみです。取得プロセスによってバッファ・キューにエンキューされたLCRは、適用プロセスによってのみデキューできます。取得LCRはアプリケーションまたはユーザーによってデキューできません。
同期取得がLCRをエンキューできるのは永続キューにのみできます。同期取得によって取得されたLCRは、適用プロセス、メッセージ・クライアント、アプリケーションおよびユーザーによってデキューできます。
伝播では、ルール・セットを満たすソース・キューのすべてのメッセージを伝播します。これらのメッセージは、バッファ・キューまたは永続キューに格納できます。伝播では、伝播で使用されるルール・セットを満たす場合、どちらのタイプのメッセージでも伝播できます。
1つの適用プロセスは、バッファ・キューまたは永続キューのいずれかからメッセージをデキューできますが、両方からデキューすることはできません。適用プロセスでは、バッファ・キューの取得LCRをデキューおよび処理できます。取得LCRをデキューするには、適用プロセスの構成でapply_capturedパラメータをTRUEに設定する必要があります。適用プロセスではバッファLCRまたはバッファ・ユーザー・メッセージをデキューできません。永続LCRまたは永続ユーザー・メッセージをデキューするには、適用プロセスの構成でapply_capturedパラメータをFALSEに設定する必要があります。
メッセージ・クライアントでは、永続キューからのみメッセージをデキューできます。また、DBMS_STREAMS_MESSAGINGパッケージを使用してバッファ・キューにメッセージをエンキューしたり、バッファ・キューからメッセージをデキューすることはできません。
|
注意: DBMS_AQおよびDBMS_AQADMパッケージは、バッファ・メッセージをサポートします。 |
|
関連項目: DBMS_AQおよびDBMS_AQADM パッケージの使用方法の詳細は、Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイドを参照 |
保護キューは、エンキューやデキューなどのキュー操作を実行できる1人以上のデータベース・ユーザーにOracle Streamsアドバンスト・キューイング（AQ）・エージェントを明示的に関連付ける必要があるキューです。保護キューの所有者はキューに対してすべてのキュー操作を実行できますが、他のユーザーは保護キュー・ユーザーとして構成されていないかぎり、保護キューに対するキュー操作を実行できません。Oracle Streamsでは、保護キューを使用して、適切なユーザーおよびOracle Streamsクライアントのみがメッセージのエンキューとデキューを確実に行えます。
DBMS_STREAMS_ADMパッケージのSET_UP_QUEUEプロシージャを使用して作成されたすべてのANYDATAキューは、保護キューです。SET_UP_QUEUEプロシージャを使用してキューを作成すると、queue_userパラメータで指定したユーザーは、可能であればキューの保護キュー・ユーザーとして自動的に構成されます。また、キュー・ユーザーには、キューに対するENQUEUEおよびDEQUEUE権限が付与されます。メッセージをエンキューおよびデキューするには、キュー・ユーザーはDBMS_STREAMS_MESSAGINGパッケージまたはDBMS_AQ パッケージのEXECUTE権限も必要です。SET_UP_QUEUEプロシージャでは、これらのいずれの権限も付与されません。また、メッセージは、デキューできるサブスクライバが構成されるまで、キューにエンキューできません。
キュー・ユーザーを保護キュー・ユーザーとして構成するために、SET_UP_QUEUEプロシージャでは、存在しない場合はユーザー名と同じ名前でOracle Streams AQエージェントが作成されます。ユーザーは、このエージェントを使用してキューに対するキュー操作を実行する必要があります。この名前のエージェントがすでに存在し、そのキュー・ユーザーのみに関連付けられている場合は、既存のエージェントが使用されます。SET_UP_QUEUEでは、エージェントとユーザーを指定して、DBMS_AQADMパッケージのENABLE_DB_ACCESSプロシージャが実行されます。
DBMS_STREAMS_ADMパッケージのSET_UP_QUEUEプロシージャを使用して保護キューを作成し、キュー所有者ではなくqueue_userパラメータで指定していないユーザーに、キューに対する操作の実行を許可する必要がある場合は、そのユーザーを手動でキューの保護キュー・ユーザーとして構成できます。また、SET_UP_QUEUEプロシージャを再実行して、キューに異なるqueue_userを指定することもできます。この場合、SET_UP_QUEUEではキューの作成をスキップしますが、queue_userで指定したユーザーがキューの保護キュー・ユーザーとして構成されます。
DBMS_AQADMパッケージを使用してANYDATAキューを作成する場合は、CREATE_QUEUE_TABLEプロシージャを実行するときにsecureパラメータを使用して、キューが保護キューかどうかを指定します。このプロシージャを実行するときにsecureパラメータにTRUEを指定すると、キューは保護キューになります。DBMS_AQADMパッケージを使用して保護キューを作成し、ユーザーが保護キューに対してキュー操作を実行できるようにする必要がある場合は、これらの保護キュー・ユーザーを手動で構成する必要があります。
取得プロセスまたは適用プロセスを作成すると、Oracle Streamsプロセスに関連付けられている保護キューのOracle Streams AQエージェントが自動的に構成され、Oracle Streamsプロセスを実行するユーザーは、このキューの保護キュー・ユーザーとして自動的に指定されます。したがって、取得プロセスは保護キューを自動的にエンキューするように構成され、適用プロセスは保護キューから自動的にデキューするように構成されます。どちらの場合も、Oracle Streams AQエージェントの名前はOracle Streamsクライアントと同じになります。
取得プロセスの場合は、capture_userとして指定したユーザーが、取得プロセスを実行するユーザーとなります。適用プロセスの場合は、apply_userとして指定したユーザーが、適用プロセスを実行するユーザーとなります。capture_userまたはapply_userを指定しなければ、Oracle Streamsプロセスの作成プロシージャを起動したユーザーが、Oracle Streamsプロセスを実行するユーザーとなります。
同期取得を作成すると、同期取得と同じ名前を持つ保護キューのOracle Streams AQエージェントは、capture_userに指定されたユーザーに関連付けられます。capture_userが指定されていない場合は、同期取得を作成するプロシージャを起動したユーザーがcapture_userになります。capture_userは、このキューの保護キュー・ユーザーとして自動的に指定されます。そのため、同期取得では、保護キューを自動的にエンキューできます。
取得プロセスまたは同期取得のcapture_user、あるいは適用プロセスのapply_userを変更すると、指定したcapture_userまたはapply_userはOracle Streamsクライアントで使用されるキューの保護キュー・ユーザーとして構成されます。ただし、古い取得ユーザーまたは適用ユーザーは、キューの保護キュー・ユーザーとして構成されたままです。古いユーザーを削除するには、そのユーザーと関連するOracle Streams AQエージェントを指定して、DBMS_AQADMパッケージのDISABLE_DB_ACCESSプロシージャを実行します。また、不要になったエージェントは削除できます。DBA_AQ_AGENT_PRIVSデータ・ディクショナリ・ビューを問い合せると、Oracle Streams AQエージェントとその関連ユーザーを表示できます。
メッセージ・クライアントを作成すると、メッセージ・クライアントと同じ名前の保護キューのOracle Streams AQエージェントは、メッセージ・クライアントの作成プロシージャを実行するユーザーに関連付けられます。このメッセージ・クライアント・ユーザーは、このキューの保護キュー・ユーザーとして自動的に指定されます。そのため、このユーザーはメッセージ・クライアントを使用して、キューからメッセージをデキューできます。
取得プロセス、同期取得、適用プロセスまたはメッセージ・クライアントは、1ユーザーのみに関連付けることができます。ただし、ユーザーは、複数の取得プロセス、同期取得、適用プロセスおよびメッセージ・クライアントを含む複数のOracle Streamsクライアントに関連付けることができます。たとえば、適用プロセスに適用ユーザーとしてhrとoeの両方を含めることはできませんが、hrを複数の適用プロセスの適用ユーザーにすることはできます。
取得プロセス、同期取得、適用プロセスまたはメッセージ・クライアントを削除しても、これらのOracle Streamsクライアントの保護キュー・ユーザーとして構成されていたユーザーは、引き続きキューの保護キュー・ユーザーのままです。保護キュー・ユーザーとしてのユーザーを削除するには、ユーザーごとにDBMS_AQADMパッケージのDISABLE_DB_ACCESSプロシージャを実行します。また、不要になったエージェントは削除できます。
|
関連項目:
|
トランザクション・キューは、複数のメッセージを1つのトランザクションとして適用されるセットにグループ化できるキューです。つまり、適用プロセスでは、グループ内のすべてのメッセージを適用した後にCOMMITを実行します。非トランザクション・キューは、各メッセージが個別のトランザクションであるキューです。つまり、適用プロセスは、各メッセージが適用された後に、COMMITを実行します。どちらの場合も、メッセージはLCRまたはユーザー・メッセージのいずれかです。
DBMS_STREAMS_ADMパッケージのSET_UP_QUEUEプロシージャでは、常にトランザクション・キューが作成されます。トランザクション・キューと非トランザクション・キューの違いが重要になるのは、アプリケーション、同期取得または適用プロセスによってエンキューされたメッセージに対してのみです。適用プロセスは、常にソース・データベースで実行されたトランザクションが保つトランザクション内で取得LCRを適用します。
表3-1に、メッセージ・タイプとキューの型ごとに、適用プロセスの動作を示します。
表3-1 トランザクション・キューと非トランザクション・キューに対する適用プロセスの動作
| メッセージ・タイプ | トランザクション・キュー | 非トランザクション・キュー |
|---|---|---|
|
取得LCR |
適用プロセスは元のトランザクションを保持します。 |
適用プロセスは元のトランザクションを保持します。 |
|
永続LCRまたは永続ユーザー・メッセージ |
ユーザーが指定したメッセージのグループを、1つのトランザクションとして適用します。 |
各メッセージをそれぞれのトランザクション内で適用します。 |
ソース・データベースで実行されたトランザクションを保持する必要がある場合は、トランザクション・キューを使用してメッセージを格納します。同期取得で取得されたLCRがトランザクション・キューに格納されていることを確認します。
永続キュー内のメッセージが参照またはデキューされる順序を制御できます。キュー内のメッセージの順序付けは、キュー表によって決定されます。キュー表の作成時にキュー表に対してメッセージの順序を指定できます。具体的には、DBMS_AQADM.CREATE_QUEUE_TABLEプロシージャのsort_listパラメータによって、メッセージの順序付けの方法が決定されます。コミット時間キュー内の各メッセージは、それぞれのメッセージをエンキューするトランザクションのコミット時に取得される近似コミット・システム変更番号（近似CSCN）によって順序付けされます。
コミット時間による順序付けはキュー表に対して指定され、そのキュー表を使用するキューをコミット時間キューと呼びます。DBMS_AQADM.CREATE_QUEUE_TABLEプロシージャのsort_listパラメータにcommit_timeを指定すると、生成されるキュー表でコミット時間による順序付けが使用されます。
Oracle Database 10g リリース2以上では、DBMS_STREAMS_ADMパッケージのSET_UP_QUEUEプロシージャによって作成されるキュー表のsort_listは、デフォルトで、commit_timeに設定されています。Oracle Database 10g リリース2より前のリリースでは、デフォルトで、enq_timeに設定されています（詳細は、次の項を参照）。SET_UP_QUEUEプロシージャのqueue_tableパラメータに既存のキュー表が指定されている場合、SET_UP_QUEUEによって作成されるキュー内でのメッセージの順序付けは、既存のキュー表によって決定されます。
Oracle Database内のキューにメッセージをエンキューすることによって、ユーザーまたはアプリケーションが情報を共有できます。エンキューされたメッセージは、単一のデータベース内で共有したり、他のデータベースに伝播することができます。メッセージは、LCRの場合とユーザー・メッセージの場合があります。たとえば、アプリケーション固有のメッセージが発生した場合や、データベースの変更に対してトリガーが起動された場合に、メッセージをエンキューできます。また、異機種間環境では、Oracle以外のデータベースで発生したメッセージを、アプリケーションでOracle Databaseでエンキューできます。
CREATE_QUEUE_TABLEプロシージャのsort_listパラメータには、commit_timeの他に、priorityとenq_timeを設定できます。priorityを設定すると、エンキュー時に指定された優先順位の高いものから順にメッセージが順序付けされます。enq_timeを設定すると、エンキューされた時間の古いものから順にメッセージが順序付けされます。
コミット時間キューは、環境でメッセージの同時エンキューに対して次のいずれかの要件をサポートする必要がある場合に役立ちます。
コミット時間キューでは、これらの要件がサポートされます。優先順位またはエンキュー時間による順序付けでは、トランザクション間の依存性の違反および一貫性のない参照が許可されるため、いずれの順序付けでもこれらの要件はサポートされません。これらの設定では、元の依存性にかかわらずメッセージがデキューされるため、トランザクションの間の依存性の違反が許可されます。また、これらの設定では、デキュー操作を伴わずに実行される複数の参照によってメッセージの様々なセットが生成されるため、キュー内のメッセージの一貫性のない参照が許可されます。
1つのデータベース・トランザクションを正常にコミットするために別のデータベース・トランザクションのコミットを必要とする場合、トランザクション間の依存性が発生します。データベース・トランザクションに関する情報を含むメッセージをエンキューできます。たとえば、データベース・トリガーによってメッセージのエンキューを実行できます。図3-1に、エンキュー時間による順序付けで、これらのメッセージのデキュー時にトランザクション間の依存性による順序付けがサポートされないことを示します。
図3-1に、エンキュー時間による順序付けで、トランザクション間の依存性による順序付けが違反される場合があることを示します。メッセージe2をエンキューしたトランザクションは、メッセージe1およびe3をエンキューしたトランザクションがコミットされる前にコミットされています。メッセージe3に含まれる更新は、メッセージe2に含まれる挿入に依存しています。そのため、トランザクション間の依存性をサポートする正しいデキュー順序は、 e2、e1、e3になります。ただし、エンキュー時間による順序付けでは、e2の前にe3をデキューできます。そのため、e3のデキュー時に、e3に含まれる変更をアプリケーションがhr.employees表に適用しようとすると、エラーが発生します。また、3つのメッセージがすべてデキューされた後、e3に含まれる変更が実行されていないために、hr.employees 表の行に誤った情報が含まれています。
図3-2に、エンキュー時間による順序付けで、キュー内のメッセージの一貫性のある参照がサポートされないことを示します。
図3-2に、エンキュー時間による順序付けで、クライアントがキュー内のメッセージを参照するときに一定の順序が保証されないことを示します。セッション1および2は、メッセージをエンキューしている同時セッションです。セッション3は、エンキューされた3つのメッセージを異なる順序で返すクライアント参照の2つのセットを示します。クライアントがメッセージの決定的な順序付けを必要とする場合は、このクライアントに対して障害が発生します。たとえば、クライアントが参照を実行してプログラム状態を開始すると、後続のデキューによって予想と異なる順序でメッセージが返される場合があります。
キューにエンキューされたメッセージのコミット・システム変更番号（CSCN）は、メッセージを含むトランザクションのコミットに関するREDOレコードがREDOログに書き込まれるまで不明です。メッセージのエンキュー時にCSCNを記録することはできません。コミット時間キューでは、トランザクションのコミット時のデータベースの現行のSCNが、トランザクション内のすべてのメッセージに対する近似CSCNとして使用されます。コミット時間キュー内のメッセージの順序は、メッセージをエンキューしたトランザクションの近似CSCNに基づきます。
コミット時間キューでは、近似CSCNを使用してメッセージの決定的な順序を確立できるまで、デキューおよび参照操作でトランザクション内のメッセージを参照することはできません。複数のトランザクションによって同じコミット時間キューにメッセージが同時にエンキューされる場合、複数のトランザクションがほぼ同時にコミットされたり、これらのトランザクションのコミット間隔が重複する可能性があります。この場合、これらのトランザクション内のメッセージは、トランザクションがコミットされるまで参照できません。その時点では、メッセージの順序は各トランザクションの近似CSCNを使用して決定できます。エンキュー時間ではなくメッセージの近似CSCNを使用することによって、依存性が保持されます。順序が完全に決定されたメッセージのみを参照可能にすることによって、参照の読取りの一貫性が保持されます。
コミット時間キューは、常に、データベース・トランザクションに基づくメッセージに対してトランザクション間の依存性による順序付けを保持します。ただし、アプリケーションおよびユーザーが、データベース・トランザクションに基づかないメッセージをエンキューする場合があります。これらのメッセージでは、トランザクション間に依存性が存在する場合には、アプリケーションまたはユーザーは、トランザクションが正しい順序でコミットされること、および依存するトランザクションのコミット間隔が重複しないことを保証する必要があります。
コミット時間キューによって記録されたトランザクションの近似CSCNには、これらのトランザクションの実際のコミット順序が反映されない場合があります。たとえば、トランザクション1およびトランザクション2は、メッセージのエンキュー後、ほぼ同時にコミットされる可能性があります。トランザクション1の近似CSCNがトランザクション2の近似CSCNより小さい場合に、トランザクション2よりもトランザクション1の方がコミットの完了に時間がかかる場合があります。この場合、トランザクション2の実際のCSCNは、トランザクション1の実際のCSCNより小さくなります。
|
注意: CREATE_QUEUE_TABLEのsort_listパラメータを次のように設定できます。
priority, commit_time この場合、まず優先順位によって、次にコミット時間によって順序付けが行われます。そのため、この設定は、優先順位の異なるメッセージに対して、トランザクション間の依存性による順序付けおよび参照の読取り一貫性を保証しません。ただし、優先順位が同じメッセージに対しては、トランザクション間の依存性による順序付けと参照の読取り一貫性が保証されます。 |
Oracle Streamsを使用すると、2つのキュー間でメッセージ伝播するように構成できます。これらのキューは、同じデータベースに存在することも異なるデータベースに存在することもできます。Oracle StreamsではOracle Schedulerジョブを使用してメッセージが伝播されます。
伝播は、常にソース・キューと宛先キューの間で行われます。伝播は常に2つのキュー間で行われますが、1つのキューが多数の伝播にかかわることができます。つまり、1つのソース・キューがメッセージを複数の宛先キューに伝播でき、1つの宛先キューが複数のソース・キューからメッセージを受信できます。また、1つのキューが、ある伝播の宛先キューと他の伝播のソース・キューを兼ねることができます。ただし、特定のソース・キューと特定の宛先キューの間で許可される伝播は1つのみです。
図3-3に、ソース・キューから宛先キューへの伝播を示します。
伝播の作成、変更および削除を行うことができます。また、伝播するメッセージを制御する伝播ルールを定義できます。ソース・キューを所有するユーザーが、メッセージを伝播するユーザーです。このユーザーは、メッセージの伝播に必要な権限を持っている必要があります。これには、次の権限が含まれます。
伝播で使用されるルール・セットのEXECUTE権限
ルール・セットで使用されるすべてのカスタム・ルールベースの変換ファンクションのEXECUTE権限
宛先キューのエンキュー権限（宛先キューが同じデータベースにある場合）
伝播によってメッセージがリモート・データベース内の宛先キューに伝播される場合、ソース・キューの所有者は、伝播で使用されるデータベース・リンクを使用できる必要があり、リモート・データベースでデータベース・リンクの接続先となるユーザーは、宛先キューに対するエンキュー権限を持っている必要があります。
伝播では、ソース・キューのすべてのメッセージを宛先キューに伝播することも、メッセージのサブセットのみを伝播することもできます。一度の伝播で、キューのバッファ・キュー部分および永続キュー部分の両方のメッセージを伝播できます。また、一度の伝播でLCRとユーザー・メッセージを伝播することもできます。ルールを使用して、ソース・キューから宛先キューに伝播するメッセージおよび破棄するメッセージを制御できます。
Oracle Streams環境の設定方法によっては、変更が発生元のサイトに送り返される場合があります。変更が無限ループで循環しないように環境を構成していることを確認してください。Oracle Streamsタグを使用すると、このような変更の循環ループを回避できます。
次の各項では、伝播についてさらに詳しく説明します。
|
関連項目:
|
伝播は、ユーザーが定義するルールに基づいてメッセージを伝播または廃棄します。LCRの場合は、各ルールでTRUEと評価するデータベース・オブジェクトと変更の種類を指定します。ユーザー・メッセージの場合は、特定のタイプのメッセージに対する伝播の動作を制御するルールを作成できます。これらのルールは、伝播で使用されるポジティブ・ルール・セットまたはネガティブ・ルール・セットに指定します。
ルールがメッセージをTRUEと評価し、そのルールが伝播のポジティブ・ルール・セットに含まれる場合、伝播はその変更を伝播します。ルールがメッセージをTRUEと評価し、そのルールが伝播のネガティブ・ルール・セットに含まれる場合、伝播はその変更を廃棄します。伝播にポジティブ・ルール・セットとネガティブ・ルール・セットの両方がある場合、ネガティブ・ルール・セットが常に最初に評価されます。
LCRの伝播ルールは次のレベルで指定できます。
表ルールは、特定の表に対するDML変更による行変更またはDDL変更を伝播または廃棄します。サブセット・ルールは、特定の表に対する行変更のサブセットを含む表ルールです。
スキーマ・ルールは、特定のスキーマのデータベース・オブジェクトに対するDML変更による行変更またはDDL変更を伝播または廃棄します。
グローバル・ルールは、ソース・キュー内のDML変更によるすべての行変更またはすべてのDDL変更を伝播または廃棄します。
条件を指定するキュー・サブスクライバによって、システムでルールが生成されます。キューのすべてのサブスクライバ用のルール・セットが組み合されて、サブスクリプションをより効率的にする1つのシステム生成ルール・セットとなります。
伝播は、キュー・ツー・キューまたはキュー・ツー・データベース・リンク（キュー・ツーdblink）が可能です。キュー・ツー・キュー伝播は、独自の排他的な伝播ジョブを使用してメッセージをソース・キューから宛先キューに伝播します。各伝播ジョブには独自の伝播スケジュールがあるため、各キュー・ツー・キュー伝播は個別に管理することができます。複数のキュー・ツー・キュー伝播が同じデータベース・リンクを使用する場合でも、各伝播の無効化、有効化および伝播スケジュールの設定を個別に行うことができます。伝播ジョブについては次に詳しく説明します。
1つのデータベース・リンクは、複数のキュー・ツー・キュー伝播で使用できます。このデータベース・リンクを作成するときのサービス名には、宛先キューを含むデータベースのグローバル名を指定する必要があります。
反対に、キュー・ツーdblink伝播は、同じソース・キューの同じデータベース・リンクを使用するキュー・ツーdblink伝播と伝播ジョブを共有します。このため、これらの伝播は同じ伝播スケジュールを共有し、伝播スケジュールを変更すると、データベース・リンクを使用するソース・キューのすべてのキュー・ツーdblink伝播に影響します。
取得LCRが宛先キューに正常に伝播されるのは、次の両方のアクションが完了した時点です。
他のタイプのメッセージが宛先キューに正常に伝播されるのは、宛先キューへのエンキューがコミットされた時点です。他のタイプのメッセージには、バッファLCR、バッファ・ユーザー・メッセージ、永続LCRおよび永続ユーザー・メッセージがあります。
2つのキュー間でメッセージが正常に伝播されると、宛先キューはそのことを確認します。ソース・キューが複数の宛先キューにメッセージを伝播するように構成されている場合は、各宛先キューがソース・キューにメッセージ伝播の確認を送信し終わるまで、メッセージはソース・キューに残ります。各宛先キューがメッセージの正常な伝播を確認し、ソース・キュー・データベース内のすべてのローカル・コンシューマがメッセージをコンシュームし終わると、ソース・キューはメッセージを削除できます。
この確認システムによって、メッセージが常にソース・キューから宛先キューに確実に伝播されますが、構成によってはソース・キューが最適サイズより大きくなる可能性があります。ソース・キューが大きくなると、システム・グローバル領域（SGA）メモリーの使用量が増加し、ディスク領域の使用量も増加する場合があります。
ソース・キューの拡大には、通常、次の2つの原因があります。
なんらかの理由（ネットワークの問題など）で、メッセージを指定された宛先キューに伝播できない場合、メッセージは宛先キューが使用可能になるまでソース・キューに残ります。この状況がソース・キューの拡大の原因となることがあります。そのため、キューを定期的に監視して問題を早期に検出する必要があります。
取得プロセスまたは同期取得によって取得されたメッセージをソース・キューが複数の宛先キューに伝播しており、1つ以上の宛先データベースが、他のキューよりもはるかに低速でメッセージが正常に伝播されたことを確認する場合を考えます。この場合、低速の宛先データベースでは、高速の宛先データベースによってすでに確認されたメッセージのバックログが作成されるため、ソース・キューが大きくなることがあります。このような環境では、複数の取得プロセスまたは同期取得を作成してソース・データベースでの変更を取得することを検討してください。これによって、あるソース・キューを低速の宛先データベースに、別のソース・キューを高速の宛先データベースに使用できます。
有向ネットワークとは、伝播されるメッセージが宛先データベースに到達する前に1つ以上の中間データベースを経由するネットワークです。メッセージは、中間データベースで適用プロセスによって処理される場合と、処理されない場合があります。Oracle Streamsを使用すると、各宛先データベースに伝播させるメッセージを選択し、メッセージが宛先データベースに到達するまでのルートを指定できます。図3-4に、有向ネットワーク環境の例を示します。
有向ネットワークを使用する利点は、ソース・データベースと宛先データベースと間に物理的なネットワーク接続を必要としないことです。そのため、メッセージをデータベース間で伝播する必要があるが、これらのデータベースを実行しているコンピュータ間にダイレクト・ネットワーク接続がない場合も、1つ以上の中間データベースがソース・データベースを宛先データベースに接続しているかぎり、ネットワークを再構成せずにメッセージを伝播させることができます。
有向ネットワークを使用している場合に、中間サイトが長期間停止されるか、中間サイトが削除されると、ネットワークとOracle Streams環境の再構成が必要になることがあります。
有向ネットワークにおける中間データベースでは、キューによる転送または適用による転送を使用してメッセージを伝播できます。キューによる転送は、中間データベースで転送されるメッセージが中間データベースによって受信されるメッセージであることを意味します。メッセージのソース・データベースは、メッセージが発生したデータベースです。
適用による転送は、中間データベースで転送されるメッセージが、最初に適用プロセスによって処理されることを意味します。このようなメッセージは、中間データベースで取得プロセスまたは同期取得によって再取得されてから転送されます。適用による転送を使用すると、中間データベースがメッセージの新しいソース・データベースになります。メッセージは、中間データベースで生成されたREDOログから取得プロセスによって再取得されるか、中間データベースで構成された同期取得によって再取得されます。
Oracle Streams環境を計画するときには、キューによる転送と適用による転送に次の違いがあることに注意してください。
キューによる転送を使用すると、取得または伝播に伴う変換がなければ、メッセージは変更されずにそのまま有向ネットワークを介して伝播されます。適用による転送を使用すると、メッセージは中間データベースで適用および再取得され、競合解消、適用ハンドラまたは適用変換によって変更される場合があります。
キューによる転送を使用する場合、宛先データベースでは、各ソース・データベースからのメッセージを個別の適用プロセスで適用する必要があります。適用による転送を使用すると、中間データベースでメッセージが再取得されることによって、変更が宛先データベースに到達する時点でソース・データベースの数が減少する場合があるため、宛先データベースに必要な適用プロセスの数が少数で済む可能性があります。
キューによる転送を使用する場合は、ソース・データベースと宛先データベースの間に1つ以上の中間データベースが位置します。適用による転送を使用する場合、メッセージは中間データベースで再取得されるため、メッセージのソース・データベースは、宛先データベースと直接接続している中間データベースと同じでもかまいません。
単一のOracle Streams環境で、キューによる転送と適用による転送を併用できます。
キューによる転送には、適用による転送と比較して次の利点があります。
メッセージが1回のみ取得されるため、パフォーマンスを改善できます。
1つ以上の中間データベースでメッセージが適用および再取得されることがないため、メッセージを生成元データベースから宛先データベースへと伝播させる所要時間が短縮されます。つまり、キューによる転送を使用すると、待機時間を短縮できる場合があります。
メッセージの発生元は、メッセージに含まれているLCRに対してGET_SOURCE_DATABASE_NAMEメンバー・プロシージャを実行すると簡単に判断できます。適用による転送を使用する場合は、メッセージの発生元を判断するために、Oracle Streamsタグおよび適用ハンドラを使用する必要があります。
別々の適用プロセスを使用すると、依存性が低減し、複数の適用コーディネータと適用リーダー・プロセスによって作業が実行されるため、パラレル適用によってスケーラビリティが向上し、スループットが増大します。
1つの中間データベースが停止した場合、キューを再度ルーティングし、取得サイトで開始SCNをリセットして、エンドツーエンドの取得、伝播および適用を再構成できます。
適用による転送を使用すると、使用不可能になった中間データベースから宛先データベースへのダウンストリームでは、この中間データベースのSCN情報が使用されているため、メッセージについてエンドツーエンドの取得、伝播および適用の再構成に必要な作業量が実質的に増大します。このSCN情報がないと、宛先データベースでは変更を正しく適用できません。
適用による転送には、キューによる転送と比較して次の利点があります。
各データベースは、複数のリモート・ソース・データベースではなく、直接接続されているデータベースからのみ変更を適用できるため、Oracle Streams環境の構成が容易です。
中間データベースによって変更が適用される大規模なOracle Streams環境では、適用プロセスが少数で済むため、環境の監視と管理が容易です。変更を適用する中間データベースでは、変更を受信するソース・データベースごとに1つの適.用プロセスが必要です。適用による転送の環境では、中間データベースのソース・データベースは、直接接続されているデータベースのみです。キューによる転送環境では、中間データベースのソース・データベースは、中間データベースに直接接続されているかどうかに関係なく環境内の他のすべてのデータベースです。
|
関連項目:
|
Oracle Streamsを使用すると、データベース間でバイナリ・ファイルを伝播できます。これを行うには、1つ以上のBFILE属性をメッセージ・ペイロードに入れ、メッセージをリモート・キューに伝播します。ペイロードで参照される各BFILEは、メッセージが伝播された後、メッセージの伝播がコミットされる前にリモート・データベースに転送されます。伝播された各BFILEのディレクトリ・オブジェクトとファイル名は保持されますが、ソース・データベースと宛先データベースの異なるディレクトリにディレクトリ・オブジェクトをマップできます。メッセージ・ペイロードは、ANYDATAペイロードにラップされたBFILE、またはANYDATAペイロードにラップされたオブジェクトの1つ以上のBFILE属性になります。
メッセージのペイロードでは、次のものがサポートされません。
1つ以上のBFILE属性を含むVARRAY
1つ以上のBFILE属性を含むANYDATA属性を持つ、ユーザー定義型オブジェクト
Oracle StreamsでのBFILEの伝播には、DBMS_FILE_TRANSFER.PUT_FILEプロシージャと同じ制限があります。
|
関連項目: DBMS_FILE_TRANSFERパッケージを使用したファイルの転送方法の詳細は、Oracle Database管理者ガイドおよびOracle Database PL/SQLパッケージ・プロシージャおよびタイプ・リファレンスを参照 |
Oracle Streams伝播は、Oracle Schedulerを使用して内部的に構成されます。したがって、伝播ジョブは、ソース・キューから宛先キューにメッセージを伝播するジョブです。他のOracle Schedulerジョブと同様に、伝播ジョブには所有者が存在し、必要に応じてスレーブ・プロセス（jnnn）を使用してジョブを実行します。
次のプロシージャでは、これらのプロシージャによって伝播が作成されるときに、伝播ジョブを作成できます。
DBMS_STREAMS_ADMパッケージのADD_GLOBAL_PROPAGATION_RULESプロシージャ
DBMS_STREAMS_ADMパッケージのADD_SCHEMA_PROPAGATION_RULESプロシージャ
DBMS_STREAMS_ADMパッケージのADD_TABLE_PROPAGATION_RULESプロシージャ
DBMS_STREAMS_ADMパッケージのADD_SUBSET_PROPAGATION_RULEプロシージャ
DBMS_PROPAGATION_ADMパッケージのCREATE_PROPAGATIONプロシージャ
このいずれかのプロシージャによって伝播が作成されると、次の場合に新しい伝播ジョブが作成されます。
queue_to_queueパラメータをTRUEに設定した場合、常に伝播に対して新しい伝播ジョブが作成されます。各キュー・ツー・キュー伝播には独自の伝播ジョブが作成されます。ただし、スレーブ・プロセスは複数の伝播ジョブで使用できます。
queue_to_queueパラメータをFALSEに設定した場合、指定されたソース・キューおよびデータベース・リンクの伝播ジョブが存在しない場合に伝播ジョブが作成されます。指定したソース・キューおよびデータベース・リンクの伝播ジョブがすでに存在する場合、新しい伝播は、既存の伝播ジョブを使用し、この伝播ジョブが、同じデータベース・リンクを使用する他のすべてのキュー・ツーdblink伝播と、この伝播ジョブを共有します。
この項の内容は次のとおりです。
|
注意: ソース・キューの所有者が伝播を実行しますが、伝播ジョブの所有者はそれを作成したユーザーです。この2人のユーザーは同一であっても異なっていてもかまいません。 |
伝播スケジュールでは、伝播ジョブでソース・キューから宛先キューにメッセージを伝播する頻度を指定します。各キュー・ツー・キュー伝播には独自の伝播ジョブおよび伝播スケジュールがありますが、同じ伝播ジョブを使用するキュー・ツーdblink伝播では同じ伝播スケジュールが共有されます。
デフォルトの伝播スケジュールは、DBMS_STREAMS_ADMまたはDBMS_PROPAGATION_ADMパッケージのプロシージャによって新しい伝播ジョブが作成されるときに設定されます。
デフォルトのスケジュールのプロパティは次のとおりです。
開始時間はSYSDATE()です。
継続期間は無限を意味するNULLです。
次回の時刻はNULLで、これは現行の期間が終了した直後に伝播が再開されることを意味します。
待機時間は3秒で、これはキューが空になってから伝播ジョブを再発行するまでの待機時間です。したがって、メッセージがエンキューされてから伝播されるまでの伝播期間での最大待機時間（秒単位）です。
DBMS_AQADMパッケージのALTER_PROPAGATION_SCHEDULEプロシージャを使用すると、伝播ジョブのスケジュールを変更できます。伝播ジョブに対する変更は、伝播ジョブを使用するすべての伝播に影響を及ぼします。
システム起動時にSTARTUP RESTRICT文を発行して制限付きセッションが有効化された場合、伝播スケジュールが有効化された伝播ジョブでのメッセージの伝播は行われません。制限付きセッションが無効化されると、有効化されて実行準備が整っている各伝播スケジュールは、使用可能なスレーブ・プロセスがあるときに実行されます。
SQL文ALTER SYSTEM ENABLE RESTRICTED SESSIONによって実行中のデータベースで制限付きセッションが有効化された場合、実行中の伝播ジョブは完了するまで引き続き実行されます。ただし、伝播スケジュールに対して発行された新規の伝播ジョブは開始しません。したがって、有効化されたスケジュールの伝播が最終的に停止する可能性があります。
ソース・データベースでデータベース・オブジェクトのインスタンス化が準備されている場合、オブジェクトに対する変更が取得プロセスによって取得されるデータベースで、Oracle Streamsデータ・ディクショナリが自動的に移入されます。Oracle Streamsデータ・ディクショナリは、ソース・データベースのプライマリ・データ・ディクショナリ内の一部の情報のマルチバージョン・コピーです。Oracle Streamsデータ・ディクショナリでは、ソース・データベースのオブジェクト番号、オブジェクト・バージョン情報および内部列番号が表名、列名および列のデータ型にマップされます。このマッピングによって、メッセージ内部に名前ではなく番号を格納できるため、各取得LCRのサイズが最小に保たれます。
ソース・データベースで取得LCRを伝播するデータベースでルールを評価するために、ソース・データベースにあるOracle Streamsデータ・ディクショナリ内のマッピング情報が必要になります。このマッピング情報を伝播で使用できるように、OracleはOracle Streamsの伝播がある各データベースでマルチバージョンのOracle Streamsデータ・ディクショナリを自動的に移入します。ソース・データベースにあるOracle Streamsデータ・ディクショナリからの関連情報を含む内部メッセージは、ソース・データベースから取得LCRを受信する他のすべてのデータベースに自動的に送信されます。
キュー内のこれらの内部メッセージに含まれるOracle Streamsデータ・ディクショナリ情報は、伝播によって伝播される場合と、伝播されない場合があります。どのOracle Streamsデータ・ディクショナリ情報が伝播されるかは、伝播のルール・セットによって決定されます。伝播が表のOracle Streamsデータ・ディクショナリ情報を検出すると、ソース・データベース名、表名および表の所有者などの特定の情報を使用して、その伝播のルール・セットが評価されます。これらのルール・セットの特定のルールを評価した結果、指定されたデータベースの特定の表に関連するLCRがあると判断された場合、その表のOracle Streamsデータ・ディクショナリ情報が伝播されます。
Oracle Streamsデータ・ディクショナリ情報が宛先キューに伝播されると、宛先キューにエンキューされるだけでなく、宛先キューを含むデータベースのOracle Streamsデータ・ディクショナリにも取り込まれます。したがって、有向ネットワーク構成で宛先キューを読み込む伝播は、Oracle Streamsデータ・ディクショナリの移入を待たずに、LCRを即時に転送できます。この方法により、ソース・データベースのOracle Streamsデータ・ディクショナリは常に、関連するデータベース・オブジェクトの正しい状態を、これらのデータベース・オブジェクトに関連するLCRに反映します。
Oracle Database 11gリリース1（11.1）以上では、効率を向上させるために、取得プロセスは、特定の条件下で伝播受信者に論理変更レコード（LCR）を直接送信する伝播送信者として動作できます。LCRは、伝播受信者によって宛先キューのバッファ・キューにエンキューされた後、適用プロセスによってデキューされます。この構成を、取得と適用の複合と呼びます。
次の各項では、取得と適用の複合についてさらに詳しく説明します。
取得と適用の複合は、取得プロセスおよび適用プロセスが同じデータベースまたは異なるデータベースに存在する場合に使用できます。
取得プロセスと適用プロセスが同じデータベースに存在するときは、次の条件がすべて満たされている場合にのみ、取得と適用の複合を使用できます。
データベースはOracle Database 11g リリース1（11.1）以上である必要があります。
取得プロセスと適用プロセスで同じキューを使用する必要があります。
キューに単一のパブリッシャがあり、それが取得プロセスである必要があります。
キューにバッファ・キューの単一のコンシューマがあり、それが適用プロセスである必要があります。キューに、永続キューのコンシューマである他の1つ以上の適用プロセスがあってもかまいません。
取得プロセスと適用プロセスが異なるデータベースまたは同じデータベースの異なるインスタンスに存在するときは、次の条件がすべて満たされている場合にのみ、取得と適用の複合を使用できます。
取得プロセスが実行されているデータベースと、適用プロセスが実行されているデータベースが、それぞれOracle Database 11g リリース1（11.1）以上である必要があります。
取得プロセス・キューに単一のパブリッシャがあり、それが取得プロセスである必要があります。
取得プロセス・キューと適用プロセス・キューの間で伝播が構成されている必要があります。中間キューは必要ありません（有向ネットワークなし）。
取得プロセス・キューに単一のコンシューマがあり、それが取得プロセス・キューと適用プロセス・キューの間の伝播である必要があります。
適用プロセス・キューに単一のパブリッシャがあり、それが取得プロセス・キューと適用プロセス・キューの間の伝播である必要があります。
適用プロセス・キューに単一のコンシューマがあり、それが適用プロセスである必要があります。キューに、永続キューのコンシューマである他の1つ以上の適用プロセスがあってもかまいません。
取得と適用の複合の要件を満たした後は、取得と適用の複合を使用するために他の構成タスクを実行する必要はありません。取得プロセスが開始されると、取得と適用の複合が使用可能であることが自動的に検出されます。取得プロセスによって伝播受信者との接続が確立された後、取得LCRが伝播受信者に直接送信されます。
取得と適用の複合が使用されていて、構成を変更したために構成が取得と適用の複合の要件を満たさなくなった場合は、取得プロセスによってこの変更が検出され、取得プロセスが再起動します。取得プロセスの再起動後、取得と適用の複合は使用されません。
取得と適用の複合が使用されておらず、構成を変更したために構成が取得と適用の複合の要件を満たすようになった場合は、取得プロセスが再起動したときに、取得と適用の複合が自動的に使用されます。この場合、取得プロセスを手動で再起動する必要があります。自動的には再起動されません。
取得と適用の複合が使用されているかどうかを判断するには、次の動的パフォーマンス・ビューを確認します。
取得プロセスの場合は、V$STREAMS_CAPTUREビューでOPTIMIZATION列が0より大きい場合に取得と適用の複合が使用されます。
適用プロセスの場合は、V$STREAMS_APPLY_READERビューでPROXY_SID列がNULLでない場合に取得と適用の複合が使用されます。
|
関連項目:
|
取得プロセスでは、伝播ルール・セットを使用して、適用プロセスに送信するLCRを決定します。伝播ルール・セットを変更して、送信するLCRを制御できます。また、ルールがTRUEと評価されると、ポジティブ伝播ルール・セットのルールに対して構成されているルールベースの変換が実行されます。
LCRのフローを停止するには、伝播を停止するか、伝播のスケジュールを解除します。LCRのフローを開始するには、伝播を開始またはスケジューリングします。ただし、伝播スケジュールのパラメータの変更は無視されます。また、伝播が取得と適用の複合で置き換えられると、次のビューには伝播に関する情報が表示されません。
DBA_QUEUE_SCHEDULES
USER_QUEUE_SCHEDULES
かわりに、伝播に関する情報について、次のビューを問い合せます。
V$PROPAGATION_SENDER
V$PROPAGATION_RECEIVER
取得と適用の複合が使用される場合は、取得プロセスおよび適用プロセスを通常どおりに管理できます。具体的には、取得プロセスと適用プロセスの動作を次のように制御します。
変更は、取得プロセスによって取得される取得プロセス・ルール・セットを満たす必要があります。
LCRは、適用プロセスによって適用される適用プロセス・ルール・セットを満たす必要があります。
ルールがTRUEと評価されると、取得プロセスまたは適用プロセスのポジティブ・ルール・セットのルールに対して構成されているルールベースの変換が実行されます。
LCRは、必要に応じて適用プロセスの適用ハンドラに送信されます。
適用時に、必要に応じて更新競合解決ハンドラが起動されます。
|
関連項目:
|
単一ソース・レプリケーション環境で取得と適用の複合を使用すると、Oracle Streamsクライアントによって宛先データベースのポイント・イン・タイム・リカバリが自動的に処理されます。Oracle Streamsクライアントには、取得と適用の複合を構成する取得プロセス、伝播および適用プロセスが含まれます。
取得と適用の複合を使用する単一ソース・レプリケーション環境では、次の一般的な手順を使用して、宛先データベースでポイント・イン・タイム・リカバリを実行します。
取得プロセスと適用プロセスを停止し、伝播を無効にします。
宛先データベースでポイント・イン・タイム・リカバリを実行します。
取得プロセスが、以前の時点のアーカイブREDOログ・ファイルにアクセスできることを確認します。
適用プロセスを起動します。
伝播を有効にします。
取得プロセスを起動します。
これらの手順を実行すると、取得プロセスによってその開始SCNが自動的に決定されるため、その他の手順は必要ありません。
|
関連項目: Oracle Streamsレプリケーション環境におけるポイント・イン・タイム・リカバリの実行の詳細は、Oracle Streamsレプリケーション管理者ガイドを参照 |
