33 適用のトラブルシューティング
33.1 適用プロセスが有効かどうか
適用プロセスが変更を適用するのは、そのプロセスが有効になっている場合のみです。
適用プロセスが有効か、無効か、中断されているかは、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';
関連項目:
-
Oracle Real Application Clusters (Oracle RAC)環境で適用プロセスを再起動する方法については、「適用プロセスおよびOracle Real Application Clusters」を参照
33.2 現行の適用プロセスかどうか
適用プロセスによって最近の変更が適用されていない場合、問題は適用プロセスの遅延である可能性があります。適用プロセスの待機時間が長い場合は、parallelism
適用プロセス・パラメータの設定を調整すると、パフォーマンスを改善できることがあります。
V$STREAMS_APPLY_COORDINATOR
動的パフォーマンス・ビューを問い合せて、適用プロセスの待機時間をチェックできます。
関連項目:
-
適用プロセス・パラメータの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』の
DBMS_APPLY_ADM.SET_PARAMETER
プロシージャに関する項を参照
33.3 適用プロセスが取得LCRに適用されているか
適用プロセスはバッファ・キューの取得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
適用プロセスが予期したタイプのメッセージを適用しないときは、これらのメッセージを適用するために適用プロセスの作成が必要になる場合があります。
関連項目:
-
Oracle Streamsレプリケーションの詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照
33.4 適用プロセスのキューが適用するメッセージを受信しているか
適用プロセスがメッセージを適用するためには、その前にキューにメッセージを受信する必要があります。このため、適用プロセスが、取得プロセスまたは同期取得で取得されるメッセージを適用する場合、それらのメッセージを取得する取得プロセスまたは同期取得が適切に構成されていることが必要です。また、取得プロセスの場合は有効になっている必要があります。同じく、メッセージが1つまたは複数のデータベースから伝播されて適用プロセスに送られる場合は、各伝播が有効になっており、適切に構成されていることが必要です。適用プロセスが依存する取得プロセス、同期取得または伝播が適切に構成されていないと、メッセージが取得プロセスのキューに到達しない可能性があります。
取得プロセス、同期取得および伝播を含むすべてのOracle Streamsクライアントで使用されるルール・セットによって、これらのOracle Streamsクライアントの動作が決定されます。したがって、適用プロセスが依存する取得プロセス、同期取得または伝播のルール・セットに適切なルールが含まれていることを確認してください。これらのOracle Streamsクライアントのルールが適切に構成されていない場合、適用プロセスのキューが適切なメッセージを受信しない可能性があります。また、ストリームを介して送受信されるメッセージには、その過程で実行されるすべての変換が反映されます。たとえば、メッセージの取得中に取得プロセスがサブセット・ルールを使用して行の移行を実行し、伝播がメッセージにルールベースの変換を実行して表の名前を変更した場合、メッセージが適用プロセスに到達した時点で、適用プロセスのルールではこれらの変換を考慮する必要があります。
取得プロセスまたは同期取得が取得する変更が、複数のデータベースに伝播されて適用される環境では、次のガイドラインに従って、問題の原因は適用プロセスが依存する取得プロセス、同期取得取得または伝播にあるのか、あるいは適用プロセス自体にあるのかを判断できます。
-
取得プロセスまたは同期取得の他の宛先データベースでも変更が適用されない場合、問題の原因は取得プロセスまたは同期取得、あるいは取得プロセスに近い伝播にあると考えられます。この場合、まず取得プロセスまたは同期取得が適切に構成されていることを確認し、次に取得プロセスまたは同期取得に最も近い伝播が有効化され適切に構成されていることを確認します。取得プロセスの場合は、取得プロセスが有効化されていることも確認します。
-
取得プロセスまたは同期取得の他の宛先データベースで、変更が適用されている場合は、問題の原因は適用プロセス自体にあるか、その適用プロセスに近い伝播にあると考えられます。この場合、まず適用プロセスが有効化され適切に構成されていることを確認し、次にその適用プロセスに最も近い伝播が有効化され適切に構成されていることを確認します。
33.5 カスタム適用ハンドラが指定されているか
適用ハンドラを使用すると、適用プロセスでデキューされたメッセージをカスタマイズした方法で処理できます。このようなハンドラには、文DMLハンドラ、プロシージャDMLハンドラ、DDLハンドラ、プリコミット・ハンドラおよびメッセージ・ハンドラがあります。適用プロセスが予期したとおりに動作していない場合は、その適用プロセスで使用されるハンドラ・プロシージャをチェックして、不備があれば修正します。適用の問題を修正するには、文DMLハンドラでSQL文の修正が必要な場合があります。また、PL/SQLプロシージャの変更や削除が必要な場合もあります。
これらのプロシージャの名前は、DBA_APPLY_DML_HANDLERS
およびDBA_APPLY
データ・ディクショナリ・ビューを問い合せると検索できます。
33.6 AQ_TM_PROCESSES初期化パラメータが0に設定されているか
AQ_TM_PROCESSES
初期化パラメータは、キュー・メッセージに対する時間の監視、および遅延プロパティと有効期限プロパティが指定されたメッセージの処理を制御します。Oracle Database 10g以上では、AQ_TM_PROCESSES
初期化パラメータが設定されていない場合、データベースによってこれらのアクションが自動的に制御されます。
適用プロセスのルール・セットを満たすメッセージが適用プロセス・キューに存在していても、適用プロセスによってメッセージが適用されない場合は、宛先データベースでAQ_TM_PROCESSES
初期化パラメータが0に設定されていないことを確認します。このパラメータが0に設定されている場合は、その設定を解除するか、0以外の値に設定し、適用プロセスを監視してメッセージの適用が開始されるかどうかを確認します。
バッファ・キューにメッセージがあるかどうかを判別するには、V$BUFFERED_QUEUES
およびV$BUFFERED_SUBSCRIBERS
動的パフォーマンス・ビューを問い合せます。永続キューにメッセージがあるかどうかを判別するには、そのキューのキュー表を問い合せます。
関連項目:
-
AQ_TM_PROCESSES
初期化パラメータの詳細は、『Oracle Databaseアドバンスト・キューイング・ユーザーズ・ガイド』を参照
33.7 適用ユーザーに必要な権限があるか
適用ユーザーに、適用ハンドラ・プロシージャまたはカスタム・ルールベースの変換ファンクションの明示的なEXECUTE
権限がない場合、プロシージャまたはファンクションを実行しようとしてORA-26808
エラーが発生することがあります。通常、このエラーでは、DBA_APPLY_ERROR
ビューにエラーが追加されずに適用プロセスが中断します。ただし、適用コーディネータのトレース・ファイルでエラーが報告されます。具体的には次のようなエラーがトレース・ファイルに記録されます。
ORA-26808: Apply process AP01 died unexpectedly
通常、このメッセージの前後にはエラー・メッセージがあり、それらのメッセージの1つ以上にプロシージャまたはファンクションの名前が含まれています。問題を解決するには、適用ユーザーに必要なEXECUTE
権限を付与します。
33.8 適用プロセスで競合が発生しているか
適用サーバーとは適用プロセスのコンポーネントのことです。適用サーバーでは、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
列を問い合せます。
関連項目:
-
競合、および様々なタイプの競合の解決の詳細は、『Oracle Databaseパフォーマンス・チューニング・ガイド』を参照
33.9 適用プロセスで依存トランザクションを待機しているか
適用プロセスの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
に設定します。
関連項目:
-
適用プロセス・パラメータの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照
-
INITRANS
の詳細は、『Oracle Database管理者ガイド』および『Oracle Database SQL言語リファレンス』を参照
33.10 適用サーバーのパフォーマンスが特定のトランザクションに対して低いか
適用プロセスのパフォーマンスがよくない場合、適用プロセスによって使用される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リファレンス』を参照
33.11 エラー・キューに適用エラーがあるか
適用プロセスでメッセージが適用できない場合は、そのメッセージおよび同じトランザクション内の他のすべてのメッセージがエラー・キューに移されます。適用エラーを定期的にチェックして、適用できなかったトランザクションの有無をチェックする必要があります。
関連項目:
33.11.1 DMLハンドラを使用したエラー・トランザクションの修正
適用プロセスによってトランザクションがエラー・キューに移動される場合は、トランザクションを確認してトランザクションを正常に再実行できる可能性を分析できます。トランザクションに異常が見つかった場合は、文DMLハンドラまたはプロシージャDMLハンドラを構成して問題を修正できることがあります。この場合、エラー・トランザクションを再実行するときに実行されるようにDMLハンドラを構成します。
DMLハンドラを使用してエラー・トランザクションの問題を修正する場合は、そのDMLハンドラを使用する適用プロセスを停止して、エラー・トランザクションに関係ないLCRがDMLハンドラによって処理されないようにする必要があります。正常に再実行した後で、DMLハンドラが不要であれば削除します。また、トランザクションがエラー・キューに移動される原因となった問題を修正して、将来エラー・トランザクションが発生しないようにします。
関連項目:
33.11.2 特定の適用エラーのトラブルシューティング
LCRについて次のタイプの適用プロセス・エラーが発生する場合があります。
前述のリストでアスタリスク(*)の付いたエラーは、通常、適用ハンドラまたはルールベースの変換に関する問題が原因となって発生します。
33.11.2.1 ORA-01031 権限が不足しています
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
データ・ディクショナリ・ビューを問い合せて、適用ユーザーに付与されていない必須の権限を判別します。- 権限を付与できる管理ユーザーとして接続します。
- 必要な権限を適用ユーザーに付与します。
- 適用プロセスのエラー・キューにあるエラー・トランザクションを再実行します。
関連項目:
33.11.2.2 ORA-01403 データが見つかりません。
通常、ORA-01403
エラーは、適用プロセスが既存の行の更新を試行した際に、行LCRのOLD_VALUES
が宛先データベースの現在の値と一致しない場合に発生します。
通常、このエラーは次の状態のいずれかが原因となって発生します。
-
ソース・データベースでサプリメンタル・ロギングを必要とする列に対してサプリメンタル・ロギングが指定されていない状態。この場合、ソース・データベースのLCRにキー列値が含まれていないことがあります。プロシージャDMLハンドラを使用して、必要なサプリメンタル・データが含まれるようにLCRを変更できます。「DMLハンドラを使用したエラー・トランザクションの修正」を参照してください。また、将来エラーが発生しないように、ソース・データベースで必要なサプリメンタル・ロギングを指定します。
-
LCRが変更を適用する表の主キーに問題がある状態。この場合、
DBA_CONSTRAINTS
データ・ディクショナリ・ビューを問い合せて主キーが使用可能となるようにします。表に対して主キーが存在しないか、または対象の表の主キーがソース表の主キーと異なる場合は、DBMS_APPLY_ADM
パッケージのSET_KEY_COLUMNS
プロシージャを使用して代替キー列を指定します。また、適用されている表に主キーが存在しない場合、エラーORA-23416
が発生することもあります。これらの変更を行った後、エラー・トランザクションを再実行できます。 -
適用されているトランザクションが、まだ実行されていない別のトランザクションに依存している状態。たとえば、トランザクションで
employee_id
が300
の従業員を更新しようとしたものの、この従業員の行がまだemployees
表に挿入されていない場合、更新は失敗します。この場合、エラー・トランザクションが依存するトランザクションを実行します。次に、エラー・トランザクションを再実行します。
関連項目:
-
適用エラーの考えられる原因の詳細は、「表へのDML変更の適用に関する考慮事項」を参照
-
「適用エラーの管理」
-
Oracle Streamsタグの詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照
33.11.2.3 ORA-23605 Oracle Streamsパラメータの値が無効です
行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ハンドラを使用したエラー・トランザクションの修正」を参照してください。また、将来エラーが発生しないようにルールベースの変換を修正します。
関連項目:
33.11.2.4 ORA-23607 無効な列
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の列を削除したり名前を変更するのに適用ハンドラまたはカスタム・ルールベースの変換を引き続き使用する必要がある場合は、将来エラーが発生しないようにハンドラまたは変換を変更します。たとえば、ハンドラや変換を変更して列が存在していることを確認してから、その列を削除したり名前を変更します。
関連項目:
-
行LCRの
DELETE_COLUMN
およびRENAME_COLUMN
メンバー・プロシージャの詳細は、『Oracle Database PL/SQLパッケージおよびタイプ・リファレンス』を参照
33.11.2.5 ORA-24031 値が無効です。parameter_nameにはNULLでない値が必要です。
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ハンドラを使用したエラー・トランザクションの修正」を参照してください。また、将来エラーが発生しないようにルールベースの変換を修正します。
関連項目:
33.11.2.6 ORA-26687 インスタンス化SCNが指定されていません
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を明示的に設定するか既存のエクスポート・ダンプ・ファイルを再インポートした場合は、エラー・キュー内のトランザクションを再実行します。
関連項目:
-
インスタンス化の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照
33.11.2.7 ORA-26688 LCRにキーがありません。
通常、ORA-26688
エラーは次の状態のいずれかが原因となって発生します。
-
トランザクションの少なくとも1つのLCRに、そのLCRを適用するための適用プロセスに関する十分な情報が含まれていない状態。依存性を計算する場合、適用プロセスでは常に、宛先データベースで定義された主キー列(複数可)の値が必要となります。また、変更を適用する任意の適用プロセスの並列性が1より大きい場合、適用プロセスでは、宛先データベースで任意の索引列(一意または一意でない索引列、外部キー列およびビットマップ索引列など)の値が必要となります。
適用プロセスで列に値が設定されている必要があり、その列がソース・データベースに存在する場合、ソース・データベースでこれらの1つ以上の列に対してサプリメンタル・ロギングが指定されていないとこのエラーが発生します。この場合、適用エラーを回避するには、ソース・データベースで必要なサプリメンタル・ロギングを指定します。
ただし、ソース・データベース表の定義が対応する宛先データベース表の定義と異なる場合があります。適用プロセスで列に値が設定されている必要があり、その列が宛先データベースに存在するがソース・データベースには存在しない場合、ソース・データベースのLCRに必要な値を追加するようにルールベースの変換を構成し、適用エラーを回避できます。
このエラーが原因でエラー・キューに置かれたトランザクションを修正するには、プロシージャDMLハンドラを使用して、必要なサプリメンタル・データが含まれるようにLCRを変更できます。「DMLハンドラを使用したエラー・トランザクションの修正」を参照してください。
-
LCRが変更を適用する表の主キーに問題がある状態。この場合、
DBA_CONSTRAINTS
データ・ディクショナリ・ビューを問い合せて主キーが使用可能となるようにします。表に対して主キーが存在していないか、または宛先の表の主キーがソース表の主キーと異なる場合は、DBMS_APPLY_ADM
パッケージのSET_KEY_COLUMNS
プロシージャを使用して代替キー列を指定します。また、表に主キーが存在しない場合、エラーORA-23416
が発生することもあります。これらの変更を行った後、エラー・トランザクションを再実行できます。
関連項目:
33.11.2.8 ORA-26689 列データ型が一致していません
通常、ORA-26689
エラーは、ソース・データベース内の1つ以上の列が宛先データベースの対応する列と一致しないために発生します。ソース・データベースのLCRに宛先データベースの表よりも多くの列が含まれていたり、1つ以上の列に対して列名や列の型が一致していない場合があります。列がデータベース間で異なる場合は、ルールベースの変換を使用して将来エラーが発生しないようにできます。
適用ハンドラまたはカスタム・ルールベースの変換を使用する場合は、任意のANYDATA
変換ファンクションが変換対象のLCRのデータ型と一致することを確認します。たとえば、列がVARCHAR2
として指定されている場合、ANYDATA.CONVERTVARCHAR2
ファンクションを使用して、データを型ANY
からVARCHAR2
に変換します。
また、ルール条件、適用ハンドラおよびルールベースの変換で適切な大/小文字を使用していることを確認してください。たとえば、列名がデータ・ディクショナリですべて大文字となっている場合、ルール条件、適用ハンドラおよびルールベースの変換ですべて大文字を使用して列名を指定する必要があります。
このエラーは、サプリメンタル・ロギングがソース・データベースの非キー列に対して必須である場所で指定されていないために発生する可能性もあります。この場合、ソース・データベースのLCRにはこれらの非キー列に対する必要な値が含まれていないことがあります。
エラー・トランザクションを適用するようにDMLハンドラを構成できる場合があります。「DMLハンドラを使用したエラー・トランザクションの修正」を参照してください。
関連項目:
-
適用エラーの考えられる原因の詳細は、「表へのDML変更の適用に関する考慮事項」を参照
33.11.2.9 ORA-26786 キーの行は存在しますが、競合する列が表にあります
宛先の表の行における一部の列の値が、行LCRの対応する列の古い値と一致しない場合、ORA-26786
エラーが発生します。
将来適用エラーが発生しないようにするには、競合ハンドラ、DMLハンドラまたはエラー・ハンドラを構成できます。ハンドラによって、レプリケーション環境にとって適切な方法で一致しない列が解決される必要があります。
また、このエラーが原因となって発生した既存のエラー・トランザクションを適用するようにDMLハンドラを構成できる場合があります。「DMLハンドラを使用したエラー・トランザクションの修正」を参照してください。
または、行LCRを正常に適用できるように行の現在の値を更新できます。行への変更が宛先データベースで取得プロセスまたは同期取得によって取得される場合、このような手動による変更が他の宛先データベースに対してレプリケートされないようにすることがあります。この場合、次の手順を実行します。
関連項目:
-
競合解決の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照
33.11.2.10 ORA-26787 キーcolumn_valueの行は表table_nameにありません
行LCRが更新または削除しようとしている行が宛先の表に存在しない場合、ORA-26787
エラーが発生します。
将来適用エラーが発生しないようにするには、競合ハンドラ、DMLハンドラまたはエラー・ハンドラを構成できます。ハンドラによって、レプリケーション環境にとって適切な方法で、対応する表の行が存在しない行LCRが解決されます。
また、このエラーが原因となって発生した既存のエラー・トランザクションを適用するようにDMLハンドラを構成できる場合があります。「DMLハンドラを使用したエラー・トランザクションの修正」を参照してください。
または、行LCRを正常に適用できるように行の現在の値を更新できます。詳細は、「ORA-26786 キーの行は存在しますが、競合する列が表にあります」を参照してください。
関連項目:
-
競合解決の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照