Chat now with support
Chat with Support

SharePlex 8.6.6 - リファレンス・ガイド

このガイドについて このガイドで使用されている表記規則 SharePlex コマンド SharePlex パラメータ SharePlex ユーティリティ 付録 B:SharePlex 環境変数

同期の問題の解決

このセクションでは、一般的な同期の問題の原因および解決方法を説明します。こうした解決方法を試しても問題が解決しない場合は、Quest サポートに連絡してください。

詳細については、次を参照: 同期の概念について

発生した問題がこのドキュメントに記載されていない場合は、以下のアドレスの SharePlex サポート技術情報を検索してください。

https://support.quest.com

サポート技術情報には、フィルタリングオプションと、SharePlex の使用およびトラブルシューティングに役立つ他のリソースへのリンクがあります。

SharePlex が非同期状態を報告するしくみ

SharePlex は、トランスフォーメーションに関与するものを除き、すべてのオブジェクトについて、複製されたデータをターゲットに post する前に、所定の操作でソースおよびターゲットのデータが同期されていることを確認します。トランスフォーメーションが使用中の場合、次の理由から、SharePlex は同期を検証しません。

  • トランスフォーメーションがターゲットデータを変更するために、変更前と変更後のイメージを比較できない。
  • SharePlex ではなく、トランスフォーメーションルーチンがデータを post する。

SharePlex は、ソースとターゲットのデータが異なると判断した場合は、エラー状態を生成しますが、post キューからの他のデータの post は継続します。非同期状態が検出されたときに Post で処理を停止するようにするには、SP_OPO_OUT_OF_SYNC_SUSPEND(Oracle)または SP_OPX_OUT_OF_SYNC_SUSPEND(オープンターゲット)パラメータを変更します。『 SharePlex リファレンスガイド』で Post パラメータの説明を参照してください。

非同期状態が発生すると、Post プロセスは Status Database およびイベントログにメッセージを記録します。これらのファイルを sp_ctrl で表示するには

  • Status Database:show statusdb または show sync コマンドを使用します。
  • イベントログ:show log コマンドを使用します。

非同期状態エラーを監視するために、これらのコマンドを頻繁に使用してください。

次は、SharePlex が非同期状態を報告する様子の例です。

sp_ctrl (irvspxu14:8567)> show sync

Out Of Sync Status Database irvspxu14

Count Details

----- --------------------

3 Table "SCOTT"."TG_TEST1" out of sync for queue irvspxu14 since 16-Jun-

08 17:06:33

3 Table "SCOTT"."TG_TEST2" out of sync for queue irvspxu14 since 17-Jun-

08 15:47:58

1 Table "SCOTT"."TG_TEST3" out of sync for queue irvspxu14 since 17-Jun-

08 15:52:03

データが非同期になった場合、SharePlex は、SharePlex 変数データディレクトリの data サブディレクトリにある database_ID_errlog.sql ファイルに失敗した SQL 文を記録します。

重要: Status Database およびイベントログで非同期メッセージが表示されたが、トランザクションの database_ID_errlog.sql ファイルにはレコードがない場合でも、これらのメッセージを無視しないでください。これらは、ROLLBACK. に関連付けられていることがあります。トランザクションがロールバックされるかどうかに関わらず、SharePlex はソースおよびターゲット行のプリイメージを依然として比較します。それらが異なる場合は、データが非同期になっていることを示します。トランザクションがソースでコミットされたが、ターゲットで失敗したときにのみ、SharePlex はそれを database_ID_errlog.sql ファイルに記録して、問題解決のツールとして、また必要に応じて文を手動で適用するために、適用されているべきであった文の記録を残します。ロールバックされた文は、取り消された操作なので、ターゲットには記録されません。

誤った非同期状態の検出

非同期メッセージが誤っており、実際にはデータが非同期状態ではないことがあります。compare コマンドを使用してソースデータとターゲットデータを比較したり、以下の比較を手動で実行したりすることができます。

compare コマンドで比較するには

『 SharePlex リファレンスガイド』で compare コマンドを参照してください。

データが非同期状態であることを確認するには

  1. ターゲットシステムの変数データディレクトリにある database_ID_errlog.sql ファイルから、影響を受ける行の rowid を取得します。
  2. WHERE 句で rowid を使用して、ソーステーブルで SELECT クエリを実行し、この rowid の行データを取得します。
  3. ソースのクエリから取得した行データを WHERE 句で使用して、ターゲットテーブルで SELECT クエリを実行します。
  4. クエリの結果を比較します。異なる場合は、行が非同期状態です。同じ場合は、行が同期されています。

