以下の項目で、レプリケーション ソリューションを実装したことで遭遇するかもしれない、最も一般的に発生する問題のトラブルシューティングと解決のための情報を提供します。

次の表に、問題解決に役立つリソースを示します。

問題を解決する前に、まず原因を究明する必要があります。以下のチェックリストでは DataExchange における問題を診断するのに役立つ項目を挙げます。

引き続き、各チェックリスト項目の詳細についてお読みください。

1 つのレプリケーション ネットワークに対して複数の第 1 サイトを設定すると、予期しない結果を招くことがあります。レプリケーション ネットワークごとに 1 つの第 1 サイトのみをインストールするようにしてください。

C:\ProgramData\Actian\Zen\Replication 下にあるデータベースをアクティブ化していた場合、まずこれらを非アクティブ化し、次にテンプレート リムーバ ウィザードを使用してレプリケーション テンプレートを削除します。テンプレートを削除する前にデータベースを非アクティブ化しなかった場合、アンインストール処理ではデータベース ファイルと関連するレプリケーション ファイルをそのまま残します。残されたファイルは何の問題も起こしませんが、これらを削除することによって物理ストレージを再生することができます。必要であれば、これらのファイルを直接手作業で削除することもできます。また、データベースに関連付けられた DSN を削除することも忘れないでください。

Zen System Analyzer（ZenSA）は、Zen データベース エンジンに含まれる診断ユーティリティです。ZenSA はスタンドアロンの診断ツールとして使用し、ネットワークの問題を解決するのに役立ちます。

レプリケーションを実行するためには Zen データベース エンジンが起動している必要があります。

レプリケーションを実行するためには、DataExchange レプリケーション エンジンが起動している必要があります。試用版ライセンスの期限が切れた場合などは、エンジンが起動しなくなります。

Zen License Administrator ユーティリティを使用して、DataExchange の期限なしライセンスがあるか、または試用版ライセンスの期限が切れていないかを確認します。『Zen User's Guide』で License Administrator に関するトピックを参照してください。

DataExchange ではイベントのログを記録することができます。DataExchange 監視ツール、DataExchange Manager、および DataExchange レプリケーション エンジンの動作を捕捉することができます。さらに、DataExchange はメッセージ ログとインストール ログも保持します。

ログはすべてテキスト ファイルで、最新のログ ファイルの拡張子は .log となります。ログ ファイルは情報、警告、エラー、およびデバッグについてのデータを組み合わせて作成します。詳細なメッセージ（簡潔なメッセージに対し）を選択することができます。詳細なメッセージにはプログラム名とプログラム内での行番号が含まれていて、デバッグの際に役立ちます。詳細なメッセージは、デバッグ ログ レベルのみに適用されます。

DataExchange レプリケーション エンジン（DRE）はその動作を dre.log ファイルに記録します。このファイルのデフォルトの場所は C:\ProgramData\Actian\Zen\Replication\LogFiles です。ZenCC の［データベース］ブランチ下にある［レプリケーション］アイコンを右クリックし、［統計およびログ ビュー］を選択すると、このファイルにあるレプリケーション動作を確認することができます。テキスト エディターを使用してログ ファイルを直接開くこともできます。

DataExchange Manager を使用して、さまざまなログ ファイル オプションを設定することができます。ログのデフォルトの場所を変更することもできます。また、デフォルトのログ サイズや履歴として保持するファイルのデフォルトの数も変更できます。手順については、DataExchange Manager での作業を参照してください。

ログ ファイルの最大サイズにゼロ（制限なし）を設定すると、ログ ファイルは物理ストレージが許す限りのサイズに増大します。トラブルシューティング時以外は、最大ログ サイズにゼロを設定しないことをお勧めします。その場合でも、長期間（一般的に 4 時間以上）に渡って「制限なし」を使用することは避けてください。たとえば、DRE ログのサイズは実行中のログの種類（デバッグ ログなど）、レプリケーションの頻度、およびレプリケーションを行うサイトの数によっては急速に増大します。

