31 暗黙的取得のトラブルシューティング

次の各項では、Oracle Streams環境での取得プロセスおよび同期取得の一般的な問題の特定と解決について説明します。

• 取得プロセスの問題のトラブルシューティング

• 同期取得に関する問題のトラブルシューティング

取得プロセスの問題のトラブルシューティング

取得プロセスで予期したとおりに変更が取得されない場合や、取得プロセスに他の問題が発生した場合は、次のチェックリストを使用し、問題を特定して解決します。

• 取得プロセスの作成またはデータ・ディクショナリのビルドに長時間を要していないか

• 取得プロセスが有効かどうか

• 取得プロセスでREDOを待機しているか

• 取得プロセスでフロー制御のために一時停止しているか

• 現行の取得プロセスかどうか

• 必須のREDOログ・ファイルが欠落していないか

• ダウンストリーム取得プロセスがREDOデータを待機していないか

• 不適切にダウンストリーム取得の構成を試行していないか

• 適切な認証を使用しないでダウンストリーム取得の構成を試行していないか

• データベース・リンクのないダウンストリーム取得に追加のアクションが必要か

関連項目: 「Oracle Streams取得プロセスによる暗黙的取得」 取得プロセスの構成の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照 「取得プロセスの管理」 「取得プロセスの監視」

取得プロセスの作成またはデータ・ディクショナリのビルドに長時間を要していないか

取得プロセスの作成またはデータ・ディクショナリのビルドに異常に長い時間を要している場合は、まだコミットされていない、処理中のトランザクションがあることが原因である場合があります。処理中のトランザクションとは、取得プロセスの作成時またはデータ・ディクショナリのビルド時にアクティブなトランザクションです。

処理中のトランザクションの有無を判別するには、アラート・ログで次のメッセージをチェックします。

wait for inflight txns at this scn
Done with waiting for inflight txns at this scn

アラート・ログに最初のメッセージのみが表示される場合、取得プロセスの作成またはデータ・ディクショナリのビルドは処理中のトランザクションの待機状態であり、処理中のトランザクションがすべてのコミットされた後に完了します。

関連項目: 取得プロセスの構成の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照 「取得プロセスの作成」 「トレース・ファイルとアラート・ログでの問題のチェック」

取得プロセスが有効かどうか

取得プロセスが変更を取得するのは、そのプロセスが有効になっている場合のみです。

取得プロセスが有効か、無効か、中断されているかは、DBA_CAPTUREデータ・ディクショナリ・ビューを問い合せるとチェックできます。たとえば、captureという取得プロセスが有効かどうかをチェックするには、次の問合せを実行します。

SELECT STATUS FROM DBA_CAPTURE WHERE CAPTURE_NAME = 'CAPTURE';

取得プロセスが無効の場合は、出力が次のようになります。

STATUS
--------
DISABLED

取得プロセスが無効の場合は、再起動してみてください。取得プロセスが中断されている場合、エラーを修正しないと正常に再起動できないことがあります。

取得プロセスが中断された理由を特定するには、DBA_CAPTUREデータ・ディクショナリ・ビューを問い合せるか、取得プロセスのトレース・ファイルをチェックします。次の問合せでは、取得プロセスがいつ中断されたかと、中断の原因となったエラーが表示されます。

COLUMN CAPTURE_NAME HEADING 'Capture|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 CAPTURE_NAME, STATUS_CHANGE_TIME, ERROR_NUMBER, ERROR_MESSAGE
  FROM DBA_CAPTURE WHERE STATUS='ABORTED';

関連項目: 「取得プロセスの起動」 「トレース・ファイルとアラート・ログでの問題のチェック」 Oracle Real Application Clusters(Oracle RAC)環境で取得プロセスを再起動する方法については、「取得プロセスおよびOracle Real Application Clusters」を参照

取得プロセスでREDOを待機しているか

有効になっている取得プロセスで予期したとおりに変更が取得されない場合、取得プロセスはWAITING FOR REDOの状態にあります。

データベース内の各取得プロセスの状態をチェックするには、次の問合せを実行します。

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の場合、取得プロセスは新しいREDOログ・ファイルが取得プロセス・セッションに追加されるまで待機しています。この状態は、REDOログ・ファイルが欠落しているか、またはソース・データベースにアクティビティが存在しない場合に発生する可能性があります。ダウンストリーム取得プロセスでは、セッションに新しいログ・ファイルが追加されるのを取得プロセスが待機している場合に、この状態が発生する可能性があります。

