| Oracle® Streamsレプリケーション管理者ガイド 12cリリース1 (12.1) B71328-02 |
|
 前 |
 次 |
この章では、Oracle Streamsレプリケーション環境を管理する方法について説明します。
この章の内容は次のとおりです。
Oracle Streamsレプリケーション環境の準備が整ったら、各データベースでOracle Streamsコンポーネントを管理できます。管理作業の1つとしてコンポーネントの管理があります。たとえば、取得処理パラメータを設定して取得プロセスの動作を変更できます。また、管理作業には、Oracle Streamsコンポーネントの監視や問題が発生した場合のトラブルシューティングも含まれます。
次のマニュアルでは、Oracle Streamsを管理する方法について説明されています。
Oracle Streamsコンポーネントを管理する方法の詳細は、『Oracle Streams概要および管理』を参照してください。
Oracle Streamsレプリケーション環境に固有の方法については、『Oracle Streamsレプリケーション管理者ガイド』(このマニュアル)を参照してください。
Oracle Enterprise Manager Cloud Controlを使用してOracle Streamsを管理する方法の詳細は、Oracle Enterprise Manager Cloud ControlのOracle Streamsインタフェースに関するオンライン・ヘルプを参照してください。
ストリームでの論理変更レコード(LCR)の流れは通常、次のようになります。
データベースの変更が取得され、LCRにフォーマットされてエンキューされます。取得プロセスまたは同期取得では、データベースの変更を暗黙的に取得できます。アプリケーションまたはユーザーは、LCRを構成およびエンキューして、データベースの変更を明示的に取得できます。
1つ以上の伝播によって、LCRがOracle Streams環境内の他のデータベースに送信されます。
1つ以上の適用プロセスによって、LCRがデキューおよび処理されます。
ストリームでLCRを追跡するには、次のいずれかの方法を使用します。
取得プロセスによってLCRが取得される場合は、message_tracking_frequency取得プロセス・パラメータを1または他の比較的低い値に設定します。
取得プロセスまたは同期取得によってLCRが取得される場合、またはアプリケーションによってLCRが構成される場合は、DBMS_STREAMS_ADMパッケージのSET_MESSAGE_TRACKINGプロシージャを実行します。
LCRの追跡は、1つ以上の適用プロセスでLCRが正しく適用されていない場合に役立ちます。この場合、LCRを追跡することによって、ストリーム内のLCRの停止場所を判断し、その場所で発生している問題に対応できます。
これらの方法のいずれかを使用してLCRを追跡した後は、V$STREAMS_MESSAGE_TRACKINGビューを使用して、ストリームでLCRの進捗を監視します。ストリームでLCRを追跡することによって、LCRがブロックされている場所を判断できます。LCRの追跡開始後、各LCRに追跡ラベルが含まれます。
message_tracking_frequency取得プロセスのパラメータを使用してLCR追跡が開始された場合、追跡ラベルはcapture_process_name:AUTOTRACKで、capture_process_nameは取得プロセスの名前です。取得プロセス名の最初の20バイトのみが使用され、20バイトを超える場合、残りは切り捨てられます。
SET_MESSAGE_TRACKINGプロシージャを使用すると、現行セッションで生成される各LCRの一部として追跡ラベルを指定できます。この追跡ラベルを使用してV$STREAMS_MESSAGE_TRACKINGビューを問い合せると、ストリームでLCRを追跡し、LCRが各Oracle Streamsクライアントによって処理された状況を確認できます。SET_MESSAGE_TRACKINGプロシージャを使用すると、次のLCRが追跡されます。
取得プロセスまたは同期取得でLCRを取得する場合、取得されるデータベースの変更を行ったセッションに対して追跡ラベルが設定されていると、LCRに自動的に追跡ラベルが含まれます。
ユーザーまたはアプリケーションがLCRを構成する場合、LCRを構成するセッションに対して追跡ラベルが設定されていると、LCRに自動的に追跡ラベルが含まれます。
ストリームでLCRを追跡するには、次の手順を実行します。
LCRの追跡を開始します。
LCRの追跡を開始するには、次の方法があります。
取得プロセスを実行しているデータベースに接続し、message_tracking_frequency取得プロセス・パラメータを1または他の比較的低い値に設定します。取得プロセス・パラメータの設定後、手順2に進みます。
取得プロセスのパラメータの設定については、『Oracle Streams概要および管理』を参照してください。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。
次の手順を実行して、DBMS_STREAMS_ADMパッケージのSET_MESSAGE_TRACKINGプロシージャを実行します。
SQL*Plusで、セッションを開始します。取得プロセスまたは同期取得によって取得されるデータベースの変更に対して追跡ラベルを使用するには、取得プロセスまたは同期取得のソース・データベースに接続します。
メッセージの追跡を開始します。
BEGIN
DBMS_STREAMS_ADM.SET_MESSAGE_TRACKING(
tracking_label => 'TRACK_LCRS');
END;
/
LCRの追跡には、任意のラベルを使用できます。この例では、TRACK_LCRSというラベルを使用しています。
LCRに関する情報がメモリーで追跡され、V$STREAMS_MESSAGE_TRACKING動的パフォーマンス・ビューにLCRに関する情報が移入されます。
セッションでメッセージの追跡が設定されていることを確認するには、追跡ラベルを問い合せます(オプション)。
SELECT DBMS_STREAMS_ADM.GET_MESSAGE_TRACKING() TRACKING_LABEL FROM DUAL;
手順bで指定した追跡ラベルが、この問合せによって戻されます。
TRACKING_LABEL -------------------------------------------------------------------------- TRACK_LCRS
取得プロセスまたは同期取得によって取得される変更をソース・データベースに対して行い、取得プロセスまたは同期取得でストリームを開始するか、または追跡するLCRを構成およびエンキューします。通常、これらのLCRはテスト用としてのみ使用します。たとえば、表に複数の仮行を挿入した後で、それらの行を変更できます。テストが完了したら、これらの行は削除できます。
Oracle Streams環境全体を監視してLCRを追跡します。これを行うには、LCRを処理する各データベースでV$STREAMS_MESSAGE_TRACKINGビューを問い合せます。
たとえば、各データベースで次の問合せを実行します。
COLUMN COMPONENT_NAME HEADING 'Component|Name' FORMAT A10
COLUMN COMPONENT_TYPE HEADING 'Component|Type' FORMAT A12
COLUMN ACTION HEADING 'Action' FORMAT A11
COLUMN SOURCE_DATABASE_NAME HEADING 'Source|Database' FORMAT A10
COLUMN OBJECT_OWNER HEADING 'Object|Owner' FORMAT A6
COLUMN OBJECT_NAME HEADING 'Object|Name' FORMAT A10
COLUMN COMMAND_TYPE HEADING 'Command|Type' FORMAT A7
SELECT COMPONENT_NAME,
COMPONENT_TYPE,
ACTION,
SOURCE_DATABASE_NAME,
OBJECT_OWNER,
OBJECT_NAME,
COMMAND_TYPE
FROM V$STREAMS_MESSAGE_TRACKING;
WHERE句に正しい追跡ラベルを指定していることを確認します。
この問合せによって、各データベースでのLCRの処理状況が表示されます。LCRが宛先データベースに適用されていない場合は、ストリーム内のLCRの停止場所が表示されます。
たとえば、同期取得によるソース・データベースでの出力は、次のようになります。
Component Component Source Object Object Command
Name Type Action Database Owner Name Type
---------- ------------ ----------- ---------- ------ ---------- -------
CAPTURE SYNCHRONOUS Create HUB.EXAMPL HR EMPLOYEES UPDATE
CAPTURE E.COM
CAPTURE SYNCHRONOUS Rule evalua HUB.EXAMPL HR EMPLOYEES UPDATE
CAPTURE tion E.COM
CAPTURE SYNCHRONOUS Enqueue HUB.EXAMPL HR EMPLOYEES UPDATE
CAPTURE E.COM
適用プロセスによる宛先データベースでの出力は、次のようになります。
Component Component Source Object Object Command Name Type Action Database Owner Name Type ---------- ------------ ----------- ---------- ------ ---------- ------- APPLY_SYNC APPLY READER Dequeue HUB.EXAMPL HR EMPLOYEES UPDATE _CAP E.COM APPLY_SYNC APPLY READER Dequeue HUB.EXAMPL HR EMPLOYEES UPDATE _CAP E.COM APPLY_SYNC APPLY READER Dequeue HUB.EXAMPL HR EMPLOYEES UPDATE _CAP E.COM
V$STREAMS_MESSAGE_TRACKINGビューで追加の列を問い合せると、詳細情報を表示できます。たとえば、ACTION_DETAILS列では各アクションに関する詳細情報が提供されます。
メッセージの追跡を停止します。手順1での選択に基づいて、次のいずれかのアクションを完了します。
手順1でmessage_tracking_frequency取得プロセス・パラメータを設定した場合、このパラメータをデフォルト値に戻します。デフォルトでは、200万番目ごとにメッセージが追跡されます。
この取得プロセス・パラメータをデフォルト値に設定するには、取得プロセスを実行しているデータベースに接続し、message_tracking_frequency取得プロセス・パラメータをNULLに設定します。
取得プロセスのパラメータの設定については、『Oracle Streams概要および管理』を参照してください。
現行セッションでメッセージの追跡を開始した場合は、そのセッション内でメッセージの追跡を停止します。
現行セッションでメッセージの追跡を停止するには、SET_MESSAGE_TRACKINGプロシージャでtracking_labelパラメータをNULLに設定します。
BEGIN
DBMS_STREAMS_ADM.SET_MESSAGE_TRACKING(
tracking_label => NULL,
actions => DBMS_STREAMS_ADM.ACTION_MEMORY);
END;
/
|
関連項目: message_tracking_frequency取得プロセス・パラメータの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。 |
次の項では、ストリームの分割方法とマージ方法およびそれらの例を示します。
Oracle Streams接続先の分割およびマージは、次の場合に役立ちます。
単一の取得プロセスで、複数の適用プロセスに送信される変更を取得する場合。
適用プロセスが、取得プロセスによって取得された変更の受入れを停止した場合。たとえば、適用プロセスは、適用プロセスが無効化された場合、適用プロセスが含まれているデータベースが停止した場合、ネットワークの問題が発生した場合、適用プロセスが含まれているデータベースを実行しているコンピュータ・システムが停止した場合、または他のなんらかの理由によって、変更の受入れを停止する場合があります。
これらの条件に該当する場合は、問題が発生した宛先を他の宛先から分割することをお薦めします。宛先を分割する理由は、取得と適用の複合による最適化を、構成で使用しているかどうかによって異なります。
問題が発生した宛先の適用プロセスが取得と適用の複合による最適化の一部である場合、宛先を分割しないと、その宛先が再度使用可能になったときにパフォーマンスが低下します。この場合、すでに分割されている宛先で適用する必要がある変更を、取得プロセスで取得する必要があります。他の宛先では、問題が発生した宛先が遅延を回復するまで、より新しい変更を受信しません。ただし、問題が発生した宛先が分割されている場合は、他の宛先に影響を与えることなく、他の宛先に対する遅延の回復を独立して行うことができます。
宛先の適用プロセスが取得と適用の複合による最適化の一部ではない場合、取得されても問題が発生した宛先キューに送信できない変更はソース・キューに残り、ソース・キューのサイズが増加します。最終的に、ソース・キューの取得論理変更レコード(LCR)はハード・ディスクにオーバーフローし、Oracle Streamsレプリケーション環境のパフォーマンスが低下します。
分割操作およびマージ操作が可能なのは、次のようなタイプのOracle Streamsレプリケーション環境です。
単一の取得プロセスによって取得された変更が、伝播を使用して複数のリモートの宛先へ送信され、リモートの宛先で適用プロセスによって適用される環境。
単一の取得プロセスによって取得された変更が、取得プロセスを実行しているデータベースと同じデータベース上で複数の適用プロセスによってローカルに適用される環境。
単一の取得プロセスによって取得された変更が、伝播を使用して1つ以上のリモートの宛先へ送信され、取得プロセスを実行しているデータベースと同じデータベース上で1つ以上の適用プロセスによってローカルに適用される環境。
ローカルの取得と適用を使用する環境については、取得プロセスと適用プロセスで同じキューを共有している場合、および1つのデータベース内で伝播によって変更が取得プロセスのキューから適用プロセスのキューに送信される場合に、分割操作およびマージ操作が可能です。
図12-1に、伝播を使用して変更を複数の宛先に送信するOracle Streamsレプリケーション環境を示します。この例では、宛先データベースAが停止しています。
次のデータ・ディクショナリ・ビューを使用すると、ストリームで問題が発生しているかどうかを判別できます。
V$BUFFERED_QUEUESビューを問い合せて、バッファ・キュー内のメッセージの数およびハード・ディスクにオーバーフローしたメッセージの数を確認します。
伝播を使用している場合は、DBA_PROPAGATIONおよびV$PROPAGATION_SENDERビューを問い合せて、データベース内の伝播および各伝播の状態を確認します。
このような状況でのパフォーマンスの低下を回避するには、問題が発生したデータベースに送信されているストリームを、取得プロセスから送信されている他のストリームから分割します。問題が解決したら、分割したストリームを、取得プロセスから送信されている他のストリームとマージします。
取得プロセス・パラメータを設定して、問題が発生したストリームを自動的に分割およびマージすることも、問題が発生したストリームを手動で分割およびマージすることもできます。どちらの場合も、DBMS_STREAMS_ADMパッケージのSPLIT_STREAMS、MERGE_STREAMS_JOBおよびMERGE_STREAMSプロシージャを使用します。SPLIT_STREAMSプロシージャは、問題が発生している宛先に対するストリームを、取得プロセスから他の宛先に送信されている他のすべてのストリームから分割します。SPLIT_STREAMSプロシージャは、常に取得プロセスおよびキューをクローニングします。また、SPLIT_STREAMSプロシージャは、変更をリモートの宛先データベースに送信する環境では、伝播をクローニングします。クローニングされたこれらのコンポーネントは、分割されたストリームで使用されます。問題が発生しているストリームは分割されますが、他の宛先に対するストリームは、通常どおり続行されます。
図12-2に、SPLIT_STREAMSプロシージャによって作成される、クローニングされたストリームを示します。
問題が発生した宛先が再度使用可能になると、クローニングされたストリームが、宛先データベースへの取得された変更の送信を再開します。
図12-3に、起動されて実行されている宛先データベースA、および取得データベースで有効になっているクローニングされた取得プロセスを示します。クローニングされたストリームの送信が開始され、元のストリームに対する遅延の回復が開始されます。
クローニングされたストリームが元のいずれかのストリームに対する遅延を回復したら、次のいずれかのプロシージャを実行して、これらのストリームをマージできます。
MERGE_STREAMSプロシージャ: 分割されたストリームを、元の取得プロセスから送信されている他のストリームとマージします。
MERGE_STREAMS_JOBプロシージャ: ストリームがユーザー指定マージしきい値の範囲内かどうかを判別します。ストリームがマージしきい値の範囲内の場合、MERGE_STREAMS_JOBプロシージャはMERGE_STREAMSプロシージャを実行します。ストリームがマージしきい値の範囲外の場合、MERGE_STREAMS_JOBプロシージャは何も実行しません。
MERGE_STREAMS_JOBプロシージャは、ストリームをマージする前にそれらのストリームをマージする準備が整っているかどうかを自動的に確認するため、通常は、MERGE_STREAMSプロシージャを直接実行するのではなく、MERGE_STREAMS_JOBプロシージャを実行することをお薦めします。
図12-4に、MERGE_STREAMSプロシージャの実行結果を示します。Oracle Streamsレプリケーション環境に元のコンポーネントが存在し、すべてのストリームが正常に送信されています。
|
関連項目: 取得と適用の複合の詳細は、『Oracle Streams概要および管理』を参照してください。 |
次の分割およびマージのオプションを使用できます。
split_thresholdおよびmerge_thesholdという2つの取得プロセス・パラメータを設定すると、Oracle Streamsによって自動的に分割操作とマージ操作が実行できます。これらのパラメータが自動の分割とマージを指定するように設定されている場合、Oracle Schedulerジョブは取得プロセスから送信されているストリームを監視します。Oracle Schedulerジョブがストリームの問題を特定した場合、ジョブは問題のあるストリームを取得プロセスから送信されている他のストリームから分割します。分割操作が完了すると、新しいOracle Schedulerマージ・ジョブが、分割されたストリームを監視します。問題が解決した場合、このジョブはストリームを他のストリームとマージします。
split_threshold取得プロセス・パラメータがINFINITEに設定されている場合、自動の分割は無効です。split_thresholdパラメータがINFINITEに設定されていない場合、自動の分割は有効です。自動の分割は、split_thresholdパラメータで指定された秒数の間、適用プロセスとの通信が失われた場合のみ発生します。たとえば、適用プロセスが無効になった場合や宛先データベースが停止した場合に、適用プロセスとの通信が失われます。1つのストリームが他のストリームより遅い速度で変更を処理している場合、自動の分割は発生しません。
ストリームが分割されると、クローニングされた取得プロセスが作成されます。クローニングされた取得プロセスは、構成で取得と適用の複合による最適化を使用しているかどうかに応じて、分割後に有効化または無効化される場合があります。
適用プロセスが取得と適用の複合による最適化の一部である場合、クローニングされた取得プロセスは有効化されます。クローニングされた取得プロセスでは、適用プロセスが有効化されて、適用プロセスとの通信が確立されるまで、変更を取得しません。
適用プロセスが取得と適用の複合による最適化の一部ではない場合、キューでLCRが構築されないようにクローニングされた取得プロセスは無効化されます。適用プロセスが有効化され、クローニングされたストリームが送信可能になれば、クローニングされた取得プロセスを手動で起動できます。
クローニングされた取得プロセスと元の取得プロセスのGV$STREAMS_CAPTUREビューのCAPTURE_MESSAGE_CREATE_TIMEの差(秒単位)が、merge_threshold取得プロセス・パラメータに指定された値以下であれば、分割されたストリームは元のストリームと自動的にマージされます。CAPTURE_MESSAGE_CREATE_TIMEは、取得された変更がREDOログに記録された時間を記録します。この差がこの取得プロセス・パラメータによって指定された値よりも大きい場合、自動のマージは開始されず、値がDBA_STREAMS_SPLIT_MERGEビューのLAG列に記録されます。
ストリームに対する取得プロセスと適用プロセスが異なるデータベース・インスタンスで実行されているときは、そのストリームに対する自動の分割およびマージはいつでも使用できます。ストリームに対する取得プロセスと適用プロセスが同じデータベース・インスタンスで実行されているときは、次のすべての条件を満たす場合のみ、自動の分割およびマージを使用できます。
取得プロセスおよび適用プロセスで同じキューを使用していること。
適用プロセスのエラー・キューにエラーがないこと。
適用プロセスがXStreamアウトバウンド・サーバーではないこと。
適用プロセスが停止していること。
バッファ・キューからハード・ディスクにオーバーフローしているメッセージがないこと。
|
関連項目:
|
SPLIT_STREAMSプロシージャによってストリームを手動で分割した場合、auto_merge_thresholdプロシージャ・パラメータを使用すると、宛先の問題が解決されたときに、ストリームを元の取得プロセスと自動的にマージできます。問題が発生したストリームの適用プロセスで変更の受入れが開始されたら、クローニングされた取得プロセスを起動して、クローニングされた取得プロセスが元の取得プロセスに対する遅延を回復するまで待機できます。クローニングされた取得プロセスがほぼ遅延を回復したら、auto_merge_thresholdパラメータ設定によって、分割されたストリームが自動的にマージされるか、手動でマージされるかが決定されます。
auto_merge_thresholdが正数に設定されている場合、SPLIT_STREAMSプロシージャは、スケジュールが設定されたOracle Schedulerジョブを作成します。このジョブによって、MERGE_STREAMS_JOBプロシージャが実行され、auto_merge_thresholdパラメータに指定された値と等しいマージしきい値が指定されます。ジョブは、作成後にそのスケジュールを変更することができます。
この場合、クローニングされた取得プロセスと元の取得プロセスのGV$STREAMS_CAPTUREビューのCAPTURE_MESSAGE_CREATE_TIMEの差(秒単位)が、auto_merge_thresholdパラメータに指定された値以下であれば、分割されたストリームは元のストリームと自動的にマージされます。CAPTURE_MESSAGE_CREATE_TIMEは、取得された変更がREDOログに記録された時間を記録します。
auto_merge_thresholdがNULLまたは0(ゼロ)に設定されている場合、分割されたストリームは元のストリームと自動的にマージされません。分割されたストリームを元のストリームとマージするには、MERGE_STREAMS_JOBまたはMERGE_STREAMSプロシージャを手動で実行します。
SPLIT_STREAMSおよびMERGE_STREAMSプロシージャは、アクションを直接実行するか、またはアクションを実行するスクリプトを生成してスクリプトの実行時にアクションを実行できます。スクリプトを実行するよりプロシージャを使用してアクションを直接実行する方が簡単で、分割操作またはマージ操作が即時に実行されます。ただし、次の理由でスクリプトを生成することもあります。
ストリームを分割またはマージする前にプロシージャによって実行されるアクションを確認する必要がある。
アクションをカスタマイズするためにスクリプトを変更する必要がある。
たとえば、クローニングされた取得プロセスのルール・セットのルールを変更する場合、スクリプトを変更することがあります。Oracle Streamsレプリケーション環境によっては、ソース・データベースに対して行われた変更のサブセットのみが各宛先データベースに送信され、各宛先データベースが異なる変更のサブセットを受信する場合があります。このような環境では、クローニングされた伝播によって伝播される変更のみを取得するように、クローニングされた取得プロセスのルール・セットを変更できます。
各プロシージャのperform_actionsパラメータは、プロシージャでアクションを直接実行するかどうかを制御します。
この項のいずれかのプロシージャを実行する際にストリームを直接分割またはマージする場合は、perform_actionsパラメータをTRUEに設定します。このパラメータのデフォルト値はTRUEです。
この項のいずれかのプロシージャを実行する際にスクリプトを生成する場合は、perform_actionsパラメータをFALSEに設定し、script_nameおよびscript_directory_objectパラメータを使用してスクリプトの名前と格納場所を指定します。
次の項では、ストリームを分割およびマージする手順について説明します。
これらの例では、Oracle Streamsレプリケーション環境に関して次のことを想定しています。
1つの取得プロセスstrms_captureで、3つの宛先データベースに送信される変更を取得します。
宛先データベースの宛先キューに変更を送信する伝播は、次のとおりです。
strms_prop_a
strms_prop_b
strms_prop_c
キューstreams_queueが、3つすべての伝播のソース・キューです。
strms_prop_a伝播の宛先に問題が発生しています。この伝播は、メッセージを宛先キューに送信できません。
他の2つの伝播(strms_prop_bおよびstrms_prop_c)は、メッセージを正常に伝播しています。
|
関連項目: SPLIT_STREAMSプロシージャおよびMERGE_STREAMSプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。 |
この例を確認する前に、次の項を参照してください。
概念については、「自動の分割およびマージ」を参照してください。
この例のOracle Streamsレプリケーション環境に関する想定については、「Oracle Streamsの分割およびマージの例」を参照してください。
次の手順を実行して、ストリームを自動的に分割およびマージします。
SQL*Plusで、Oracle Streams管理者として取得プロセスを含むデータベースに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。
次のパラメータが自動の分割とマージが有効化されるようにstrms_capture取得プロセスに対して適切に設定されていることを確認します。
split_threshold: このパラメータがINFINITEに設定されていないことを確認します。このパラメータのデフォルトの設定は1800秒です。
merge_threshold: このパラメータが負の値に設定されていないことを確認します。このパラメータのデフォルトの設定は60秒です。
これらのパラメータの設定を確認するには、DBA_CAPTURE_PARAMETERSビューを問い合せます。手順については、『Oracle Streams概要および管理』を参照してください。
手順2で説明した取得プロセス・パラメータのいずれかまたは両方をリセットする必要がある場合は、Oracle Enterprise Manager Cloud ControlまたはDBMS_CAPTURE_ADMパッケージのSET_PARAMETERプロシージャを使用してパラメータをリセットします。SET_PARAMETERプロシージャの使用手順については、『Oracle Streams概要および管理』を参照してください。
DBA_STREAMS_SPLIT_MERGEビューを定期的に監視し、自動の分割操作およびマージ操作が処理中であるかどうかを確認します。
自動の分割が発生すると、取得プロセス、キュー、伝播などの特定のコンポーネントがクローニングされ、それぞれにシステム生成名が付けられます。DBA_STREAMS_SPLIT_MERGEビューには、クローニングされた各コンポーネントの名前などの分割操作およびマージ操作に関する情報が含まれています。
DBA_STREAMS_SPLIT_MERGEビューを問い合せて、ストリームが元の取得プロセスから分割されたかどうかを判別します。
COLUMN ORIGINAL_CAPTURE_NAME HEADING 'Original|Capture|Process' FORMAT A10
COLUMN ACTION_TYPE HEADING 'Action|Type' FORMAT A7
COLUMN STATUS_UPDATE_TIME HEADING 'Status|Update|Time' FORMAT A15
COLUMN STATUS HEADING 'Status' FORMAT A16
COLUMN JOB_NEXT_RUN_DATE HEADING 'Next Job|Run Date' FORMAT A20
SELECT ORIGINAL_CAPTURE_NAME,
ACTION_TYPE,
STATUS_UPDATE_TIME,
STATUS,
JOB_NEXT_RUN_DATE
FROM DBA_STREAMS_SPLIT_MERGE
ORDER BY STATUS_UPDATE_TIME DESC;
ストリームが元の取得プロセスから分割されている場合、出力は次のようになります。
Original Status
Capture Action Update Next Job
Process Type Time Status Run Date
---------- ------- --------------- ---------------- --------------------
DB$CAP MERGE 01-APR-09 06.49 NOTHING TO MERGE 01-APR-09 06.54.29.0
.29.204804 AM 00000 AM -07:00
DB$CAP SPLIT 01-APR-09 06.49 SPLIT DONE 01-APR-09 06.47.59.0
.17.389146 AM 00000 AM -07:00
この出力には、自動の分割が実行されたことが示されています。マージ・ジョブは01-APR-09 06.49.29.204804 AMに実行されましたが、分割されたストリームをマージする準備ができていなかったため、状態にはNOTHING TO MERGEが示されています。SPLIT DONE状態は、01-APR-09 06.49.17.389146 AMの日時にストリームが分割されたことを示しています。
自動の分割の実行後、宛先で発生した問題を解決します。宛先データベースの適用プロセスで、クローニングされた取得プロセスからの変更の受入れが可能になったら、問題は解決しています。問題が解決されたら、Oracle Schedulerジョブは自動のマージを実行します。
クローニングされた取得プロセスが無効になっている場合は、クローニングされた取得プロセスを起動します。クローニングされた取得プロセスが無効になるのは、ストリームが取得と適用の複合による最適化ではない場合のみです。取得プロセスの起動手順については、『Oracle Streams概要および管理』を参照してください。
クローニングされた取得プロセスでは、ルール・セットを満たす変更を取得します。これらの変更は、適用プロセスに送信されます。
この場合、Oracle Schedulerジョブは、スケジュールに従ってMERGE_STREAMS_JOBプロシージャを実行します。MERGE_STREAMS_JOBプロシージャでは、GV$STREAMS_CAPTUREビューのCAPTURE_MESSAGE_CREATE_TIMEを問い合せます。クローニングされた取得プロセスと元の取得プロセスのCAPTURE_MESSAGE_CREATE_TIMEの差がmerge_threshold取得プロセス・パラメータの値以下であれば、MERGE_STREAMS_JOBプロシージャによって、ストリームをマージする準備ができていると判断されます。MERGE_STREAMS_JOBプロシージャは、MERGE_STREAMSプロシージャを自動的に実行してストリームをマージします。
DBA_STREAMS_SPLIT_MERGEビューのLAG列では、クローニングされた取得プロセスが元の取得プロセスに対して遅延している時間(秒単位)を追跡します。次の問合せでは、遅延時間が表示されます。
COLUMN ORIGINAL_CAPTURE_NAME HEADING 'Original Capture Process' FORMAT A25
COLUMN CLONED_CAPTURE_NAME HEADING 'Cloned Capture Process' FORMAT A25
COLUMN LAG HEADING 'Lag' FORMAT 999999999999999
SELECT ORIGINAL_CAPTURE_NAME,
CLONED_CAPTURE_NAME,
LAG
FROM DBA_STREAMS_SPLIT_MERGE
WHERE ACTION_TYPE = 'MERGE';
出力は次のようになります。
Original Capture Process Cloned Capture Process Lag ------------------------- ------------------------- ---------------- DB$CAP CLONED$_DB$CAP_5 2048
この出力には、元の取得プロセスとクローニングされた取得プロセスのCAPTURE_MESSAGE_CREATE_TIME値の間に2,048秒の遅延があることが示されています。クローニングされた取得プロセスがしきい値の範囲内である場合、マージ・ジョブはMERGE_STREAMSプロシージャを開始できます。デフォルトでは、マージしきい値は60秒です。
MERGE_STREAMSプロシージャを実行すると、次のアクションが実行されます。
クローニングされた取得プロセスが停止されます。
元の伝播strms_prop_aが再作成されます。
クローニングされた伝播が削除されます。
クローニングされた取得プロセスが削除されます。
クローニングされたキューが削除されます。
手順4の問合せを定期的に繰り返し、分割操作およびマージ操作を監視します。マージ操作の完了後、この問合せの出力は次のようになります。
Original Status
Capture Action Update Next Job
Process Type Time Status Run Date
---------- ------- --------------- ---------------- --------------------
DB$CAP MERGE 01-APR-09 07.32 NOTHING TO MERGE 01-APR-09 07.37.04.0
.04.820795 AM 00000 AM -07:00
DB$CAP MONITOR 01-APR-09 07.32 MERGE DONE 01-APR-09 07.36.20.0
.04.434925 AM 00000 AM -07:00
DB$CAP SPLIT 01-APR-09 06.49 SPLIT DONE 01-APR-09 06.47.59.0
.17.389146 AM 00000 AM -07:00
この出力には、01-APR-09 07.32.04.434925 AMの日時に、分割されたストリームが元の取得プロセスとマージされたことが示されています。分割されたストリームは残っていないため、次の状態にはNOTHING TO MERGEが示されています。
ストリームがマージされた後は、Oracle Streamsレプリケーション環境に、分割操作およびマージ操作の前と同じコンポーネントが存在するようになります。今後の参照用に、完了した分割操作およびマージ操作に関する情報はDBA_STREAMS_SPLIT_MERGE_HISTに格納されます。
|
関連項目: 自動の分割操作およびマージ操作の監視の詳細は、『Oracle Streams概要および管理』を参照してください。 |
この例を確認する前に、次の項を参照してください。
概念については、「手動の分割および自動のマージ」を参照してください。
この例のOracle Streamsレプリケーション環境に関する想定については、「Oracle Streamsの分割およびマージの例」を参照してください。
この項の例では、手動でストリームを分割し、自動的にマージします。そのため、SPLIT_STREAMSプロシージャのperform_actionsパラメータはTRUEに設定されています。また、この例では、SPLIT_STREAMSプロシージャのauto_merge_thresholdパラメータが正数(60)に設定されているため、ストリームを適切なタイミングで自動的にマージします。
次の手順を実行して、ストリームを直接分割し、自動的にマージします。
SQL*Plusで、Oracle Streams管理者として取得プロセスを含むデータベースに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。
次のプロシージャを実行して、伝播strms_prop_aを介して送信されているストリームを、strms_capture取得プロセスから送信されている他の伝播から分割します。
DECLARE
schedule_name VARCHAR2(30);
job_name VARCHAR2(30);
BEGIN
schedule_name := 'merge_job1_schedule';
job_name := 'merge_job1';
DBMS_STREAMS_ADM.SPLIT_STREAMS(
propagation_name => 'strms_prop_a',
cloned_propagation_name => 'cloned_prop_a',
cloned_queue_name => 'cloned_queue',
cloned_capture_name => 'cloned_capture',
perform_actions => TRUE,
auto_merge_threshold => 60,
schedule_name => schedule_name,
merge_job_name => job_name);
END;
/
このプロシージャを実行すると、次のアクションが実行されます。
新しいキューcloned_queueが作成されます。
cloned_queueキューからstrms_prop_a伝播によって使用されている既存の宛先キューにメッセージを伝播する新しい伝播cloned_prop_aが作成されます。クローニングされた伝播cloned_prop_aでは、元の伝播strms_prop_aと同じルール・セットが使用されます。
取得プロセスstrms_captureが停止されます。
元の伝播strms_prop_aの確認済SCNが問い合されます。確認済SCNとは、伝播によって送信された変更を適用する適用プロセスによって最後に確認されたSCNです。伝播の確認済SCNは、DBA_PROPAGATIONビューのACKED_SCN値に示されます。
新しい取得プロセスcloned_captureが作成されます。cloned_captureの開始SCNは、strms_prop_a伝播の確認済SCNの値に設定されます。クローニングされた取得プロセスcloned_captureでは、元の取得プロセスstrms_captureと同じルール・セットが使用されます。
元の伝播strms_prop_aが削除されます。
開始SCNがstrms_prop_a伝播の確認済SCNの値に設定された、元の取得プロセスstrms_captureが起動されます。
スケジュールmerge_job1_scheduleが設定されたOracle Schedulerジョブmerge_job1が作成されます。ジョブとスケジュールは両方とも、SPLIT_STREAMSプロシージャを実行したユーザーによって所有されます。このスケジュールは、SPLIT_STREAMSプロシージャが完了すると実行が開始されます。初期スケジュールは、システムによって定義されますが、他のOracle Schedulerジョブを変更する場合と同じ方法で変更できます。手順については、『Oracle Database管理者ガイド』を参照してください。
cloned_prop_aの宛先で発生した問題を解決します。宛先データベースの適用プロセスで、クローニングされた取得プロセスからの変更の受入れが可能になったら、問題は解決しています。
Oracle Streams管理者として接続したまま、次のプロシージャを実行して、クローニングされた取得プロセスを起動します。
exec DBMS_CAPTURE_ADM.START_CAPTURE('cloned_capture');
クローニングされた取得プロセスcloned_captureの実行が開始されると、ルール・セットを満たす、確認済SCN以降の変更が取得されます。これらの変更は、cloned_prop_a伝播によって伝播され、宛先データベースの適用プロセスによって処理されます。
この場合、Oracle Schedulerジョブは、スケジュールに従ってMERGE_STREAMS_JOBプロシージャを実行します。MERGE_STREAMS_JOBプロシージャでは、GV$STREAMS_CAPTUREビューのCAPTURE_MESSAGE_CREATE_TIMEを問い合せます。クローニングされた取得プロセスcloned_captureと元の取得プロセスstrms_captureのCAPTURE_MESSAGE_CREATE_TIMEの差が60秒以下であれば、MERGE_STREAMS_JOBプロシージャによって、ストリームをマージする準備ができていると判断されます。MERGE_STREAMS_JOBプロシージャは、MERGE_STREAMSプロシージャを自動的に実行してストリームをマージします。
次の問合せでは、元の取得プロセスおよびクローニングされた取得プロセスのCAPTURE_MESSAGE_CREATE_TIMEが表示されます。
COLUMN CAPTURE_NAME HEADING 'Capture|Name' FORMAT A17 COLUMN STATE HEADING 'State' FORMAT A20 COLUMN CREATE_MESSAGE HEADING 'Last Message|Create Time' SELECT CAPTURE_NAME, STATE, TO_CHAR(CAPTURE_MESSAGE_CREATE_TIME, 'HH24:MI:SS MM/DD/YY') CREATE_MESSAGE FROM V$STREAMS_CAPTURE;
出力は次のようになります。
Capture Last Message Name State Create Time ----------------- -------------------- ----------------- DB$CAP CAPTURING CHANGES 07:22:55 04/01/09 CLONED$_DB$CAP_5 CAPTURING CHANGES 06:50:39 04/01/09
この出力には、元の取得プロセスとクローニングされた取得プロセスのCAPTURE_MESSAGE_CREATE_TIME値の間に30分を超える遅延があることが示されています。クローニングされた取得プロセスがしきい値の範囲内である場合、マージ・ジョブはMERGE_STREAMSプロシージャを開始できます。デフォルトでは、マージしきい値は60秒です。
MERGE_STREAMSプロシージャを実行すると、次のアクションが実行されます。
クローニングされた取得プロセスcloned_captureが停止されます。
伝播strms_prop_aが再作成されます。
クローニングされた伝播cloned_prop_aが削除されます。
クローニングされた取得プロセスcloned_captureが削除されます。
クローニングされたキューcloned_queueが削除されます。
ストリームがマージされた後は、Oracle Streamsレプリケーション環境に、分割操作およびマージ操作の前と同じコンポーネントが存在するようになります。今後の参照用に、完了した分割操作およびマージ操作に関する情報はDBA_STREAMS_SPLIT_MERGE_HISTに格納されます。
この例を確認する前に、次の項を参照してください。
概念については、「手動の分割および生成されたスクリプトによるマージ」を参照してください。
この例のOracle Streamsレプリケーション環境に関する想定については、「Oracle Streamsの分割およびマージの例」を参照してください。
この項の例では、スクリプトを生成して実行し、ストリームを分割およびマージします。そのため、SPLIT_STREAMSプロシージャのperform_actionsパラメータは、FALSEに設定されています。また、この例では、SPLIT_STREAMSプロシージャのauto_merge_thresholdパラメータがNULLに設定されているため、ストリームを適切なタイミングで手動でマージします。
次の手順を実行して、スクリプトを使用し、ストリームを分割およびマージします。
SQL*Plusで、Oracle Streams管理者として取得プロセスを含むデータベースに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。
ディレクトリ・オブジェクトdb_dirが存在しない場合は、プロシージャによって生成されるスクリプトを保持できるようにこのディレクトリ・オブジェクトを作成します。
CREATE DIRECTORY db_dir AS '/usr/db_files';
次のプロシージャを実行して、ストリームを分割するスクリプトを生成します。
DECLARE
schedule_name VARCHAR2(30);
job_name VARCHAR2(30);
BEGIN
DBMS_STREAMS_ADM.SPLIT_STREAMS(
propagation_name => 'strms_prop_a',
cloned_propagation_name => 'cloned_prop_a',
cloned_queue_name => 'cloned_queue',
cloned_capture_name => 'cloned_capture',
perform_actions => FALSE,
script_name => 'split.sql',
script_directory_object => 'db_dir',
auto_merge_threshold => NULL,
schedule_name => schedule_name,
merge_job_name => job_name);
END;
/
このプロシージャを実行すると、split.sqlスクリプトが生成されます。このスクリプトには、伝播strms_prop_aを介して送信されているストリームを、strms_capture取得プロセスから送信されている他の伝播から分割するアクションが含まれています。
db_dirディレクトリ・オブジェクトによって使用されるディレクトリに移動して、テキスト・エディタでsplit.sqlスクリプトをオープンします。
スクリプトを確認し、必要に応じて変更します。
スクリプトを保存してクローズします。
Oracle Streams管理者としてSQL*Plusに接続したままで、スクリプトを実行します。
@/usr/db_files/split.sql
このスクリプトを実行すると、次のアクションが実行されます。
DBMS_STREAMS_ADMパッケージのSET_UP_QUEUEプロシージャが実行され、キューcloned_queueが作成されます。
DBMS_PROPAGATION_ADMパッケージのCREATE_PROPAGATIONプロシージャが実行され、伝播cloned_prop_aが作成されます。この新しい伝播では、cloned_queueキューからstrms_prop_a伝播によって使用されている既存の宛先キューにメッセージが伝播されます。クローニングされた伝播cloned_prop_aでは、元の伝播strms_prop_aと同じルール・セットが使用されます。
CREATE_PROPAGATIONプロシージャによって、original_propagation_nameパラメータがstrms_prop_aに、auto_merge_thresholdパラメータがNULLに設定されます。
DBMS_CAPTURE_ADMパッケージのSTOP_CAPTUREプロシージャが実行され、取得プロセスstrms_captureが停止されます。
元の伝播strms_prop_aの確認済SCNが問い合されます。確認済SCNとは、伝播によって送信された変更を適用する適用プロセスによって最後に確認されたSCNです。伝播の確認済SCNは、DBA_PROPAGATIONビューのACKED_SCN値に示されます。
DBMS_CAPTURE_ADMパッケージのCREATE_CAPTUREプロシージャが実行され、取得プロセスcloned_captureが作成されます。cloned_captureの開始SCNは、strms_prop_a伝播の確認済SCNの値に設定されます。クローニングされた取得プロセスcloned_captureでは、元の取得プロセスstrms_captureと同じルール・セットが使用されます。
DBMS_PROPAGATION_ADMパッケージのDROP_PROPAGATIONプロシージャが実行され、元の伝播strms_prop_aが削除されます。
DBMS_CAPTURE_ADMパッケージのSTART_CAPTUREプロシージャが実行され、開始SCNがstrms_prop_a伝播の確認済SCNの値に設定された、元の取得プロセスstrms_captureが起動されます。
cloned_prop_aの宛先で発生した問題を解決します。宛先データベースの適用プロセスで、クローニングされた取得プロセスからの変更の受入れが可能になったら、問題は解決しています。
Oracle Streams管理者として接続したまま、次のプロシージャを実行して、クローニングされた取得プロセスを起動します。
exec DBMS_CAPTURE_ADM.START_CAPTURE('cloned_capture');
クローニングされた取得プロセスが元の取得プロセスに対する遅延を回復する(またはほぼ回復する)まで、Oracle Streamsレプリケーション環境を監視します。具体的には、各取得プロセスのGV$STREAMS_CAPTUREビューのCAPTURE_MESSAGE_CREATION_TIME列を問い合せます。
次の問合せを実行して、各取得プロセスのCAPTURE_MESSAGE_CREATE_TIMEを定期的に確認します。
SELECT CAPTURE_NAME,
TO_CHAR(CAPTURE_MESSAGE_CREATE_TIME, 'HH24:MI:SS MM/DD/YY')
FROM GV$STREAMS_CAPTURE;
クローニングされた取得プロセスcloned_captureと元の取得プロセスstrms_captureのCAPTURE_MESSAGE_CREATE_TIMEの差が比較的小さくなるまで、次の手順には進まないでください。
次のプロシージャを実行して、ストリームをマージするスクリプトを生成します。
BEGIN
DBMS_STREAMS_ADM.MERGE_STREAMS(
cloned_propagation_name => 'cloned_prop_a',
perform_actions => FALSE,
script_name => 'merge.sql',
script_directory_object => 'db_dir');
END;
/
このプロシージャを実行すると、merge.sqlスクリプトが生成されます。このスクリプトには、伝播cloned_prop_aを介して送信されているストリームを、strms_capture取得プロセスから送信されている他の伝播とマージするアクションが含まれています。
db_dirディレクトリ・オブジェクトによって使用されるディレクトリに移動して、テキスト・エディタでmerge.sqlスクリプトをオープンします。
スクリプトを確認し、必要に応じて変更します。
スクリプトを保存してクローズします。
Oracle Streams管理者としてSQL*Plusに接続したままで、スクリプトを実行します。
@/usr/db_files/merge.sql
このスクリプトを実行すると、次のアクションが実行されます。
DBMS_CAPTURE_ADMパッケージのSTOP_CAPTUREプロシージャが実行され、クローニングされた取得プロセスcloned_captureが停止されます。
DBMS_CAPTURE_ADMパッケージのSTOP_CAPTUREプロシージャが実行され、元の取得プロセスstrms_captureが停止されます。
DBMS_PROPAGATION_ADMパッケージのCREATE_PROPAGATIONプロシージャが実行され、伝播strms_prop_aが再作成されます。
元の取得プロセスstrms_captureが、次の2つのSCN値のうちで小さい方のSCN値から起動されます。
クローニングされた伝播cloned_prop_aの確認済SCN
元の取得プロセスによって取得された変更を伝播する他の伝播(この例では伝播strms_prop_bおよびstrms_prop_c)の最も小さい確認済SCN
strms_capture取得プロセスが起動されると、このプロセスによって取得済の変更が再取得されたり、クローニングされた取得プロセスcloned_captureによって取得済の変更が取得される場合があります。いずれの場合も、関連する適用プロセスによって、重複して受信した変更が破棄されます。
DBMS_PROPAGATION_ADMパッケージのDROP_PROPAGATIONプロシージャが実行され、クローニングされた伝播cloned_prop_aが削除されます。
DBMS_CAPTURE_ADMパッケージのDROP_CAPTUREプロシージャが実行され、クローニングされた取得プロセスcloned_captureが削除されます。
DBMS_STREAMS_ADMパッケージのREMOVE_QUEUEプロシージャが実行され、クローニングされたキューcloned_queueが削除されます。
スクリプトが正常に実行された後は、ストリームがマージされ、Oracle Streamsレプリケーション環境に、分割操作およびマージ操作の前と同じコンポーネントが存在するようになります。今後の参照用に、完了した分割操作およびマージ操作に関する情報はDBA_STREAMS_SPLIT_MERGE_HISTに格納されます。
通常、あるデータベースが別のデータベースのクローンである場合、データベース管理者はそのデータベースのDBIDおよびグローバル名を変更します。V$DATABASE動的パフォーマンス・ビューでDBID列を問い合せると、データベースのDBIDを確認でき、GLOBAL_NAME静的データ・ディクショナリ・ビューを問い合せると、データベースのグローバル名を確認できます。ソース・データベースのDBIDまたはグローバル名を変更すると、そのソース・データベースで発生した変更を取得する既存の取得プロセスは使用不可になります。取得プロセスは、ソース・データベースで発生した変更を取得するローカルの取得プロセスまたはダウンストリームの取得プロセスになることが可能です。ソース・データベースの変更を適用する既存の適用プロセスも、使用不可になります。ただし、伝播ルールを変更する必要がある可能性はありますが、既存の同期取得および伝播を再作成する必要はありません。
DBIDまたはグローバル名を変更したソース・データベースに対する変更を取得プロセスまたは同期取得で取得している場合は、次の手順を実行します。
ソース・データベースを停止します。
STARTUP RESTRICTを使用し、RESTRICTED SESSIONを有効化してソース・データベースを再起動します。
DBMS_CAPTURE_ADMパッケージのDROP_CAPTUREプロシージャを使用して、取得プロセスを削除します。取得プロセスは、ソース・データベースのローカルの取得プロセスか、またはリモート・データベースのダウンストリームの取得プロセスである場合があります。同期取得を削除する必要はありません。
ソース・データベースでALTER SYSTEM SWITCH LOGFILE文を実行します。
ソース・データベースですでに変更が取得されている場合は、このソース・データベースで発生した変更を適用するすべての宛先データベースで、データを手動で再同期化します。まだデータベースで変更が取得されていない場合は、この手順は不要です。
ソース・データベース名を条件として使用しているルールを変更します。必要に応じて、これらのルールでソース・データベース名をソース・データベースの新しいグローバル名に変更します。環境内のローカル・データベースおよびリモート・データベースで、取得プロセス、伝播および適用プロセスのルールを変更する必要がある場合があります。通常、同期取得ルールには、ソース・データベースの条件は含まれていません。
手順3で削除した取得プロセスからの変更を適用する適用プロセスを削除します。適用プロセスを削除するには、DBMS_APPLY_ADMパッケージのDROP_APPLYプロシージャを使用します。同期取得で取得した変更を適用する適用プロセスは、削除する必要はありません。
ソース・データベースの変更を適用する宛先データベースごとに、手順7で削除した適用プロセスを再作成します。各適用プロセスを、削除される前と同じルール・セットに関連付ける必要がある場合があります。手順については、第7章「暗黙的適用の構成」を参照してください。
必要に応じて、手順3で削除した取得プロセスを再作成します。取得プロセスを、手順3で削除した取得プロセスと同じルール・セットに関連付ける必要がある場合があります。手順については、「取得プロセスの構成」を参照してください。
ソース・データベースで、再作成した取得プロセスによって変更が取得されるデータベース・オブジェクトについて、インスタンス化の準備を行います。「ソース・データベースでインスタンス化を行うためのデータベース・オブジェクトの準備」を参照してください。
ソース・データベースの変更を適用する宛先データベースごとに、ソース・データベースの変更を適用するすべてのデータベース・オブジェクトについて、インスタンス化SCNを設定します。手順については、「宛先データベースでのインスタンス化SCNの設定」を参照してください。
ALTER SYSTEM DISABLE RESTRICTED SESSION文を使用し、RESTRICTED SESSIONを無効化します。
ソース・データベースの変更を適用する宛先データベースごとに、手順8で作成した適用プロセスを起動します。
ソース・データベースで、手順9で作成した取得プロセスを起動します。
|
関連項目: DBNEWIDユーティリティを使用してデータベースのDBIDを変更する方法の詳細は、『Oracle Databaseユーティリティ』を参照してください。 |
複数ソース環境とは、共有データに複数のソース・データベースが存在する環境です。複数ソース環境のソース・データベースを現在の時点までリカバリできない場合、この項で説明する方法を使用して、そのソース・データベースを環境内の他のソース・データベースと再同期化できます。データベースを現在の時点までリカバリできない理由には、アーカイブREDOログの破損や、オンラインREDOログ・グループのメディア障害などがあります。
たとえば、ある双方向のOracle Streams環境で、2つのデータベースが、レプリケートされたデータベース・オブジェクトおよびデータを共有していると想定します。この例では、再同期化する必要のあるデータベースをデータベースA、環境内の他のソース・データベースをデータベースBとします。この双方向のOracle Streams環境内のデータベースAを再同期化するには、次の手順を実行します。
データベースBがデータベースAから送信されたすべての変更を適用しているかどうか検証します。データベースBでV$BUFFERED_SUBSCRIBERSデータ・ディクショナリ・ビューを問い合せると、これらの変更を適用する適用プロセスのキュー内に適用されていない変更があるかどうかを判別できます。このような問合せの例については、『Oracle Streams概要および管理』の「各バッファ・キューからLCRをデキューする伝播の表示」の例を参照してください。すべての変更が適用されたら、次の手順に進みます。
DBMS_STREAMS_ADMパッケージのREMOVE_STREAMS_CONFIGURATIONプロシージャを実行して、データベースAからOracle Streams構成を削除します。このプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
データベースBで、データベースAの変更を適用する適用プロセスを削除します。後の手順で適用プロセスを再作成するため、この適用プロセスで使用されているルール・セットは削除しないでください。
「既存の複数ソース環境への新規データベースの追加」の手順を完了し、Oracle Streams環境内にデータベースAを再度追加します。
Point-in-Timeリカバリとは、指定した現在以外の時刻、SCNまたはログ順序番号までデータベースをリカバリすることです。ここでは、Oracle Streamsレプリケーション環境でPoint-in-Timeリカバリを実行する方法について説明します。
|
関連項目: Point-in-Timeリカバリの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。 |
単一ソースのOracle Streamsレプリケーション環境とは、共有データのソース・データベースが1つのみの環境です。単一ソースのOracle Streams環境のソース・データベースでデータベースのPoint-in-Timeリカバリが必要であり、ソース・データベースで生成される変更を取得するすべての取得プロセスが実行されている場合は、これらの取得プロセスを停止してから、リカバリ操作を実行する必要があります。ソース・データベースで生成される変更を取得するローカルの取得プロセス、およびダウンストリームの取得プロセスの両方を停止する必要があります。通常、データベース管理者は、Point-in-Timeリカバリ中にデータベースのログ順序番号をリセットします。ALTER DATABASE OPEN RESETLOGS文は、ログ順序番号をリセットする文の一例です。
この項の手順では、次の特性を持つ単一ソース・レプリケーション環境を想定しています。
ローカル取得プロセスまたはダウンストリーム取得プロセスである取得プロセスstrm01_captureが1つのみ存在します。
グローバル名dest.example.comを持つ宛先データベースが1つのみ存在します。
宛先データベースに、適用プロセスstrm01_applyが1つのみ存在します。
ソース・データベースでPoint-in-Timeリカバリを実行する必要がある場合、宛先データベースで適用されるトランザクションを使用してこの項の手順を実行すると、ソース・データベースでできるかぎり多くのトランザクションをリカバリできます。この項の手順では、ソースのPoint-in-Time SCNより後に宛先データベースで適用されたトランザクションを識別し、ソース・データベースでそれらのトランザクションを実行することを想定しています。
|
注意: 単一ソースのOracle Streamsレプリケーション環境でPoint-in-Timeリカバリを実行する場合は、適用プロセス・パラメータcommit_serializationをFULLに設定することをお薦めします。 |
単一ソースのOracle Streamsレプリケーション環境のソース・データベースでPoint-in-Timeリカバリを実行するには、次の手順を実行します。
ソース・データベースでPoint-in-Timeリカバリを実行します(実行済でない場合)。後の手順で必要になるため、Point-in-TimeリカバリSCNをメモします。
ソース・データベースが制限付きモードになっていることを確認します。
取得プロセスを実行するデータベースに接続し、取得プロセスで使用するルール・セットを表示します。
取得プロセスで使用するルール・セットを表示するには、次の問合せを実行します。
COLUMN CAPTURE_NAME HEADING 'Capture|Process|Name' FORMAT A15
COLUMN RULE_SET_OWNER HEADING 'Positive|Rule Owner' FORMAT A15
COLUMN RULE_SET_NAME HEADING 'Positive|Rule Set' FORMAT A15
COLUMN NEGATIVE_RULE_SET_OWNER HEADING 'Negative|Rule Owner' FORMAT A15
COLUMN NEGATIVE_RULE_SET_NAME HEADING 'Negative|Rule Set' FORMAT A15
SELECT CAPTURE_NAME,
RULE_SET_OWNER,
RULE_SET_NAME,
NEGATIVE_RULE_SET_OWNER,
NEGATIVE_RULE_SET_NAME
FROM DBA_CAPTURE;
取得プロセスで使用するルール・セットをメモします。手順12で新規の取得プロセスにこれらのルール・セットを指定する必要があります。
宛先データベースに接続し、適用プロセスで使用するルール・セットを表示します。
取得プロセスで使用するルール・セットを表示するには、次の問合せを実行します。
COLUMN APPLY_NAME HEADING 'Apply|Process|Name' FORMAT A15
COLUMN RULE_SET_OWNER HEADING 'Positive|Rule Owner' FORMAT A15
COLUMN RULE_SET_NAME HEADING 'Positive|Rule Set' FORMAT A15
COLUMN NEGATIVE_RULE_SET_OWNER HEADING 'Negative|Rule Owner' FORMAT A15
COLUMN NEGATIVE_RULE_SET_NAME HEADING 'Negative|Rule Set' FORMAT A15
SELECT APPLY_NAME,
RULE_SET_OWNER,
RULE_SET_NAME,
NEGATIVE_RULE_SET_OWNER,
NEGATIVE_RULE_SET_NAME
FROM DBA_APPLY;
適用プロセスで使用するルール・セットをメモします。手順kで新規の適用プロセスにこれらのルール・セットを指定する必要があります。
DBMS_CAPTURE_ADMパッケージのSTOP_CAPTUREプロシージャを使用して、取得プロセスを停止します。
ソース・データベースで、データ・ディクショナリの構築を実行します。
SET SERVEROUTPUT ON
DECLARE
scn NUMBER;
BEGIN
DBMS_CAPTURE_ADM.BUILD(
first_scn => scn);
DBMS_OUTPUT.PUT_LINE('First SCN Value = ' || scn);
END;
/
手順12で必要になるため、戻されたSCN値をメモします。
宛先データベースで、適用プロセスのキューに含まれるソース・データベースからのすべてのトランザクションが適用されるまで待機します。これらのトランザクションが適用されると、適用プロセスはアイドル状態になります。V$STREAMS_APPLY_READERおよびV$STREAMS_APPLY_SERVERの両方で、STATE列を問い合せることができます。両方のビューで適用プロセスの状態がIDLEになってから、次の手順に進む必要があります。
宛先データベースで問合せを実行して、適用されたトランザクションの最大SCNを判断します。
適用プロセスが実行中の場合は、次の問合せを実行します。
SELECT HWM_MESSAGE_NUMBER FROM V$STREAMS_APPLY_COORDINATOR WHERE APPLY_NAME = 'STRM01_APPLY';
適用プロセスが無効化されている場合は、次の問合せを実行します。
SELECT APPLIED_MESSAGE_NUMBER FROM DBA_APPLY_PROGRESS WHERE APPLY_NAME = 'STRM01_APPLY';
後の手順で必要になるため、問合せで戻される最大適用SCNをメモします。
手順8で取得した最大適用SCNが、手順1でメモしたPoint-in-TimeリカバリSCNより小さい場合は、手順10に進みます。手順8で取得した最大適用SCNが、手順1でメモしたPoint-in-TimeリカバリSCN以上の場合は、適用プロセスは、Point-in-TimeリカバリSCNの後で、ソース・データベースからのいくつかのトランザクションを適用しており、次の手順を実行する必要があります。
ソース・データベースで、Point-in-Time SCNの後に適用されたトランザクションを手動で実行します。これらのトランザクションをソース・データベースで実行する場合は、トランザクションが取得プロセスによって取得されないようにセッションのOracle Streamsタグを設定していることを確認します。Oracle Streamsセッション・タグが設定されていないと、これらの変更が宛先データベースに循環される場合があります。手順については、「現行セッションのOracle Streamsタグの管理」を参照してください。
ソース・データベースで、制限付きセッションを無効化します。
手順8で取得した最大適用SCNが、手順1でメモしたPoint-in-TimeリカバリSCNより小さい場合、適用プロセスは、Point-in-TimeリカバリSCNの後で、ソース・データベースからのどのトランザクションも適用していません。この場合は、次の手順を実行する必要があります。
ソース・データベースで、制限付きセッションを無効化します。
宛先データベースで適用プロセスが実行中であることを確認します。
DBMS_CAPTURE_ADMパッケージのSET_PARAMETERプロシージャを使用して、元の取得プロセスのmaximum_scn取得プロセス・パラメータを、Point-in-TimeリカバリSCNに設定します。
元の取得プロセスの開始SCNを、適用プロセスの最も古いSCNに設定します。実行中の適用プロセスの最も古いSCNを判断するには、宛先データベースで、V$STREAMS_APPLY_READER動的パフォーマンス・ビューのOLDEST_SCN_NUM列を問い合せます。取得プロセスの開始SCNを設定するには、DBMS_CAPTURE_ADMパッケージのALTER_CAPTUREプロシージャを実行する際にstart_scnパラメータを指定します。
次のプロシージャを実行して、取得プロセスがアラート・ログに情報を書き込むことを確認します。
BEGIN
DBMS_CAPTURE_ADM.SET_PARAMETER(
capture_name => 'strm01_capture',
parameter => 'write_alert_log',
value => 'Y');
END;
/
DBMS_CAPTURE_ADMパッケージのSTART_CAPTUREプロシージャを使用して、元の取得プロセスを起動します。
DBA_CAPTUREデータ・ディクショナリ・ビューのCAPTURED_SCN列を問い合せて、元の取得プロセスがmaximum_scn設定値までのすべての変更を取得していることを確認します。問合せで戻される値がmaximum_scn値以上である場合、取得プロセスは自動的に停止します。取得プロセスが停止したら、次の手順に進みます。
アラート・ログでLAST_ENQUEUE_MESSAGE_NUMBERの値を検索します。後の手順で必要になるため、この値をメモします。
宛先データベースで、すべての変更が適用されるまで待機します。宛先データベースで次の問合せを実行すると、適用プロセスstrm01_applyで適用される変更を監視できます。
SELECT DEQUEUED_MESSAGE_NUMBER
FROM V$STREAMS_APPLY_READER
WHERE APPLY_NAME = 'STRM01_APPLY' AND
DEQUEUED_MESSAGE_NUMBER = last_enqueue_message_number;
手順hでアラート・ログから検出したLAST_ENQUEUE_MESSAGE_NUMBERを、問合せの最後の行のlast_enqueue_message_number に代入します。この問合せが行を戻す場合、取得データベースからのすべての変更は宛先データベースで適用されています。
適用プロセスのリーダー・サーバーおよび各適用サーバーの状態がIDLEになっていることも確認します。たとえば、適用プロセスstrm01_applyに次の問合せを実行します。
SELECT STATE FROM V$STREAMS_APPLY_READER WHERE APPLY_NAME = 'STRM01_APPLY'; SELECT STATE FROM V$STREAMS_APPLY_SERVER WHERE APPLY_NAME = 'STRM01_APPLY';
どちらの問合せでもIDLEが戻ったら、次の手順に進みます。
宛先データベースで、DBMS_APPLY_ADMパッケージのDROP_APPLYプロシージャを使用して、適用プロセスを削除します。
宛先データベースで、新規の適用プロセスを作成します。新規の適用プロセスでは、元の適用プロセスと同じキューおよびルール・セットが使用される必要があります。
宛先データベースで、DBMS_APPLY_ADMパッケージのSTART_APPLYプロシージャを使用して、新規の適用プロセスを起動します。
DBMS_CAPTURE_ADMパッケージのDROP_CAPTUREプロシージャを使用して、元の取得プロセスを削除します。
DBMS_CAPTURE_ADMパッケージのCREATE_CAPTUREプロシージャを使用して新規の取得プロセスを作成し、手順11で削除した取得プロセスと置き換えます。手順6でデータ・ディクショナリの構築によって戻されたSCNを、first_scnおよびstart_scnの両方のパラメータに指定します。新規の取得プロセスでは、元の取得プロセスと同じキューおよびルール・セットが使用される必要があります。
DBMS_CAPTURE_ADMパッケージのSTART_CAPTUREプロシージャを使用して、新規の取得プロセスを起動します。
複数ソース環境とは、共有データに複数のソース・データベースが存在する環境です。複数ソースのOracle Streams環境のソース・データベースでデータベースのPoint-in-Timeリカバリが必要な場合、環境内の他のソース・データベースを使用して、Point-in-Timeリカバリ後にリカバリ対象のソース・データベースに対して行われた変更を再取得できます。
たとえば、複数ソースのOracle Streams環境で、あるソース・データベースが時刻T2に使用不可になり、それ以前の時刻T1までのPoint-in-Timeリカバリを実行する場合があります。T1までリカバリされると、リカバリ対象のデータベースでT1からT2の間に実行されたトランザクションは、リカバリ済のデータベースで失われます。ただし、リカバリ対象のデータベースが使用不可になる前に、これらのトランザクションが他のソース・データベースに伝播され、適用されていたと想定します。この場合、この他のソース・データベースを使用して、リカバリ済のデータベースに失われた変更をリストアできます。
具体的には、Point-in-Timeリカバリ後にリカバリ対象のデータベースに対して行われた変更をリストアするには、取得プロセスを構成してこれらの変更を他のソース・データベースのREDOログから再取得し、それらの変更を再取得したデータベースからリカバリ済のデータベースに伝播によって伝播して、リカバリ済のデータベースの適用プロセスで適用します。
他のソース・データベースで発生し、T1からT2の間にリカバリ対象のデータベースで適用された変更も失われているため、それらの変更をリカバリする必要があります。これを行うには、他のソース・データベースで取得プロセスを変更して、それ以前のSCNから変更の取得を開始します。このSCNは、リカバリ対象のデータベースの適用プロセスの最も古いSCNです。
リカバリ済のデータベースに失われた変更をリストアするには、次のSCN値が必要です。
Point-in-Time SCN: リカバリ対象のデータベースのPoint-in-TimeリカバリのSCN。
インスタンス化SCN: 変更が再適用されている間に、リカバリ済のデータベースでリカバリに含まれていた各データベース・オブジェクトに設定する必要があるインスタンス化SCNのSCN値。他のソース・データベースでは、このSCN値は、他のソース・データベースで適用され、リカバリ済のデータベースで失われた最初のトランザクションのコミットSCNより小さい値に相当します。
開始SCN: 他のソース・データベースで変更を再取得するために作成される取得プロセスに設定する開始SCNのSCN値。このSCN値は、他のソース・データベースの適用プロセスが、リカバリ済のデータベースで失われたトランザクションの適用を開始した最も古いSCNに相当します。この取得プロセスは、そのソース・データベース用に他のソース・データベースを使用するローカルの取得プロセスまたはダウンストリームの取得プロセスである場合があります。
最大SCN: 失われた変更を再取得するために作成される取得プロセスのmaximum_scnパラメータに設定する必要があるSCN値。取得プロセスは、このSCN値に達した時点で変更の取得を停止します。他のソース・データベースの現行のSCNが、この値に使用されます。
リカバリ対象のデータベースでPoint-in-Timeリカバリを実行する際に、Point-in-Time SCNをメモする必要があります。DBMS_STREAMS_ADMパッケージのGET_SCN_MAPPINGプロシージャを使用すると、他の必要なSCN値を判断できます。
|
関連項目: GET_SCN_MAPPINGプロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。 |
Oracle Streams環境の宛先データベースでデータベースのPoint-in-Timeリカバリが必要な場合は、Point-in-Timeリカバリ後に適用された取得済の変更を再適用する必要があります。
関連する取得プロセスごとに、次のいずれかの方法を選択して、Oracle Streams環境の宛先データベースでPoint-in-Timeリカバリを実行できます。
宛先データベースで適用される変更を取得する既存の取得プロセスについて、開始SCNをリセットします。
宛先データベースで再適用する必要のある変更を取得するように、新規の取得プロセスを作成します。
新規の取得プロセスを作成するよりも、既存の取得プロセスの開始SCNをリセットする方が簡単です。ただし、複数の宛先データベースで適用される変更が取得プロセスによって取得されると、Point-in-Timeリカバリを実行していないデータベースも含め、すべての宛先データベースに変更が再送信されます。変更がすでに宛先データベースで適用されている場合、その変更は適用プロセスで廃棄されますが、複数の宛先データベースに変更を再送信するために必要なネットワーク・リソースとコンピュータ・リソースを、使用しないようにすることが必要な場合があります。この場合は、リカバリ済の宛先データベースにのみ変更を伝播するように、新規の取得プロセスと新規の伝播を作成して一時的に使用できます。
ここでは、次の各タスクの手順について説明します。
Point-in-Timeリカバリを実行した宛先データベースに複数の適用プロセスがある場合は、この項で説明するタスクの1つを適用プロセスごとに実行してください。
リカバリ中の宛先データベースに関して、次のいずれかの条件がTRUEである場合、どちらの方法も使用できません。
伝播では、永続LCRが宛先データベースに伝播されます。いずれの方法でも、宛先データベースでは、永続LCRではなく取得LCRのみが再適用されます。
有向ネットワーク構成では、宛先データベースは取得プロセスからのLCRをその他のデータベースに伝播させる目的で使用されますが、宛先データベースにはこの取得プロセスからのLCRは適用されません。
宛先データベースの適用プロセスの最も古いメッセージ番号が、この適用プロセス用の変更を取得する取得プロセスの先頭SCNより小さい値です。宛先データベースで次の問合せを実行すると、各適用プロセスの最も古いメッセージ番号(最も古いSCN)が表示されます。
SELECT APPLY_NAME, OLDEST_MESSAGE_NUMBER FROM DBA_APPLY_PROGRESS;
ソース・データベースで次の問合せを実行すると、各取得プロセスの先頭SCNが表示されます。
SELECT CAPTURE_NAME, FIRST_SCN FROM DBA_CAPTURE;
対象の開始SCNを含むアーカイブ・ログ・ファイルが使用不可になっています。
環境でこれらのいずれかの条件がTRUEである場合、この項で説明している方法は使用できません。かわりに、すべての宛先データベースでデータを手動で再同期化する必要があります。
|
注意: 単一ソースのレプリケーション環境で取得と適用の複合を使用している場合に宛先データベースでPoint-in-Timeリカバリを実行すると、Oracle Streamsの取得プロセスは、再起動時に変更を取得する場所を自動的に検出するため、追加の手順は必要ありません。詳細は、『Oracle Streams概要および管理』を参照してください。 |
|
関連項目: 取得プロセスに関連するSCN値および有向ネットワークの詳細は、『Oracle Streams概要および管理』を参照してください。 |
Point-in-Timeリカバリを実行するために、既存の取得プロセスの開始SCNをリセットするように決定した場合は、次の手順を実行します。
複数ソースのOracle Streams環境で、宛先データベースがソース・データベースでもある場合は、「複数ソース環境におけるPoint-in-Timeリカバリの実行」の手順を実行します。
ソース・データベースのソース・キューから宛先データベースの宛先キューに変更を伝播させる伝播を削除します。伝播を削除するには、DBMS_PROPAGATION_ADMパッケージのDROP_PROPAGATIONプロシージャを使用します。
有向ネットワークを使用しており、ソース・データベースと宛先データベースの間に中間データベースがある場合は、ソース・データベースの伝播を含め、宛先データベースへのパスに含まれる各中間データベースで伝播を削除します。
削除する伝播で使用されているルール・セットは削除しないでください。
既存の取得プロセスが、宛先データベースで構成されるダウンストリーム取得プロセスである場合、手順3でPoint-in-Timeリカバリを実行すると、ダウンストリーム取得プロセスは宛先データベースと同じ時点にリカバリされます。この場合、この項の手順3より後の手順は不要です。必要なREDOログ・ファイルは取得プロセスで使用可能であることに注意してください。
|
注意: 適切な伝播を削除する必要があります。無効化するのみでは不十分です。手順7で伝播を再作成しますが、この時点で削除すると、取得プロセスの開始SCNをリセットした後に作成されたLCRのみが確実に伝播されます。 |
|
関連項目: 有向ネットワークの詳細は、『Oracle Streams概要および管理』を参照してください。 |
宛先データベースでPoint-in-Timeリカバリを実行します。
宛先データベースで、適用プロセスについてソース・データベースからの最も古いメッセージ番号(最も古いSCN)を問い合せます。次に、問合せ結果をメモします。最も古いメッセージ番号とは、適用する必要があると思われる最も古いシステム変更番号(SCN)です。
宛先データベースで次の問合せを実行すると、各適用プロセスの最も古いメッセージ番号が表示されます。
SELECT APPLY_NAME, OLDEST_MESSAGE_NUMBER FROM DBA_APPLY_PROGRESS;
DBMS_CAPTURE_ADMパッケージのSTOP_CAPTUREプロシージャを使用して、既存の取得プロセスを停止します。
既存の取得プロセスの開始SCNをリセットします。
既存の取得プロセスの開始SCNをリセットするには、DBMS_CAPTURE_ADMパッケージのALTER_CAPTUREプロシージャを実行し、start_scnパラメータを手順4の問合せでメモした値に設定します。たとえば、取得プロセスstrm01_captureの開始SCNを値829381993にリセットするには、次のALTER_CAPTUREプロシージャを実行します。
BEGIN
DBMS_CAPTURE_ADM.ALTER_CAPTURE(
capture_name => 'strm01_capture',
start_scn => 829381993);
END;
/
ソース・データベースと宛先データベースの間で有向ネットワークを使用していない場合は、DBMS_PROPAGATION_ADMパッケージのCREATE_PROPAGATIONプロシージャを使用して、変更をソース・キューから宛先キューに伝播させる新規の伝播を作成します。伝播の作成時には、元の伝播で使用していたルール・セットを指定します。
有向ネットワークを使用しており、ソース・データベースと宛先データベースの間に中間データベースがある場合は、ソース・データベースの伝播を含め、宛先データベースへのパスに含まれる各中間データベースで、新規の伝播を作成します。
DBMS_CAPTURE_ADMパッケージのSTART_CAPTUREプロシージャを使用して、既存の取得プロセスを起動します。
Point-in-Timeリカバリを実行するために取得プロセスを作成するように決定した場合は、次の手順を実行します。
複数ソースのOracle Streams環境で、宛先データベースがソース・データベースでもある場合は、「複数ソース環境におけるPoint-in-Timeリカバリの実行」の手順を実行します。
ソース・データベースと宛先データベースの間で有向ネットワークを使用していない場合は、ソース・データベースのソース・キューから宛先データベースの宛先キューに変更を伝播させる伝播を削除します。伝播を削除するには、DBMS_PROPAGATION_ADMパッケージのDROP_PROPAGATIONプロシージャを使用します。
有向ネットワークを使用しており、ソース・データベースと宛先データベースの間に中間データベースがある場合は、最後の中間データベースと宛先データベースの間でLCRを伝播する伝播を削除します。他の中間データベースやソース・データベースでは、伝播を削除する必要はありません。
|
注意: 適切な伝播を削除する必要があります。伝播を無効化するのみでは不十分です。 |
|
関連項目: 有向ネットワークの詳細は、『Oracle Streams概要および管理』を参照してください。 |
宛先データベースでPoint-in-Timeリカバリを実行します。
宛先データベースで、適用プロセスについてソース・データベースからの最も古いメッセージ番号(最も古いSCN)を問い合せます。次に、問合せ結果をメモします。最も古いメッセージ番号とは、適用する必要があると思われる最も古いシステム変更番号(SCN)です。
宛先データベースで次の問合せを実行すると、各適用プロセスの最も古いメッセージ番号が表示されます。
SELECT APPLY_NAME, OLDEST_MESSAGE_NUMBER FROM DBA_APPLY_PROGRESS;
DBMS_STREAMS_ADMパッケージのSET_UP_QUEUEプロシージャを使用して、取得プロセスで使用するキューをソース・データベースに作成します。
有向ネットワークを使用しており、ソース・データベースと宛先データベースの間に中間データベースがある場合は、ソース・データベースの新規キューを含め、宛先データベースへのパスに含まれる各中間データベースでキューを作成します。宛先データベースでは新規キューを作成しないでください。
ソース・データベースと宛先データベースの間で有向ネットワークを使用していない場合は、DBMS_PROPAGATION_ADMパッケージのCREATE_PROPAGATIONプロシージャを使用して、変更を手順5で作成したソース・キューから宛先キューに伝播させる新規の伝播を作成します。伝播の作成時には、元の伝播で使用していたルール・セットを指定します。
有向ネットワークを使用しており、ソース・データベースと宛先データベースの間に中間データベースがある場合は、ソース・データベースから最初の中間データベースへの伝播を含め、宛先データベースへのパスに含まれる各中間データベースで伝播を作成します。これらの伝播では、手順7で作成する取得プロセスによって取得された変更が、手順5で作成したキュー間で伝播されます。
DBMS_CAPTURE_ADMパッケージのCREATE_CAPTUREプロシージャを使用して、ソース・データベースで新規の取得プロセスを作成します。source_queueパラメータを手順5で作成したローカル・キューに設定し、start_scnパラメータを手順4の問合せでメモした値に設定します。元の取得プロセスで使用していたルール・セットも指定します。元の取得プロセスで使用していたルール・セットによって、リカバリした宛先データベースに送信する必要のない変更が取得される場合は、一部のルールを元のルール・セットと共有するようにカスタマイズした小型のルール・セットを作成して使用できます。
DBMS_CAPTURE_ADMパッケージのSTART_CAPTUREプロシージャを使用して、手順7で作成した取得プロセスを起動します。
リカバリ後のデータベースの適用プロセスの最も古いメッセージ番号が、ソース・データベースの元の取得プロセスの取得番号に近づいた時点で、DBMS_CAPTURE_ADMパッケージのSTOP_CAPTUREプロシージャを使用して元の取得プロセスを停止します。
宛先データベースでは、次の問合せを使用すると、適用プロセスについてソース・データベースからの最も古いメッセージ番号を判断できます。
SELECT APPLY_NAME, OLDEST_MESSAGE_NUMBER FROM DBA_APPLY_PROGRESS;
ソース・データベースでは、次の問合せを使用すると、元の取得プロセスの取得番号を判断できます。
SELECT CAPTURE_NAME, CAPTURE_MESSAGE_NUMBER FROM V$STREAMS_CAPTURE;
リカバリ後のデータベースの適用プロセスの最も古いメッセージ番号が、ソース・データベースの元の取得プロセスの取得番号を超えた時点で、手順7で作成した新規の取得プロセスを削除します。
ソース・データベースと宛先データベースの間で有向ネットワークを使用していない場合は、手順6で作成した新規の伝播を削除します。
有向ネットワークを使用しており、ソース・データベースと宛先データベースの間に中間データベースがある場合は、ソース・データベースの新規の伝播を含め、宛先データベースへのパスに含まれる各中間データベースで新規の伝播を削除します。
ソース・データベースと宛先データベースの間で有向ネットワークを使用していない場合は、手順5で作成したキューを削除します。
有向ネットワークを使用しており、ソース・データベースと宛先データベースの間に中間データベースがある場合は、ソース・データベースの新規キューを含め、宛先データベースへのパスに含まれる各中間データベースで新規キューを削除します。宛先データベースではキューを削除しないでください。
ソース・データベースと宛先データベースの間で有向ネットワークを使用していない場合は、ソース・データベースの元のソース・キューから宛先データベースの宛先キューに変更を伝播させる伝播を作成します。伝播を作成するには、DBMS_PROPAGATION_ADMパッケージのCREATE_PROPAGATIONプロシージャを使用します。伝播の作成時には、元の伝播で使用していたルール・セットを指定します。
有向ネットワークを使用しており、ソース・データベースと宛先データベースの間に中間データベースがある場合は、最後の中間データベースから宛先データベースへの伝播を再作成します。これは、手順2で削除した伝播です。
手順9で停止した取得プロセスを起動します。
Oracle Flashback Queryを使用すると、履歴データを表示および修正できます。特定の時刻またはシステム変更番号(SCN)におけるデータベースに問合せを実行できます。単一ソースのOracle Streamsレプリケーション環境では、レプリケートされたデータベース・オブジェクトが同じであると予測する過去の時点のソース・データベースと宛先データベースでフラッシュバック問合せを使用できます。
ソース・データベースと宛先データベースで対応するSCNに対して問合せを実行すると、ソース・データベースで実行されたレプリケート・オブジェクトへのすべての変更が、宛先データベースに適用されているかどうかを判断できます。宛先データベースに適用エラーが発生している場合、フラッシュバック問合せによって、エラー発生時のレプリケート・オブジェクトの状態が表示されます。この情報は、エラーの原因と、エラーの最適な訂正方法を判断するために役立ちます。
各データベースでフラッシュバック問合せを実行すると、表の対応するSCNに特定の行が存在するかどうかを確認することもできます。対応するSCNの表データが一致しない場合、レプリケーション環境に問題があります。
問合せを実行するには、Oracle Streamsレプリケーション環境が次の条件を満たしている必要があります。
レプリケーション環境は単一ソース環境であり、レプリケート・オブジェクトへの変更が1つのデータベースのみで取得される。
Streamsのレプリケート・オブジェクトに対して変更が行われていない。つまり、変換、サブセット・ルール(行の移行)または適用ハンドラによって、レプリケート・オブジェクトのLCRが変更されていない。
宛先データベースのレプリケート・オブジェクトに対して、DMLまたはDDLの変更が行われていない。
ソース・データベースと宛先データベースの両方がOracle Flashbackを使用するように構成されており、両方のデータベースのOracle Streams管理者がDBMS_FLASHBACKパッケージのサブプログラムを実行する権限を持っている。
UNDO表領域に、各データベースで問合せを実行するために十分な情報が含まれている。Oracle Flashbackの機能では、自動UNDO管理システムを使用して、トランザクションの履歴データとメタデータが取得されます。各データベースのUNDO_RETENTION初期化パラメータは、フラッシュバック問合せを実行するために十分大きい値に設定されている必要があります。
Oracle Streamsレプリケーションは非同期であるため、フラッシュバック問合せで過去の時間を使用することはできません。ただし、DBMS_STREAMS_ADMパッケージのGET_SCN_MAPPINGプロシージャを使用することによって、ソース・データベースのSCNに対応する宛先データベースのSCNを判断することができます。
次の手順では、ソース・データベースでのフラッシュバック問合せのSCNがわかっていると想定しています。このSCNを使用して、宛先データベースでのフラッシュバック問合せの対応するSCNを判断できます。この問合せを実行するには、次の手順を実行します。
宛先データベースで、フラッシュバック問合せ対象のおおまかな時間のアーカイブREDOログ・ファイルがデータベースで使用可能であることを確認します。GET_SCN_MAPPINGプロシージャを実行する場合、このREDOログ・ファイルが使用可能である必要があります。
SQL*Plusで、Oracle Streams管理者として宛先データベースに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。
GET_SCN_MAPPINGプロシージャを実行します。この例では、ソース・データベースのSCNが52073983であり、ソース・データベースからの変更を適用する適用プロセスの名前がstrm01_applyであると想定しています。
SET SERVEROUTPUT ON
DECLARE
dest_scn NUMBER;
start_scn NUMBER;
dest_skip DBMS_UTILITY.NAME_ARRAY;
BEGIN
DBMS_STREAMS_ADM.GET_SCN_MAPPING(
apply_name => 'strm01_apply',
src_pit_scn => '52073983',
dest_instantiation_scn => dest_scn,
dest_start_scn => start_scn,
dest_skip_txn_ids => dest_skip);
IF dest_skip.count = 0 THEN
DBMS_OUTPUT.PUT_LINE('No Skipped Transactions');
DBMS_OUTPUT.PUT_LINE('Destination SCN: ' || dest_scn);
ELSE
DBMS_OUTPUT.PUT_LINE('Destination SCN invalid for Flashback Query.');
DBMS_OUTPUT.PUT_LINE('At least one transaction was skipped.');
END IF;
END;
/
有効な接続先SCNが戻されたら、手順4に進みます。
適用プロセスで1つ以上のトランザクションがスキップされたために、宛先SCNがフラッシュバック問合せで有効ではない場合は、適用プロセス・パラメータcommit_serializationがDEPENDENT_TRANSACTIONSに設定され、非依存トランザクションが順不同で適用されています。戻されたdest_instantiation_scnの後に宛先データベースでコミットされたsrc_pit_scnより小さいソース・コミットSCNを持つトランザクションが1つ以上存在しています。したがって、指定したソースSCNのソース・データベースと宛先データベースの表は異なる可能性があります。別のソースSCNを選択して、手順1から再度実行できます。
ソースSCNを使用して、ソース・データベースでフラッシュバック問合せを実行します。
手順3で戻されたSCNを使用して、宛先データベースでフラッシュバック問合せを実行します。
|
関連項目:
|
DBMS_STREAMS_ADMパッケージのRECOVER_OPERATIONプロシージャを使用して、次の操作からのリカバリを行うことができます。
次を使用した分割操作およびマージ操作
split_thresholdおよびmerge_threshold取得プロセス・パラメータによって起動される自動の分割操作およびマージ操作。
DBMS_STREAMS_ADMパッケージのSPLIT_STREAMSおよびMERGE_STREAMS_JOBプロシージャを使用する分割操作およびマージ操作
DBMS_STREAMS_ADMパッケージのMAINTAIN_CHANGE_TABLEプロシージャによって実行される変更表構成操作
DBMS_STREAMS_ADMパッケージにある次のプロシージャによって実行されるレプリケーション構成操作
MAINTAIN_GLOBAL
MAINTAIN_SCHEMAS
MAINTAIN_SIMPLE_TTS
MAINTAIN_TABLES
MAINTAIN_TTS
PRE_INSTANTIATION_SETUPおよびPOST_INSTANTIATION_SETUP
操作に関する情報は、操作の処理中に次のデータ・ディクショナリ・ビューに格納されます。
DBA_RECOVERABLE_SCRIPT
DBA_RECOVERABLE_SCRIPT_HIST
DBA_RECOVERABLE_SCRIPT_PARAMS
DBA_RECOVERABLE_SCRIPT_BLOCKS
DBA_RECOVERABLE_SCRIPT_ERRORS
|
注意: perform_actionsパラメータをFALSEに設定していずれかの構成プロシージャを実行し、スクリプトを使用してOracle Streamsレプリケーション環境を構成した場合、これらのデータ・ディクショナリ・ビューは移入されず、RECOVER_OPERATIONプロシージャを操作に使用できません。 |
操作が正常に完了すると、操作に関するメタデータはDBA_RECOVERABLE_SCRIPTビューからDBA_RECOVERABLE_SCRIPT_HISTビューに移動されます。その他のビュー(DBA_RECOVERABLE_SCRIPT_PARAMS、DBA_RECOVERABLE_SCRIPT_BLOCKSおよびDBA_RECOVERABLE_SCRIPT_ERRORS)では、操作に関する情報は30日間保存された後に自動的に削除されます。
操作でエラーが発生した場合、DBMS_STREAMS_ADMパッケージのRECOVER_OPERATIONプロシージャを使用して、操作のロールフォワード、操作のロールバックまたは操作に関するメタデータの削除を実行できます。具体的には、RECOVER_OPERATIONプロシージャのoperation_modeパラメータに次のオプションを使用できます。
FORWARD: 障害が発生した時点から操作の完了が試行されます。このオプションを指定する前に、DBA_RECOVERABLE_SCRIPT_ERRORSビューにレポートされたエラーの原因となった条件を訂正します。
また、FORWARDオプションを使用してエラーの原因の詳細を取得することもできます。そのためには、SQL*PlusでSET SERVEROUTPUT ONを実行し、さらに適切なスクリプトIDを指定してRECOVER_OPERATIONプロシージャを実行します。RECOVER_OPERATIONプロシージャを実行すると、エラーの原因となったアクション、エラー番号およびエラー・メッセージが表示されます。
ROLLBACK: 操作によって実行されたすべてのアクションがロールバックされます。ロールバックが成功すると、このオプションは操作に関するメタデータをDBA_RECOVERABLE_SCRIPTビューからDBA_RECOVERABLE_SCRIPT_HISTビューに移動します。他のビューでは、操作に関する情報は30日間保存されます。
PURGE: 操作をロールバックせずに、操作に関するメタデータがDBA_RECOVERABLE_SCRIPTビューからDBA_RECOVERABLE_SCRIPT_HISTビューに移動されます。他のビューでは、操作に関する情報は30日間保存されます。
リカバリ操作の完了後、操作に関する情報はDBA_RECOVERABLE_SCRIPT_HISTビューに格納されます。STATUS列には、リカバリ操作ごとにEXECUTEDまたはPURGEDが表示されます。
|
注意: RECOVER_OPERATIONプロシージャを実行するには、両方のデータベースがOracle Database 10g リリース2以上のデータベースである必要があります。 |
|
関連項目:
|
ここでは、エラーの発生によってMAINTAIN_SCHEMASプロシージャが停止する例について説明します。取得データベースでの実行中に次のプロシージャでエラーが発生したと想定します。
BEGIN
DBMS_STREAMS_ADM.MAINTAIN_SCHEMAS(
schema_names => 'hr',
source_directory_object => 'SOURCE_DIRECTORY',
destination_directory_object => 'DEST_DIRECTORY',
source_database => 'dbs1.example.com',
destination_database => 'dbs2.example.com',
perform_actions => TRUE,
dump_file_name => 'export_hr.dmp',
capture_queue_table => 'rep_capture_queue_table',
capture_queue_name => 'rep_capture_queue',
capture_queue_user => NULL,
apply_queue_table => 'rep_dest_queue_table',
apply_queue_name => 'rep_dest_queue',
apply_queue_user => NULL,
capture_name => 'capture_hr',
propagation_name => 'prop_hr',
apply_name => 'apply_hr',
log_file => 'export_hr.clg',
bi_directional => FALSE,
include_ddl => TRUE,
instantiation => DBMS_STREAMS_ADM.INSTANTIATION_SCHEMA);
END;
/
次の手順を実行して、問題を診断し、操作をリカバリします。
SQL*Plusで、Oracle Streams管理者として取得データベースに接続します。
SQL*Plusでデータベースに接続する手順については、『Oracle Database管理者ガイド』を参照してください。
次の問合せを実行して、操作のSCRIPT_ID値を判断します。
SELECT SCRIPT_ID FROM DBA_RECOVERABLE_SCRIPT ORDER BY CREATION_TIME DESC;
この問合せでは、エラーが発生したのは最新の構成操作であると想定しています。したがって、問合せで複数のSCRIPT_IDが戻される場合は、リストで最初に表示されるSCRIPT_IDを使用します。
DBA_RECOVERABLE_SCRIPT_ERRORSデータ・ディクショナリ・ビューを問い合せてエラーがないかどうかを判別し、手順2で戻されたSCRIPT_IDをWHERE句に指定します。
たとえば、SCRIPT_IDがF73ED2C9E96B27B0E030578CB10B2424である場合は、次の問合せを実行します。
COLUMN SCRIPT_ID HEADING 'Script ID' FORMAT A35 COLUMN BLOCK_NUM HEADING 'Block|Number' FORMAT 999999 COLUMN ERROR_MESSAGE HEADING 'Error Message' FORMAT A33 SELECT BLOCK_NUM, ERROR_MESSAGE FROM DBA_RECOVERABLE_SCRIPT_ERRORS WHERE SCRIPT_ID = 'F73ED2C9E96B27B0E030578CB10B2424';
この問合せでは、次の出力が戻されます。
Block
Number Error Message
------- ---------------------------------
12 ORA-39001: invalid argument value
手順2で戻されたスクリプトIDおよび手順3で戻されたブロック番号をDBA_RECOVERABLE_SCRIPT_BLOCKSデータ・ディクショナリ・ビューで問い合せて、エラーが発生したブロックに関する情報を取得します。
たとえば、スクリプトIDがF73ED2C9E96B27B0E030578CB10B2424、ブロック番号が12の場合は、次の問合せを実行します。
COLUMN FORWARD_BLOCK HEADING 'Forward Block' FORMAT A50
COLUMN FORWARD_BLOCK_DBLINK HEADING 'Forward Block|Database Link' FORMAT A13
COLUMN STATUS HEADING 'Status' FORMAT A12
SET LONG 10000
SELECT FORWARD_BLOCK,
FORWARD_BLOCK_DBLINK,
STATUS
FROM DBA_RECOVERABLE_SCRIPT_BLOCKS
WHERE SCRIPT_ID = 'F73ED2C9E96B27B0E030578CB10B2424' AND
BLOCK_NUM = 12;
この出力には、次の情報が表示されます。
FORWARD_BLOCK列には、指定したブロック内のプロシージャによって実行されたアクションの詳細が表示されます。必要に応じて、出力をファイルにスプールします。この例では、ブロック12のFORWARD_BLOCK列にデータ・ポンプ・エクスポートのコードが含まれています。
FORWARD_BLOCK_DBLINK列には、ブロックが実行されたデータベースが表示されます。この例では、エラーの発生時にデータ・ポンプ・エクスポートがDBS1.EXAMPLE.COMで実行されていたため、ブロック12のFORWARD_BLOCK_DBLINK列にDBS1.EXAMPLE.COMが表示されます。
STATUS列には、ブロック実行の状態が表示されます。この例では、ブロック12のSTATUS列にはERRORが表示されます。
オプションで、取得データベースでSET SERVEROUTPUT ONを指定してRECOVER_OPERATIONプロシージャを実行し、エラーの詳細を表示します。
SET SERVEROUTPUT ON
BEGIN
DBMS_STREAMS_ADM.RECOVER_OPERATION(
script_id => 'F73ED2C9E96B27B0E030578CB10B2424',
operation_mode => 'FORWARD');
END;
/
サーバー出力をオンにすると、エラーの原因となったアクションが再度実行され、そのアクションとこれにより生じたエラーが表示されます。
前述の手順で生成された出力を解析し、問題を診断します。手順3で戻された出力には、次の情報が提供されます。
構成操作の一意識別子はF73ED2C9E96B27B0E030578CB10B2424です。この値は、SCRIPT_IDフィールドに戻されたRAW値です。
問合せによって1つの行のみが戻されたため、実行中のOracle Streams構成プロシージャは1つのみです。問合せによって複数の行が戻された場合、DBA_RECOVERABLE_SCRIPTおよびDBA_RECOVERABLE_SCRIPT_PARAMSビューを問い合せて、その構成操作に該当するスクリプトIDを判別します。
ORA-39001エラーの原因は、『Oracle Databaseエラー・メッセージ』ではユーザーが指定したAPIパラメータのタイプまたは値範囲が不適切であると示されています。DBMS_DATAPUMP.GET_STATUSによって提供される後続のメッセージに、エラーの詳細が説明されます。
DBA_RECOVERABLE_SCRIPT_BLOCKSビューを問い合せると、データ・ポンプ・エクスポート中にエラーが発生したことが示されます。
問合せの出力には、MAINTAIN_SCHEMASプロシージャでデータ・ポンプ・エラーが発生したことが示されています。MAINTAIN_SCHEMASプロシージャのinstantiationパラメータがDBMS_STREAMS_ADM.INSTANTIATION_SCHEMAに設定されていたことに注意してください。この設定は、MAINTAIN_SCHEMASプロシージャによってデータ・ポンプ・エクスポート/インポートを使用してインスタンス化が実行されることを意味します。データ・ポンプ・エクスポート・ダンプ・ファイルが、エクスポート/インポートを完了するために生成されます。
通常、データ・ポンプ・エラーは次のいずれかの条件が原因で発生します。
エクスポート・ダンプ・ファイルの格納に使用される1つ以上のディレクトリ・オブジェクトが存在しない。
プロシージャを実行しているユーザーが、指定されたディレクトリ・オブジェクトに対するアクセス権を持っていない。
プロシージャによって生成されたエクスポート・ダンプ・ファイルと同じ名前のエクスポート・ダンプ・ファイルが、source_directory_objectまたはdestination_directory_objectパラメータに指定されたディレクトリにすでに存在する。
取得データベースでDBA_RECOVERABLE_SCRIPT_PARAMSデータ・ディクショナリ・ビューを問い合せて、MAINTAIN_SCHEMASプロシージャの実行中に指定されたディレクトリ・オブジェクトの名前を判別します。
COLUMN PARAMETER HEADING 'Parameter' FORMAT A30
COLUMN VALUE HEADING 'Value' FORMAT A45
SELECT PARAMETER,
VALUE
FROM DBA_RECOVERABLE_SCRIPT_PARAMS
WHERE SCRIPT_ID = 'F73ED2C9E96B27B0E030578CB10B2424';
この問合せでは、次の出力が戻されます。
Parameter Value ------------------------------ --------------------------------------------- SOURCE_DIRECTORY_OBJECT SOURCE_DIRECTORY DESTINATION_DIRECTORY_OBJECT DEST_DIRECTORY SOURCE_DATABASE DBS1.EXAMPLE DESTINATION_DATABASE DBS2.EXAMPLE CAPTURE_QUEUE_TABLE REP_CAPTURE_QUEUE_TABLE CAPTURE_QUEUE_OWNER STRMADMIN CAPTURE_QUEUE_NAME REP_CAPTURE_QUEUE CAPTURE_QUEUE_USER APPLY_QUEUE_TABLE REP_DEST_QUEUE_TABLE APPLY_QUEUE_OWNER STRMADMIN APPLY_QUEUE_NAME REP_DEST_QUEUE APPLY_QUEUE_USER CAPTURE_NAME CAPTURE_HR APPLY_NAME APPLY_HR PROPAGATION_NAME PROP_HR INSTANTIATION INSTANTIATION_SCHEMA BI_DIRECTIONAL TRUE INCLUDE_DDL TRUE LOG_FILE export_hr.clg DUMP_FILE_NAME export_hr.dmp SCHEMA_NAMES HR
source_directory_objectパラメータに指定されたディレクトリ・オブジェクトがソース・データベースに存在し、destination_directory_objectパラメータに指定されたディレクトリ・オブジェクトが宛先データベースに存在していることを確認します。これらのディレクトリ・オブジェクトが存在するかどうかをチェックするには、DBA_DIRECTORIESデータ・ディクショナリ・ビューを問い合せます。
この例では、SOURCE_DIRECTORYディレクトリ・オブジェクトがソース・データベースに存在せず、DEST_DIRECTORYディレクトリ・オブジェクトが宛先データベースに存在していないことを想定しています。エクスポート・ダンプ・ファイルに使用されるディレクトリ・オブジェクトが存在していなかったため、データ・ポンプ・エラーが発生しました。
SQL文CREATE DIRECTORYを使用して、ソース・データベースおよび宛先データベースに、必要なディレクトリ・オブジェクトを作成します。手順については、「必要なディレクトリ・オブジェクトの作成」を参照してください。
取得データベースでRECOVER_OPERATIONプロシージャを実行します。
BEGIN
DBMS_STREAMS_ADM.RECOVER_OPERATION(
script_id => 'F73ED2C9E96B27B0E030578CB10B2424',
operation_mode => 'FORWARD');
END;
/
構成を完了するには、script_idパラメータが手順3で判別した値に設定され、operation_modeパラメータがFORWARDに設定されていることに注意してください。また、RECOVER_OPERATIONプロシージャは、構成プロシージャが実行されたデータベースで実行する必要があります。
