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

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

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

各チェックリストの項目の詳しい説明については、本章の以降のセクションで述べています。

このセクションでは、インストールに関連するトピックについて説明します。

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

DataExchange をターミナル サーバー クライアントにインストールするには、まず、ターミナル サーバー クライアントのレジストリ設定を変更する必要があります。『Getting Started with Pervasive DataExchange』の Windows ターミナル サービス上へのインストールを参照してください。

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

データベースの非アクティブ化とテンプレートの削除方法の説明は、例を使った作業を参照してください。

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

PSA の使用法の詳細については、『Pervasive PSQL User's Guide』で説明されています。PSA に関する完全な情報については、このマニュアルを参照してください。

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

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

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

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

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

ログ ファイルのデフォルトの場所は <インストール ディレクトリ>\Replication\LogFiles ですが、変更することもできます。必要な場合は、デフォルトのログのサイズとデフォルトの保存ログ ファイル（履歴）の数を変更することもできます。LogFiles フォルダーは、オペレーティング システムの［スタート］メニューまたはアプリ画面から表示できます。

ログ ファイルの最大サイズにゼロ（制限なし）を設定すると、ログ ファイルは物理ストレージが許す限りのサイズに増大します。トラブルシューティング時以外は、最大ログ サイズにゼロを設定しないことをお勧めします。その場合でも、長期間（一般的に 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 コンポーネントは、ユーティリティまたはサービスが実行されると自動的に新しいログ ファイルを開始します。この場合、ユーティリティがアクティブにされるたびに、ユーティリティが関連付けられた XXX.log ファイルは新しい XXX.lo1 ファイルにコピーされます。ユーティリティは、空になった XXX.log ファイルにログの記録を開始します。この場合も、［保持するログの最大数］の設定は、lo1、lo2、lo3 などのように残しておく履歴の限度を決定します。

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

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

このセクションでは、データのレプリケーションに関連するトピックについて説明します。

［レプリケーションの開始］ダイアログからレプリケーションを開始することができます（このダイアログは、PCC のツリーで、［レプリケーション － 接続されました］を右クリックし、次に［タスク｜レプリケーションの開始］をクリックして表示します）。このダイアログで、ソース データベースおよびレプリケートするサイトを選択します。パートナー サイトのアクティブ化の方法によっては、レプリケートするサイトの一覧に矛盾があるように思われることがあります。

一覧に矛盾が見られる場合の一例を挙げます。パートナー サイト PS1 を作成して第 1 サイトと初期レプリケーションを行います（デフォルトの動作）。次に、パートナー サイト PS2 を作成しても、第 1 サイトと初期レプリケーションを行わなかったとします。

［レプリケーションの開始］ダイアログでソース データベースとして第 1 サイトまたは PS1 を選択した場合、PS2 はレプリケートするサイトとして表示されません。「パートナー サイトに何が起きたのだろう？」という疑問がわきます。PS2 はなぜ一覧にないのでしょう？

一覧に表示されないのは、レプリケーション ネットワークに関する情報（ネットワーク上のサイトなど）もレプリケートされてしまったためです。PS2 をソース データベースとして選択した場合、レプリケートするサイトとして最初のレプリケーション サイトの選択が表示されます。第 1 サイトとレプリケートを行った後、PS2 は第 1 サイトと PS1 の一覧に表示されます。

この一覧の整合性を確実に保つ最も簡単な方法は、各パートナー サイトをアクティブ化したときに第 1 サイトとの初期レプリケーションを行うことです。パートナー サイトは、第 1 サイトとレプリケートするまではほかのサイトとレプリケートできません。

レプリケーション ネットワーク上のその他のサイトは、レプリケーションが実行されるまでサイトが非アクティブ化されたことを認識しません。したがって、レプリケーション ネットワークからサイトを非アクティブ化した後に実行される最初のレプリケーションでは、そのサイトに対する処理が失敗します。これは正常な動作です。

DRE ログ ファイルには次のようなエラー メッセージが含まれます。

最初のレプリケーションが行われると、レプリケーション ネットワーク上のすべてのサイトがそのサイトの非アクティブ化状態を認識できるので、以降のレプリケーションでこのエラーは発生しません。

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

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

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

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

動的に作成したテーブルがレプリケートされない場合は、dCNF テーブル内のファイルのマッチング パターンが正しいかどうか調べてください。DataExchange では Dxdynpath というユーティリティを提供しているので、ファイル マッチング パターンを調べる際に役立ちます。『Pervasive DataExchange User's Guide』の 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 個までしか持てません。ページ サイズが小さくなると、この制限も小さくなります。

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

TRUENULLCREATE の詳細については、Pervasive PSQL マニュアルの『SQL Engine Reference』を参照してください。

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

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

イベント ハンドラー DLL の作成に関する情報は、株式会社エージーテックまでお問い合わせください。イベント コールバック API マニュアル（英語のみ）をご提供します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

これにより、データベース内のデータに関しては何が起きているのでしょうか？この処理を段階的に見た Region テーブルの内容を示します。

まず、各サイトに同じキー値を持つ行が挿入されました。

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

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

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

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

通知エージェントは、マシンに Pervasive PSQL サーバー製品が含まれている場合にのみインストールされます。これはワークグループ製品では使用できません。通知エージェントが電子メールを送信しない場合は、以下の点を調べてください。

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

Pervasive Software では、インストールが正しく完了するよう万全を期しています。インストール中またはインストール後に、ユーザー マニュアルでは対処できない問題が発生した場合は、株式会社エージーテックにお問い合わせください。速やかに対処いたします。

次の表では、ご質問への回答や問題のトラブルシューティング方法に関するリソースおよび問い合わせ先についての情報を提供しています。

Pervasive DataExchange のインストールに関するご質問や問題については、株式会社エージーテックのサポート サービス部門がお役に立ちます。

Pervasive 製品のご購入後、最初のお問い合わせから 30 日間は、インストールや設定に関する問題のテクニカル サポートを無償でご提供いたします。