V$STREAMS_CAPTUREビューを問い合せると、状態の情報とともに追加情報が表示されることがあります。追加情報は、取得プロセスがREDOを待機している理由を判別するのに役立ちます。たとえば、ビューを問い合せると、次のような文がSTATE列に対して表示される場合があります。

WAITING FOR REDO: LAST SCN MINED 8077284

この場合、出力では取得プロセスによってスキャンされた最後のシステム変更番号(SCN)のみが識別されます。場合によっては、出力でREDOログ・ファイル名が明示的に識別されることもあります。いずれにしても、追加情報は取得プロセスが待機しているREDOログを識別するのに役立ちます。問題を修正するには、欠落している任意のREDOログ・ファイルを取得プロセスに対して使用可能にします。

関連項目: 「ダウンストリーム取得プロセスが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;

取得プロセスの状態が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プールのサイズの拡大を試行します。

関連項目: 第16章「ステージングと伝播の管理」 第17章「Oracle Streams情報コンシュームの管理」 第12章「取得と適用の複合による最適化」

現行の取得プロセスかどうか

取得プロセスによって最近の変更が取得されていない場合は、取得プロセスの遅延が原因の可能性があります。これをチェックするには、V$STREAMS_CAPTURE動的パフォーマンス・ビューを問い合せます。取得プロセスの待機時間が長い場合は、parallelism取得プロセス・パラメータの設定を調整すると、パフォーマンスを改善できることがあります。

関連項目: 「各取得プロセスのREDOログのスキャン待機時間の判別」 「各取得プロセスのメッセージのエンキュー待機時間の判別」 「取得プロセスのサブコンポーネント」 「取得プロセス・パラメータの設定」

必須のREDOログ・ファイルが欠落していないか

取得プロセスの起動時または再起動時には、開始SCNを含むログ・ファイルよりも前に生成されたREDOログ・ファイルをスキャンする必要がある場合があります。取得プロセスの先頭SCNと開始SCNを確認するには、DBA_CAPTUREデータ・ディクショナリ・ビューを問い合せます。必要なREDOログ・ファイルを取得プロセスでスキャンする前に削除すると、取得プロセスが異常終了し、取得プロセスのトレース・ファイルで次のエラーが発生します。

ORA-01291: missing logfile

このエラーが表示された場合は、欠落しているREDOファイルをリストアした後、取得プロセスを再起動してみてください。V$LOGMNR_LOGS動的パフォーマンス・ビューをチェックして欠落しているSCNの範囲を特定し、該当するREDOログ・ファイルを追加できます。取得プロセスには、必須チェックポイントSCNを含むREDOログ・ファイルと、後続のすべてのREDOログ・ファイルが必要です。DBA_CAPTUREデータ・ディクショナリ・ビューのREQUIRED_CHECKPOINT_SCN列を問い合せると、取得プロセスの必須チェックポイントSCNを判別できます。

取得プロセスがCONTROL_FILE_RECORD_KEEP_TIME初期化パラメータで指定された時間よりも長い間無効である場合、欠落しているREDOログ・ファイルの情報が制御ファイルで置き換えられる可能性があります。V$ARCHIVE_LOGビューを問い合せて、ログ・ファイル名がリストされているかどうかを確認できます。リストされていない場合、ALTER DATABASE REGISTER OR REPLACE LOGFILE SQL文を使用して登録できます。

Oracle Streams環境内のソース・データベースでRecovery Manager(RMAN)の高速リカバリ領域機能を使用している場合、取得プロセスに必要なアーカイブREDOログ・ファイルがRMANによって削除されることがあります。リカバリ関連ファイルで使用されているディスク領域が、高速リカバリ領域で指定されたディスク割当て制限に近づくと、RMANによってこれらのファイルが削除される場合があります。将来この問題が発生するのを防止するには、次のアクションを1つ以上実行します。

• 高速リカバリ領域のディスク割当て制限を引き上げます。ディスク割当て制限を引き上げると、必要なアーカイブREDOログ・ファイルがRMANによって削除される可能性が低減しますが、必ずしも問題を回避できるわけではありません。

• アーカイブREDOログ・ファイルが高速リカバリ領域以外の場所に格納されるようにソース・データベースを構成します。ローカル取得プロセスでは、必要なログ・ファイルが高速リカバリ領域に見つからない場合に、別の場所にあるログ・ファイルを使用できます。この場合、別の場所にあるログ・ファイルをデータベース管理者が手動で管理する必要があります。