dre.log の場合、ログ ファイルが最大サイズに達すると、ファイルは次の履歴ファイル名に再割り当てされます。たとえば、dre.log が最大サイズに達したとき、このファイルは dre.LO1 という名前に変更され、新しい dre.log ファイルが作成されます。この時点で dre.log は空で、再びデータの収集を開始します。再度ファイルが最大サイズに達すると、dre.LO1 の名前が dre.LO2 に変更され、dre.log が dre.LO1 に変更されます。そして、新しい dre.log ファイルは空のファイルとなり、データの収集を始めることができます。［保持する最大ログ数］の設定は、LO1、LO2、LO3 などのように残しておく履歴の限度を決定します。

その他の DataExchange コンポーネントは、ユーティリティまたはサービスが実行されると自動的に新しいログ ファイルを開始します。ユーティリティが起動されるたびに、それに関連するファイル名.log ファイルは、ファイル名.LO1 ファイルにコピーされます。ユーティリティは、空になったファイル名.log ファイルにログの記録を開始します。前にも説明したように、［保持する最大ログ数］の設定で保存数が制御されます。

DataExchange Manager および DataExchange 監視ツールには、ログの設定を変更することができるロギング ダイアログがあります。

次の表で、さまざまなログ ファイルの内容について説明します。

ここでは、データのレプリケーションに関連するトピックを取り上げます。

スケジュールを削除、変更または無効にした場合、その他のレプリケーション サイトはこれを認識しません。これはレプリケーションが発生しないためです。その他のサイトの通知エージェントは引き続きスケジューリング サイトに接触を試みます。スケジューリング サイトが停止している、あるいはサイトに到達できない場合、エージェントは失敗の警告を送信します。スケジュールはもう適用されていないため、この警告は正しくありません。

このような間違った警告を防ぐためには、スケジュールを削除、変更または無効にした後にレプリケーションを手作業で初期化してください。このレプリケーションによって、確実にスケジュールの変更がレプリケートされます。レプリケーション ネットワーク全体がレプリケーションを必要としなくなった場合は、ネットワーク上のすべてのレプリケーション サイトを非アクティブ化するという方法もあります。

スケジュールをリモートから変更した場合、このような状況が起こります。たとえば、サイト B で DataExchange Manager を起動し、これを使用してサイト A のスケジュールを変更します。サイト A のレプリケーション エンジンは、再起動されない限り新しい設定を使用しません。しかし、通知エージェントは再起動なしで新しいスケジュールを使用します。エージェントは、レプリケーションのスケジュールが間違っていることを適切に通知します。

このような状況を回避するには、スケジュールをリモートから変更しないでください。

動的に作成したテーブルがレプリケートされない場合は、dCNF テーブル内のファイルのマッチング パターンが正しいかどうか調べてください。DataExchange には、ファイルのマッチング パターンを調べるのに役立つ、Dxdynpath というユーティリティが用意されています。dxdynpath を参照してください。

相対パスは、DataExchange が認識できるデータ辞書ファイル（DDF）を含むホーム ディレクトリに対する相対パスであることに注意してください。

SQL トリガーとは、INSERT、UPDATE、または DELETE によってテーブル内のデータが変更されるときに自動的に実行されるストアド プロシージャの一種です。ストアド プロシージャは、あらかじめ定義されデータベース辞書に保存されている SQL ステートメントです。

レプリケーションは従属テーブルを更新する前にベース テーブルを更新します。この順序により、外部キーのリレーションシップが正しく維持されます。たとえば、サンプル データベース Tracker の場合では Region テーブルが Employee テーブルの前に更新されます。

例として、ベース テーブル A と従属テーブル B（テーブル B は外部キーで A と関連付けられている）があると仮定します。テーブル B にレコードが追加された場合にテーブル A を更新するトリガーを作成します。

