31 暗黙的取得のトラブルシューティング
31.1 取得プロセスの問題のトラブルシューティング
取得プロセスで予期したとおりに変更が取得されない場合や、取得プロセスに他の問題が発生した場合は、次のチェックリストを使用し、問題を特定して解決します。
関連項目:
-
取得プロセスの構成の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照
31.1.1 取得プロセスの作成またはデータ・ディクショナリのビルドに長時間を要していないか
取得プロセスの作成またはデータ・ディクショナリのビルドに異常に長い時間を要している場合は、まだコミットされていない、処理中のトランザクションがあることが原因である場合があります。処理中のトランザクションとは、取得プロセスの作成時またはデータ・ディクショナリのビルド時にアクティブなトランザクションです。
処理中のトランザクションの有無を判別するには、アラート・ログで次のメッセージをチェックします。
wait for inflight txns at this scn Done with waiting for inflight txns at this scn
アラート・ログに最初のメッセージのみが表示される場合、取得プロセスの作成またはデータ・ディクショナリのビルドは処理中のトランザクションの待機状態であり、処理中のトランザクションがすべてのコミットされた後に完了します。
関連項目:
-
取得プロセスの構成の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照
31.1.2 取得プロセスが有効かどうか
取得プロセスが変更を取得するのは、そのプロセスが有効になっている場合のみです。
取得プロセスが有効か、無効か、中断されているかは、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」を参照
31.1.3 取得プロセスで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ログ・ファイルを取得プロセスに対して使用可能にします。
関連項目:
31.1.4 取得プロセスでフロー制御のために一時停止しているか
有効になっている取得プロセスで予期したとおりに変更が取得されない場合、取得プロセスは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プールのサイズの拡大を試行します。
31.1.5 現行の取得プロセスかどうか
取得プロセスによって最近の変更が取得されていない場合は、取得プロセスの遅延が原因の可能性があります。これをチェックするには、V$STREAMS_CAPTURE
動的パフォーマンス・ビューを問い合せます。取得プロセスの待機時間が長い場合は、parallelism
取得プロセス・パラメータの設定を調整すると、パフォーマンスを改善できることがあります。
31.1.6 必須の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によってアラート・ログに記録されます。
関連項目:
-
高速リカバリ領域機能の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照
31.1.7 ダウンストリーム取得プロセスが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レプリケーション管理者ガイド』を参照
31.1.8 不適切にダウンストリーム取得の構成を試行していないか
ダウンストリーム取得プロセスを作成するには、次のプロシージャのいずれかを使用する必要があります。
-
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レプリケーション管理者ガイド』を参照
31.1.9 適切な認証を使用しないでダウンストリーム取得の構成を試行していないか
ソース・データベースおよびダウンストリーム取得データベース間で認証が適切に構成されていないと、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概要および管理』を参照
31.1.10 データベース・リンクのないダウンストリーム取得に追加のアクションが必要か
ダウンストリーム取得がデータベース・リンク付きで構成されている場合は、そのデータベース・リンクを使用してソース・データベースで操作を実行し、ソース・データベースから自動的に情報を取得できます。ダウンストリーム取得がデータベース・リンクなしで構成されている場合は、これらのアクションを手動で実行し、情報を手動で取得する必要があります。これらのアクションを手動で完了しないでダウンストリーム取得プロセスを作成しようとすると、エラーが発生します。
ダウンストリーム取得をデータベース・リンクなしで構成する場合、具体的には次のアクションを手動で実行する必要があります。
-
状況によっては、取得プロセスを作成する前にソース・データベースで
DBMS_CAPTURE_ADM.BUILD
プロシージャを実行して、ソース・データベースのデータ・ディクショナリをREDOログに抽出する必要があります。 -
ソース・データベース・オブジェクトをインスタンス化のために準備する必要があります。
-
ダウンストリーム取得プロセスの先頭SCNを取得し、
DBMS_CAPTURE_ADM
パッケージのCREATE_CAPTURE
プロシージャを使用して取得プロセスを作成する際に、first_scn
パラメータでその先頭SCNを指定する必要があります。
関連項目:
取得プロセスの構成の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照
31.2 同期取得に関する問題のトラブルシューティング
同期取得によって変更が予期したとおりに取得されない場合は、この項を参考にして、同期取得に関する問題を特定し、解決してください。
関連項目:
-
同期取得の構成の詳細は、『Oracle Streamsレプリケーション管理者ガイド』を参照
-
「同期取得の管理」
-
「同期取得の監視」
31.2.1 同期取得で表の変更の取得に失敗しないか
同期取得で表の変更が予期したとおりに取得されない場合は、同期取得のルール・セット内のルールが正しく構成されていない可能性があります。問題を回避するには、同期取得のルール・セットにルールを追加する際、常にDBMS_STREAMS_ADM
パッケージのADD_TABLE_RULES
またはADD_SUBSET_RULES
プロシージャを使用します。
同期取得で変更が予期したとおりに取得されない場合の一般的な原因を次に示します。
-
同期取得の動作を制御しようとするグローバル・ルールまたはスキーマ・ルールが使用されている場合。同期取得では、そのルール・セット内のグローバル・ルールおよびスキーマ・ルールは無視されます。同期取得では、表ルールとサブセット・ルールを満たす変更のみが取得されます。
-
同期取得のルールの構成に
DBMS_RULE_ADM
パッケージが使用された場合。この場合は同期取得が正常に動作しません。-
同期取得のルール・セットに追加するルールの作成に
DBMS_RULE_ADM
パッケージが使用された場合。 -
同期取得のルール・セットへのルールの追加に
DBMS_RULE_ADM
パッケージが使用された場合。
-
同期取得で表の変更が予期したとおりに取得されない場合は、次の手順を実行して、問題を特定し、解決してください。
-
DBA_SYNC_CAPTURE_TABLES
データ・ディクショナリ・ビューを問い合せて、同期取得で変更が取得されている表を特定します。同期取得では、表のENABLED
列がYES
に設定されている場合にのみ表の変更が取得されます。 -
同期取得で変更を取得する必要がある表が
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
プロシージャを使用してこれらのアクションを実行することもできます。