RMANでは、アーカイブREDOログ・ファイルを削除する前に、それらがバックアップされていることを常に確認します。取得プロセスに必要なアーカイブREDOログ・ファイルがRMANによって削除されると、このアクションがRMANによってアラート・ログに記録されます。

関連項目: 「ARCHIVELOGモードおよび取得プロセス」 「先頭SCNおよび開始SCN」 「各取得プロセスの登録済REDOログ・ファイルの表示」 高速リカバリ領域機能の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照

ダウンストリーム取得プロセスがREDOデータを待機していないか

ダウンストリーム取得プロセスで変更が取得されない場合は、スキャン対象のREDOデータを待機している可能性があります。REDOログ・ファイルはダウンストリーム取得プロセスに暗黙的に登録される場合と明示的に登録される場合があります。暗黙的に登録されるREDOログ・ファイルは、一般に次のいずれかの方法で登録されます。

• リアルタイム・ダウンストリーム取得プロセスの場合は、REDO転送サービスによって、ソース・データベースからダウンストリーム・データベースのスタンバイREDOログにREDOデータが送信されます。次に、ダウンストリーム・データベースのアーカイバによって、REDOログ・ファイルがアーカイブ時にダウンストリーム取得プロセスに登録されます。

• アーカイブ・ログ・ダウンストリーム取得プロセスの場合は、REDO転送サービスによって、アーカイブREDOログ・ファイルがソース・データベースからダウンストリーム・データベースに転送され、ダウンストリーム取得プロセスに登録されます。

REDOログ・ファイルがダウンストリーム取得プロセスに明示的に登録されている場合は、REDOログ・ファイルを手動でダウンストリーム・データベースに転送し、ダウンストリーム取得プロセスに登録する必要があります。

REDOログファイルが暗黙的に登録されるか、明示的に登録されるかにかかわりなく、ダウンストリーム取得プロセスでは適切なREDOログ・ファイルがその取得プロセスに登録されている場合にのみ、ソース・データベースで行われた変更が取得されます。V$STREAMS_CAPTURE動的パフォーマンス・ビューを問い合せると、ダウンストリーム取得プロセスがREDOログ・ファイルを待機しているかどうかを判別できます。たとえば、strm05_captureというダウンストリーム取得プロセスについて次の問合せを実行します。

SELECT STATE FROM V$STREAMS_CAPTURE WHERE CAPTURE_NAME='STRM05_CAPTURE';

取得プロセスの状態がWAITING FOR DICTIONARY REDOまたはWAITING FOR REDOの場合は、DBA_REGISTERED_ARCHIVED_LOGおよびDBA_CAPTUREデータ・ディクショナリ・ビューを問い合せて、REDOログ・ファイルがそのダウンストリーム取得プロセスに登録されているかどうかを確認します。たとえば次の問合せでは、strm05_captureダウンストリーム取得プロセスに現在登録されているREDOログ・ファイルがリストされます。

COLUMN SOURCE_DATABASE HEADING 'Source|Database' FORMAT A15
COLUMN SEQUENCE# HEADING 'Sequence|Number' FORMAT 9999999
COLUMN NAME HEADING 'Archived Redo Log|File Name' FORMAT A30
COLUMN DICTIONARY_BEGIN HEADING 'Dictionary|Build|Begin' FORMAT A10
COLUMN DICTIONARY_END HEADING 'Dictionary|Build|End' FORMAT A10

SELECT r.SOURCE_DATABASE,
       r.SEQUENCE#, 
       r.NAME, 
       r.DICTIONARY_BEGIN, 
       r.DICTIONARY_END 
  FROM DBA_REGISTERED_ARCHIVED_LOG r, DBA_CAPTURE c
  WHERE c.CAPTURE_NAME = 'STRM05_CAPTURE' AND 
        r.CONSUMER_NAME = c.CAPTURE_NAME;

この問合せによって行が返されない場合、現在、この取得プロセスにREDOファイルは登録されていません。この取得プロセスのためにソース・データベースからダウンストリーム・データベースにREDOデータを転送するようREDO転送サービスを構成した場合は、REDO転送サービスが正しく構成されていることを確認してください。REDO転送サービスが正しく構成されている場合は、ソース・データベースでALTER SYSTEM ARCHIVE LOG CURRENT文を実行してログ・ファイルをアーカイブします。REDOデータを転送するようREDO転送サービスを構成しなかった場合は、ログ・ファイルの転送と登録に使用している方法が正常に機能していることを確認してください。ALTER DATABASE REGISTER LOGICAL LOGFILE文を使用すると、ログ・ファイルを明示的に登録できます。