パートナー サイト 1 では、新しいレコードをテーブル B に追加し、これによりトリガーが実行されます。テーブル A はパートナー サイト 1 で更新されました。次にパートナー サイト 1 を別のサイトとレプリケートします。

その他のサイトでは、レプリケーションがテーブル A を更新し、新しいレコードをテーブル B に追加します。これによりテーブル B のトリガーが実行され、再度テーブル A の更新を試みます。レプリケーション エンジンは既にテーブル A のレコードをパートナー サイト 1 で行われた変更で更新してしまっているので、この動作は好ましくありません。

トリガーとレプリケーションに関する明確な規則はありません。一般的に、レプリケートされるデータベースの一部である各トリガーについて注意深く考慮する必要があります。トリガーの機能とレプリケーションの動作について明確にすることにより、期待した結果を確実に得ることができます。

デザイン時にレプリケーションのために準備したテンプレート データは、アクティブ化で準備されたデータとは異なるマーク（タイムスタンプとその他の内部方式）が付けられています。レプリケーション エンジンはこの違いをレプリケーション中に解決します。まれに、第 1 サイトをアクティブ化した方法とパートナー サイトをアクティブ化した方法の間でデータの競合が起こることがあります。

ページ サイズが 4096 バイトのデータ ファイルでは、ファイル当たりのインデックス セグメント数は 119 に制限されます。真のヌルがサポートされるインデックスの設定されたヌル値を許可する列には 2 つのセグメントから成るインデックスが必要なため、1 つのテーブルではインデックス付きのヌル値を許可する列（Btrieve ファイルでは、インデックス付きでヌル値を許可する真のヌル フィールド）は 59 個までしか持てません。ページ サイズが小さくなると、この制限も小さくなります。

Zen で、ファイル作成モードを 7.x に設定し、TRUENULLCREATE をデフォルト値のオンに設定して作成されたファイルはすべて、真のヌルをサポートします。以前のファイル形式で作成されたファイル、あるいは PSQL 7 を使用するか TRUENULLCREATE をオフに設定して作成されたファイルは、真のヌルをサポートせず、この制限を受けません。

TRUENULLCREATE の詳細については、『SQL Engine Reference』を参照してください。

レプリケーション ソリューションの中核は、競合が起きたときにそれを検出して解決することです。競合の最良の解決方法は、予防です。デザインによって競合を回避します。これらに加え、DataExchange にはデフォルトの Last-in-wins（最新操作の優先）ポリシーがあります。制御テーブルのタイムスタンプを保持し、レプリケーション サイトの時計と同期化することにより、レコードがいつ追加、更新および削除されたかの正確な情報が保持されます。競合が発生すると、レプリケーション エンジンが競合のポリシーを実施（かつ競合をログに記録）する責務を果たします。

さらに、DataExchange は独自の競合解決方法を定義できるインターフェイスも提供します。どのような業務規則に対しても適切な競合解決をデザインし、イベント ハンドラー DLL を介して解決方法を提供することができます。DLL はレプリケーション エンジンの機能を置き換えるかまたは拡張します。

データの競合は DataExchange によっていくつかの種類に分けられます。競合はそれぞれログ ファイル dre.log に記録されます。ログのエントリを読んで、競合があれば必要な操作を決定してください。ログには以下のようなメッセージが記録されます。ログには競合の種類、関連するレコードのキー、および競合を解決した方法が含まれます。

競合が起きるとレコードは上書きされ、常に最新のレコードが使用されます。この動作を変更するためには、レプリケーション エンジンに独自にカスタマイズしたイベント ハンドラー DLL を登録する必要があります。

レコードが更新されなかったサイトのログ ファイルには、上の例のようにパートナー サイトでレコードが更新されたことを示すメッセージが含まれます。レコードが上書きされたサイトのメッセージは次のようなもので、変更前のデータ値と変更後のデータ値を示します（この例ではラスト ネーム Yin が Yan に置き換えられました）。

