| Oracle® Databaseアドバンスト・レプリケーション 11g リリース2 (11.2) B72089-02 |
|
 前 |
 次 |
この付録では、レプリケーション環境を管理するためのトラブルシューティングのガイドラインについて説明します。
この付録には、次の項が含まれます。
データベース・リンクが正常に機能していないと考えられる場合、Oracle Enterprise Manager、SQL*Plusまたは別のツールを使用してデータベース・リンクを削除し、再作成します。
データベース・リンク名が、ターゲット・データベースのグローバル名と同じであることを確認します。
スケジュールした間隔が意図したとおりであることを確認します。
スケジュールした間隔が、必要な実行時間よりも短くないことを確認します。
指定サイトへのデータベース・リンクで接続修飾子を使用した場合は、そのサイトにリンクする他のサイトでも同じ接続修飾子を使用する必要があります。たとえば、次のようにデータベース・リンクを作成するとします。
CREATE DATABASE LINK dbs1.example.com@myethernet CONNECT TO repadmin IDENTIFIED BY password USING 'connect_string_myethernet';
マスター・サイトかマテリアライズド・ビュー・サイトかにかかわらず、dbs1.example.com@myethernetに対応付けられたすべてのサイトで、接続修飾子myethernetを使用する必要があります。
|
関連項目: データベース・リンクと接続修飾子の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
マルチマスター・レプリケーション・システムで問題が発生する可能性があります。次の各項で、これらの問題とその解決方法について説明します。
マスター・グループに新しいマスター・サイトを追加しても、新しいマスター・サイトで適切なオブジェクトが作成されない場合は、次の処理を実行します。
必要なプライベート・データベース・リンクが新しいマスター・サイトと既存のマスター・サイトの間に存在することを確認します。Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースの「構成ウィザード」を使用してサイトを設定した場合は、何も問題はありません。リンクは、既存の各サイトから新しいサイトへ、および新しいサイトから既存の各サイトへ相互に存在している必要があります。
すべてのサイトで管理要求が正常に終了していることを確認します。管理要求がまだ実行されていない場合、保留になっている管理要求を手動で実行し、即時に操作を完了させることができます。
マスター・グループ・オブジェクトを作成しても、またはマスター定義サイトでマスター・グループ・オブジェクトの定義を変更しても、変更がマスター・サイトに伝播されない場合は、すべてのサイトで管理要求が正常に完了していることを確認します。管理要求が保留になっている場合は、手動で実行して即時に操作を完了させることができます。
レプリケーションAPIを通してDDL文を実行すると、DDLを送信するユーザー名においてDDL文が実行されます。発行者のスキーマ以外のスキーマ内のオブジェクトにDDL文を適用するときは、発行者に文を実行する適切な権限が必要です。また、文の中でスキーマを明示的に指定する必要があります。たとえば、DBMS_REPCAT.CREATE_MASTER_ REPOBJECTプロシージャのddl_textパラメータに次のように指定するとします。
CREATE TABLE oe.new_employees AS SELECT * FROM hr.employees WHERE ...;
それぞれの表名にはスキーマ名が含まれるので、レプリケーション管理者がoeやhrまたは別のユーザーであっても、必要な権限があれば、この文は正しく機能します。
|
注意: 各スキーマ・オブジェクトの名前を適切なスキーマで修飾してください。 |
マスター・サイトのデータを更新し、その変更がレプリケーション環境の他のサイトに非同期で伝播されない場合は、次の処理を実行します。
Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースを使用して、対応する遅延トランザクションが接続先にプッシュされているかどうかをチェックします。プッシュされていない場合、スケジュール・リンクがキューを接続先サイトにプッシュするまでの待ち時間をチェックできます。リンクによるスケジュール・プッシュを待機できない場合、遅延トランザクションを手動で実行できます。
スケジュール・リンクのプッシュ間隔が経過しても対応する遅延トランザクションがプッシュされない場合は、リンクの対応するジョブをチェックします。
遅延トランザクションが接続先に伝播されても、エラーのために実行できない場合もあります。接続先サイトのDEFERRORのデータ・ディクショナリ・ビューでエラーの有無を調べます。
|
関連項目: 変更をレプリケートせずに表を変更する方法の詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。レプリケート表のデータを手動で同期する際にこの方法が必要になる場合があります。 |
レプリケート表を変更しようとしたときにdeferred_rpc_quiesce例外を受け取った場合は、レプリケート・オブジェクトが属するマスター・グループが静止または静止中になっています。先に進むには、レプリケーション管理者がマスター・グループのレプリケーション・アクティビティを再開する必要があります。
1つのUPDATE文をレプリケート表に適用すると、ゼロ以上の行を更新できます。UPDATE文を実行すると、ゼロ以上の更新要求が、更新される行ごとに1つずつ遅延実行用のキューに入れられます。Oracleでは文末で制約のチェックをまとめて行うので、制約が存在する場合はこの機能が重要になります。たとえば、バルク更新では一意制約違反が発生しなくても、同じ順序で1行ずつ更新すると一意制約違反が発生する場合があります。
更新順序が重要である場合は、適切な順序で1行ずつ更新します。これによって、遅延トランザクション・キューにおける更新要求の順序を定義できます。
パッケージ、プロシージャ、ビューなどのオブジェクトをマスター・グループに追加する場合は、オブジェクトの状態が有効である必要があります。オブジェクトの状態が無効の場合は、マスター・グループにオブジェクトを追加する前に、オブジェクトを再コンパイルするか、オブジェクトを削除して再作成してください。DBA_REPOBJECTのデータ・ディクショナリ・ビューでレプリケーション・オブジェクトの状態を調べます。
表のレプリケーション・サポートを生成すると、ローカル・サイトで内部トリガーがアクティブ化されます。レプリケーションに関連するほとんどのパッケージ(DBMS_REPCATやDBMS_DEFERなど)について、EXECUTE権限を、レプリケーション管理者およびレプリケート・オブジェクトを所有するユーザーに付与する必要があります。多くの一般的なレプリケーション・シナリオでレプリケーション管理者が必要とする権限は、Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースの「構成ウィザード」およびDBMS_REPCAT_ADMINパッケージを使用して付与します。ただし、レプリケート・オブジェクトの所有者がレプリケーション管理者でない場合は、DBMS_DEFERに対するEXECUTE権限をオブジェクトの所有者に対して明示的に付与する必要があります。
予期しない未解消の競合を発見した場合で、プロシージャ・レプリケーションと行レベルのレプリケーションが表に混在しているときは、プロシージャを注意深く検証し、レプリケート・プロシージャが競合の原因かどうかを確認します。次のチェックを実行します。
プロシージャでの更新と行レベルの更新の順序競合でないことを確認してください。
レプリケート・プロシージャが更新の実行前に表をEXCLUSIVEモードにロックしているかどうか、行レベルの更新の競合を回避するために他のメカニズムを使用しているかどうかをチェックします。
レプリケート・プロシージャの最初で行レベルのレプリケーションを使用禁止にし、最後に再び使用可能にしていることをチェックします。
プロシージャの実行時に例外が発生した場合も、行レベルのレプリケーションを再び使用可能にしていることを確認します。
レプリケート・プロシージャがすべてのマスター・サイトで実行されたことをチェックします。
レプリケート表で定義したレプリケート・トリガーのすべてについて、同様のチェックを行う必要があります。
サイトの遅延トランザクションが接続先にプッシュされない場合、その原因は次の各項で説明している問題である可能性があります。
スケジュール・リンクを作成すると、対応するジョブがサイトのジョブ・キューに追加されます。スケジュール・リンクが定期的な間隔で遅延トランザクションをプッシュするように設定しているときに問題が検出された場合は、まずジョブ・キューに関する問題かどうかを確認する必要があります。
同期レプリケーションを使用する場合、Oracleでは分散トランザクションを使用して、そのトランザクションがリモート・サイトで正しくコミットされるようにします。分散トランザクションでは2フェーズ・コミットが使用されます。非同期レプリケーションでは2フェーズ・コミットは使用されません。
|
関連項目: 分散トランザクション使用時の問題の診断方法の詳細は、『Oracle Database管理者ガイド』を参照してください。 |
指定したリモート・サイトにトランザクションがプッシュされていない場合、トランザクションの接続先の指定方法に問題がある場合があります。スケジュール・リンクを作成するときは、完全なデータベース・リンク名を指定する必要があります。
レプリケーション・システムのマテリアライズド・ビュー・サイトでは様々な問題が発生します。次の項では、これらの問題とその解決方法をいくつか説明します。
マテリアライズド・ビュー・サイトでオブジェクトの作成に失敗した場合は、次の処理を実行します。
更新可能マテリアライズド・ビューの場合は、対応するマスター表またはマスター・マテリアライズド・ビューにマテリアライズド・ビュー・ログがあることを確認します。
オブジェクトを作成する権限があるかどうかを確認します。マテリアライズド・ビューの場合は、マスター表またはマスター・マテリアライズド・ビューとそのマテリアライズド・ビュー・ログに対するSELECT権限が必要です。詳細は、「権限の割当て」を参照してください。
既存のマテリアライズド・ビューをマテリアライズド・ビュー・グループに追加する場合は、マテリアライズド・ビューを再作成してグループに追加します。
高速リフレッシュを実行する主キーまたは副問合せマテリアライズド・ビューを作成する場合は、マスター表やマスター・マテリアライズド・ビューのマテリアライズド・ビュー・ログに主キーがロギングされていることを確認します。
高速リフレッシュを実行するROWIDマテリアライズド・ビューを作成する場合は、マスター表のマテリアライズド・ビュー・ログにROWIDがロギングされていることを確認します。
副問合せマテリアライズド・ビューの場合は、必要な列がマテリアライズド・ビュー・ログに追加されていることを確認します。詳細は、「マテリアライズド・ビュー・ログへの列のロギング」を参照してください。
高速リフレッシュを実行するマテリアライズド・ビューと関連するすべての表に対して、マテリアライズド・ビュー・ログが存在することを確認します。マテリアライズド・ビューに副問合せが含まれている場合は、副問合せで参照される表のそれぞれに対してマテリアライズド・ビュー・ログが必要です。
デプロイメント・テンプレートをオフラインでインスタンス化しようとしたときに、一時表領域でエクステントを初期化できないというエラーを受け取った場合に、一時データベースが自動的に拡張されるように、一時データベースのデータファイルを調整する必要があります。
たとえば、次の文を発行してデータファイルを調整します。
ALTER DATABASE TEMPFILE '/u02/oracle/rbdb1/temp.dbf'
AUTOEXTEND ON
NEXT 10M;
この調整を行った後、マテリアライズド・ビュー・サイトでデプロイメント・テンプレートをオフラインでインスタンス化します。
次の項では、マテリアライズド・ビューのリフレッシュに関するいくつかの一般的な問題について説明します。
次のようないくつかの一般的な要因で、マテリアライズド・ビューのグループの自動リフレッシュが実行されない場合があります。
マテリアライズド・ビュー・データベースでのジョブ・スレーブの欠落
ネットワークまたはサーバー障害の影響
サーバー・シャットダウンの影響
マテリアライズド・ビューのリフレッシュ・グループで問題が発生したときは、前述の状況が原因かどうかを確認します。
グループの自動リフレッシュが失敗すると、グループはリフレッシュ実行予定のままになります。次の条件に基づいて、グループの自動リフレッシュが再試行されます。
グループのリフレッシュを初回は1分後、次は2分後、その次は4分後というように、失敗するたびに再試行間隔を倍にします。
再試行間隔はリフレッシュ間隔自体より長い時間にはなりません。
最高16回まで自動リフレッシュを再試行します。
リフレッシュ・グループのリフレッシュを16回再試行してもエラーが発生する場合は、グループは破損しているとみなされます。Schema Managerの「リフレッシュ・グループ」プロパティ・シートの「一般」ページを参照すると、いつリフレッシュ・グループが破損したかがわかります。USER_REFRESHおよびUSER_REFRESH_CHILDRENデータ・ディクショナリ・ビューのBROKEN列を問い合せて、リフレッシュ・グループの現在の状態を知ることもできます。
マテリアライズド・ビューのリフレッシュ・グループの破損によるエラーは、トレース・ファイルに記録されます。リフレッシュ・グループが正常にリフレッシュされない原因となった問題を修正し、グループを手動でリフレッシュする必要があります。この結果、破損フラグがリセットされ、自動リフレッシュが実行できるようになります。
|
関連項目: マテリアライズド・ビュー・トレース・ファイルの名前の形式はjnで、nはオペレーティング・システム固有です。各システムにおける名前は、オペレーティング・システム固有のOracleドキュメントを参照してください。 |
新規マテリアライズド・ビュー・サイトでマテリアライズド・ビュー作成中に、マスター表またはマスター・マテリアライズド・ビューのマテリアライズド・ビュー・ログがパージされる場合があります。これが発生すると、次のエラーが検出される場合があります。
ORA-12004 REFRESH FAST cannot be used for materialized view materialized_view_name ORA-12034 materialized view log on materialized_view_name younger than last refresh
マテリアライズド・ビュー・グループのリフレッシュが継続的に繰り返される場合、グループのリフレッシュ間隔をチェックします。グループの自動リフレッシュ間隔は、リフレッシュを開始する前に評価されます。グループのリフレッシュ間隔がグループのすべてのマテリアライズド・ビューのリフレッシュに要する時間よりも短い場合、ジョブ・スレーブで未処理ジョブのキューがチェックされるたびに、グループ・リフレッシュが繰り返し開始されます。
マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトでマテリアライズド・ビュー・ログが大きくなりすぎる場合は、ネットワークまたはサイトの障害のためにマテリアライズド・ビューが削除されたことが、マスター・サイトまたはマスター・マテリアライズド・ビュー・サイトで認識されているかどうかをチェックします。マテリアライズド・ビュー・ログの部分的なパージ、あるいは未使用のマテリアライズド・ビュー・サイトの登録の解除が必要になる場合があります。
|
関連項目: マテリアライズド・ビュー・ログの管理方法の詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。 |
マテリアライズド・ビューのリフレッシュに関する問題が発生している場合、次の処理を実行します。
DBA_REFRESH_CHILDRENビューに表示されているNEXT_DATE値をチェックして、リフレッシュがスケジュールされているかどうかを判断します。
リフレッシュ間隔が経過している場合は、DBA_REFRESHビューで、マテリアライズド・ビューのリフレッシュが対応付けられたジョブ番号をチェックして、ジョブ・キューに関する問題の診断を行います。
実行中のジョブ・スレーブがあるかどうかをチェックします。JOB_QUEUE_PROCESSES初期化パラメータをチェックし、DBA_JOBS_RUNNINGビューを問い合せ、オペレーティング・システムを使用してジョブ・スレーブが稼働中かどうかをチェックします。
2つのマテリアライズド・ビュー間のマスター・ディテール関係を定義すると、エラーが発生することもあります。マスター・ディテール関係は、宣言参照整合性の制約を使用して、マスター表に対してのみ定義します。その後、関連するマテリアライズド・ビューを同じリフレッシュ・グループ内に入れて、この関係を保ちます。ただし、遅延(遅延可能)制約はマテリアライズド・ビューに対して定義します。
マテリアライズド・ビューのマスター・サイトまたはマスター・マテリアライズド・ビュー・サイトに未解決の競合が記録されている場合、REFRESH_AFTER_ERRORSをTRUEに設定しないとマテリアライズド・ビューをリフレッシュできません。このパラメータは、マテリアライズド・ビューのリフレッシュ・グループの作成または変更時に設定できます。Oracle Enterprise Managerのアドバンスト・レプリケーション・インタフェースに、これと対応するパラメータがあります。
同じリフレッシュ・グループ内のマテリアライズド・ビューでは、行は1つのトランザクションで更新されます。このようなトランザクションは非常に大きくなる可能性があるので、大きなロールバック・セグメント(リフレッシュ中に使用するように指定したロールバック・セグメントを含む)がマテリアライズド・ビュー・サイトで必要になるか、または、リフレッシュをより頻繁に実行してトランザクションのサイズを小さくする必要があります。
OracleエラーORA-12004が発生した場合は、マテリアライズド・ビュー・ログを管理するためにマスター・サイトでロールバック・セグメントが不足したか、マテリアライズド・ビュー・ログの情報が古い可能性があります。たとえば、マテリアライズド・ビュー・ログがパージまたは再作成された可能性があります。
1つのマテリアライズド・ビューの完全リフレッシュでは、内部的にTRUNCATE機能が使用されるので、処理速度が向上し、ロールバック・セグメントの必要量が少なくなります。ただし、マテリアライズド・ビューが完全リフレッシュされるまで、マテリアライズド・ビューには一時的にデータが表示されないことがあります。複数のマテリアライズド・ビュー(リフレッシュ・グループなど)をリフレッシュするときは、TRUNCATE機能は使用されません。
マスター表を再編成するとき(たとえば、システム・リソースの再利用などの目的で)は、マスター表にTRUNCATE機能を実行して、ROWIDマテリアライズド・ビューの完全リフレッシュを実行する必要があります。そうしないと、マテリアライズド・ビューがマスター表への誤ったROWIDを持つことになります。マスター表の再編成には、DBMS_MVIEWパッケージのBEGIN_TABLE_REORGANIZATIONおよびEND_TABLE_REORGANIZATIONプロシージャを使用します。詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。
リフレッシュの実行中にエラーORA-00942(表またはビューが存在しません)が発生した場合は、データベース・リンクをチェックし、マスター表またはマスター・マテリアライズド・ビューとマテリアライズド・ビュー・ログに対して必要な権限を持っていることを確認します。
高速リフレッシュが成功した後で障害が発生した場合、次の点をチェックします。
マテリアライズド・ビュー・ログの切捨て、パージまたは削除が実行されたかどうか
マテリアライズド・ビュー・ログに対する必要な権限を持っているかどうか
強制リフレッシュに非常に長い時間を要する場合は、リフレッシュ時に使用するマテリアライズド・ビュー・ログが削除されていないかチェックします。
BUILD DEFERREDを使用して作成したマテリアライズド・ビューの最初の高速リフレッシュが失敗した場合は、その他の問題をチェックする前に、前の完全リフレッシュが成功していたことを確認します。
|
関連項目: マテリアライズド・ビュー・ログの管理方法の詳細は、『Oracle Databaseアドバンスト・レプリケーション・マネージメントAPIリファレンス』を参照してください。 |
