この章では、Oracle Streamsレプリケーション環境を管理する方法について説明します。
この章の内容は次のとおりです。
Oracle Streamsレプリケーション環境の準備が整ったら、各データベースでOracle Streamsコンポーネントを管理できます。管理作業の1つとしてコンポーネントの管理があります。たとえば、取得処理パラメータを設定して取得プロセスの動作を変更できます。また、管理作業には、Oracle Streamsコンポーネントの監視や問題が発生した場合のトラブルシューティングも含まれます。
次のマニュアルでは、Oracle Streamsを管理する方法について説明されています。
Oracle Streamsコンポーネントを管理する方法の詳細は、『Oracle Streams概要および管理』を参照してください。
最も一般的な管理タスクを実行する方法については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。
Oracle Streamsレプリケーション環境に固有の方法については、『Oracle Streamsレプリケーション管理者ガイド』(このマニュアル)を参照してください。
Oracle Enterprise Managerを使用してOracle Streamsを管理する方法の詳細は、Oracle Enterprise Managerの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 Database 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 Database 2日でデータ・レプリケーションおよび統合ガイド』または『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またはDBMS_CAPTURE_ADM
パッケージのSET_PARAMETER
プロシージャを使用してパラメータをリセットします。Oracle Enterprise Managerの使用手順については、『Oracle Database 2日でデータ・レプリケーションおよび統合ガイド』を参照してください。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
プロシージャは、構成プロシージャが実行されたデータベースで実行する必要があります。