12 Oracle Streamsレプリケーションの管理
12.1 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インタフェースに関するオンライン・ヘルプを参照してください。
12.2 ストリームでのLCRの追跡
ストリームでの論理変更レコード(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;
手順1.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パッケージおよびタイプ・リファレンス』を参照してください。
12.3 Oracle Streamsの接続先の分割およびマージ
次の項では、ストリームの分割方法とマージ方法およびそれらの例を示します。
12.3.1 Oracle Streamsの分割およびマージ
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概要および管理』を参照してください。
12.3.2 分割およびマージのオプション
次の分割およびマージのオプションを使用できます。
12.3.2.1 自動分割とマージ
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アウトバウンド・サーバーではないこと。
-
適用プロセスが停止していること。
-
バッファ・キューからハード・ディスクにオーバーフローしているメッセージがないこと。
関連項目:
-
例については、「Oracle Streamsの宛先の自動的な分割およびマージ」を参照してください
-
取得プロセス・パラメータの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照してください。
-
自動の分割操作およびマージ操作の監視の詳細は、『Oracle Streams概要および管理』を参照してください。
12.3.2.2 手動の分割および自動のマージ
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
プロシージャを手動で実行します。
関連項目:
例については、「Oracle Streamsの宛先の手動の分割および自動的なマージ」を参照してください
12.3.2.3 手動の分割および生成されたスクリプトによるマージ
SPLIT_STREAMS
およびMERGE_STREAMS
プロシージャは、アクションを直接実行するか、またはアクションを実行するスクリプトを生成してスクリプトの実行時にアクションを実行できます。スクリプトを実行するよりプロシージャを使用してアクションを直接実行する方が簡単で、分割操作またはマージ操作が即時に実行されます。ただし、次の理由でスクリプトを生成することもあります。
-
ストリームを分割またはマージする前にプロシージャによって実行されるアクションを確認する必要がある。
-
アクションをカスタマイズするためにスクリプトを変更する必要がある。
たとえば、クローニングされた取得プロセスのルール・セットのルールを変更する場合、スクリプトを変更することがあります。Oracle Streamsレプリケーション環境によっては、ソース・データベースに対して行われた変更のサブセットのみが各宛先データベースに送信され、各宛先データベースが異なる変更のサブセットを受信する場合があります。このような環境では、クローニングされた伝播によって伝播される変更のみを取得するように、クローニングされた取得プロセスのルール・セットを変更できます。
各プロシージャのperform_actions
パラメータは、プロシージャでアクションを直接実行するかどうかを制御します。
-
この項のいずれかのプロシージャを実行する際にストリームを直接分割またはマージする場合は、
perform_actions
パラメータをTRUE
に設定します。このパラメータのデフォルト値はTRUE
です。 -
この項のいずれかのプロシージャを実行する際にスクリプトを生成する場合は、
perform_actions
パラメータをFALSE
に設定し、script_name
およびscript_directory_object
パラメータを使用してスクリプトの名前と格納場所を指定します。
関連項目:
例については、「Oracle Streamsの宛先のスクリプトによる手動の分割およびマージ」を参照してください
12.3.3 Oracle Streamsの分割およびマージの例
次の項では、ストリームを分割およびマージする手順について説明します。
これらの例では、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パッケージおよびタイプ・リファレンス』を参照してください。
12.3.3.1 Oracle Streamsの宛先の自動的な分割およびマージ
この例を確認する前に、次の項を参照してください。
-
概念については、「自動の分割およびマージ」を参照してください
-
この例のOracle Streamsレプリケーション環境に関する想定については、「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概要および管理』を参照してください。
12.3.3.2 Oracle Streamsの宛先の手動での分割および自動的なマージ
この例を確認する前に、次の項を参照してください。
-
概念については、「手動の分割および自動のマージ」を参照してください
-
この例のOracle Streamsレプリケーション環境に関する想定については、「Oracle Streamsの分割およびマージの例」を参照してください
この項の例では、手動でストリームを分割し、自動的にマージします。そのため、SPLIT_STREAMS
プロシージャのperform_actions
パラメータはTRUE
に設定されています。また、この例では、SPLIT_STREAMS
プロシージャのauto_merge_threshold
パラメータが正数(60)に設定されているため、ストリームを適切なタイミングで自動的にマージします。
次の手順を実行して、ストリームを直接分割し、自動的にマージします。
クローニングされた取得プロセス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
に格納されます。
12.3.3.3 Oracle Streamsの接続先のスクリプトによる手動の分割およびマージ
この例を確認する前に、次の項を参照してください。
-
概念については、「手動の分割および生成されたスクリプトによるマージ」を参照してください
-
この例のOracle Streamsレプリケーション環境に関する想定については、「Oracle Streamsの分割およびマージの例」を参照してください
この項の例では、スクリプトを生成して実行し、ストリームを分割およびマージします。そのため、SPLIT_STREAMS
プロシージャのperform_actions
パラメータは、FALSE
に設定されています。また、この例では、SPLIT_STREAMS
プロシージャのauto_merge_threshold
パラメータがNULL
に設定されているため、ストリームを適切なタイミングで手動でマージします。
次の手順を実行して、スクリプトを使用し、ストリームを分割およびマージします。
スクリプトが正常に実行された後は、ストリームがマージされ、Oracle Streamsレプリケーション環境に、分割操作およびマージ操作の前と同じコンポーネントが存在するようになります。今後の参照用に、完了した分割操作およびマージ操作に関する情報はDBA_STREAMS_SPLIT_MERGE_HIST
に格納されます。
12.4 ソース・データベースのDBIDまたはグローバル名の変更
通常、あるデータベースが別のデータベースのクローンである場合、データベース管理者はそのデータベースの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で削除した適用プロセスを再作成します。各適用プロセスを、削除される前と同じルール・セットに関連付ける必要がある場合があります。手順については、「暗黙的適用の構成」を参照してください。
- 必要に応じて、手順3で削除した取得プロセスを再作成します。取得プロセスを、手順3で削除した取得プロセスと同じルール・セットに関連付ける必要がある場合があります。手順については、「取得プロセスの構成」を参照してください。
- ソース・データベースで、再作成した取得プロセスによって変更が取得されるデータベース・オブジェクトについて、インスタンス化の準備を行います。「ソース・データベースでインスタンス化を行うためのデータベース・オブジェクトの準備」を参照してください。
- ソース・データベースの変更を適用する宛先データベースごとに、ソース・データベースの変更を適用するすべてのデータベース・オブジェクトについて、インスタンス化SCNを設定します。手順については、「宛先データベースでのインスタンス化SCNの設定」を参照してください。
ALTER
SYSTEM
DISABLE
RESTRICTED
SESSION
文を使用し、RESTRICTED SESSIONを無効化します。- ソース・データベースの変更を適用する宛先データベースごとに、手順8で作成した適用プロセスを起動します。
- ソース・データベースで、手順9で作成した取得プロセスを起動します。
関連項目:
DBNEWIDユーティリティを使用してデータベースのDBID
を変更する方法の詳細は、『Oracle Databaseユーティリティ』 を参照してください
12.5 複数ソース環境でのソース・データベースの再同期化
複数ソース環境とは、共有データに複数のソース・データベースが存在する環境です。複数ソース環境のソース・データベースを現在の時点までリカバリできない場合、この項で説明する方法を使用して、そのソース・データベースを環境内の他のソース・データベースと再同期化できます。データベースを現在の時点までリカバリできない理由には、アーカイブ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を再度追加します。
12.6 Oracle Streams環境におけるデータベースのPoint-in-Timeリカバリの実行
Point-in-Timeリカバリとは、指定した現在以外の時刻、SCNまたはログ順序番号までデータベースをリカバリすることです。ここでは、Oracle Streamsレプリケーション環境でPoint-in-Timeリカバリを実行する方法について説明します。
関連項目:
Point-in-Timeリカバリの詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』 を参照してください
12.6.1 単一ソース環境のソースにおけるPoint-in-Timeリカバリの実行
単一ソースの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;
適用プロセスで使用するルール・セットをメモします。手順10.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
;手順10.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
プロシージャを使用して、新規の取得プロセスを起動します。
12.6.2 複数ソース環境におけるPoint-in-Timeリカバリの実行
複数ソース環境とは、共有データに複数のソース・データベースが存在する環境です。複数ソースの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パッケージおよびタイプ・リファレンスを参照してください。
12.6.3 宛先データベースにおけるPoint-in-Timeリカバリの実行
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概要および管理』 を参照してください
12.6.3.1 リカバリを実行するための既存の取得プロセスの開始SCNのリセット
Point-in-Timeリカバリを実行するために、既存の取得プロセスの開始SCNをリセットするように決定した場合は、次の手順を実行します。
12.7 Oracle Streamsレプリケーション環境でのフラッシュバック問合せの実行
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を判断できます。この問合せを実行するには、次の手順を実行します。
関連項目:
-
フラッシュバック問合せの詳細は、『Oracle Database開発ガイド』 を参照してください
-
GET_SCN_MAPPING
プロシージャの詳細は、Oracle Database PL/SQLパッケージおよびタイプ・リファレンスを参照してください。
12.8 操作エラーからのリカバリ
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
パッケージにある次のプロシージャによって実行されるレプリケーション構成操作
操作に関する情報は、操作の処理中に次のデータ・ディクショナリ・ビューに格納されます。
注意:
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以上のデータベースである必要があります。
関連項目:
-
これらのプロシージャを使用してOracle Streamsレプリケーション環境を構成する方法の詳細は、「DBMS_STREAMS_ADMパッケージを使用したレプリケーションの構成」を参照してください
-
これらのプロシージャを実行する前に満たす必要がある前提条件については、「Oracle Streamsレプリケーションを構成する前に実行するタスク」を参照してください
12.8.1 リカバリの例
ここでは、エラーの発生によって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; /
次の手順を実行して、問題を診断し、操作をリカバリします。