ダウンストリーム取得プロセスがREDOを待機している場合、ソース・データベースとダウンストリーム・データベースの間のネットワーク接続に問題がある可能性もあります。また、ログ・ファイルの転送方法に問題がある可能性もあります。ネットワーク接続とログ・ファイルの転送方法をチェックして、それらが正常に機能していることを確認してください。

リアルタイム・ダウンストリーム取得プロセスを構成していて、その取得プロセスにREDOログ・ファイルが登録されていない場合は、ソース・データベースのログ・ファイルを切り替えてみてください。ソース・データベースにアクティビティがほとんどまたはまったく存在しない場合は、ログ・ファイルを複数回切替える必要がある場合があります。

また、ダウンストリーム取得プロセスを使用して履歴データの変更を取得する予定の場合は、さらに次の項目を考慮します。

• REDOログ・ファイルが生成されるソース・データベースと、ダウンストリーム取得プロセスが実行されるデータベースは、どちらもOracle Database 10g以上のデータベースである必要があります。

• 作成されたデータ・ディクショナリの先頭が、最も早く追加されたREDOログに存在している必要があります。また、取得プロセスが、作成されたデータ・ディクショナリの先頭と一致する先頭SCNで構成されている必要があります。

• 取得プロセスで変更を取得するデータベース・オブジェクトは、ダウンストリーム・データベースではなくソース・データベースでインスタンス化のために準備する必要があります。また、インスタンス化のためにオブジェクトを準備する場合、過去の時点は指定できません。オブジェクトは常に現行のデータベースSCNでインスタンス化のために準備され、オブジェクトがインスタンス化のために準備された後に発生したデータベース・オブジェクトの変更のみを取得プロセスによって取得できます。

関連項目: 「ローカル取得およびダウンストリーム取得」 取得プロセスの状態 取得プロセスの構成の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

不適切にダウンストリーム取得の構成を試行していないか

ダウンストリーム取得プロセスを作成するには、次のプロシージャのいずれかを使用する必要があります。

• DBMS_CAPTURE_ADM.CREATE_CAPTURE

• DBMS_STREAMS_ADM.MAINTAIN_GLOBAL

• DBMS_STREAMS_ADM.MAINTAIN_SCHEMAS

• DBMS_STREAMS_ADM.MAINTAIN_SIMPLE_TTS

• DBMS_STREAMS_ADM.MAINTAIN_TABLES

• DBMS_STREAMS_ADM.MAINTAIN_TTS

• DBMS_STREAMS_ADMパッケージのPRE_INSTANTIATION_SETUPおよびPOST_INSTANTIATION_SETUP

DBMS_STREAMS_ADMパッケージのプロシージャでは、ダウンストリーム取得プロセス以外にも、Oracle Streamsレプリケーション環境のその他のOracle Streamsコンポーネントを構成できます。

これらのプロシージャを使用せずにダウンストリーム取得プロセスを作成しようとすると、次のエラーが戻されます。

ORA-26678: Streams capture process must be created first

この問題を修正するには、これらのプロシージャのいずれかを使用してダウンストリーム取得プロセスを作成します。

DBMS_STREAMS_ADMパッケージのプロシージャを使用してローカル取得プロセスを作成しているときにこのエラーが発生した場合は、実行しているプロシージャのsource_databaseパラメータに指定されているデータベース名が、ローカル・データベースのグローバル名と一致していることを確認します。

関連項目: 取得プロセスの構成の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

適切な認証を使用しないでダウンストリーム取得の構成を試行していないか

ソース・データベースおよびダウンストリーム取得データベース間で認証が適切に構成されていないと、REDOデータ転送が次のいずれかのエラーで失敗します。

ORA-16191: Primary log shipping client not logged on standby
 
ORA-1017: Invalid username/password; login denied

REDO転送セッションは、Secure Sockets Layer(SSL)プロトコルまたはリモート・ログイン・パスワード・ファイルのいずれかを使用して認証されます。

この問題を修正するには、パスワード・ファイルが、ソース・データベースとダウンストリーム取得データベースで同じであることを確認します。ソース・データベースにリモート・ログイン・パスワード・ファイルがある場合は、問題を修正するために、そのファイルをダウンストリーム取得データベース・システムの適切なディレクトリにコピーします。ファイルをコピーした後、両方のデータベースを再起動して変更を反映する必要がある場合があります。