一般的な非同期状態と解決方法

次に、データが非同期になる一般的な状態を説明します。ほとんどの場合で、SharePlex が非同期状態を検出し、エラーメッセージを戻しますが、非同期状態が隠れていて、SharePlex がエラーを戻さない状況もあります。

非同期状態 説明 解決策

不正確なクリーンアップ手順

いずれかの database_cleansp クリーンアップユーティリティが、(すべてではなく)一部のアクティブ設定に関係するシステムで実行されると、SharePlex は非同期状態と認識します。

イベントログを確認して、クリーンアップユーティリティがすべてのシステムで実行されたかどうかを判断します。ログから、各システムで実行されたかどうかと、その実行時期が分かります。また、設定がアクティベートされたかどうか、およびその時期も分かります。これらのイベントの時間を比較することで、何が起こったかを判断できます。

この設定のすべての複製システムでクリーンアップが完了していない場合は、クリーンアップユーティリティをすべてのシステムで実行します。クリーンアップでは、複製キューおよびプロセスを削除して、設定をディアクティベートするために、最初の同期を再び実行する必要があります。

DDL 変更

DDL に関連する非同期状態の原因には次のようなものがあります。

  • ソースオブジェクトに対して複製されていない DDL 変更が行われたが、設定が再アクティベートされておらず、オブジェクトを再分析できない。
  • SharePlex が複製する DDL が、ターゲットでも手動で実行されている。

サポートされる DDL のリストについては、『SharePlex リリースノート』を参照してください。

手動および SharePlex による重複した DDL 変更を取り消すには

  1. Post プロセスを停止します(すでに停止されていることがあります)。

    sp_ctrl(sysB)> stop post

  2. DDL 変更を取り消すために、ターゲットテーブルを変更します。
  3. Post を開始して、SharePlex に複製された DDL を post させます(これはまだ post キューにあります)。

    sp_ctrl(sysB)> start post

 

ターゲットに直接加えられた DML 変更 アプリケーションまたはユーザーがターゲットのテーブルに DML 変更を加えると、その変更の結果によって、Post が影響を受ける行に複製された変更を適用しようとするまで隠れた非同期状態が生じます。変更が適用されると、SharePlex は非同期エラーを返します。

複製中のターゲットテーブルに対するすべての DML アクセスを防止します。

compare および repair コマンドを使用し、テーブルで非同期行を比較し、該当する行を修復します。詳細については、『 SharePlex リファレンスガイド』でコマンドの説明を参照してください。

ターゲットオブジェクトのトリガ

トリガはターゲットオブジェクトで無効にする必要があります。トリガはソースシステムで起動され、SharePlex はその影響をターゲットに複製します。

トリガがターゲットシステムで起動された場合は、トリガで変更されたオブジェクトは非同期になるので、再同期する必要があります。「ソーステーブルとターゲットテーブルの再同期方法」を参照してください。

Oracle ターゲットでトリガの効果を無効にするには

データを再同期した後でターゲット Oracle オブジェクト上のトリガの効果を無効にするには、次のいずれかを実行します。

  • SharePlex Oracle ユーザーを無視するようにトリガに指示する sp_add_trigger.sql スクリプトを実行します。トリガスクリプトの詳細については、『 SharePlex リファレンスガイド』でユーティリティの説明を参照してください。

  • 不要な場合はトリガを無効にします。
不要な制約

一方向の複製設定において、ターゲットテーブルで必要な制約は、プライマリキーおよび一意キー制約だけです。チェック制約はソースで満たされるため、ターゲットでは不要です。外部キーおよび ON DELETE CASCADE 制約もソースで満たされるため、SharePlex はターゲットの適切なテーブルに子操作を複製します。

Oracle ターゲットで ON DELETE CASCADE 制約を無視するように SharePlex を設定する場合は、この制約を有効にしておくことができます。

複製されるオブジェクトで制約を処理する方法については、 「複製する Oracle データベースオブジェクトのセットアップ」を参照してください。

設定ファイルの重複エントリ 重複エントリ(ソース、ターゲット、およびルーティングマップが同一)によって、ターゲットでの post が重複します。

設定ファイルを新しいファイルにコピーします。

新しいファイルで重複を探し、削除します。

ソーステーブルとターゲットテーブルの再同期方法」の指示に従って、再同期および再アクティベートを実行します。