タイプ I の競合は、最後のレプリケーション セッション以降にレコードが両方のサイトで更新されたときに発生します。これが発生した場合、新しいレコードがレプリケートされ、次のメッセージに似たログ メッセージが生成されます。

この種の競合のバリエーションとして、以下のようなシナリオと関連するログ メッセージがあります。

タイプ V の競合は、各サイトのスタート データにエラーがある場合に発生します（データベース アプリケーションがアクティブ化されたときにデータベース内に既に存在するデータ）。

スタート データが 1 つのサイトに存在してもう一方には存在しない場合、スタート データはもう一方のサイトにレプリケートされます。ただし、既存のスタート データが異なる場合はタイプ V の競合はログに記録されてレプリケーションが停止します。

1 つのサイトで追加または更新されたレコードと、別のサイトで削除されたレコードの競合は、タイプ VI の競合として扱われます。競合処理の間、すべてのレコードが 1 つのサイトで更新（またはレコードが追加）されていて、そのレコードが別のサイトで削除されている場合、タイプ VIa の競合がログに記録され、最新の操作が優先されます。レコードが更新されていない場合、削除操作が常に優先されます。このタイプ VI の競合は、レコードが削除されたサイトでそのレコードを再度追加するための十分な情報がないため、このような方法で解決する必要があります。考えられるシナリオと関連するログ メッセージについて、以下に説明します。

レプリケーション サイクル中に競合の解決に成功した場合、レプリケーション ログ ファイルに次のようなメッセージが記録されます。

主キーの競合を解決する最良の方法は、ソース データベースの主キーを一意のキーとしてデザインすることです。一意の主キーを持たない既存のデータベースをレプリケーションに使用している場合、Control Center を使用して主キーを指定することができます。

主キーの競合は、同じ主キーを持つ 2 つの異なるアクティブなデータベースに 2 つの行が挿入されたときに発生します。それぞれの行は潜在的に関連のあるデータのため、レプリケーション エンジンはレプリケーションを停止してこれらの行を変更しません。

主キーの競合が検出されたシステム上の dre.log ファイルに以下のエラーが記録されます。たとえば、サンプル データベース Tracker の Region テーブルで主キーの競合が検出されたとします。

このシステムとレプリケートを試みたシステムはすべてこのエラーで失敗します。

主キーの競合を修復するには、手作業が必要です。これらの競合している行の 1 つを新しい一意の値に変更する必要があります。それに引き続きレプリケーション セッションを開始する必要があります。

たとえば、上の例では、主キー 8 で競合が発生しています。したがって、関連のあるデータベースの 1 つで主キーをそのテーブルでの一意なキーである 9 に変更します。次に、その 2 つのシステムを一緒にレプリケートします。

このレプリケーション中に、レプリケーション制御テーブルがクリーンアップされて主キーの競合が訂正され、dre.log ファイルには警告メッセージとして次のように書き込まれます。この目的は、主キーの競合の解決に成功したことを知らせることです。

これにより、データベース内のデータに関しては何が起きているのでしょうか？この処理を段階的に見た Region テーブルの内容を示します。まず、各サイトに同じキー値を持つ行が挿入されました。

レプリケートを行い、主キーの競合が発生しました。レプリケーションは停止してどのテーブルも更新されませんでした。

1 つのサイトを新しい一意の値で更新します。

新しい変更をレプリケートします。

これで両サイト共に矛盾のないデータのコピーがレプリケートされ、どのデータも失われませんでした。

通知エージェントは、マシンに Zen サーバー製品が含まれている場合にのみインストールされます。通知エージェントが電子メールを送信しない場合は、以下の点を調べてください。

SMTP メール サーバーも正しく機能している必要があります。必要に応じ、SMTP メール サーバーが電子メールを正しく送受信しているかどうかを調べてください。お使いの SMTP サーバー ソフトウェアのマニュアルを参照するか、ベンダーの Web サイトでテスト用のプロシージャをチェックします。