| Oracle Streamsレプリケーション管理者ガイド 11g リリース1（11.1） E05776-02 |
|
 戻る |
 次へ |
この章では、Oracle Streamsレプリケーション環境で一般的な問題を識別して解決する方法について説明します。
この章の内容は次のとおりです。
|
参照: Oracle Streams環境のトラブルシューティングの詳細は、『Oracle Streams概要および管理』を参照してください。 |
アラートとは、潜在的な問題に関する警告、またはクリティカルのしきい値を超えたことを示す指標です。Oracle Database 11g リリース1以上のデータベースでは、次の場合にOracle Streamsアラートが生成されます。
取得プロセスが異常終了した場合
連続して16回エラーが発生した後に伝播が異常終了した場合
適用プロセスが異常終了した場合
空のエラー・キューをが含まれている適用プロセスで適用エラーが発生した場合
Oracle Streamsプールのメモリー使用率が指定した割合を超えた場合
|
参照: Oracle Streamsアラートとその表示手順、およびこのアラートに応答する方法の詳細は、『Oracle Streams概要および管理』を参照してください。 |
DBMS_STREAMS_ADMパッケージの次のプロシージャでは、Oracle Streamsによってメンテナンスされるレプリケーション環境が構成されます。
MAINTAIN_GLOBAL
MAINTAIN_SCHEMAS
MAINTAIN_SIMPLE_TTS
MAINTAIN_TABLES
MAINTAIN_TTS
PRE_INSTANTIATION_SETUPおよびPOST_INSTANTIATION_SETUP
perform_actionsパラメータをTRUEに設定してこれらのいずれかのプロシージャでレプリケーション環境を直接構成すると、プロシージャの実行中に構成アクションに関する情報が次のデータ・ディクショナリ・ビューに格納されます。
DBA_RECOVERABLE_SCRIPT
DBA_RECOVERABLE_SCRIPT_PARAMS
DBA_RECOVERABLE_SCRIPT_BLOCKS
DBA_RECOVERABLE_SCRIPT_ERRORS
プロシージャが正常に完了すると、これらのビューから構成操作に関するメタデータが削除されます。ただし、これらのいずれかのプロシージャでエラーが発生して停止した場合、構成操作に関するメタデータはこれらのビューに残ります。通常、これらのプロシージャでは、実行するための前提条件が1つ以上満たされていない場合にエラーが発生します。
これらのいずれかのプロシージャでエラーが発生した場合、DBMS_STREAMS_ADMパッケージのRECOVER_OPERATIONプロシージャを使用して、操作のロールフォワード、操作のロールバックまたは操作に関するメタデータの削除を実行できます。具体的には、RECOVER_OPERATIONプロシージャのoperation_modeパラメータに次のオプションを使用できます。
FORWARD: 障害が発生した時点から構成操作の完了が試行されます。このオプションを指定する前に、DBA_RECOVERABLE_SCRIPT_ERRORSビューにレポートされたエラーの原因となった条件を訂正します。
ROLLBACK: 構成プロシージャによって実行されたすべてのアクションがロールバックされます。このオプションを指定すると、ロールバックが正常に実行された場合に、前述のデータ・ディクショナリ・ビュー内の操作に関するメタデータも削除されます。
PURGE: 操作をロールバックせずに、前述のデータ・ディクショナリ・ビュー内の操作に関するメタデータが削除されます。
|
注意:
|
|
参照:
|
ここでは、エラーの発生によってMAINTAIN_SCHEMASプロシージャが停止する例について説明します。取得データベースでの実行中に次のプロシージャでエラーが発生したと想定します。
BEGIN
DBMS_STREAMS_ADM.MAINTAIN_SCHEMAS(
schema_names => 'hr',
source_directory_object => 'SOURCE_DIRECTORY',
destination_directory_object => 'DEST_DIRECTORY',
source_database => 'inst1.net',
destination_database => 'inst2.net',
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;
/
次の手順を実行して、問題を診断し、操作をリカバリします。
取得データベースでDBA_RECOVERABLE_SCRIPT_ERRORSデータ・ディクショナリ・ビューを問い合せて、エラーがないかどうかを判別します。
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 SCRIPT_ID, BLOCK_NUM, ERROR_MESSAGE FROM DBA_RECOVERABLE_SCRIPT_ERRORS;
この問合せでは、次の出力が戻されます。
Block
Script ID Number Error Message
----------------------------------- ------- ---------------------------------
F73ED2C9E96B27B0E030578CB10B2424 12 ORA-39001: invalid argument value
手順1で戻されたスクリプトIDとブロック番号を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列には、ブロックが実行されたデータベースが表示されます。この例では、エラーの発生時にデータ・ポンプ・エクスポートがINST1.NETで実行されていたため、ブロック12のFORWARD_BLOCK_DBLINK列にINST1.NETが表示されます。
STATUS列には、ブロック実行の状態が表示されます。この例では、ブロック12のSTATUS列にはERRORが表示されます。
問合せの出力を解析し、問題を診断します。手順1で戻された出力には、次の情報が提供されます。
構成操作の一意識別子は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 INST1.NET DESTINATION_DATABASE INST2.NET 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パラメータが手順1で判別した値に設定され、operation_modeパラメータがFORWARDに設定されていることに注意してください。また、RECOVER_OPERATIONプロシージャは、構成プロシージャが実行されたデータベースで実行する必要があります。
Oracle Streams構成レポートとヘルス・チェック・スクリプトでは、個々のOracle DatabaseのOracle Streamsコンポーネントに関する重要な情報が提供されます。このレポートは、Oracle Streamsの前提条件を満たしているかどうかの確認、およびOracle Streamsの対象データベース・オブジェクトの識別に役立ちます。また、このレポートでは、データベースのルールを分析してOracle Streamsルールの一般的な問題を識別できます。
Streams構成レポートとヘルス・チェック・スクリプトは、OracleMetaLink Webサイトで使用できます。スクリプトを実行するには、次の手順を実行します。
Webブラウザで、OracleMetaLink Webサイトにアクセスします。
https://metalink.oracle.com
OracleMetaLink にログインします。
|
注意: OracleMetaLink の登録ユーザーでない場合は、「Register for MetaLink」をクリックして登録してください。 |
「Quick Find」フィールドで「Knowledge Base」を選択し、関連するテキスト・フィールドに次のとおり入力します。
Streams Configuration Report and Health Check Script
「Go」をクリックします。
Streams構成レポートとヘルス・チェック・スクリプトのリンクをクリックします。
指示に従ってスクリプトをダウンロードして実行し、結果を分析します。
Oracle Streamsレプリケーション環境のデータベースに、複数の接続先データベースに対する変更を取得する取得プロセスが1つ含まれている場合、いずれかの接続先データベースが使用不可になると、パフォーマンスの問題が発生する可能性があります。問題が発生し、使用不可能な宛先に対する変更を伝播できなくなると、それらの変更は取得プロセス・キューに蓄積され、最終的にハード・ディスクにオーバーフローします。取得データベースでメッセージがハード・ディスクにオーバーフローすると、Oracle Streamsレプリケーション環境のパフォーマンスが低下する可能性があります。V$BUFFERED_QUEUESビューを問い合せて、キュー内のメッセージの数およびハード・ディスクにオーバーフローしたメッセージの数を確認することができます。 また、DBA_PROPAGATIONおよびV$PROPAGATION_SENDERビューを問い合せて、データベース内の伝播および各伝播の状態を確認することもできます。
このような状況が発生した場合は、DBMS_STREAMS_ADMパッケージのSPLIT_STREAMSおよびMERGE_STREAMS_JOBプロシージャを使用して問題に対応できます。SPLIT_STREAMSプロシージャは、問題が発生しているストリームを、取得プロセスから送信されている他のストリームから分割します。ストリームを分割することによって、宛先が使用不可能な間のパフォーマンスの問題を回避できます。宛先の問題が解決したら、MERGE_STREAMS_JOBプロシージャを実行して、ストリームを取得プロセスから送信されている他のストリームとマージします。
有効化した取得プロセスで変更が正しく取得されない場合、その取得プロセスは次のいずれかの状態である可能性があります。
WAITING FOR REDO
PAUSED FOR FLOW CONTROL
データベース内の各取得プロセスの状態を確認するには、次の問合せを実行します。
COLUMN CAPTURE_NAME HEADING 'Capture Name' FORMAT A30 COLUMN STATE HEADING 'State' FORMAT A30 SELECT CAPTURE_NAME, STATE FROM V$STREAMS_CAPTURE;
ここでは、取得プロセスの状態がWAITING FOR REDOまたはPAUSED FOR FLOW CONTROLのいずれかである場合の、レプリケーション環境での取得プロセスの問題のトラブルシューティングについて説明します。
|
参照: 取得プロセスの管理の詳細は、『Oracle Streams概要および管理』を参照してください。 |
取得プロセスは、WAITING FOR REDO状態の場合、新しいREDOログ・ファイルが取得プロセス・セッションに追加されるまで待機しています。この状態は、REDOログ・ファイルが欠落している場合またはソース・データベースにアクティビティがない場合に発生する可能性があります。ダウンストリーム取得プロセスでは、新しいログ・ファイルがセッションに追加されるまで取得プロセスが待機している場合にこの状態が発生する可能性があります。
V$STREAMS_CAPTUREビューを問い合せると、状態情報とともに追加情報が表示される場合があります。この追加情報によって、取得プロセスがREDOを待機している理由を判断できます。たとえば、このビューを問い合せると、STATE列に次のような文が表示される場合があります。
WAITING FOR REDO: LAST SCN MINED 8077284
この場合、出力では、取得プロセスによって最後にスキャンされたシステム変更番号（SCN）のみが識別されます。また、出力で、REDOログ・ファイル名が明示的に識別される場合もあります。いずれの場合も、追加情報によって、取得プロセスが待機しているREDOログ・ファイルを識別できます。この問題を解決するには、欠落しているREDOログ・ファイルを取得プロセスで使用できるようにします。
|
参照: 『Oracle Streams概要および管理』 |
取得プロセスは、PAUSED FOR FLOW CONTROL状態の場合、メモリー不足のため、または伝播および適用プロセスでのメッセージのコンシューム速度が取得プロセスでのメッセージの作成速度より遅いため、論理変更レコード（LCR）をエンキューできません。この状態は、伝播または適用が遅れたり、使用不可能になった場合に、取得LCRのオーバーフローを減らすために使用されるフロー制御を示しています。
取得プロセスがこの状態である場合、次の問題が発生していないかどうかを確認します。
適用プロセスが無効化されているか、またはその実行速度が遅い。
伝播が無効化されているか、またはそのパフォーマンスが良くない。
Streamsプールに十分なメモリーがない。
V$STREAMS_APPLY_READERビューを問い合せると、適用プロセスで受信されるLCRを監視できます。V$STREAMS_APPLY_SERVERビューを問い合せて、すべての適用サーバーでLCRが適用され、トランザクションが実行されているかどうかを判断することもできます。
また、取得プロセスで取得と適用の複合を使用していない場合は、V$BUFFERED_PUBLISHERSビューのPUBLISHER_STATE列を問い合せると、取得プロセスがフロー制御のために中断した正確な理由を確認できます。
この問題を解決するには、次の1つ以上の操作を実行します。
伝播または適用プロセスが無効化されている場合は、それらを有効化します。
適用リーダーのデータ受信速度が十分でない場合は、伝播および適用プロセスのルールの削除またはルール条件の簡略化を試行します。
取得プロセス・データベースのStreamsプールに十分なメモリーがない場合は、Streamsプールのサイズの増加を試行します。
|
参照:
|
ここでは、レプリケーション環境での適用プロセスの問題のトラブルシューティングについて説明します。
適用サーバーは、適用プロセスのコンポーネントです。適用サーバーは、接続先データベースのデータベース・オブジェクトにDMLおよびDDL変更を適用します。適用プロセスは1つ以上の適用サーバーを使用する場合があり、parallelism適用プロセス・パラメータには、トランザクションを同時に適用できる適用サーバーの数を指定します。たとえば、parallelismを5に設定すると、適用プロセスでは合計5つの適用サーバーが使用されます。
適用サーバーが他のセッションによって使用されているリソースを待機する必要がある場合、適用サーバーに競合が発生します。論理的な依存性が原因で競合が発生する場合があります。たとえば、ユーザーがロックした行に適用サーバーが変更を適用しようとすると、適用サーバーはそのユーザーを待機する必要があります。論理的な依存性が原因で競合が発生する場合があります。たとえば、論理的に依存していない適用中の2つのトランザクションがディスク上の同じブロックをロックしようとすると、対象トランザクション・リスト（ITL）の競合が発生します。この場合、一方の適用サーバーがブロック内の行をロックし、他方の適用サーバーが異なる行をロックしようとしても、そのブロックへのアクセスを待機する必要があります。 ITL競合の詳細は、「適用プロセスが依存トランザクションを待機しているかどうか」を参照してください。
適用サーバーに、同じ適用プロセスの他の適用サーバーに関連しない競合が発生した場合、その適用サーバーは競合が解消されるまで待機します。適用サーバーに、同じ適用プロセスの他の適用サーバーに関連する競合が発生した場合は、2つの適用サーバーの一方がロールバックされます。複数の適用サーバーを使用している適用プロセスでは、同時に複数のトランザクションが適用されている場合があります。適用プロセスは、最小コミットSCNを持つトランザクションを適用している適用サーバーの状態を追跡します。2つのトランザクションの間に依存性がある場合、適用プロセスでは常に最小コミットSCNを持つトランザクションが最初に適用されます。上位コミットSCNを持つトランザクションは、最小コミットSCNを持つトランザクションがコミットされるまで待機します。したがって、最小コミットSCNのトランザクションを持つ適用サーバーに競合が発生した場合、その競合の原因は依存トランザクション以外にあります。この場合、最小コミットSCNトランザクションを持つ適用サーバーを監視すると、競合の原因を判別できます。
適用サーバーの待機状態は次の4つのいずれかになります。
待機なし: 適用サーバーに競合は発生しておらず、待機もしていません。この場合、何もする必要はありません。
他のセッションに関連しないイベントを待機中: 他のセッションに関連しないイベントの例には、log file syncイベントがあります。このイベントでは、コミットまたはロールバックのために、REDOデータがフラッシュされる必要があります。このような待機は頻繁に発生し、通常は一時的なものであるため、最初はログに何も書き込まれません。一定時間経過後に適用サーバーが同じイベントを待機している場合、適用サーバーはアラート・ログと適用プロセス・トレース・ファイルにメッセージを書き込みます。たとえば、適用サーバーAS01は次のようなメッセージを書き込みます。
AS01: warning -- apply server 1, sid 26 waiting for event: AS01: [log file sync] ...
問題が解決されるまで、このメッセージが定期的にアラート・ログに書き込まれます。
適用サーバー以外のセッションに関連するイベントを待機中: 適用サーバーは、すぐにアラート・ログと適用プロセス・トレース・ファイルにメッセージを書き込みます。たとえば、適用サーバーAS01は次のようなメッセージを書き込みます。
AS01: warning -- apply server 1, sid 10 waiting on user sid 36 for event:
AS01: [enq: TM - contention] name|mode=544d0003, object #=a078,
table/partition=0
問題が解決されるまで、このメッセージが定期的にアラート・ログに書き込まれます。
他の適用サーバー・セッションを待機中: この状態は、対象トランザクション・リスト（ITL）の競合、または適用ハンドラのロックの競合などのより重大な問題によって発生する場合があります。この場合、他の適用サーバーによってブロックされている適用サーバーがアラート・ログと適用プロセス・トレース・ファイルに1回のみメッセージを出力し、ブロックされた適用サーバーがブロック元の適用サーバーにロールバックを発行します。ブロック元の適用サーバーがロールバックすると、適用サーバーがロールバックされたことを示す別のメッセージがログ・ファイルに出力され、ロールバックされたトランザクションはその適用プロセスのコーディネータ・プロセスによって再割当てされます。
たとえば、適用プロセスAP01の適用サーバー1が同じ適用プロセス（AP01）の適用サーバー2によってブロックされた場合、適用プロセスは次のメッセージをログ・ファイルに書き込みます。
AP01: apply server 1 blocked on server 2
AP01: [enq: TX - row lock contention] name|mode=54580006, usn<<16 |
slot=1000e, sequence=1853
AP01: apply server 2 rolled back
適用プロセスが最後に起動されてから適用サーバーがロールバックされた合計回数を表示するには、V$STREAMS_APPLY_COORDINATOR動的パフォーマンス・ビューのTOTAL_ROLLBACKS列を問い合せます。
|
参照:
|
適用プロセスについて、parallelismパラメータを1より大きい値に設定し、commit_serializationパラメータをfullに設定した場合は、上位SCNを持つ他のトランザクションに依存するトランザクションがあると、その適用プロセスは対象トランザクション・リスト（ITL）の競合を検出する可能性があります。ITLの競合が発生するのは、トランザクションを作成したセッションがブロック内のITLスロットを待機していた場合です。この状況が発生するのは、セッションがブロック内で1行をロックする必要があるが、他の1つ以上のセッションによって同一ブロック内で数行がロックされており、ブロックに空きITLスロットがない場合です。
ITLの競合は、共有ビットマップ索引の断片が原因でセッションが待機中でも発生する可能性があります。ビットマップ索引は、キー値とROWIDの範囲に索引を付けます。ビットマップ索引の各エントリで実際の表の多数の行に対処できます。同じビットマップ索引の断片で扱われる複数行を2つのセッションで更新する必要がある場合、2番目のセッションは最初のトランザクションがCOMMITまたはROLLBACKされるまで待機します。
適用プロセスでこの種の依存性が検出されると、ITLの競合が自動的に解決され、これに関する情報がデータベース用のアラート・ログと適用プロセスのトレース・ファイルに記録されます。デッドロックが検出されている間は適用プロセスが進まないため、ITLの競合は、適用プロセスのパフォーマンスに悪影響を及ぼす可能性があります。
将来の問題を回避するには、次のいずれかの操作を実行します。
使用可能なITLの数を増加させます。これを行うには、ALTER TABLE文を使用して表のINITRANS設定を変更します。
適用プロセスのcommit_serializationパラメータをnoneに設定します。
適用プロセスのparallelism適用プロセス・パラメータを1に設定します。
|
参照:
|
適用プロセスのパフォーマンスが低い場合、適用プロセスで使用されている1つ以上の適用サーバーで、特定のトランザクションの適用に極めて長い時間がかかっていることが原因である場合があります。次の問合せを実行すると、strm01_applyという適用プロセスで使用される各適用サーバーが適用しているトランザクションに関する情報が表示されます。
COLUMN SERVER_ID HEADING 'Apply Server ID' FORMAT 99999999 COLUMN STATE HEADING 'Apply Server State' FORMAT A20 COLUMN APPLIED_MESSAGE_NUMBER HEADING 'Applied Message|Number' FORMAT 99999999 COLUMN MESSAGE_SEQUENCE HEADING 'Message Sequence|Number' FORMAT 99999999 SELECT SERVER_ID, STATE, APPLIED_MESSAGE_NUMBER, MESSAGE_SEQUENCE FROM V$STREAMS_APPLY_SERVER WHERE APPLY_NAME = 'STRM01_APPLY' ORDER BY SERVER_ID;
この問合せを繰り返し実行すると、各適用サーバーがトランザクションを適用するにつれて、適用サーバーの状態、適用されたメッセージの数およびメッセージ順序番号が変化します。1つ以上の適用サーバーに対してこれらの値が変化しない場合、その適用サーバーのパフォーマンスが低い可能性があります。この場合、適用プロセスが変更を適用する表ごとに、すべてのキー列に索引が作成されていることを確認する必要があります。
このような表が多く存在する場合、適用サーバーのパフォーマンスを低下させている特定の表、DMLまたはDDL操作を判別する必要があります。これを行うには、適用サーバーによるトランザクションの適用に極めて長い時間がかかっているときに、次の問合せを実行します。この例では、適用プロセス名がstrm01_applyであり、適用サーバー2のパフォーマンスが低いことを想定しています。
COLUMN OPERATION HEADING 'Operation' FORMAT A20
COLUMN OPTIONS HEADING 'Options' FORMAT A20
COLUMN OBJECT_OWNER HEADING 'Object|Owner' FORMAT A10
COLUMN OBJECT_NAME HEADING 'Object|Name' FORMAT A10
COLUMN COST HEADING 'Cost' FORMAT 99999999
SELECT p.OPERATION, p.OPTIONS, p.OBJECT_OWNER, p.OBJECT_NAME, p.COST
FROM V$SQL_PLAN p, V$SESSION s, V$STREAMS_APPLY_SERVER a
WHERE a.APPLY_NAME = 'STRM01_APPLY' AND a.SERVER_ID = 2
AND s.SID = a.SID
AND p.HASH_VALUE = s.SQL_HASH_VALUE;
この問合せでは、特定の適用サーバーによって現在実行されている操作が戻されます。また、操作が実行されている表の所有者と表名、および操作のコストも戻されます。この表の各キー列に索引が作成されていることを確認してください。COST列の結果がFULLである場合、その操作によって全表スキャンが実行されています。この問題を解決するには、その表のキー列に索引を作成します。
また、次の問合せを実行して、適用サーバーのパフォーマンス低下の原因となっている特定のDMLまたはDDLのSQL文を判別できます。ここでは、適用プロセス名がstrm01_applyであり、適用サーバー2がパフォーマンス低下の原因となっていると想定します。
SELECT t.SQL_TEXT FROM V$SESSION s, V$SQLTEXT t, V$STREAMS_APPLY_SERVER a WHERE a.APPLY_NAME = 'STRM01_APPLY' AND a.SERVER_ID = 2 AND s.SID = a.SID AND s.SQL_ADDRESS = t.ADDRESS AND s.SQL_HASH_VALUE = t.HASH_VALUE ORDER BY PIECE;
この問合せでは、特定の適用サーバーによって現在実行されているSQL文が戻されます。この文には、トランザクションが適用されている表の名前が含まれます。この表の各キー列に索引が作成されていることを確認してください。
前述の問合せによって戻されたSQL文の長さが1000文字未満の場合、かわりに次の簡略化した問合せを実行することができます。
SELECT t.SQL_TEXT FROM V$SESSION s, V$SQLAREA t, V$STREAMS_APPLY_SERVER a WHERE a.APPLY_NAME = 'STRM01_APPLY' AND a.SERVER_ID = 2 AND s.SID = a.SID AND s.SQL_ADDRESS = t.ADDRESS AND s.SQL_HASH_VALUE = t.HASH_VALUE;
|
参照: V$SQL_PLAN動的パフォーマンス・ビューの詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』および『Oracle Databaseリファレンス』を参照してください。 |
適用プロセスがメッセージを適用できない場合は、そのメッセージおよび同じトランザクション内の他のすべてのメッセージが、エラー・キューに移動されます。適用エラーを定期的にチェックして、適用できなかったトランザクションの有無を確認する必要があります。適用エラーの有無は、DBA_APPLY_ERRORデータ・ディクショナリ・ビューを問い合せてチェックできます。
|
参照: 適用エラーを確認する方法および適用エラーを管理する方法の詳細は、『Oracle Streams概要および管理』を参照してください。 |
適用プロセスによってトランザクションがエラー・キューに移動されると、トランザクションを調べて、トランザクションの再実行が成功する可能性を解析できます。トランザクションに異常が発見された場合は、DMLハンドラを構成して問題を解決できる場合があります。この場合、エラー・トランザクションの再実行時にDMLハンドラが実行されるように構成できます。
DMLハンドラを使用してエラー・トランザクション内の問題を解決する場合、このDMLハンドラを使用する適用プロセスを停止して、エラー・トランザクションと無関係なLCRでこのDMLハンドラが動作しないようにする必要があります。再実行が成功した後、不要なDMLハンドラを削除します。また、トランザクションがエラー・キューに移動する原因となった問題を訂正し、将来のエラー・トランザクションを防止します。
LCRには、次のタイプの適用プロセス・エラーが発生する場合があります。
アスタリスク（*）の付いたエラーは、多くの場合、適用ハンドラまたはルールベースの変換の問題によって発生します。
ORA-01031エラーは、適用ユーザーとして指定されたユーザーが、レプリケート・オブジェクトでSQL処理を実行するための十分な権限を持っていない場合に発生します。適用ユーザー権限は、各権限の明示的な付与によって付与される必要があります。Oracle Streams適用ユーザーにロールを介してこれらの権限を付与するのみでは不十分です。
具体的には、次の権限が必要です。
INSERT、UPDATE、DELETEおよびSELECT権限: 表レベルのDMLの変更を行う場合に必要です。
ALTER TABLE権限: 表レベルのDDLの変更を行う場合に必要です。
CREATE ANY TABLE、CREATE ANY INDEX、CREATE ANY PROCEDURE、ALTER ANY TABLEおよびALTER ANY PROCEDURE権限: スキーマ・レベルの変更を行う場合に必要です。
ALL PRIVILEGES権限: グローバル・レベルの変更を行う場合に必要です。
このエラーを訂正するには、次の手順を実行します。
接続先データベースで適用ユーザーとして接続します。
SESSION_PRIVSデータ・ディクショナリ・ビューを問い合せ、適用ユーザーに付与されていない必要な権限を判別します。
権限を付与できる管理ユーザーとして接続します。
適用ユーザーに必要な権限を付与します。
適用プロセスのエラー・キューのエラー・トランザクションを再実行します。
|
参照:
|
通常、ORA-01403エラーが発生するのは、既存の行の更新が試行され、その行LCR内のOLD_VALUESが接続先データベースの現行の値と一致しない場合です。
通常、このエラーは次のいずれかの条件が原因で発生します。
ソース・データベースでサプリメンタル・ロギングが必要な列に、それが指定されていない場合。この場合、ソース・データベースからのLCRには、キー列の値が含まれない可能性があります。DMLハンドラを使用して、必要なサプリメンタル・データを含むようにLCRを変更できます。「DMLハンドラを使用したエラー・トランザクションの訂正」を参照してください。また、必要なサプリメンタル・ロギングをソース・データベースで指定し、将来のエラーを防止します。
LCRで変更が適用される表の主キーに問題がある場合。この場合は、DBA_CONSTRAINTSデータ・ディクショナリ・ビューを問い合せて、主キーが使用可能になっているかどうかを確認します。表の主キーが存在しない場合、またはターゲット表とソース表の主キーが異なる場合は、DBMS_APPLY_ADMパッケージのSET_KEY_COLUMNSプロシージャを使用して代替キー列を指定します。また、適用対象となる表に主キーがない場合は、エラーORA-23416も発生する可能性があります。これらの変更後に、エラー・トランザクションを再実行できます。
適用対象となるトランザクションは、まだ実行されていない他のトランザクションに応じて異なります。たとえば、トランザクションでemployee_idが300の従業員の更新が試行されたときに、この従業員の行がemployees表に挿入されていなかった場合、更新は失敗します。この場合、エラー・トランザクションが依存するトランザクションを実行します。次に、エラー・トランザクションを再実行します。
|
参照:
|
行LCR（SYS.LCR$_ROW_RECORDタイプ）のメンバー・サブプログラムをコールする際に、メンバー・サブプログラムによって渡されたパラメータの値が行LCRと一致しない場合、ORA-23605エラーが発生する場合があります。たとえば、メンバー・サブプログラムによって挿入行LCRに古い列値の追加が試行されたり、メンバー・サブプログラムによってLOB列の値の数値への設定が試行された場合に、エラーが発生します。
行LCRには、操作に応じて、次の古い値と新しい値が含まれている必要があります。
INSERT操作の行LCRには、新しい値を含めてください。古い値は含めないでください。
UPDATE操作の行LCRには、新しい値と古い値の両方を含めることができます。
DELETE操作の行LCRには、古い値を含めてください。新しい値は含めないでください。
行LCR操作（INSERT、UPDATEまたはDELETE）に、正しいパラメータ・タイプ（OLD、NEWまたは両方）が指定されていることを確認します。たとえば、DMLハンドラまたはカスタム・ルールベースの変換によって、UPDATE行LCRがINSERT行LCRに変更された場合、そのハンドラまたは変換によって行LCRの古い値が削除されていることを確認します。
適用ハンドラにエラーが発生した場合、適用ハンドラを訂正し、エラー・トランザクションを再実行します。カスタム・ルールベースの変換にエラーが発生した場合、DMLハンドラを作成して問題を訂正できる場合があります。「DMLハンドラを使用したエラー・トランザクションの訂正」を参照してください。また、ルールベースの変換も訂正して、将来のエラーを回避します。
|
参照: ルールベースの変換の詳細は、『Oracle Streams概要および管理』を参照してください。 |
メンバー・サブプログラムのcolumn_nameパラメータの値が行LCR内のどの列名とも一致しない場合、行LCR（SYS.LCR$_ROW_RECORDタイプ）のメンバー・サブプログラムによってORA-23607エラーが発生します。行LCR内の列名を確認してください。
適用ハンドラにエラーが発生した場合、適用ハンドラを訂正し、エラー・トランザクションを再実行します。カスタム・ルールベースの変換にエラーが発生した場合、DMLハンドラを作成して問題を訂正できる場合があります。「DMLハンドラを使用したエラー・トランザクションの訂正」を参照してください。また、ルールベースの変換も訂正して、将来のエラーを回避します。
適用ハンドラおよびカスタム・ルールベースの変換で、次のいずれかの行LCRのメンバー・プロシージャが使用された場合に、このエラーが発生する可能性があります。
DELETE_COLUMN: このプロシージャで、行LCRから行LCRに存在しない列の削除が試行された場合に、エラーが発生します。
RENAME_COLUMN: このプロシージャで、行LCRから行LCRに存在しない列の名前の変更が試行された場合に、エラーが発生します。
この場合、将来の同様なエラーを回避するには、次のいずれかの操作を実行します。
適用ハンドラまたはカスタム・ルールベースの変換を使用するかわりに、宣言ルールベースの変換を使用して、行LCR内の列の削除または名前の変更を行います。宣言ルールベースの変換で、存在しない列の削除または名前の変更が試行された場合、宣言ルールベースの変換ではエラーは発生しません。列を削除する宣言ルールベースの変換を指定するには、DBMS_STREAMS_ADM.DELETE_COLUMNプロシージャを使用します。また、列の名前を変更する宣言ルールベースの変換を指定するには、DBMS_STREAMS_ADM.RENAME_COLUMNプロシージャを使用します。宣言ルールベースの変換は、適用ハンドラおよびカスタム・ルールベースの変換と組み合せて使用できます。
行LCR内の列の削除または名前の変更に、適用ハンドラおよびカスタム・ルールベースの変換を引き続き使用する場合、将来のエラーを防止するためにハンドラまたは変換を変更します。たとえば、列の名前の変更または削除を試行する前に、列が存在することを確認するようにハンドラまたは変換を変更します。
|
参照:
|
ORA-24031エラーは、適用ハンドラまたはカスタム・ルールベースの変換によって、NULLを含むANYDATA値ではなく、NULL値がLCRメンバー・サブプログラムに渡された場合に発生します。
たとえば、次のようにADD_COLUMNメンバー・プロシージャの行LCRをコールすることによって、このエラーが発生する場合があります。
new_lcr.ADD_COLUMN('OLD','LANGUAGE',NULL);
次の例では、行LCRのADD_COLUMNメンバー・プロシージャをコールする正しい方法を示します。
new_lcr.ADD_COLUMN('OLD','LANGUAGE',ANYDATA.ConvertVarchar2(NULL));
適用ハンドラにエラーが発生した場合、適用ハンドラを訂正し、エラー・トランザクションを再実行します。カスタム・ルールベースの変換にエラーが発生した場合、DMLハンドラを作成して問題を訂正できる場合があります。「DMLハンドラを使用したエラー・トランザクションの訂正」を参照してください。また、ルールベースの変換も訂正して、将来のエラーを回避します。
|
参照: ルールベースの変換の詳細は、『Oracle Streams概要および管理』を参照してください。 |
通常、ORA-26687エラーが発生する原因は、適用プロセスで変更を適用するオブジェクトにインスタンス化SCNが設定されていないことです。DBA_APPLY_INSTANTIATED_OBJECTSデータ・ディクショナリ・ビューを問い合せると、インスタンス化SCNを持つオブジェクトをリスト表示できます。
ソース・データベースでオブジェクトをエクスポートし、それを接続先データベースでインポートすると、1つ以上のオブジェクトのインスタンス化SCNを設定できます。データ・ポンプ・エクスポート/インポートを使用できます。エクスポート/インポートを使用しない場合は、DBMS_APPLY_ADMパッケージの次の1つ以上のプロシージャを実行できます。
SET_TABLE_INSTANTIATION_SCN
SET_SCHEMA_INSTANTIATION_SCN
SET_GLOBAL_INSTANTIATION_SCN
接続先データベースのオブジェクトにインスタンス化SCNが設定されない一般的な理由として、次の点があげられます。
インスタンス化のためにエクスポート/インポートを使用し、インスタンス化のためにオブジェクトを準備する前にソース・データベースからそのオブジェクトをエクスポートした場合。インスタンス化のためにオブジェクトを準備するには、DBMS_STREAMS_ADMパッケージを使用してオブジェクトのOracle Streamsルールを作成するか、またはDBMS_CAPTURE_ADMパッケージ内のプロシージャまたはファンクションを実行します。インスタンス化のためにオブジェクトを準備する前にエクスポートした場合、エクスポート・ファイルにインスタンス化SCN情報が含まれず、インスタンス化SCNは設定されません。
この場合、「ソース・データベースでインスタンス化を行うためのデータベース・オブジェクトの準備」の手順を実行して、ソース・データベースでインスタンス化のためにデータベース・オブジェクトを準備します。次に、接続先データベースで、データベース・オブジェクトについてインスタンス化SCNを設定します。
インスタンス化のためにエクスポート/インポートを使用するかわりに、DBMS_APPLY_ADMパッケージの適切なプロシージャを使用して、インスタンス化SCNを明示的に設定した場合。データベース管理者がインスタンス化SCNを明示的に設定した場合、データが正しいかどうかの責任は管理者が負います。
この場合、「DBMS_APPLY_ADMパッケージを使用したインスタンス化SCNの設定」の手順を実行して、データベース・オブジェクトのインスタンス化SCNを明示的に設定します。または、「接続先データベースでのインスタンス化SCNの設定」の手順を実行して、メタデータのみのエクスポート/インポートを実行し、インスタンス化SCNを設定することもできます。
DDL変更を適用する必要があるが、スキーマ・レベルまたはグローバル・レベルでインスタンス化SCNを設定しなかった場合。
この場合、SET_SCHEMA_INSTANTIATION_SCNプロシージャを実行して適切なスキーマのインスタンス化SCNを設定するか、またはSET_GLOBAL_INSTANTIATION_SCNプロシージャを実行してソース・データベースのインスタンス化SCNを設定します。これらのプロシージャは、いずれもDBMS_APPLY_ADMパッケージに含まれています。これを行うには、「DBMS_APPLY_ADMパッケージを使用したインスタンス化SCNの設定」の手順を実行します。
エラーの原因となった条件を訂正した後、エラー・トランザクションを再実行するか削除するかは、エラー条件を訂正した際に、トランザクションに含まれる変更が接続先データベースで実行されたかどうかによって異なります。エラー・キュー内のトランザクションを再実行するか削除するかを判断する際は、次のガイドラインに従ってください。
新規エクスポート/インポートを実行し、新規エクスポートにエラー・キュー内のトランザクションが含まれる場合は、エラー・キュー内のトランザクションを削除します。
インスタンス化SCNを明示的に設定するか、または既存のエクスポート・ダンプ・ファイルを再インポートする場合は、エラー・キュー内のトランザクションを再実行します。
|
参照:
|
通常、ORA-26688エラーは次のいずれかの条件が原因で発生します。
トランザクション内の1つ以上のLCRに、適用プロセスがそのLCRを適用するための十分な情報が含まれていない場合。適用プロセスには、依存性の計算のために、接続先データベースの定義済の主キー列の値が常に必要です。また、変更を適用する適用プロセスの並列性が2以上の場合、適用プロセスには接続データベースのすべての索引列の値が必要です。索引列には、一意索引列、一意でない索引列、外部キー列およびビットマップ索引列が含まれます。
適用プロセスに列の値が必要であり、その列がソース・データベースに存在する場合、ソース・データベースで1つ以上のこれらの列に対してサプリメンタル・ロギングが指定されていないと、このエラーが発生します。この場合、必要なサプリメンタル・ロギングをソース・データベースで指定し、適用エラーを防止します。
ただし、ソース・データベースの表の定義は、対応する接続先データベースの表の定義と異なる場合があります。適用プロセスに列の値が必要であり、その列が接続先データベースには存在するがソース・データベースに存在しない場合、適用エラーを防止するために、ソース・データベースからLCRに必要な値が追加されるようにルールベースの変換を構成できます。
このエラーによってエラー・キューに置かれたトランザクションを訂正するには、DMLハンドラを使用して、必要なサプリメンタル・データを含むようにLCRを変更します。「DMLハンドラを使用したエラー・トランザクションの訂正」を参照してください。
LCRで変更が適用される表の主キーに問題がある場合。この場合は、DBA_CONSTRAINTSデータ・ディクショナリ・ビューを問い合せて、主キーが使用可能になっているかどうかを確認します。表の主キーが存在しない場合、またはターゲット表とソース表の主キーが異なる場合は、DBMS_APPLY_ADMパッケージのSET_KEY_COLUMNSプロシージャを使用して代替キー列を指定します。また、表に主キーが存在しない場合も、エラーORA-23416が発生する可能性があります。これらの変更後に、エラー・トランザクションを再実行できます。
通常、ORA-26689エラーが発生するのは、ソース・データベースの表にある1つ以上の列が、接続先データベースの対応する列と一致しない場合です。ソース・データベースからのLCRには、接続先データベースの表より多数の列が含まれている場合や、1つ以上の列の名前または型が一致しない場合があります。データベース間で列が異なる場合は、ルールベースの変換を使用して将来のエラーを回避できます。
適用ハンドラまたはカスタム・ルールベースの変換を使用している場合、ANYDATA変換ファンクションが、変換対象のLCRのデータ型と一致していることを確認します。たとえば、列がVARCHAR2として指定されている場合、ANYDATA.CONVERTVARCHAR2ファンクションを使用してANYデータ型からVARCHAR2データ型にデータを変換します。
また、ルール条件、適用ハンドラおよびルールベースの変換に適切な大/小文字を使用していることを確認してください。たとえば、列名がデータ・ディクショナリではすべて大文字になっている場合は、ルール条件、適用ハンドラおよびルールベースの変換にもすべて大文字で指定する必要があります。
また、このエラーの発生原因には、ソース・データベースで非キー列に必要なサプリメンタル・ロギングが指定されていないことも考えられます。この場合、ソース・データベースからのLCRには、これらの非キー列に必要な値が含まれない可能性があります。
エラー・トランザクションを適用するようにDMLハンドラを構成できる場合があります。「DMLハンドラを使用したエラー・トランザクションの訂正」を参照してください。
|
参照:
|
ORA-26786エラーは、宛先表の行にある一部の列の値が、行LCRの対応する列の古い値と一致しない場合に発生します。
将来の適用エラーを回避するために、競合ハンドラ、DMLハンドラまたはエラー・ハンドラのいずれかを構成できます。ハンドラによって、レプリケーション環境に適した方法で、一致しない列が解決されます。
また、このエラーが原因で発生した既存のエラー・トランザクションを適用するようにDMLハンドラを構成できる場合もあります。「DMLハンドラを使用したエラー・トランザクションの訂正」を参照してください。
または、行LCRを正常に適用できるように、行の現行の値を更新します。行の変更が接続先データベースの取得プロセスまたは同期取得で取得されている場合、他の接続先データベースでこの手動変更をレプリケートする必要はありません。この場合は、次の手順で操作します。
行を訂正するセッションでタグを設定します。このタグは、手動変更のレプリケートを防止する値に設定してください。たとえば、タグによって、取得プロセスまたは同期取得による変更の取得を防止できます。
EXEC DBMS_STREAMS.SET_TAG(tag => HEXTORAW('17'));
環境によっては、タグを異なる値に設定する必要があります。
データがLCRの古い値と一致するように表の行を更新します。
このエラーまたはすべてのエラーを再実行します。単一のエラーを再実行するには、DBMS_APPLY_ADMパッケージのEXECUTE_ERRORプロシージャを実行し、エラーの原因となったトランザクションのトランザクション識別子を指定します。次に例を示します。
EXEC DBMS_APPLY_ADM.EXECUTE_ERROR(local_transaction_id => '5.4.312');
または、EXECUTE_ALL_ERRORSプロシージャを実行して、適用プロセスのエラーをすべて実行します。
EXEC DBMS_APPLY_ADM.EXECUTE_ALL_ERRORS(apply_name => 'APPLY');
接続先データベースでレプリケートする他の変更を現行セッションで行う場合は、セッションのタグを次のように適切な値にリセットします。
EXEC DBMS_STREAMS.SET_TAG(tag => NULL);
環境によっては、タグをNULL以外の値に設定する必要があります。
ORA-26787エラーは、行LCRが更新または削除を試行する行が宛先表に存在しない場合に発生します。
将来の適用エラーを回避するために、競合ハンドラ、DMLハンドラまたはエラー・ハンドラのいずれかを構成できます。ハンドラによって、レプリケーション環境に適した方法で、対応する表の行が存在しない行LCRが解決されます。
また、このエラーが原因で発生した既存のエラー・トランザクションを適用するようにDMLハンドラを構成できる場合もあります。「DMLハンドラを使用したエラー・トランザクションの訂正」を参照してください。
または、行LCRを正常に適用できるように、行の現行の値を更新します。手順については、「ORA-26786: キーcolumn_value の行は存在しますが、競合する列column_name(s) が表table_name にあります」を参照してください。
