| Oracle® Streams概要および管理 11gリリース2 (11.2) B61351-03 |
|
 前 |
 次 |
この付録では、Oracle Streamsと他のOracle Databaseコンポーネントとの連携について説明します。
内容は次のとおりです。
次の項では、Oracle StreamsとOracle Real Application Clusters(Oracle RAC)との連携について説明します。
|
関連項目: Oracle RAC環境におけるOracle Streamsのベスト・プラクティスについては、『Oracle Streamsレプリケーション管理者ガイド』を参照 |
取得プロセスは、Oracle Real Application Clusters(Oracle RAC)環境での変更を取得できます。同じ環境で1つ以上の取得プロセスとOracle RACを使用する場合は、取得プロセスによって取得される変更を含むすべてのアーカイブ・ログは、Oracle RAC環境のすべてのインスタンスで使用可能である必要があります。Oracle RAC環境では、取得プロセスによってすべてのインスタンスによる変更が読み取られます。単一の取得プロセスによって使用されるプロセスは、Oracle RAC環境の単一インスタンスで実行されます。
各取得プロセスは、起動プロシージャまたは停止プロシージャが別のインスタンスで実行されている場合でも、そのANYDATAキューの所有者インスタンスで起動および停止されます。また、現行の所有者インスタンスが使用不可能になった場合、取得プロセスは別のインスタンスに対するキューに従います。キュー自体は、プライマリ・インスタンスとセカンダリ・インスタンスの所有権のルールに従います。
取得プロセスによって使用されるキューを含むキュー表の所有者インスタンスが使用不可能になった場合、キュー所有権がクラスタ内の別のインスタンスに自動的に移動します。さらに、所有者インスタンスが使用不可能になったときに取得プロセスが有効であった場合、取得プロセスは新しい所有者インスタンスで自動的に再起動されます。所有者インスタンスが使用不可能になったときに取得プロセスが無効であった場合、取得プロセスは新しい所有者インスタンスでも無効のままです。
LogMinerではLOG_ARCHIVE_DEST_n初期化パラメータがサポートされており、Oracle Streamsの取得プロセスでは、LogMinerを使用してREDOログから変更が取得されます。1つの宛先からアーカイブ・ログ・ファイルにアクセスできない場合は、ローカル取得プロセスで、アクセス可能な別の宛先からアーカイブ・ログ・ファイルを読み取ることができます。Oracle RACデータベースでは、この機能を使用して、インスタンス間アーカイブ(CIA)を使用することもできます。CIAでは、各インスタンスによってファイルがすべてのインスタンスにアーカイブされます。この方法では、アーカイブ・ログ・ファイルの欠落による差異を検出したり、解決することはできません。このため、この方法は、既存の方法を補完して、アーカイブ・ファイルをすべてのインスタンスで共有可能にする場合にのみ使用できます。
ダウンストリーム取得プロセス環境では、ソース・データベースは、単一インスタンス・データベースまたは複数インスタンスのOracle RACデータベースです。ダウンストリーム・データベースは、ソース・データベースが単一インスタンスか複数インスタンスかに関係なく、単一インスタンスのデータベースまたは複数インスタンスのOracle RACデータベースとして構成できます。
|
関連項目:
|
同期取得は、Oracle Real Application Clusters(Oracle RAC)環境での変更を取得できます。Oracle RAC環境では、同期取得によって、すべてのインスタンスで行われた変更が読み取られます。
Oracle RAC環境での同期取得のパフォーマンスを向上させるには、個別の表セットに対する変更を個別の同期取得で取得する必要があります。たとえば、様々なアプリケーションでデータベース内の異なるセットのデータベース・オブジェクトが使用されている場合は、各アプリケーションのデータベース・オブジェクトに対する変更を取得する個別の同期取得を構成します。この場合、各同期取得で、別々のキューおよびキュー表を使用する必要があります。
取得と適用の複合はOracle Real Application Clusters(Oracle RAC)環境で使用できます。Oracle RAC環境では、取得プロセスおよび適用プロセスは、同じインスタンス、単一のOracle RACデータベース内の異なるインスタンス、または異なるデータベースに存在することができます。取得プロセスおよび適用プロセスが同じデータベースの異なるインスタンスまたは異なるデータベースに存在する場合、取得と適用の複合を使用するには、取得プロセスのキューと適用プロセスのキューの間の伝播を構成する必要があります。
Oracle Real Application Clusters(Oracle RAC)環境で、LCRとユーザー・メッセージをステージングするようにキューを構成できます。Oracle RAC環境では、キューのバッファを使用できるのは所有者インスタンスのみですが、別のインスタンスは、別のキューのバッファを使用できます。バッファ・キューは、キューに関連付けられたシステム・グローバル領域(SGA)メモリーです。
Oracle Streamsのプロセスおよびジョブは、キュー表のプライマリ・インスタンスおよびセカンダリ・インスタンスの指定をサポートしています。これらの指定を使用する場合、プライマリ・インスタンスが使用不可能になると、セカンダリ・インスタンスがキュー表の所有者となります。プライマリ・インスタンスが再度使用可能になると、所有権はプライマリ・インスタンスに戻ります。
プライマリ・インスタンスおよびセカンダリ・インスタンスの指定は、DBMS_AQADMパッケージのALTER_QUEUE_TABLEプロシージャを使用して設定できます。DBA_QUEUE_TABLESデータ・ディクショナリ・ビューは、キュー表の所有者インスタンスに関する情報を示します。キュー表には、複数のキューが含まれている場合があります。この場合、キュー表内の各キューの所有者インスタンスは、キュー表と同じになります。
|
関連項目:
|
伝播は、あるキューからOracle Real Application Clusters(Oracle RAC)環境内の別のキューにメッセージを伝播できます。インスタンスで実行されている伝播ジョブは、そのインスタンスで所有されるキューから宛先キューに論理変更レコード(LCR)を伝播します。
Oracle RACデータベースへの伝播は、データベース・リンクを介して行われます。データベース・リンクは、メッセージを受信予定のキューを所有している宛先インスタンスに接続するように構成する必要があります。
伝播で宛先キューを含むキュー表の所有者インスタンスが使用不可能になると、キューの所有権がクラスタ内の別のインスタンスに自動的に移動します。宛先キューを含むキュー表のプライマリ・インスタンスおよびセカンダリ・インスタンスの両方が使用不可能になると、キューの所有権がクラスタ内の別のインスタンスに自動的に移動します。この場合、プライマリ・インスタンスまたはセカンダリ・インスタンスが再度使用可能になると、所有権は使用可能になったインスタンスに戻ります。
バッファ宛先キューへのキュー・ツー・キュー伝播は、サービスを使用してOracle RAC環境での透過的フェイルオーバーを提供します。つまり、キュー・ツー・キュー伝播の伝播ジョブは、宛先キューを所有するインスタンスに自動的に接続します。キュー・ツー・キュー伝播で使用されるサービスは、常に宛先キューの所有者インスタンスで実行されます。このサービスは、Oracle RACデータベース内のバッファ・キュー用にのみ作成されます。Oracle RACデータベースにバッファリングされたメッセージ機能を使用する予定の場合は、任意のインスタンスでメッセージをバッファ・キューにエンキューできます。キューを所有していないインスタンスにメッセージがエンキューされた場合、メッセージは正しいインスタンスに送信されますが、キューを所有しているインスタンスにメッセージをエンキューする方がより効率的です。このサービスを使用すると、メッセージをバッファ・キューにエンキューする前にキューの所有者インスタンスに接続できます。
キュー・サービスはキューの所有者インスタンスで常に実行しているため、Oracle RACインスタンスが失敗すると、透過的フェイルオーバーが行われます。複数のキュー・ツー・キュー伝播が1つのデータベース・リンクを使用する場合、メッセージを適切な宛先キューに伝播するように各伝播の接続記述が自動的に変わります。
これに対し、キュー・ツーdblink伝播ではサービスを使用しません。伝播で宛先キューを含むOracle RACデータベースの所有者インスタンスが失敗すると、キュー・ツーdblink伝播ではユーザーがデータベース・リンクを再び指す必要があります。伝播ジョブが宛先データベースの正しいインスタンスに接続するようにするには、宛先キューを所有しているインスタンスに接続するようにソース・データベースからのデータベース・リンクを手動で再構成します。再作成されたデータベース・リンクを使用する伝播を変更する必要はありません。
DBA_SERVICESデータ・ディクショナリ・ビューのNAME列に、キューのサービス名が含まれています。DBA_QUEUESデータ・ディクショナリ・ビューのNETWORK_NAME列には、キューのネットワーク名が含まれています。キュー・ツー・キュー伝播のサービスを管理することはできません。これらのサービスはOracleによって自動的に管理されます。キュー・ツーdblink伝播の場合、正しいインスタンスに接続するには、データベース・リンクの接続文字列でネットワーク名をサービス名として使用します。
|
注意: Oracle RAC環境でキューが取得LCRを含む場合、キュー・ツー・キュー伝播を使用してOracle RACの宛先データベースにメッセージを伝播してください。キュー・ツーdblink伝播で取得LCRがOracle RACの宛先データベースに伝播される場合、この伝播は、宛先キューの所有者インスタンスを参照するインスタンス固有のデータベース・リンクを使用する必要があります。このような伝播が他のインスタンスに接続すると、伝播でエラーが発生します。 |
Oracle Streamsの適用プロセスは、Oracle Real Application Clusters(Oracle RAC)環境での変更を適用するように構成できます。各適用プロセスは、開始プロシージャおよび停止プロシージャが別のインスタンスで実行されている場合でも、そのANYDATAキューの所有者インスタンスで開始または停止されます。適用コーディネータ・プロセス、それに対応する適用リーダー・サーバーおよびそのすべての適用サーバーは、単一インスタンスで実行されます。
適用プロセスで使用されるキューが含まれているキュー表の所有者インスタンスが使用不可能になると、キューの所有権は自動的にクラスタ内の別のインスタンスに譲渡されます。また、現行の所有者インスタンスが使用不可能になった場合、適用プロセスは、別のインスタンスに対するキューに従います。キュー自体は、プライマリ・インスタンスとセカンダリ・インスタンスの所有権のルールに従います。また、適用プロセスは、所有者インスタンスが使用不可能になったときに有効だった場合、新しい所有者インスタンスで自動的に起動されます。所有者インスタンスが使用不可能になったときに無効だった場合は、新しい所有者インスタンスでも無効のままになります。
次の項では、Oracle Streamsと透過的データ暗号化との連携について説明します。
|
関連項目: 透過的データ暗号化の詳細は、Oracle Database Advanced Security管理者ガイドを参照 |
ローカル取得プロセスでは、透過的データ暗号化を使用して暗号化されている列に対する変更を取得できます。ダウンストリーム取得プロセスでは、ダウンストリーム・データベースがソース・データベースとウォレットを共有している場合にのみ、暗号化されている列に対する変更を取得できます。ウォレットは、ネットワーク・ファイル・システム(NFS)を介して共有するか、または1つのコンピュータ・システムから別のコンピュータ・システムに手動でコピーできます。ウォレットがダウンストリーム・データベースと共有されている場合は、ダウンストリーム・データベースのsqlnet.oraファイルのENCRYPTION_WALLET_LOCATIONパラメータにウォレットの場所が指定されていることを確認してください。
ダウンストリーム・データベースにウォレットをコピーする場合は、ソース・データベースのウォレットが変更されるたびに、ソース・データベースからダウンストリーム・データベースにウォレットをコピーしてください。ダウンストリーム・データベースのウォレットに対して、レプリケートされた表の暗号化鍵の変更などの操作は実行しないでください。
ローカル取得プロセスまたはダウンストリーム取得プロセスによって取得された行論理変更レコード(行LCR)内の暗号化された列は、行LCRがバッファ・キューにステージングされると復号化されます。透過的データ暗号化が有効になっているデータベース内のディスクに行LCRがオーバーフローした場合、行LCRはディスクに格納されますが、すべての暗号化された列はOracle Streamsによって透過的に暗号化されます。
|
注意: 取得プロセスによって使用されるREDOログが互換性レベル11.0.0以上のデータベースで生成されている場合、取得プロセスでは、暗号化された列のみがサポートされます。互換性レベルは、COMPATIBLE初期化パラメータによって制御されます。 |
同期取得では、透過的データ暗号化を使用して暗号化されている列に対する変更を取得できます。同期取得によって取得された行論理変更レコード(行LCR)内の暗号化された列は、行LCRが永続キューにステージングされている場合は暗号化されたままになります。
明示的取得を使用すると、データベース表で暗号化されている列の行論理変更レコード(行LCR)を作成およびエンキューできます。ただし、行LCRの作成時に列が暗号化されるように指定することはできません。したがって、明示的に取得された行LCRがキューにステージングされると、行LCRのすべての列が復号化されます。
永続キューは、同期取得によって取得された行論理変更レコード(行LCR)を格納できます。これらの行LCRには、透過的データ暗号化を使用して暗号化された列に対する変更を含めることができます。行LCRは、永続キューに格納されている間は暗号化されたままです。明示的に取得された行LCRには、暗号化された列を含めることはできません。
バッファ・キューは、取得プロセスによって取得された変更を含む行LCRを格納できます。これらの行LCRには、透過的データ暗号化を使用して暗号化された列に対する変更を含めることができます。暗号化された列を含む行LCRがバッファ・キューに格納されると、それらの列は復号化されます。行LCRがディスクにオーバーフローした場合に、その行LCRがディスクに格納されている間、Oracle Streamsは透過的に暗号化された列を暗号化します。
伝播では、ネットワーク・データの暗号化を使用して暗号化された列に対する変更を含む行論理変更レコード(行LCR)を伝播できます。伝播によって、暗号化された列とともに行LCRが伝播されると、行LCRがネットワーク上を転送される間に、暗号化された列が復号化されます。必要に応じて、Oracle Advanced Securityの機能を使用して、ネットワーク上でのデータ転送を暗号化できます。
適用プロセスでは、透過的データ暗号化を使用して暗号化された列を含む、暗黙的に取得された行論理変更レコード(行LCR)をデキューおよび処理できます。暗号化された列は、それらの暗号化列を含む行LCRが適用プロセスによってデキューされると復号化されます。復号化された列を含むこれらの行LCRは、カスタム処理のために適用ハンドラに送信するか、または直接適用することができます。行LCRが適用され、変更された表に暗号化された列が含まれている場合、暗号化された列に対する変更は適用時に暗号化されます。
暗号化された列が行LCRに含まれていて、宛先データベースの対応する列が暗号化されていない場合は、preserve_encryption適用プロセス・パラメータによって適用プロセスの動作が制御されます。
preserve_encryptionパラメータがYに設定されているときに、暗号化された列が行LCRに含まれていて、宛先データベースの対応する列が暗号化されていない場合は、適用プロセスでエラーが発生します。エラーが発生すると、行LCRは適用されず、トランザクションのすべての行LCRがエラー・キューに移動されます。
preserve_encryptionパラメータがNに設定されているときに、暗号化された列が行LCRに含まれていて、宛先データベースの対応する列が暗号化されていない場合は、適用プロセスによって行の変更が適用されます。
適用プロセスが、暗黙的に取得された行LCR(暗号化された列を含む)をエラー・キューに移動する場合、行LCRがエラー・キュー内に存在している間は暗号化された列は暗号化されています。行LCRは、取得プロセスおよび同期取得を使用して暗黙的に取得されます。
メッセージ・クライアントは、暗黙的に取得された行LCR(透過的データ暗号化を使用して暗号化された列を含む)をデキューできます。暗号化された列を含む行LCRがメッセージ・クライアントでデキューされるとその列は復号化されます。
Oracle Streamsは、フラッシュバック・データ・アーカイブ内の表をサポートします。取得プロセスは、これらの表に対して行われたデータ操作言語(DML)およびデータ定義言語(DDL)の変更を取得できます。同期取得は、これらの表に対するDMLの変更を取得できます。適用プロセスは、論理変更レコード(LCR)でカプセル化された変更をこれらの表に適用できます。
また、Oracle Streamsの取得プロセスおよび適用プロセスは、次のDDL文もサポートします。
CREATE FLASHBACK ARCHIVE
ALTER FLASHBACK ARCHIVE
DROP FLASHBACK ARCHIVE
FLASHBACK ARCHIVE句を指定したCREATE TABLE
FLASHBACK ARCHIVE句を指定したALTER TABLE
|
注意: Oracle Streamsは、フラッシュバック・データ・アーカイブによって使用される内部表に対して行われた変更を取得または適用しません。 |
|
関連項目:
|
次の項では、Oracle StreamsとRecovery Manager(RMAN)との連携について説明します。
|
関連項目: 『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』 |
RMANを使用すると、Oracle Streamsレプリケーション環境の構成中にデータベース・オブジェクトをインスタンス化することができます。RMANのDUPLICATEおよびCONVERT DATABASEコマンドはデータベース全体をインスタンス化することができ、RMANのTRANSPORT TABLESPACEコマンドは1つの表領域または表領域のセットをインスタンス化することができます。
|
関連項目: インスタンス化のためのRMANの使用については、『Oracle Streamsレプリケーション管理者ガイド』を参照 |
Recovery Manager(RMAN)の一部の削除ポリシーおよびコマンドは、アーカイブREDOログ・ファイルを削除します。RMANのこれらのポリシーまたはコマンドのいずれかを、1つ以上の取得プロセスに対してREDOログ・ファイルを生成するデータベースで使用する場合は、そのRMANのコマンドが取得プロセスで必要となるアーカイブREDOログ・ファイルを削除しないことを確認してください。
次の項では、ローカル取得プロセスおよびダウンストリーム取得プロセスにおけるRMANの削除ポリシーおよびコマンドの動作について説明します
|
関連項目:
|
ローカル取得プロセスが構成されるとき、高速リカバリ領域に余裕があれば、RMANはローカル取得プロセスで必要となるアーカイブREDOログ・ファイルを削除しません。具体的には、RMANは、ローカル取得プロセスの必須チェックポイントSCN以上のシステム変更番号(SCN)値の変更を含むアーカイブREDOログ・ファイルを削除しません。これは、RMANのすべての削除ポリシーおよびDELETEコマンド(DELETE ARCHIVELOGおよびDELETE OBSOLETEを含む)におけるRMANのデフォルトの動作です。
高速リカバリ領域に新しいログ・ファイルを書き込む領域が十分にない場合、RMANは1つ以上のアーカイブREDOログ・ファイルを自動的に削除します。RMANが自動的に削除したアーカイブREDOログ・ファイルがローカル取得プロセスで必要なものであれば、Oracle Databaseによってアラート・ログに警告が書き込まれます。
アーカイブREDOログ・ファイルのバックアップがローカル取得プロセス・データベースで作成される場合は、RMANの次の削除ポリシーをお薦めします。
CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP integer TIMES TO DEVICE TYPE deviceSpecifier;
この削除ポリシーでは、ログ・ファイルが削除対象とみなされるまでにinteger回バックアップされる必要があります。
アーカイブREDOログ・ファイルのバックアップがローカル取得プロセス・データベースで作成されない場合は、推奨される特定の削除ポリシーはありません。デフォルトでは、RMANはローカル取得プロセスで必要となるアーカイブREDOログ・ファイルを削除しません。
ダウンストリーム取得プロセスが、ソース・データベースで行われたデータベースの変更を取得する場合、アーカイブREDOログ・ファイルがソース・データベースからダウンストリーム取得プロセス・データベースに移動されるまで、RMANの削除ポリシーまたはコマンドがそのアーカイブREDOログ・ファイルを削除しないことを確認してください。
アーカイブREDOログ・ファイルを削除するRMANの特定の削除ポリシーおよびコマンドの考慮事項を次に示します。
RMANコマンドCONFIGURE ARCHIVELOG DELETION POLICYは、高速リカバリ領域内のアーカイブREDOログ・ファイルが削除対象となるタイミングを決定する削除ポリシーを設定します。また、この削除ポリシーは、RMANのすべてのDELETEコマンド(DELETE ARCHIVELOGおよびDELETE OBSOLETEを含む)に適用されます。
次の設定は、ソース・データベースでの動作を決定します。
TO SHIPPED TO STANDBYを設定した削除ポリシーは、ログ・ファイルを必要とするダウンストリーム取得プロセス・データベースにそのファイルが移動されるまで、ログ・ファイルを削除しません。これらのログ・ファイルは、ダウンストリーム取得プロセスで処理された場合もあれば、処理されなかった場合もあります。自動削除が発生するのは、高速リカバリ領域に新しいログ・ファイルを書き込む領域が十分にない場合です。
TO APPLIED ON STANDBYを設定した削除ポリシーは、ログ・ファイルを必要とするダウンストリーム取得プロセス・データベースにそのファイルが移動され、ソース・データベースがそのログ・ファイルを適用済とマークするまで、ログ・ファイルを削除しません。ソース・データベースがログ・ファイルを適用済とマークするのは、ソース・データベースのすべてのダウンストリーム取得プロセスの最小必須チェックポイントSCNがログ・ファイル内の最大SCNより大きくなった場合です。
TO BACKED UP integer TIMES TO DEVICE TYPEを設定した削除ポリシーでは、ログ・ファイルが削除対象とみなされるまでに、そのログ・ファイルはinteger回バックアップされる必要があります。ログ・ファイルは、そのファイルを必要とするダウンストリーム取得プロセスで処理されていない場合であっても削除できます。
TO NONEを設定した削除ポリシーは、高速リカバリ領域に余裕がなくなった場合に、ログ・ファイルが、そのファイルを必要とするダウンストリーム取得プロセスで処理されていなくても、そのログ・ファイルを削除できることを意味します。
RMANコマンドDELETE ARCHIVELOGは、次の条件をすべて満たすアーカイブREDOログ・ファイルを削除します。
ログ・ファイルが、DELETE ARCHIVELOGコマンドで指定した条件を満たしている。
CONFIGURE ARCHIVELOG DELETION POLICYに従ってログ・ファイルを削除できる。たとえば、ポリシーにTO SHIPPED TO STANDBYを設定した場合、ログ・ファイルが、そのファイルを必要とするダウンストリーム取得プロセス・データベースに移動されるまで、このコマンドではそのログ・ファイルを削除できません。
この動作は、データベースがマウントまたはオープンされたときに適用されます。
アーカイブREDOログ・ファイルがダウンストリーム取得プロセスで必要な変更を含むために削除されない場合は、RMANによって警告メッセージが表示され、これらのファイルに対する削除操作がスキップされたことが示されます。
RMANコマンドDELETE OBSOLETEは、次の条件をすべて満たすアーカイブREDOログ・ファイルを完全に削除します。
ログ・ファイルが、保存ポリシーに従って不要になっている。
CONFIGURE ARCHIVELOG DELETION POLICYに従ってログ・ファイルを削除できる。たとえば、ポリシーにTO SHIPPED TO STANDBYを設定した場合、ログ・ファイルが、そのファイルを必要とするダウンストリーム取得プロセス・データベースに移動されるまで、このコマンドではそのログ・ファイルを削除できません。
この動作は、データベースがマウントまたはオープンされたときに適用されます。
RMANコマンドBACKUP ARCHIVELOG ALL DELETE INPUTは、アーカイブREDOログ・ファイルをコピーし、バックアップの完了後に元のファイルを削除します。このコマンドでは、次の条件が満たされている場合、ログ・ファイルがダウンストリーム取得プロセス・データベースに移動されるまで、そのログ・ファイルは削除されません。
データベースがマウントまたはオープンされている。
ログ・ファイルが、ダウンストリーム取得プロセスで必要である。
削除ポリシーにTO SHIPPED TO STANDBYを設定している。
アーカイブREDOログ・ファイルがダウンストリーム取得プロセスで必要な変更を含むために削除されない場合は、RMANによって警告メッセージが表示され、これらのファイルに対する削除操作がスキップされたことが示されます。
ダウンストリーム取得プロセスの場合、ソース・データベースにおけるRMANの削除ポリシーを次のいずれかにすることをお薦めします。
アーカイブREDOログ・ファイルのバックアップがソース・データベースで作成される場合、削除ポリシーを次のように設定します。
CONFIGURE ARCHIVELOG DELETION POLICY TO SHIPPED TO STANDBY BACKED UP integer TIMES TO DEVICE TYPE deviceSpecifier;
アーカイブREDOログ・ファイルのバックアップがソース・データベースで作成されない場合、削除ポリシーを次のように設定します。
CONFIGURE ARCHIVELOG DELETION POLICY TO SHIPPED TO STANDBY;
|
注意: ダウンストリーム取得プロセス・データベースでは、ソース・データベースから移動されたアーカイブREDOログ・ファイルは、RMANで管理されません。 |
Oracle Streamsでは、単方向レプリケーション環境におけるリカバリ・カタログのレプリケートがサポートされます。リカバリ・カタログの双方向レプリケーションはサポートされません。
|
関連項目:
|
次のいずれかの方法を使用して分散トランザクションを実行できます。
データベース・リンクを使用して、複数のデータベース内の表を調節された方法で変更します。
DBMS_XA提供のPL/SQLパッケージ、あるいはOCIまたはJDBCライブラリによって公開されているXAインタフェースを使用します。XAインタフェースは、X/Open分散トランザクション処理(DTP)アーキテクチャを実装します。
これらの2つの方法のいずれかを使用した分散トランザクション中にソース・データベースに変更が加えられると、Oracle Streamsはその変更を宛先データベースにレプリケートします。宛先データベースの適用プロセスは、トランザクションがコミットされた後に、そのトランザクションでの変更を適用します。
ただし、分散トランザクションの状態はレプリケートも送信もされません。宛先データベースやクライアント・アプリケーションは、このようなトランザクションのインダウト状態または準備済状態を継承しません。また、Oracle Streamsでは、ソース・データベースでXAトランザクションのために使用されるものと同じグローバル・トランザクション識別子を使用した変更はレプリケートも送信もしません。
XAトランザクションは、次の2つの方法で実行できます。
密結合(異なるXAブランチがロックを共有する)
疎結合(異なるXAブランチがロックを共有しない)
Oracle Streamsでは、疎結合のXAブランチによって行われる変更のレプリケーションは、COMPATIBLE初期化パラメータの値に関係なくサポートされます。Oracle RACソース・データベースで密結合のブランチによって行われる変更のレプリケーションについては、COMPATIBLE初期化パラメータが11.2.0以上に設定されている場合にのみサポートされます。
|
関連項目:
|
Oracle Database Vaultは、管理権限を持つユーザーを含めた任意のユーザーによるOracle Database内の特定のエリアへのアクセスを制限します。Oracle Data Vault環境でOracle Streamsを使用する場合は、次の権限およびロールが必要です。
取得プロセスの作成、適用プロセスの作成および取得プロセスの取得ユーザーの変更というタスクを実行するために、Streams管理者にDV_STREAMS_ADMINロールを付与する必要があります。Streams管理者がこれらのタスクを実行しない場合は、Streams管理者のDV_STREAMS_ADMINロールを取り消すことができます。
適用プロセスの適用ユーザーは、レプリケートされたデータベース・オブジェクトを含むレルムに対する変更の適用が可能である必要があります。レプリケートされたデータベース・オブジェクトは、適用プロセスが変更を適用するオブジェクトです。
レルムに対する適用ユーザーを認可するには、DBMS_MACADM.ADD_AUTH_TO_REALMプロシージャを実行して、レルムおよび適用ユーザーを指定します。たとえば、salesレルムに対し適用ユーザーstrmadminを認可するには、次のプロシージャを実行します。
BEGIN
DBMS_MACADM.ADD_AUTH_TO_REALM(
realm_name => 'sales',
grantee => 'strmadmin');
END;
/
また、次の操作を実行するユーザーにBECOME USERシステム権限を付与する必要があります。
取得プロセスの作成または変更
アウトバウンド・サーバーの作成または変更
インバウンド・サーバーの作成または変更
Oracle Database Vaultがインストールされていない場合は、これらの操作を実行するユーザーにBECOME USERシステム権限を付与する必要はありません。BECOME USERシステム権限は、これらの操作のいずれかを実行した後、必要に応じて、ユーザーから取り消すことができます。
『Oracle Database Vault管理者ガイド』を参照してください。