ディスク領域の不足

SharePlex にデータをキューに格納するために十分な場所がないときに、ユーザートランザクションが継続した場合は、データが非同期になります。この状態は次の場合に発生します。

  • ネットワークまたはターゲットシステムが使用不能になり、export キューに蓄積したデータが多すぎた場合。
  • ターゲットが使用不能になり、Post キューに蓄積したデータが多すぎた場合。
  • Capture がソーストランザクションのロギングのペースに追い付かなくなった場合。この場合、Capture キューにデータが蓄積されます。
  • SharePlex プロセスが停止されたが、再起動されていない場合。
  • flush コマンドが発行されたが、Post が再起動されなかった場合。
ディスクスペース不足の解決方法」を参照してください。

水平分割レプリケーションでのカラムコンディションの変更

非同期状態は、次の場合に水平分割レプリケーションを使用すると発生する可能性があります。

  • カラムコンディション値が更新され、新しい値が行選択条件を満たさなくなった。
  • カラムコンディションを満たしていなかった行が、更新されて条件を満たすようになった。

パーティションシフトが発生しないようにカラムコンディションを作成する方法の詳細については、該当の資料を参照してください。

設定変更後に再アクティベートされていない。

テーブルが設定に追加されたが、設定を再アクティベートしなかった場合は、そのテーブルの操作は複製されません。

:Oracle ソーステーブルの場合、自動追加機能はデフォルトで有効であり、設定ファイルで名前がワイルドカードを満たす新しいテーブルは、複製に自動で追加されます。詳細については、次を参照: Oracle DDL 複製の制御

SharePlex がそのオブジェクトキャッシュをアップデートできるように、影響を受けたテーブルを再同期してから、設定を再アクティベートします。テーブルを再同期するには、「ソーステーブルとターゲットテーブルの再同期方法」を参照してください。

キューの破損

システム障害時など、SharePlex キューが破損している場合は、その中のデータが消失することがあります。この場合は、再同期が必要です。

テーブルを再同期するには、「ソーステーブルとターゲットテーブルの再同期方法」を参照してください。

(Oracle)システム障害によるキューの破損を防ぐには、SP_QUE_SYNC パラメータを使用できます。『 SharePlex リファレンスガイド』で Queue パラメータの説明を参照してください。

Oracle 関連の非同期状態と解決方法

次に、特に Oracle データベース間の複製に関連する、一般的な同期の問題を示します。ほとんどの場合で、SharePlex が非同期状態を検出し、エラーメッセージを戻しますが、非同期状態が隠れていて、SharePlex がエラーを戻さない状況もあります。

非同期状態 説明 解決策
DDL 変更

DDL に関連する非同期状態の原因には次のようなものがあります。

  • ソースオブジェクトに対して複製されていない DDL 変更が行われたが、設定が再アクティベートされておらず、オブジェクトを再分析できない。
  • SharePlex が複製する DDL が、ターゲットでも手動で実行されている。

サポートされる DDL のリストについては、『SharePlex リリースノート』を参照してください。

手動および SharePlex による重複した DDL 変更を取り消すには

  1. Post プロセスを停止します(すでに停止されていることがあります)。

    sp_ctrl(sysB)> stop post

  2. DDL 変更を取り消すために、ターゲットテーブルを変更します。
  3. Post を開始して、SharePlex に複製された DDL を post させます(これはまだ post キューにあります)。

    sp_ctrl(sysB)> start post

 

不適切または存在しない競合解決ルーチン

ピアトゥピア(active-active)設定では、競合解決手順が必要です。SharePlex は、同じデータ変更を異なるシステムから受信したときに、どの操作を post するかを判断するために、競合解決手順を使用します。

競合解決手順を修正およびテストしてから、「ソーステーブルとターゲットテーブルの再同期方法」を参照してください。
ログラップ

Capture が必要なデータを処理できる前に REDO ログがラップした場合は、アーカイブログが有効になっていない場合、または Capture が必要とするアーカイブログが削除されている場合に、データが非同期になることがあります(通常、Capture はアーカイブログにアクセスして、複製を継続します)。

