| Oracle Streams概要および管理 11g リリース1（11.1） E05775-02 |
|
 前へ |
 次へ |
次の各項では、Oracle Streams環境での一般的な問題の特定と解決について説明します。
アラートとは、潜在的に問題があったり、クリティカルのしきい値を超えた場合に発せられる警告のことです。アラートには2つのタイプがあります。
ステートレス: 必ずしもシステムの状態と結び付かない単一イベントを示すアラート。たとえば、取得が特定のエラーで中断したことを示すアラートはステートレス・アラートです。
ステートフル: 特定のシステム状態に関連するアラート。ステートフル・アラートは、通常は数値に基づき、警告レベルとクリティカル・レベルでしきい値が定義されます。たとえば、警告レベルが85%でクリティカル・レベルが95%の現在のOracle Streamsプール・メモリー使用率に関するアラートは、ステートフル・アラートです。
Oracle Database 11g リリース1以上のデータベースでは、次の条件下でステートレスOracle Streamsアラートが生成されます。
取得プロセスが中断された場合
エラーが連続して16回発生した後に伝播が中断された場合
適用プロセスが中断された場合
空のエラー・キューのある適用プロセスで適用エラーが発生した場合
Oracle Database 11g リリース1以上のデータベースでは、次の条件下でステートフルOracle Streamsアラートが生成されます。
Oracle Streamsプールのメモリー使用量が、STREAMS_POOL_USED_PCTメトリックに指定されたパーセンテージを超えた場合。このメトリックは、Oracle Enterprise Managerで、またはDBMS_SERVER_ALERTパッケージのSET_THRESHOLDプロシージャを使用して管理できます。
Enterprise Managerでアラートを表示するか、次のデータ・ディクショナリ・ビューを問い合せることができます。
DBA_OUTSTANDING_ALERTSビューでは、現行のステートフル・アラートが記録されます。DBA_ALERT_HISTORYビューでは、クリアされたステートレス・アラートおよびステートフル・アラートが記録されます。たとえば、Oracle Streamsプールでのメモリー使用量が指定されたしきい値を超えると、DBA_OUTSTANDING_ALERTSビューにステートフル・アラートが記録されます。
DBA_ALERT_HISTORYデータ・ディクショナリ・ビューには、DBA_OUTSTANDING_ALERTSビューからクリアされたアラートが表示されます。たとえば、Oracle Streamsプールでのメモリー使用量が指定されたしきい値を下回ると、DBA_OUTSTANDING_ALERTSビューに記録されていたアラートがクリアされ、DBA_ALERT_HISTORYビューに移動します。
たとえば、現行のOracle Streamsステートフル・アラートをリストするには、DBA_OUTSTANDING_ALERTSビューで次の問合せを実行します。
COLUMN REASON HEADING 'Reason for Alert' FORMAT A35 COLUMN SUGGESTED_ACTION HEADING 'Suggested Response' FORMAT A35 SELECT REASON, SUGGESTED_ACTION FROM DBA_OUTSTANDING_ALERTS WHERE MODULE_ID LIKE '%STREAMS%';
Oracle Streamsステートレス・アラートと、クリアされたOracle Streamsステートフル・アラートをリストするには、DBA_ALERT_HISTORYビューで次の問合せを実行します。
COLUMN REASON HEADING 'Reason for Alert' FORMAT A35 COLUMN SUGGESTED_ACTION HEADING 'Suggested Response' FORMAT A35 SELECT REASON, SUGGESTED_ACTION FROM DBA_ALERT_HISTORY WHERE MODULE_ID LIKE '%STREAMS%';
DBA_ALERT_HISTORYビューを問い合せた出力例を次に示します。
Reason for Alert Suggested Response
----------------------------------- -----------------------------------
STREAMS apply process "APPLY_EMP_DE Obtain the exact error message in d
P" aborted with ORA-26714 ba_apply, take the appropriate acti
on for this error, and restart the
apply process using dbms_apply_adm.
start_apply. If the error is an OR
A-26714, consider setting the 'DISA
BLE_ON_ERROR' apply parameter to 'N
' to avoid aborting on future user
errors.
STREAMS error queue for apply proce Look at the contents of the error q
ss "APPLY_EMP_DEP" contains new tra ueue as well as dba_apply_error to
nsaction with ORA-26786 determine the cause of the error.
Once the errors are resolved, reexe
cute them using dbms_apply_adm.exec
ute_error or dbms_apply_adm.execute
_all_errors.
|
注意: Oracle Streamsアラートは情報提供のみを目的としています。これらのアラートを管理する必要はありません。Oracle Streams環境を定期的に監視し、問題が発生したときに対処する場合は、Oracle Streamsアラートの監視は必要でない可能性があります。 |
|
関連項目:
|
取得プロセスで予期したとおりに変更が取得されない場合や、取得プロセスに他の問題が発生した場合は、次のチェックリストを使用し、問題を特定して解決します。
取得プロセスの作成またはデータ・ディクショナリのビルドに異常に長い時間を要している場合は、まだコミットされていない、処理中のトランザクションがあることが原因である場合があります。処理中のトランザクションとは、取得プロセスの作成時またはデータ・ディクショナリのビルド時にアクティブなトランザクションです。
処理中のトランザクションの有無を判別するには、アラート・ログで次のメッセージをチェックします。
wait for inflight txns at this scn Done with waiting for inflight txns at this scn
アラート・ログに最初のメッセージのみが表示される場合、取得プロセスの作成またはデータ・ディクショナリのビルドは処理中のトランザクションの待機状態であり、処理中のトランザクションがすべてのコミットされた後に完了します。
取得プロセスが変更を取得するのは、そのプロセスが有効になっている場合のみです。
取得プロセスが有効か、無効か、中断されているかは、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';
|
関連項目:
|
取得プロセスによって最近の変更が取得されていない場合は、取得プロセスの遅延が原因の可能性があります。これをチェックするには、V$STREAMS_CAPTURE動的パフォーマンス・ビューを問い合せます。取得プロセスの待機時間が長い場合は、parallelism取得プロセス・パラメータの設定を調整すると、パフォーマンスを改善できることがあります。
取得プロセスの起動時または再起動時には、開始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を特定できます。
Oracle Streams環境内のソース・データベースでRecovery Manager（RMAN）のフラッシュ・リカバリ領域機能を使用している場合、取得プロセスに必要なアーカイブREDOログ・ファイルがRMANによって削除されることがあります。リカバリ関連ファイルで使用されているディスク領域が、フラッシュ・リカバリ領域で指定されたディスク割当て制限に近づくと、Recovery Managerによってこれらのファイルが削除される場合があります。将来この問題が発生するのを防止するには、次のアクションを1つ以上実行します。
フラッシュ・リカバリ領域のディスク割当て制限を引き上げます。ディスク割当て制限を引き上げると、必要なアーカイブREDOログ・ファイルがRecovery Managerによって削除される可能性が低減しますが、必ずしも問題を回避できるわけではありません。
アーカイブREDOログ・ファイルがフラッシュ・リカバリ領域以外の場所に格納されるようにソース・データベースを構成します。ローカル取得プロセスでは、必要なログ・ファイルがフラッシュ・リカバリ領域に見つからない場合に、別の場所にあるログ・ファイルを使用できます。この場合、別の場所にあるログ・ファイルをデータベース管理者が手動で管理する必要があります。
Recovery Managerでは、アーカイブREDOログ・ファイルを削除する前に、それらがバックアップされていることを常に確認します。取得プロセスに必要なアーカイブREDOログ・ファイルがRecovery Managerによって削除されると、このアクションがRecovery Managerによってアラート・ログに記録されます。
|
関連項目:
|
ダウンストリーム取得プロセスで変更が取得されない場合は、スキャン対象のREDOデータを待機している可能性があります。REDOログ・ファイルはダウンストリーム取得プロセスに暗黙的に登録される場合と明示的に登録される場合があります。暗黙的に登録されるREDOログ・ファイルは、一般に次のいずれかの方法で登録されます。
リアルタイム・ダウンストリーム取得プロセスの場合は、REDO転送サービスによって、ログ・ライター・プロセス（LGWR）を使用してソース・データベースからダウンストリーム・データベースのスタンバイ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でインスタンス化のために準備され、オブジェクトがインスタンス化のために準備された後に発生したデータベース・オブジェクトの変更のみを取得プロセスによって取得できます。
ダウンストリーム取得プロセスを作成するには、次のプロシージャのいずれかを使用する必要があります。
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パラメータに指定されているデータベース名が、ローカル・データベースのグローバル名と一致していることを確認します。
ソース・データベースおよびダウンストリーム取得データベース間で認証が適切に構成されていないと、REDOデータ転送が次のいずれかのエラーで失敗します。
ORA-16191: Primary log shipping client not logged on standby ORA-1017: Invalid username/password; login denied
REDO転送セッションは、Secure Sockets Layer（SSL）プロトコルまたはリモート・ログイン・パスワード・ファイルのいずれかを使用して認証されます。パスワード・ファイルは、ソース・データベースおよびダウンストリーム取得データベースで同じである必要があります。
この問題を修正するには、次のアクションのいずれかを実行します。
ソース・データベースにリモート・ログイン・パスワード・ファイルがある場合は、ダウンストリーム取得データベース・システムの適切なディレクトリにこのファイルをコピーします。
初期化パラメータSEC_CASE_SENSITIVE_LOGONにFALSEを設定し、大/小文字区別オプションを無効にします。次に、ORAPWDを使用し、ソースおよびダウンストリーム取得データベース・システムでパスワード・ファイルを作成します。パスワードは両方のシステムで同一にし、ignorecase引数にYを設定する必要があります。
|
関連項目: REDO転送の認証要件の詳細は、Oracle Data Guard概要および管理を参照 |
ダウンストリーム取得がデータベース・リンク付きで構成されている場合は、そのデータベース・リンクを使用してソース・データベースで操作を実行し、ソース・データベースから自動的に情報を取得できます。ダウンストリーム取得がデータベース・リンクなしで構成されている場合は、これらのアクションを手動で実行し、情報を手動で取得する必要があります。これらのアクションを手動で完了しないでダウンストリーム取得プロセスを作成しようとすると、エラーが発生します。
ダウンストリーム取得をデータベース・リンクなしで構成する場合、具体的には次のアクションを手動で実行する必要があります。
状況によっては、取得プロセスを作成する前にソース・データベースでDBMS_CAPTURE_ADM.BUILDプロシージャを実行して、ソース・データベースのデータ・ディクショナリをREDOログに抽出する必要があります。
ソース・データベース・オブジェクトをインスタンス化のために準備する必要があります。
ダウンストリーム取得プロセスの先頭SCNを取得し、DBMS_CAPTURE_ADMパッケージのCREATE_CAPTUREプロシージャを使用して取得プロセスを作成する際に、first_scnパラメータでその先頭SCNを指定する必要があります。
同期取得によって変更が予期したとおりに取得されない場合は、この項を参考にして、同期取得に関する問題を特定し、解決してください。
同期取得で表の変更が予期したとおりに取得されない場合は、同期取得のルール・セット内のルールが正しく構成されていない可能性があります。問題を回避するには、同期取得のルール・セットにルールを追加する際、常に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プロシージャを使用してこれらのアクションを実行することもできます。 |
伝播で予期したとおりに変更が伝播されない場合は、次のチェックリストを使用し、伝播の問題を特定して解決します。
メッセージが予期したとおりに伝播の宛先キューに格納されないときは、適切なソース・キューから適切な宛先キューにメッセージを伝播するように伝播が構成されていない場合があります。
たとえば、dbs1_to_dbs2という伝播のソース・キューと宛先キューをチェックするには、次の問合せを実行します。
COLUMN SOURCE_QUEUE HEADING 'Source Queue' FORMAT A35
COLUMN DESTINATION_QUEUE HEADING 'Destination Queue' FORMAT A35
SELECT
p.SOURCE_QUEUE_OWNER||'.'||
p.SOURCE_QUEUE_NAME||'@'||
g.GLOBAL_NAME SOURCE_QUEUE,
p.DESTINATION_QUEUE_OWNER||'.'||
p.DESTINATION_QUEUE_NAME||'@'||
p.DESTINATION_DBLINK DESTINATION_QUEUE
FROM DBA_PROPAGATION p, GLOBAL_NAME g
WHERE p.PROPAGATION_NAME = 'DBS1_TO_DBS2';
出力は次のようになります。
Source Queue Destination Queue ----------------------------------- ----------------------------------- STRMADMIN.QUEUE1@DBS1.EXAMPLE.COM STRMADMIN.QUEUE2@DBS2.EXAMPLE.COM
伝播が適切なキューを使用していない場合は、新しい伝播を作成します。ご使用の環境に既存の伝播が適さない場合には削除が必要になることがあります。
伝播ジョブでメッセージを伝播するには、伝播が有効であることが必要です。予期したとおりに伝播でメッセージが伝播されないときは、伝播が無効になっている場合があります。
伝播について次の情報を確認できます。
伝播がENABLED、DISABLEDまたはABORTEDのいずれであるか
最後のエラーの日付（伝播エラーが発生した場合）
最後のエラーのエラー番号（伝播エラーが発生した場合）
最後のエラーのエラー・メッセージ（伝播エラーが発生した場合）
たとえば、streams_propagationという伝播が有効かどうかチェックするには、次の問合せを実行します。
COLUMN DESTINATION_DBLINK HEADING 'Database|Link' FORMAT A15
COLUMN STATUS HEADING 'Status' FORMAT A8
COLUMN ERROR_DATE HEADING 'Error|Date'
COLUMN ERROR_MESSAGE HEADING 'Error Message' FORMAT A35
SELECT DESTINATION_DBLINK,
STATUS,
ERROR_DATE,
ERROR_MESSAGE
FROM DBA_PROPAGATION
WHERE PROPAGATION_NAME = 'STREAMS_PROPAGATION';
伝播が現在無効の場合は、出力が次のようになります。
Database Error
Link Status Date Error Message
--------------- -------- --------- -----------------------------------
D2.EXAMPLE.COM DISABLED 27-APR-05 ORA-25307: Enqueue rate too high, f
low control enabled
問題がある場合は、次の方法を試行して修正してください。
伝播が無効の場合、DBMS_PROPAGATION_ADMパッケージのSTART_PROPAGATIONプロシージャをまだ実行していなければ、これを実行して伝播を有効にできます。
伝播が無効になっているか、中断されていて、Error DateおよびError Messageフィールドに値が移入されている場合は、エラー・メッセージに基づいて問題を診断し、修正します。
伝播が無効になっているか、中断されている場合は、伝播ジョブ・プロセスのトレース・ファイルをチェックします。「伝播ジョブのスケジュールの表示」の問合せを実行すると、伝播ジョブ・プロセスが表示されます。
伝播ジョブが有効だが、メッセージが伝播されない場合は、伝播を停止してから再起動します。
ANYDATAキューは保護キューであり、ユーザーがその操作を実行できるように、セキュリティを適切に構成する必要があります。DBMS_STREAMS_ADMパッケージのSET_UP_QUEUEプロシージャを使用して保護キューANYDATAを構成する場合、SET_UP_QUEUEが作成しようとするエージェントがすでに存在し、このプロシージャのqueue_userで指定されているユーザー以外のユーザーに関連付けられていると、エラーが発生します。この場合は、DBMS_AQADMパッケージのALTER_AQ_AGENTプロシージャを使用して既存のエージェントの名前を変更するか、DROP_AQ_AGENTプロシージャを使用して既存のエージェントを削除します。次に、SET_UP_QUEUEを再試行します。
また、ANYDATAキューのセキュリティが適切に構成されていないと、次のいずれかのエラーが発生することがあります。
Oracle Streamsアドバンスト・キューイング（AQ）エージェントには、エンキュー操作とデキュー操作の両方について、保護キューへのアクセス権が明示的に付与される必要があります。DBMS_AQADMパッケージのENABLE_DB_ACCESSプロシージャを使用して、エージェントにこれらの権限を付与します。
たとえば、explicit_dqというエージェントにデータベース・ユーザーoeの権限を付与するには、次のプロシージャを実行します。
BEGIN
DBMS_AQADM.ENABLE_DB_ACCESS(
agent_name => 'explicit_dq',
db_username => 'oe');
END;
/
データベースでのエージェントの権限をチェックするには、次の問合せを実行します。
SELECT AGENT_NAME "Agent", DB_USERNAME "User" FROM DBA_AQ_AGENT_PRIVS;
出力は次のようになります。
Agent User ------------------------------ ------------------------------ EXPLICIT_ENQ OE APPLY_OE OE EXPLICIT_DQ OE
適用プロセスで予期したとおりに変更が適用されない場合は、次のチェックリストを使用し、適用の問題を特定して解決します。
|
関連項目:
|
適用プロセスが変更を適用するのは、そのプロセスが有効になっている場合のみです。
適用プロセスが有効か、無効か、中断されているかは、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';
|
関連項目:
|
適用プロセスによって最近の変更が適用されていない場合、問題は適用プロセスの遅延である可能性があります。V$STREAMS_APPLY_COORDINATOR動的パフォーマンス・ビューを問い合せると、適用プロセスの待機時間をチェックできます。適用プロセスの待機時間が長い場合は、parallelism適用プロセス・パラメータの設定を調整すると、パフォーマンスを改善できることがあります。
適用プロセスはバッファ・キューの取得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ハンドラ、DDLハンドラ、プリコミット・ハンドラおよびメッセージ・ハンドラがあります。適用プロセスが予期したとおりに動作していない場合は、その適用プロセスで使用されるハンドラ・プロシージャをチェックして、不備があれば修正します。適用に関する問題を解決するには、ハンドラ・プロシージャの変更または削除が必要になることがあります。
これらのプロシージャの名前は、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権限を付与します。
適用プロセスでメッセージが適用できない場合は、そのメッセージおよび同じトランザクション内の他のすべてのメッセージがエラー・キューに移されます。適用エラーを定期的にチェックして、適用できなかったトランザクションの有無をチェックする必要があります。
適用エラーは、DBA_APPLY_ERRORデータ・ディクショナリ・ビューを問い合せるとチェックできます。また、エラー・キューから特定のトランザクションを再実行するか、エラー・キュー内のすべてのトランザクションを再実行することもできます。
取得プロセス、同期取得、伝播、適用プロセスまたはメッセージ・クライアントが予期したとおりに動作しない場合、Oracle Streamsクライアントのルール・セット、ルールまたはルールベースの変換が適切に構成されていないことが原因である可能性があります。次の各項を参照して、ルール・セット、ルールおよびルールベースの変換の問題を特定して解決します。
取得プロセス、同期取得、伝播、適用プロセスまたはメッセージ・クライアントが想定したとおりに動作しない場合は、Oracle Streamsクライアントの1つ以上のルール・セットのルールが適切に構成されていないことが問題である可能性があります。たとえば、取得プロセスが特定の表に対する変更を取得することを予期していたが、取得しないという場合は、取得プロセスで使用されるルール・セット内のルールが、表の変更を取得するように取得プロセスに指示していないことが原因である可能性があります。
DBA_STREAMS_RULESデータ・ディクショナリ・ビューを問い合せると、特定のOracle Streamsクライアントのルールをチェックできます。Oracle Streams環境でポジティブ・ルール・セットとネガティブ・ルール・セットの両方を使用する場合は、このビューで返されるルールが特定のOracle Streamsクライアントのポジティブ・ルール・セットかネガティブ・ルール・セットかを把握することが重要です。
Oracle Streamsクライアントは、ルール・セットを満たすメッセージに対して取得、伝播、適用、デキューなどのアクションを実行します。通常、メッセージがOracle Streamsクライアントのルールを満たすのは、メッセージについてネガティブ・ルール・セットのどのルールもTRUEと評価されず、ポジティブ・ルール・セットの1つ以上のルールがTRUEと評価された場合です。
「ルール・セットおよびメッセージのルール評価」では、メッセージがどのようにOracle Streamsクライアントのルール・セットを満たすかに関する詳細情報を示します。これには、1つ以上のルール・セットが指定されていない場合のOracle Streamsクライアントの動作に関する情報が含まれます。
この項は、次のトピックで構成されています。
Oracle Streamsクライアントのポジティブ・ルール・セット内のスキーマ・ルールおよびグローバル・ルールでは、それぞれ特定のスキーマまたはデータベースに関連するすべてのメッセージに対してタスクを実行するようOracle Streamsクライアントに指示します。Oracle Streamsクライアントのネガティブ・ルール・セット内のスキーマ・ルールおよびグローバル・ルールでは、それぞれ特定のスキーマまたはデータベースに関連するすべてのメッセージを廃棄するようOracle Streamsクライアントに指示します。Oracle Streamsクライアントが予期したとおりに動作しない場合、Oracle Streamsに対してスキーマ・ルールまたはグローバル・ルールが正しく構成されていないことが原因の可能性があります。
たとえば、データベースでstrm01_applyという適用プロセスが実行されていて、hrスキーマの変更を含むLCRをこの適用プロセスで適用するとします。適用プロセスでネガティブ・ルール・セットが使用される場合は、このスキーマについてTRUEと評価されるスキーマ・ルールがそのネガティブ・ルール・セットに存在しないことを確認します。そのようなルールがあると、スキーマの変更を含むLCRが適用プロセスによって廃棄されます。Oracle Streamsクライアント用のネガティブ・ルール・セット内のルールの表示に、このようなルールを表示する問合せの例を示しています。
問合せによってこのようなルールが返される場合、返されたルールが原因で、スキーマの変更が適用プロセスによって廃棄されている可能性があります。この問合せによって行が返されない場合は、このスキーマについてTRUEと評価されるスキーマ・ルールが適用プロセスのポジティブ・ルール・セット内に存在することを確認してください。Oracle Streamsクライアント用のネガティブ・ルール・セット内のルールの表示に、このようなルールが表示される問合せの例を示しています。
Oracle Streamsクライアントのポジティブ・ルール・セット内の表ルールでは、1つ以上の特定の表に関連するメッセージに対してタスクを実行するようOracle Streamsクライアントに指示します。Oracle Streamsクライアントのネガティブ・ルール・セット内の表ルールでは、1つ以上の特定の表に関連するメッセージを廃棄するようOracle Streamsクライアントに指示します。
Oracle Streamsクライアントが特定の表に対して予期したとおりに動作しない場合は、次のいずれかが原因の可能性があります。
その表が特定のデータベースに含まれるために、Oracle Streamsクライアントのルール・セット内の1つ以上のグローバル・ルールで、その表に関連するメッセージに対して特定の方法で動作するようOracle Streamsクライアントに指示している場合。つまり、Oracle Streamsクライアントのネガティブ・ルール・セット内のグローバル・ルールで、その表を含むソース・データベースからのすべてのメッセージを廃棄するようOracle Streamsクライアントに指示しているか、Oracle Streamsクライアントのポジティブ・ルール・セット内のグローバル・ルールで、その表を含むソース・データベースからのすべてのメッセージに対してタスクを実行するようOracle Streamsクライアントに指示している可能性があります。
その表が特定のスキーマに含まれるために、Oracle Streamsクライアントのルール・セット内の1つ以上のスキーマ・ルールで、その表に関連するメッセージに対して特定の方法で動作するようOracle Streamsクライアントに指示している場合。つまり、Oracle Streamsクライアントのネガティブ・ルール・セット内のスキーマ・ルールで、スキーマ内のデータベース・オブジェクトに関連するすべてのメッセージを廃棄するようOracle Streamsクライアントに指示しているか、Oracle Streamsクライアントのポジティブ・ルール・セット内のスキーマ・ルールで、スキーマ内のデータベース・オブジェクトに関連するすべてのメッセージに対してタスクを実行するようOracle Streamsクライアントに指示している可能性があります。
Oracle Streamsクライアントのルール・セット内の1つ以上の表ルールで、その表に関連するメッセージに対して特定の方法で動作するようOracle Streamsクライアントに指示している場合。
予期しない動作の原因がグローバル・ルールまたはスキーマ・ルールではないと思われる場合は、Oracle Streamsクライアントのルール・セット内の表ルールをチェックします。たとえば、取得プロセスが特定の表の変更を取得することを想定しているが、取得されない場合、取得プロセスのポジティブ・ルール・セットとネガティブ・ルール・セット内のルールで、その表の変更を取得するように指示していないことが原因であることがあります。
データベースでstrm01_captureという取得プロセスが実行され、この取得プロセスでhr.departments表に対する変更を取得するとします。取得プロセスでネガティブ・ルール・セットが使用される場合、この表に対してTRUEと評価される表ルールがこのネガティブ・ルール・セットに存在しないことを確認します。そのようなルールがあると、この表に対する変更が取得プロセスによって廃棄されます。「Oracle Streamsクライアント用のネガティブ・ルール・セット内のルールの表示」に、ネガティブ・ルール・セット内のルールを表示する問合せの例を示しています。
問合せによってこのようなルールが返される場合、返されたルールが原因で、表の変更が取得プロセスによって廃棄されている可能性があります。この問合せによってルールが返されない場合は、この表についてTRUEと評価される表ルールが取得プロセスのポジティブ・ルール・セットに1つ以上含まれていることを確認します。「Oracle Streamsクライアント用のポジティブ・ルール・セット内のルールの表示」に、ポジティブ・ルール・セット内のルールを表示する問合せの例を示しています。
ルール条件に特定のパターンが含まれるルールを特定することもできます。「条件に指定パターンが含まれる各ルールのリスト表示 」を参照してください。たとえば、ルール条件にdepartmentsという文字列のあるすべてのルールを検索し、これらのルールが正しいルール・セットに含まれることを確認できます。
サブセット・ルールは、取得プロセス、同期取得、伝播、適用プロセスまたはメッセージ・クライアントで使用されるルール・セットに含めることができます。サブセット・ルールは、表内の特定の行サブセットに対する変更がDML操作に含まれる場合にのみTRUEと評価されます。たとえば、hr.departments表に対する変更があるときに、strm01_applyという適用プロセスについてTRUEと評価される表ルールをチェックするには、次の問合せを実行します。
COLUMN RULE_NAME HEADING 'Rule Name' FORMAT A20
COLUMN RULE_TYPE HEADING 'Rule Type' FORMAT A20
COLUMN DML_CONDITION HEADING 'Subset Condition' FORMAT A30
SELECT RULE_NAME, RULE_TYPE, DML_CONDITION
FROM DBA_STREAMS_RULES
WHERE STREAMS_NAME = 'STRM01_APPLY' AND
STREAMS_TYPE = 'APPLY' AND
SCHEMA_NAME = 'HR' AND
OBJECT_NAME = 'DEPARTMENTS';
Rule Name Rule Type Subset Condition -------------------- -------------------- ------------------------------ DEPARTMENTS5 DML location_id=1700 DEPARTMENTS6 DML location_id=1700 DEPARTMENTS7 DML location_id=1700
この問合せでは、出力結果にSubset Conditionというラベルが付くDML_CONDITION列に表のサブセット条件が返されることに注意してください。この例では、hr.departments表に対してサブセット・ルールが指定されています。これらのサブセット・ルールは、location_id が1700である行が関与する変更がLCRに含まれている場合にのみTRUEと評価されます。したがって、適用プロセスで表のすべての変更が適用されることを想定している場合でも、これらのサブセット・ルールにより、location_idが1700ではない行が関係する変更は廃棄されます。
|
注意: サブセット・ルールは、ポジティブ・ルール・セット内にのみ存在する必要があります。 |
メッセージ・ルールは、伝播、適用プロセスまたはメッセージ・クライアントで使用されるルール・セットに含めることができます。メッセージ・ルールは、取得LCRではなく、指定したメッセージ・タイプのユーザー・メッセージのみに関連します。メッセージ・ルールがTRUEと評価されるのは、キュー内のユーザー・メッセージがメッセージ・ルールで指定されたメッセージ・タイプであり、メッセージ・ルールのルール条件を満たしている場合のみです。
伝播、適用プロセスまたはメッセージ・クライアントで特定のユーザー・メッセージに対してタスクが実行されることを想定していたが、Oracle Streamsクライアントではそれらのメッセージに対するタスクが実行されない場合は、Oracle Streamsクライアントのポジティブ・ルール・セットおよびネガティブ・ルール・セット内のルールで、それらのメッセージに対するタスクを実行するようにOracle Streamsクライアントに指示していないことが原因である可能性があります。同様に、伝播、適用プロセスまたはメッセージ・クライアントで、特定のユーザー・メッセージが廃棄されることを想定していたが、Oracle Streamsクライアントではそれらのメッセージが廃棄されない場合は、Oracle Streamsクライアントのポジティブ・ルール・セットおよびネガティブ・ルール・セット内のルールで、それらのメッセージを廃棄するように指示していないことが原因である可能性があります。
たとえば、oeというメッセージ・クライアントで、次の条件を満たすoe.user_msgタイプのメッセージをデキューするとします。
:"VAR$_2".OBJECT_OWNER = 'OE' AND :"VAR$_2".OBJECT_NAME = 'ORDERS'
メッセージ・クライアントでネガティブ・ルール・セットが使用される場合は、このメッセージ・タイプについてTRUEと評価されるメッセージ・ルールがネガティブ・ルール・セット内に存在しないことを確認します。このようなルールがあると、メッセージ・クライアントでそれらのメッセージが廃棄されます。たとえば、メッセージ・クライアントのネガティブ・ルール・セットにそのようなルールが存在するかどうか判別するには、次の問合せを実行します。
COLUMN RULE_NAME HEADING 'Rule Name' FORMAT A30
COLUMN RULE_CONDITION HEADING 'Rule Condition' FORMAT A30
SELECT RULE_NAME, RULE_CONDITION
FROM DBA_STREAMS_RULES
WHERE STREAMS_NAME = 'OE' AND
MESSAGE_TYPE_OWNER = 'OE' AND
MESSAGE_TYPE_NAME = 'USER_MSG' AND
RULE_SET_TYPE = 'NEGATIVE';
この問合せによってルールが返される場合は、それらのルールが原因となってメッセージ・クライアントでメッセージが廃棄されている可能性があります。返されたルールのルール条件を調べて、それらのルールが、メッセージ・クライアントでデキューする必要があるメッセージを廃棄する原因となっているかどうか判別します。この問合せでルールが返されない場合は、このメッセージ・タイプと条件についてTRUEと評価されるメッセージ・ルールがメッセージ・クライアントのポジティブ・ルール・セットに存在することを確認します。
たとえば、このメッセージ・タイプについてTRUEと評価されるメッセージ・ルールがメッセージ・クライアントのポジティブ・ルール・セットに存在するかどうか判別するには、次の問合せを実行します。
COLUMN RULE_NAME HEADING 'Rule Name' FORMAT A35
COLUMN RULE_CONDITION HEADING 'Rule Condition' FORMAT A35
SELECT RULE_NAME, RULE_CONDITION
FROM DBA_STREAMS_RULES
WHERE STREAMS_NAME = 'OE' AND
MESSAGE_TYPE_OWNER = 'OE' AND
MESSAGE_TYPE_NAME = 'USER_MSG' AND
RULE_SET_TYPE = 'POSITIVE';
このメッセージ・タイプについてTRUEと評価されるメッセージ・ルールがメッセージ・クライアントのポジティブ・ルール・セットに存在する場合は、それらのルールが返されます。この場合、出力は次のようになります。
Rule Name Rule Condition
----------------------------------- -----------------------------------
RULE$_3 :"VAR$_2".OBJECT_OWNER = 'OE' AND
:"VAR$_2".OBJECT_NAME = 'ORDERS'
返されたルールのルール条件を調べて、適切なメッセージをデキューするようメッセージ・クライアントに指示しているかどうか判別します。これらの結果に基づき、oeというメッセージ・クライアントは出力に表示された条件を満たすoe.user_msgタイプのメッセージをデキューします。つまり、ルール条件を満たすoe.user_msgタイプのメッセージがキュー内でメッセージ・クライアントによって検出されたときに、それらのメッセージを廃棄するルールが、メッセージ・クライアントのネガティブ・ルール・セットに存在せず、そのメッセージをTRUEと評価するルールがメッセージ・クライアントのポジティブ・ルール・セットに存在しています。
Oracle Streamsクライアントのルール・セットに、必要なルールが欠落していることにより、Oracle Streamsの取得プロセス、同期取得、伝播、適用プロセスまたはメッセージ・クライアントが予期したとおりに動作していないと思われる場合は、DBMS_STREAMS_ADMパッケージの次のいずれかのプロシージャを使用して適切なルールを追加します。
ADD_GLOBAL_PROPAGATION_RULES
ADD_GLOBAL_RULES
ADD_SCHEMA_PROPAGATION_RULES
ADD_SCHEMA_RULES
ADD_SUBSET_PROPAGATION_RULES
ADD_SUBSET_RULES
ADD_TABLE_PROPAGATION_RULES
ADD_TABLE_RULES
ADD_MESSAGE_PROPAGATION_RULE
ADD_MESSAGE_RULE
必要に応じて、DBMS_RULE_ADMパッケージを使用してカスタマイズ済ルールを追加できます。
また、Oracle Streamsの取得プロセス、同期取得、伝播、適用プロセスまたはメッセージ・クライアントが予期したとおりに動作しない原因は、ルールを変更する必要があるか、ルール・セットからルールを削除する必要があるためである場合もあります。
ルールが適切であっても、必要なメッセージがOracle Streamsの取得プロセス、伝播または適用プロセスで除外される場合は、トレース・ファイルとアラート・ログで、マルチバージョン・データ・ディクショナリ（Oracle Streamsデータ・ディクショナリ）の欠落に関する警告をチェックします。このような警告メッセージには、次の情報が含まれます。
gdbnm: 欠落しているオブジェクトのソース・データベースのグローバル名
scn: 欠落しているトランザクションのSCN
このようなメッセージがあるときに、カスタム取得プロセス・ルールを使用している場合、または新しい宛先データベースに既存の取得プロセス・ルールを再利用している場合は、次のようなプロシージャを適切に実行し、インスタンス化の準備をしてください。
PREPARE_TABLE_INSTANTIATION
PREPARE_SCHEMA_INSTANTIATION
PREPARE_GLOBAL_INSTANTIATION
また、ソース・データベースから宛先データベースへの伝播が機能していることを確認します。Oracle Streamsデータ・ディクショナリの情報は、宛先データベースに伝播された後、その宛先データベースのディクショナリにロードされます。
|
関連項目:
|
宣言ルールベースの変換は、行LCRの一般的な変換シナリオに対応するルールベースの変換です。宣言ルールベースの変換は、PL/SQLを使用せずに内部的に実行されます。Oracle Streamsの取得プロセス、同期取得、伝播、適用プロセスまたはメッセージ・クライアントが想定したとおりに動作しない場合は、そのOracle Streamsクライアントで使用されるルールに指定されている宣言ルールベースの変換をチェックし、誤りがあれば訂正します。
宣言ルールベースの変換で多く発生する問題には、次のものがあります。
宣言ルールベースの変換が表に指定されているか、または変換が表の列に関係している場合に、その変換が作成されたときに、そのスキーマが指定されなかった、または正しく指定されませんでした。宣言ルールベースの変換のスキーマが正しくないと、適切なLCRで変換されません。宣言ルールベースの変換を作成する際は、その表を所有しているスキーマを指定する必要があります。宣言ルールベースの変換を作成する際にスキーマを指定していないときは、デフォルトで、変換を作成するユーザーがスキーマに指定されます。
宣言ルールベースの変換のスキーマが正しくない場合、問題を解決するには、変換を削除して再作成し、各表の正しいスキーマを指定します。
特定のルールに対して複数の宣言ルールベースの変換が指定されている場合は、それらの変換の実行順序が正しいことを確認します。宣言ルールベースの変換の順序が正しくないと、エラーが発生するか、一貫性のないデータが生成される可能性があります。
単一のルールに対して指定された宣言ルールベースの変換の順序が正しくない場合、問題を解決するには、変換を削除し、正しい順序で再作成します。
カスタム・ルールベースの変換は、ルールがTRUEと評価されたときに実行される、ユーザー定義ファンクションによるメッセージの変更です。カスタム・ルールベースの変換は、ルールのアクション・コンテキスト内で指定されます。また、このようなアクション・コンテキストに含まれる名前/値ペアは、名前がSTREAMS$_TRANSFORM_FUNCTION、値がユーザー作成ファンクション名です。このユーザー作成ファンクションによって変換が実行されます。ユーザー作成ファンクションに不備があると、予期しない動作が発生する可能性があります。
Oracle Streamsの取得プロセス、同期取得、伝播、適用プロセスまたはメッセージ・クライアントが想定したとおりに動作しない場合は、Oracle Streamsクライアントで使用されるルールで指定したカスタム・ルールベースの変換ファンクションをチェックして不備を修正します。DBA_STREAMS_TRANSFORM_FUNCTIONデータ・ディクショナリ・ビューを問い合せると、これらのファンクションの名前を検索できます。問題を解決するには、変換ファンクションの変更やカスタム・ルールベースの変換の削除が必要になる場合があります。また、ルールに対して変換を指定するときにはファンクション名を正確に指定してください。
カスタム・ルールベースの変換が原因のエラーによって、取得プロセス、同期取得、伝播、適用プロセスおよびメッセージ・クライアントが中断されることがあります。この場合、変換を修正しないと、Oracle Streamsクライアントを再起動または起動できないことがあります。
ルールの評価は、カスタム・ルールベースの変換の前に行われます。たとえば、表名をempsからemployeesに変更する変換がある場合は、その変換を使用する各ルールのルール条件で、表名employeesではなくempsが指定されていることを確認してください。
場合によっては、誤って変換されたLCRが、適用プロセスによってエラー・キューに移動されていることがあります。このときは、エラー・キューのトランザクションを調べて、トランザクションを正常に再実行できる可能性を分析する必要があります。トランザクションに異常が見つかった場合は、問題を修正するためにDMLハンドラを構成することができます。DMLハンドラは、エラー・トランザクションを再実行するときに実行されます。DMLハンドラを使用してエラー・トランザクションの問題を修正するときは、そのDMLハンドラを使用する適用プロセスを停止して、エラー・トランザクションに関係ないLCRをDMLハンドラが処理しないようにすることが必要です。正常に再実行した後で、DMLハンドラが不要であれば削除します。また、ルールベースの変換を修正して、将来エラーが発生しないようにします。
各取得プロセス、伝播および適用プロセスに関するメッセージは、そのプロセスまたは伝播ジョブが実行されているデータベースのトレース・ファイルに記録されます。ローカル取得プロセスはソース・データベース、ダウンストリーム取得プロセスはダウンストリーム・データベース、伝播ジョブは伝播のソース・キューを含むデータベース、適用プロセスは宛先データベースでそれぞれ実行されます。これらのトレース・ファイル・メッセージは、Oracle Streams環境内の問題を特定し、解決するために役立ちます。
バックグラウンド・プロセスのすべてのトレース・ファイルは、自動診断リポジトリに書き込まれます。トレース・ファイル名はオペレーティング・システム固有ですが、通常、各ファイルにはそれを書き込むプロセスの名前が含まれます。
たとえば、一部のオペレーティング・システムでは、プロセスのトレース・ファイル名はsid_xxxx_iiiii.trcとなります。その意味は次のとおりです。
sidはデータベースのシステム識別子です。
xxxxはプロセスの名前です。
iiiiiはオペレーティング・システムのプロセス番号です。
また、取得プロセスと適用プロセスの両方について、write_alert_logパラメータをyに設定できます。このパラメータにyを設定（デフォルト）すると、取得プロセスまたは適用プロセスが停止した理由を示すメッセージがデータベースのアラート・ログに書き込まれます。
DBMS_CAPTURE_ADMおよびDBMS_APPLY_ADMパッケージのSET_PARAMETERプロシージャを使用して取得プロセスまたは適用プロセスのtrace_levelパラメータを設定すると、トレース・ファイル内の情報を制御できます。
次のチェックリストを使用して、Oracle Streamsに関連するトレース・ファイルをチェックします。
|
関連項目:
|
取得プロセスは、CPnnという名前のOracleバックグラウンド・プロセスです。nnには文字および番号が含まれます。たとえば、一部のオペレーティング・システムでは、取得プロセスが実行されているデータベースのシステム識別子がhqdbで、取得プロセス番号が01であれば、その取得プロセスのトレース・ファイル名はhqdb_CP01で始まります。
各伝播では、jnnnという名前の1つ以上のスレーブ・プロセスに依存する伝播ジョブが使用されます。ここでnnnはスレーブ・プロセス番号です。たとえば、一部のオペレーティング・システムでは、スレーブ・プロセスが001であれば、そのスレーブ・プロセスのトレース・ファイル名にはj001が含まれます。DBA_QUEUE_SCHEDULESデータ・ディクショナリ・ビューのPROCESS_NAME列を問い合せると、プロセス名をチェックできます。
適用プロセスは、APnnという名前のOracleバックグラウンド・プロセスです。nnには文字および番号が含まれます。たとえば、一部のオペレーティング・システムでは、適用プロセスが実行されているデータベースのシステム識別子がhqdbで、適用プロセス番号が01であれば、その適用プロセスのトレース・ファイル名はhqdb_AP01で始まります。
適用プロセスでは他のプロセスも使用されます。適用プロセスに関する情報は、それらの1つ以上のプロセスのトレース・ファイルに記録される可能性があります。リーダー・サーバーと適用サーバーのプロセス名はASnnであり、nnには文字および番号が含まれます。したがって、一部のオペレーティング・システムでは、適用プロセスが実行されているデータベースのシステム識別子がhqdbであり、プロセス番号が01であれば、適用プロセスで使用されるプロセスに関する情報を含むトレース・ファイルの名前はhqdb_AS01で始まります。
|
関連項目:
|