関連項目: REDO転送の認証要件の詳細は、『Oracle Data Guard概要および管理』を参照

データベース・リンクのないダウンストリーム取得に追加のアクションが必要か

ダウンストリーム取得がデータベース・リンク付きで構成されている場合は、そのデータベース・リンクを使用してソース・データベースで操作を実行し、ソース・データベースから自動的に情報を取得できます。ダウンストリーム取得がデータベース・リンクなしで構成されている場合は、これらのアクションを手動で実行し、情報を手動で取得する必要があります。これらのアクションを手動で完了しないでダウンストリーム取得プロセスを作成しようとすると、エラーが発生します。

ダウンストリーム取得をデータベース・リンクなしで構成する場合、具体的には次のアクションを手動で実行する必要があります。

• 状況によっては、取得プロセスを作成する前にソース・データベースでDBMS_CAPTURE_ADM.BUILDプロシージャを実行して、ソース・データベースのデータ・ディクショナリをREDOログに抽出する必要があります。

• ソース・データベース・オブジェクトをインスタンス化のために準備する必要があります。

• ダウンストリーム取得プロセスの先頭SCNを取得し、DBMS_CAPTURE_ADMパッケージのCREATE_CAPTUREプロシージャを使用して取得プロセスを作成する際に、first_scnパラメータでその先頭SCNを指定する必要があります。

関連項目: 取得プロセスの構成の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照

同期取得に関する問題のトラブルシューティング

同期取得によって変更が予期したとおりに取得されない場合は、この項を参考にして、同期取得に関する問題を特定し、解決してください。

関連項目: 「同期取得による暗黙的取得」 同期取得の構成の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照 「同期取得の管理」 「同期取得の監視」

同期取得で表の変更の取得に失敗しないか

同期取得で表の変更が予期したとおりに取得されない場合は、同期取得のルール・セット内のルールが正しく構成されていない可能性があります。問題を回避するには、同期取得のルール・セットにルールを追加する際、常にDBMS_STREAMS_ADMパッケージのADD_TABLE_RULESまたはADD_SUBSET_RULESプロシージャを使用します。

同期取得で変更が予期したとおりに取得されない場合の一般的な原因を次に示します。

• 同期取得の動作を制御しようとするグローバル・ルールまたはスキーマ・ルールが使用されている場合。同期取得では、そのルール・セット内のグローバル・ルールおよびスキーマ・ルールは無視されます。同期取得では、表ルールとサブセット・ルールを満たす変更のみが取得されます。

• 同期取得のルールの構成にDBMS_RULE_ADMパッケージが使用された場合。この場合は同期取得が正常に動作しません。

  • 同期取得のルール・セットに追加するルールの作成にDBMS_RULE_ADMパッケージが使用された場合。

  • 同期取得のルール・セットへのルールの追加にDBMS_RULE_ADMパッケージが使用された場合。

同期取得で表の変更が予期したとおりに取得されない場合は、次の手順を実行して、問題を特定し、解決してください。

1. DBA_SYNC_CAPTURE_TABLESデータ・ディクショナリ・ビューを問い合せて、同期取得で変更が取得されている表を特定します。同期取得では、表のENABLED列がYESに設定されている場合にのみ表の変更が取得されます。

2. 同期取得で変更を取得する必要がある表がDBA_SYNC_CAPTURE_TABLESビューにリストされない場合は、DBMS_STREAMS_ADMパッケージのADD_TABLE_RULESまたはADD_SUBSET_RULESプロシージャを使用して、それらの表についてのルールを追加します。

DBA_SYNC_CAPTURE_TABLESで表のENABLEDが表示されていても、同期取得でその表の変更が取得されない場合は、表のルールに含まれるルール条件に問題がある可能性があります。この場合は、ルール条件をチェックしてエラーを訂正するか、そのルールを削除し、ADD_TABLE_RULESまたはADD_SUBSET_RULESプロシージャを使用してルールを作成し直します。

注意: 同期取得のルール・セットからルールを削除したり、同期取得で使用されるルールを削除する場合は、DBMS_STREAMS_ADMパッケージのREMOVE_RULEプロシージャを使用することをお薦めします。ただし、DBMS_RULE_ADMパッケージのREMOVE_RULEまたはDROP_RULEプロシージャを使用してこれらのアクションを実行することもできます。

関連項目: 「同期取得によって変更が取得される表の表示」 「同期取得のルール・セットへのルールの追加」 「ルール・セット内の各ルールの条件の表示」 「同期取得のルール・セットからのルールの削除」