問題を先に解決する」を参照してください。

  • アーカイブが有効になっていない場合は、SharePlex が読み取るアーカイブログはありません。ログラップの後で消失したデータは、回復できません。アーカイブログを有効にして、データを再同期してください。「ソーステーブルとターゲットテーブルの再同期方法」を参照してください。
  • SharePlex が多数のログで Oracle より遅れている場合は、ログをリストアする代わりにデータを再同期することを検討してください。Capture がアーカイブログから消失したレコードを処理するためにかかる時間よりも、この方が短いことがあります。さらに、こうすることで、アーカイブログを処理中に capture キューが空きディスク領域を超過する可能性がなくなります。REDO ログのサイズおよび複製するテーブルの数に基づいて判断することができます。両方が Capture が処理する必要がある情報の量を決定します。また、ターゲットデータのユーザーが許容できる遅延も考慮してください。
  • アーカイブログが利用可能な場合は、適切なログをソースシステムのアーカイブログディレクトリにコピーして戻すか、SP_OCT_ARCH_LOC パラメータを使用して、SharePlex にその場所を示します。
LONG 列

テーブルに主キーまたは一意キーがない場合は、SharePlex は「LONG および LOB 列を除いて」すべての列にシミュレーションされたキーを構築します。ターゲット行の LONG 列が一意の値を含む唯一の列である場合、シミュレーションされたキーの条件を複数の行が満たすことがあります。SharePlex は、エラーを検出せずに、違う行に UPDATE または DELETE を適用することがあり、これにより、エラーメッセージを表示せずにテーブルが非同期になります。

ターゲットテーブルの一意性を確保する列からキーを作成できる場合は、この種類の非同期状態を防止できます。キーを作成した後で、これらのオブジェクトを再同期して再アクティベートすると、SharePlex はそのオブジェクトキャッシュをアップデートできます。

主キーまたは一意キーを追加できない場合は(パッケージアプリケーションを使用している場合など)、ターゲットシステム上の行の一意性は保証できません。

キーの変更

テーブルがキーとして自動生成された数値シーケンスを使用しており、キーの値が変更される場合は、結果的にターゲットシステムで重複が生じる可能性があります。新しい値が、ターゲットシステムの他の行にキーとしてすでに存在している場合は、SharePlex が一意キー制約違反および非同期エラーを戻します。これは、x +n 式を使用して値をアップデートしたときに発生することがあります。ここで n は増分です。x +n の値の 1 つが既存の値に等しい可能性があります。

ターゲットシステムで更新によるキーの重複が発生しないように、シーケンスを作成します。詳細については、「複製する Oracle データベースオブジェクトのセットアップ」を参照してください。
ソースシステムやターゲットシステムで実行中の DBMS_SCHEDULER 手順 これらの手順の影響(オブジェクトの作成、複製外での操作や削除など)は、複製で認識されなかったりサポートされなかったりします。そのため、非同期状態の原因となるデータ変更が発生します。 ジョブからソースオブジェクトとターゲットオブジェクトを除外します。
仮想プライベートデータベース 仮想プライベートデータベースとして設定されたデータを複製する場合、SharePlex データベースユーザーにデータをキャプチャするアクセス権限がないことがあります。そのデータの変更は、ターゲットに反映されません。

そのデータがターゲットに複製される必要がない場合は、分割レプリケーションによって SharePlex 設定からフィルタで除外できます。

データを複製する場合は、SharePlex ユーザーに適切なアクセス権限を割り当てます。

PK/UK ロギングが有効でない キーの値をログに記録することで、特定の複製の問題を防止できます。SharePlex は、rowid に基づいてキーの値を取得します。ALTER TABLE...MOVE など、rowid を変更するあらゆる操作が、その後の DML 操作で間違ったキーの値が使用される原因となる可能性があります。 SharePlex は、プライマリキーと一意のキーの両方のサプリメンタルロギングを設定するか、複製内のすべてのテーブルで一意の列にサプリメンタルロググループを定義することをお勧めします。

問題を先に解決する

データが非同期になっている場合は、データを再同期する前に以下の手順を実行します。

  1. 非同期が発生した原因を特定してから、データを再同期してください。そうしない場合は、問題自体が繰り返され、より多くのデータが非同期になります。
  2. Post プロセスを停止して、エラーがこれ以上発生しないようにします。Post キューにメッセージが蓄積されるために、ディスクスペースの問題が発生しそうな場合、およびソースシステムに十分なディスクスペースがある場合は、Post が他のトランザクションによる操作の一部をクリアできるようになるまで、Import を停止できます。この手順については、「ディスクスペース不足の解決方法」を参照してください。
  3. Status Database とイベントログを表示して、問題の原因を特定します。
  4. 問題を解決します。

データの再同期

ソーステーブルとターゲットテーブルの再同期方法」を参照して、データを再同期します。

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating