| Oracle® Streams概要および管理 11gリリース2 (11.2) B61351-03 |
|
 前 |
 次 |
次の各項では、Oracle Streams環境内での適用プロセスの一般的な問題の特定と解決について説明します。
|
関連項目:
|
適用プロセスが変更を適用するのは、そのプロセスが有効になっている場合のみです。
適用プロセスが有効か、無効か、中断されているかは、DBA_APPLYデータ・ディクショナリ・ビューを問い合せるとチェックできます。たとえば、applyという適用プロセスが有効かどうかチェックするには、次の問合せを実行します。
SELECT STATUS FROM DBA_APPLY WHERE APPLY_NAME = 'APPLY';
適用プロセスが無効の場合は、出力が次のようになります。
STATUS -------- DISABLED
適用プロセスが無効の場合は、再起動してみてください。適用プロセスが中断されている場合、エラーを修正しないと正常に起動できないことがあります。適用プロセスが正常に停止されていない場合は、再起動しないことがあります。この場合は次のエラーが返されます。
ORA-26666 cannot alter STREAMS process
このとき、DBMS_APPLY_ADMパッケージのSTOP_APPLYプロシージャをforceパラメータをTRUEに設定して実行してください。その後、適用プロセスを再起動します。
適用プロセスが中断された理由を特定するには、DBA_APPLYデータ・ディクショナリ・ビューを問い合せるか、適用プロセスのトレース・ファイルをチェックします。次の問合せを実行すると、適用プロセスがいつ中断されたかと、中断の原因となったエラーが表示されます。
COLUMN APPLY_NAME HEADING 'APPLY|Process|Name' FORMAT A10 COLUMN STATUS_CHANGE_TIME HEADING 'Abort Time' COLUMN ERROR_NUMBER HEADING 'Error Number' FORMAT 99999999 COLUMN ERROR_MESSAGE HEADING 'Error Message' FORMAT A40 SELECT APPLY_NAME, STATUS_CHANGE_TIME, ERROR_NUMBER, ERROR_MESSAGE FROM DBA_APPLY WHERE STATUS='ABORTED';
|
関連項目:
|
適用プロセスによって最近の変更が適用されていない場合、問題は適用プロセスの遅延である可能性があります。適用プロセスの待機時間が長い場合は、parallelism適用プロセス・パラメータの設定を調整すると、パフォーマンスを改善できることがあります。
V$STREAMS_APPLY_COORDINATOR動的パフォーマンス・ビューを問い合せて、適用プロセスの待機時間をチェックできます。
|
関連項目:
|
適用プロセスはバッファ・キューの取得LCRに適用できます。また、永続キューのメッセージにも適用できますが、両方のタイプのメッセージには適用できません。永続キューのメッセージは永続LCRおよび永続ユーザー・メッセージです。適用プロセスは1つのタイプのメッセージに適用されるように構成されているため、別のタイプのメッセージには適用できません。
適用プロセスで適用されるメッセージのタイプは、DBA_APPLYデータ・ディクショナリ・ビューを問い合せるとチェックできます。たとえば、applyという適用プロセスで取得LCRが適用されるかどうかをチェックするには、次の問合せを実行します。
COLUMN APPLY_CAPTURED HEADING 'Type of Messages Applied' FORMAT A25
SELECT DECODE(APPLY_CAPTURED,
'YES', 'Captured',
'NO', 'Messages from Persistent Queue') APPLY_CAPTURED
FROM DBA_APPLY
WHERE APPLY_NAME = 'APPLY';
この適用プロセスで取得LCRが適用される場合は、出力が次のようになります。
Type of Messages Applied ------------------------- Captured
適用プロセスが予期したタイプのメッセージを適用しないときは、これらのメッセージを適用するために適用プロセスの作成が必要になる場合があります。
適用プロセスがメッセージを適用するためには、その前にキューにメッセージを受信する必要があります。このため、適用プロセスが、取得プロセスまたは同期取得で取得されるメッセージを適用する場合、それらのメッセージを取得する取得プロセスまたは同期取得が適切に構成されていることが必要です。また、取得プロセスの場合は有効になっている必要があります。同じく、メッセージが1つまたは複数のデータベースから伝播されて適用プロセスに送られる場合は、各伝播が有効になっており、適切に構成されていることが必要です。適用プロセスが依存する取得プロセス、同期取得または伝播が適切に構成されていないと、メッセージが取得プロセスのキューに到達しない可能性があります。
取得プロセス、同期取得および伝播を含むすべてのOracle Streamsクライアントで使用されるルール・セットによって、これらのOracle Streamsクライアントの動作が決定されます。したがって、適用プロセスが依存する取得プロセス、同期取得または伝播のルール・セットに適切なルールが含まれていることを確認してください。これらのOracle Streamsクライアントのルールが適切に構成されていない場合、適用プロセスのキューが適切なメッセージを受信しない可能性があります。また、ストリームを介して送受信されるメッセージには、その過程で実行されるすべての変換が反映されます。たとえば、メッセージの取得中に取得プロセスがサブセット・ルールを使用して行の移行を実行し、伝播がメッセージにルールベースの変換を実行して表の名前を変更した場合、メッセージが適用プロセスに到達した時点で、適用プロセスのルールではこれらの変換を考慮する必要があります。
取得プロセスまたは同期取得が取得する変更が、複数のデータベースに伝播されて適用される環境では、次のガイドラインに従って、問題の原因は適用プロセスが依存する取得プロセス、同期取得取得または伝播にあるのか、あるいは適用プロセス自体にあるのかを判断できます。
取得プロセスまたは同期取得の他の宛先データベースでも変更が適用されない場合、問題の原因は取得プロセスまたは同期取得、あるいは取得プロセスに近い伝播にあると考えられます。この場合、まず取得プロセスまたは同期取得が適切に構成されていることを確認し、次に取得プロセスまたは同期取得に最も近い伝播が有効化され適切に構成されていることを確認します。取得プロセスの場合は、取得プロセスが有効化されていることも確認します。
取得プロセスまたは同期取得の他の宛先データベースで、変更が適用されている場合は、問題の原因は適用プロセス自体にあるか、その適用プロセスに近い伝播にあると考えられます。この場合、まず適用プロセスが有効化され適切に構成されていることを確認し、次にその適用プロセスに最も近い伝播が有効化され適切に構成されていることを確認します。
適用ハンドラを使用すると、適用プロセスでデキューされたメッセージをカスタマイズした方法で処理できます。このようなハンドラには、文DMLハンドラ、プロシージャDMLハンドラ、DDLハンドラ、プリコミット・ハンドラおよびメッセージ・ハンドラがあります。適用プロセスが予期したとおりに動作していない場合は、その適用プロセスで使用されるハンドラ・プロシージャをチェックして、不備があれば修正します。適用の問題を修正するには、文DMLハンドラでSQL文の修正が必要な場合があります。また、PL/SQLプロシージャの変更や削除が必要な場合もあります。
これらのプロシージャの名前は、DBA_APPLY_DML_HANDLERSおよびDBA_APPLYデータ・ディクショナリ・ビューを問い合せると検索できます。
AQ_TM_PROCESSES初期化パラメータは、キュー・メッセージに対する時間の監視、および遅延プロパティと有効期限プロパティが指定されたメッセージの処理を制御します。Oracle Database 10g以上では、AQ_TM_PROCESSES初期化パラメータが設定されていない場合、データベースによってこれらのアクションが自動的に制御されます。
適用プロセスのルール・セットを満たすメッセージが適用プロセス・キューに存在していても、適用プロセスによってメッセージが適用されない場合は、宛先データベースでAQ_TM_PROCESSES初期化パラメータが0に設定されていないことを確認します。このパラメータが0に設定されている場合は、その設定を解除するか、0以外の値に設定し、適用プロセスを監視してメッセージの適用が開始されるかどうかを確認します。
バッファ・キューにメッセージがあるかどうかを判別するには、V$BUFFERED_QUEUESおよびV$BUFFERED_SUBSCRIBERS動的パフォーマンス・ビューを問い合せます。永続キューにメッセージがあるかどうかを判別するには、そのキューのキュー表を問い合せます。
|
関連項目:
|
適用ユーザーに、適用ハンドラ・プロシージャまたはカスタム・ルールベースの変換ファンクションの明示的なEXECUTE権限がない場合、プロシージャまたはファンクションを実行しようとしてORA-26808エラーが発生することがあります。通常、このエラーでは、DBA_APPLY_ERRORビューにエラーが追加されずに適用プロセスが中断します。ただし、適用コーディネータのトレース・ファイルでエラーが報告されます。具体的には次のようなエラーがトレース・ファイルに記録されます。
ORA-26808: Apply process AP01 died unexpectedly
通常、このメッセージの前後にはエラー・メッセージがあり、それらのメッセージの1つ以上にプロシージャまたはファンクションの名前が含まれています。問題を解決するには、適用ユーザーに必要なEXECUTE権限を付与します。
適用サーバーとは適用プロセスのコンポーネントのことです。適用サーバーでは、DML変更およびDDL変更が宛先データベースのデータベース・オブジェクトに適用されます。適用プロセスでは1つ以上の適用サーバーを使用でき、parallelism適用プロセス・パラメータを使用して、トランザクションを同時に適用できる適用サーバーの数を指定します。たとえば、parallelismを5に設定すると、適用プロセスで合計5つの適用サーバーが使用されます。
適用サーバーが別のセッションで使用中のリソースを待機する必要がある場合、適用サーバーで競合が発生します。競合は論理的な依存性が原因で発生する可能性があります。たとえば、ユーザーがロックした行に対して適用サーバーで変更を適用する場合、適用サーバーはユーザーを待機する必要があります。また、競合は物理的な依存性が原因で発生する可能性もあります。たとえば、対象トランザクション・リスト(ITL)の競合は、適用中の2つのトランザクション(論理的に依存していない場合があります)がディスク上の同じブロックをロックしようとした場合に発生します。この場合、1つ目の適用サーバーがブロック内の行をロックすると、2つ目の適用サーバーは、異なる行をロックしようとしていてもブロックへのアクセスを待機する必要があります。ITLの競合の詳細は、「適用プロセスで依存トランザクションを待機しているか」を参照してください。
同じ適用プロセス内の別の適用サーバーに関係のない競合が適用サーバーで発生した場合、適用サーバーは競合が解決するまで待機します。同じ適用プロセス内の別の適用サーバーに関係のある競合が適用サーバーで発生した場合、2つの適用サーバーのいずれかがロールバックされます。複数の適用サーバーを使用中の適用プロセスでは、複数のトランザクションが同時に適用されることがあります。適用プロセスでは、コミットSCNが最小のトランザクションを適用中の適用サーバーの状態を追跡します。2つのトランザクション間に依存性がある場合、適用プロセスでは常に、コミットSCNが最小のトランザクションが最初に適用されます。コミットSCNがより大きいトランザクションは、他のトランザクションがコミットされるのを待機します。したがって、最小のコミットSCNのトランザクションを含む適用サーバーで競合が発生している場合には、競合の原因は依存トランザクション以外にあります。この場合、最小のコミットSCNのトランザクションを含む適用サーバーを監視して、競合の原因を判別できます。
適用サーバーの待機状態として、次の4とおりが考えられます。
待機していない: 適用サーバーで競合は発生しておらず、サーバーは待機していません。この場合、アクションは必要ありません。
別のセッションに関連していないイベントを待機中: 別のセッションに関連していないイベント例としては、log file syncイベントがあげられます。このイベントでは、コミットまたはロールバックが原因でREDOデータをフラッシュする必要があります。このような場合、こうした待機が一般的で通常一時的なものであるため、Oracle Databaseでは最初は何も書き込まれません。特定の時間間隔が経過しても適用サーバーが同じイベントを待機している場合、適用サーバーはアラート・ログおよび適用プロセスのトレース・ファイルにメッセージを書き込みます。たとえば、適用サーバーAS01では、次のようなメッセージが書き込まれる場合があります。
AS01: warning -- apply server 1, sid 26 waiting for event: AS01: [log file sync] ...
Oracle Databaseでは、問題が修正されるまで、この出力が周期的にアラート・ログに書き込まれます。
適用サーバー以外のセッションに関連しているイベントを待機中: 適用サーバーは、アラート・ログおよび適用プロセスのトレース・ファイルに即時にメッセージを書き込みます。たとえば、適用サーバー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
Oracle Databaseでは、問題が修正されるまで、この出力が周期的にアラート・ログに書き込まれます。
別の適用サーバー・セッションを待機中: この状態は対象トランザクション・リスト(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つ以上の他のセッションで同じブロックの行がロックされており、ブロックにITLの空きスロットがない場合です。
ITLの競合は、ビットマップ索引のフラグメントが共有されているためにセッションが待機中である場合にも発生する可能性があります。ビットマップ索引では、キー値およびROWID範囲が索引付けされます。ビットマップ索引の各エントリには実際の表の行を数多く含めることができます。同じビットマップ索引のフラグメントに含まれている行を2つのセッションで更新する必要がある場合、2番目のセッションは1番目のトランザクションがコミットまたはロールバックされるのを待機します。
適用プロセスでこのような依存性が検出されると、適用プロセスによってITLの競合が動的に解決され、その競合に関する情報がデータベースのアラート・ログおよび適用プロセスのトレース・ファイルに記録されます。デッドロックが検出されている間は進捗が停止する場合があるため、ITLの競合は適用プロセスのパフォーマンスに悪影響を与える可能性があります。
この問題が将来発生しないようにするには、次のアクションのいずれかを実行します。
使用可能なITLの数を増やします。このことを行うには、ALTER TABLE文を使用して表のINITRANS設定を変更します。
適用プロセスに対して、commit_serializationパラメータをDEPENDENT_TRANSACTIONSに設定します。
適用プロセスに対して、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リファレンス』を参照 |
適用プロセスでメッセージが適用できない場合は、そのメッセージおよび同じトランザクション内の他のすべてのメッセージがエラー・キューに移されます。適用エラーを定期的にチェックして、適用できなかったトランザクションの有無をチェックする必要があります。
適用プロセスによってトランザクションがエラー・キューに移動される場合は、トランザクションを確認してトランザクションを正常に再実行できる可能性を分析できます。トランザクションに異常が見つかった場合は、文DMLハンドラまたはプロシージャDMLハンドラを構成して問題を修正できることがあります。この場合、エラー・トランザクションを再実行するときに実行されるようにDMLハンドラを構成します。
DMLハンドラを使用してエラー・トランザクションの問題を修正する場合は、そのDMLハンドラを使用する適用プロセスを停止して、エラー・トランザクションに関係ないLCRがDMLハンドラによって処理されないようにする必要があります。正常に再実行した後で、DMLハンドラが不要であれば削除します。また、トランザクションがエラー・キューに移動される原因となった問題を修正して、将来エラー・トランザクションが発生しないようにします。
LCRについて次のタイプの適用プロセス・エラーが発生する場合があります。
前述のリストでアスタリスク(*)の付いたエラーは、通常、適用ハンドラまたはルールベースの変換に関する問題が原因となって発生します。
ORA-01031エラーは、適用ユーザーとして指定されたユーザーに、レプリケートされたオブジェクトにSQL操作を実行する権限がない場合に発生します。適用ユーザーの権限は直接付与するか、またはロールを介して付与できます。
具体的には、次の権限が必要となります。
表レベルのDML変更の場合は、INSERT、UPDATE、DELETEおよびSELECTの各権限が付与されている必要があります。
表レベルのDDL変更の場合は、ALTER TABLE権限が付与されている必要があります。
スキーマ・レベルの変更の場合は、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には、新しい値ではなく古い値が含まれている必要があります。
正しいパラメータ・タイプ(OLDまたはNEWあるいはその両方)が行LCRの操作(INSERT、UPDATEまたはDELETE)に対して指定されていることを確認します。たとえば、プロシージャDMLハンドラまたはカスタム・ルールベースの変換によってUPDATEの行LCRがINSERTの行LCRに変更される場合は、ハンドラまたは変換で行LCRの古い値が削除される必要があります。
適用ハンドラがエラーの原因である場合、適用ハンドラを修正し、エラー・トランザクションを再実行してください。カスタム・ルールベースの変換がエラーの原因である場合、DMLハンドラを作成して問題を修正できます。「DMLハンドラを使用したエラー・トランザクションの修正」を参照してください。また、将来エラーが発生しないようにルールベースの変換を修正します。
ORA-23607エラーは、メンバー・サブプログラムのcolumn_nameパラメータの値が行LCRの列名のいずれとも一致しない場合、行LCR(SYS.LCR$_ROW_RECORDタイプ)メンバー・サブプログラムが原因で発生します。行LCRの列名をチェックします。
適用ハンドラがエラーの原因である場合、適用ハンドラを修正し、エラー・トランザクションを再実行してください。カスタム・ルールベースの変換がエラーの原因である場合、DMLハンドラを作成して問題を修正できます。「DMLハンドラを使用したエラー・トランザクションの修正」を参照してください。また、将来エラーが発生しないようにルールベースの変換を修正します。
次の行LCRメンバー・プロシージャのいずれかを使用することにより、適用ハンドラまたはカスタム・ルールベースの変換が原因でこのエラーが発生する可能性があります。
DELETE_COLUMN(このプロシージャによって、行LCRから、行LCRに存在しない列の削除が試行される場合)
RENAME_COLUMN(このプロシージャによって、行LCRに存在しない列の名前の変更が試行される場合)
この場合、同様の問題が将来発生しないようにするには、次のアクションのいずれかを実行します。
行LCRの列を削除したり名前を変更するために適用ハンドラまたはカスタム・ルールベースの変換を使用するかわりに、宣言ルールベースの変換を使用します。宣言ルールベースの変換によって存在しない列の削除または名前の変更が試行される場合、宣言ルールベースの変換ではエラーは発生しません。DBMS_STREAMS_ADM.DELETE_COLUMNプロシージャを使用して列を削除する宣言ルールベースの変換を指定でき、DBMS_STREAMS_ADM.RENAME_COLUMNプロシージャを使用して列の名前を変更する宣言ルールベースの変換を指定できます。宣言ルールベースの変換は、適用ハンドラおよびカスタム・ルールベースの変換と組み合せて使用できます。
行LCRの列を削除したり名前を変更するのに適用ハンドラまたはカスタム・ルールベースの変換を引き続き使用する必要がある場合は、将来エラーが発生しないようにハンドラまたは変換を変更します。たとえば、ハンドラや変換を変更して列が存在していることを確認してから、その列を削除したり名前を変更します。
|
関連項目:
|
ORA-24031エラーは、適用ハンドラまたはカスタム・ルールベースの変換により、LCRメンバー・サブプログラムにNULLを含むANYDATAではなく、NULL値が渡された場合に発生する可能性があります。
たとえば、行LCRに対するADD_COLUMNメンバー・プロシージャの次のコールでは、このエラーが発生する可能性があります。
new_lcr.ADD_COLUMN('OLD','LANGUAGE',NULL);
次の例は、行LCRに対してADD_COLUMNメンバー・プロシージャを適切にコールする方法を示しています。
new_lcr.ADD_COLUMN('OLD','LANGUAGE',ANYDATA.ConvertVarchar2(NULL));
適用ハンドラがエラーの原因である場合、適用ハンドラを修正し、エラー・トランザクションを再実行してください。カスタム・ルールベースの変換がエラーの原因である場合、DMLハンドラを作成して問題を修正できます。「DMLハンドラを使用したエラー・トランザクションの修正」を参照してください。また、将来エラーが発生しないようにルールベースの変換を修正します。
ORA-26687エラーは、適用プロセスが変更の適用を試行しているオブジェクトにインスタンス化SCNが設定されていない場合に発生します。この場合、DBA_APPLY_INSTANTIATED_OBJECTSデータ・ディクショナリ・ビューに問い合せ、インスタンス化SCNを持つオブジェクトをリストできます。
インスタンス化SCNは、ソース・データベースでオブジェクトをエクスポートしてから宛先データベースでそれらのオブジェクトをインポートすることにより、1つ以上のオブジェクトに対して設定できます。データ・ポンプ・エクスポート/インポートを使用できます。エクスポート/インポートを使用しない場合は、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が明示的に設定される場合、データの正確性についての責任は管理者にあります。
この場合、データベース・オブジェクトに対してインスタンス化SCNを明示的に設定します。または、メタデータのみのエクスポート/インポートを実行してインスタンス化SCNを設定することもできます。
DDL変更を適用する必要があるものの、スキーマ・レベルまたはグローバル・レベルでインスタンス化SCNを設定しませんでした。
この場合、SET_SCHEMA_INSTANTIATION_SCNプロシージャを実行して適切なスキーマに対してインスタンス化SCNを設定するか、またはSET_GLOBAL_INSTANTIATION_SCNプロシージャを実行してソース・データベースに対してインスタンス化SCNを設定します。これらのプロシージャは両方ともDBMS_APPLY_ADMパッケージにあります。
エラーが発生する原因となった状態を修正した後、エラー・トランザクションを再実行または削除する必要があるかどうかは、トランザクションに含まれる変更がエラー状態を修正したときに宛先データベースで実行されたかどうかによって異なります。エラー・キュー内のトランザクションを再実行または削除する必要があるかどうかを決定するときには、次のガイドラインに従ってください。
新規エクスポート/インポートを実行し、新規エクスポートにエラー・キュー内のトランザクションが含まれる場合は、エラー・キュー内のトランザクションを削除します。
インスタンス化SCNを明示的に設定するか既存のエクスポート・ダンプ・ファイルを再インポートした場合は、エラー・キュー内のトランザクションを再実行します。
通常、ORA-26688エラーは次の状態のいずれかが原因となって発生します。
トランザクションの少なくとも1つのLCRに、そのLCRを適用するための適用プロセスに関する十分な情報が含まれていない状態。依存性を計算する場合、適用プロセスでは常に、宛先データベースで定義された主キー列(複数可)の値が必要となります。また、変更を適用する任意の適用プロセスの並列性が1より大きい場合、適用プロセスでは、宛先データベースで任意の索引列(一意または一意でない索引列、外部キー列およびビットマップ索引列など)の値が必要となります。
適用プロセスで列に値が設定されている必要があり、その列がソース・データベースに存在する場合、ソース・データベースでこれらの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ハンドラを使用したエラー・トランザクションの修正」を参照してください。
宛先の表の行における一部の列の値が、行LCRの対応する列の古い値と一致しない場合、ORA-26786エラーが発生します。
将来適用エラーが発生しないようにするには、競合ハンドラ、DMLハンドラまたはエラー・ハンドラを構成できます。ハンドラによって、レプリケーション環境にとって適切な方法で一致しない列が解決される必要があります。
また、このエラーが原因となって発生した既存のエラー・トランザクションを適用するようにDMLハンドラを構成できる場合があります。「DMLハンドラを使用したエラー・トランザクションの修正」を参照してください。
または、行LCRを正常に適用できるように行の現在の値を更新できます。行への変更が宛先データベースで取得プロセスまたは同期取得によって取得される場合、このような手動による変更が他の宛先データベースに対してレプリケートされないようにすることがあります。この場合、次の手順を実行します。
行を修正するセッションでタグを設定します。手動による変更がレプリケートされないようにする値をタグに設定するようにしてください。たとえば、タグにより、取得プロセスまたは同期取得によって変更が取得されないようにすることができます。
EXEC DBMS_STREAMS.SET_TAG(tag => HEXTORAW('17'));
環境によっては、異なる値をタグに設定する必要がある場合があります。
データがLCRの古い値と一致するように表の行を更新します。
該当するエラーまたはすべてのエラーを再実行します。1つのエラーを再実行するには、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以外の値をタグに設定する必要があります。
行LCRが更新または削除しようとしている行が宛先の表に存在しない場合、ORA-26787エラーが発生します。
将来適用エラーが発生しないようにするには、競合ハンドラ、DMLハンドラまたはエラー・ハンドラを構成できます。ハンドラによって、レプリケーション環境にとって適切な方法で、対応する表の行が存在しない行LCRが解決されます。
また、このエラーが原因となって発生した既存のエラー・トランザクションを適用するようにDMLハンドラを構成できる場合があります。「DMLハンドラを使用したエラー・トランザクションの修正」を参照してください。
または、行LCRを正常に適用できるように行の現在の値を更新できます。手順については、「ORA-26786 キーの行は存在しますが、競合する列が表にあります」を参照してください。
