配信プロトコルの実行設定の指定
配信プロトコルを構成するときには、配信の再試行、失敗、およびタイムアウトの処理を構成する複数の実行設定を定義できます。このトピックでは、これら配信プロトコルの実行設定を指定する方法について説明します。
通知配信の再試行
通知の配信に失敗した場合は、ディストリビュータで通知の配信を再試行することができます。通知クラスで使用される各配信プロトコルに対して、再試行スケジュールを構成します。
再試行のロジックは、ディストリビュータの作業項目レベルで適用されます。配信できない通知が作業項目にあった場合は、ディストリビュータの作業項目自体が失敗したものと見なされます。この場合、ディストリビュータは、指定されているスケジュールに従って、ディストリビュータの作業項目の配信を後に再試行します。
ディストリビュータによる作業項目の再試行では、前回配信されなかった通知のみが再送信されます。ただし、エラーが発生した結果、ディストリビュータが通知の配信の状態を更新できなかった場合は、配信が再試行されて、次回の再試行の際に重複した通知が再送信される可能性があります。
再試行スケジュールを構成するときには、再試行間隔の値を 1 つ以上指定します。通知の配信が失敗した場合、ディストリビュータは、1 つ目の再試行間隔の値で指定されている時間が経過してから作業項目を再度取得します。通知の配信が再度失敗した場合は、2 つ目の再試行間隔が経過してから配信を再試行します。再試行間隔の値がなくなるか、配信されていない通知の有効期限が切れるまで、このプロセスが繰り返されます。
.gif "ms171406.note(ja-jp,SQL.90).gif") メモ : |
|---|
| 有効期限は、配信プロトコルではなく通知クラスごとに指定します。詳細については、「通知の有効期限の指定」を参照してください。 |
例
次の表は、再試行間隔の値が 3 つ指定されている場合にディストリビュータがどのように通知の配信を再試行するかを示しています。
1 回目の配信 |
1:00 |
1 つ目の再試行間隔 = 15 分 |
1:15 |
2 つ目の再試行間隔 = 30 分 |
1:45 |
3 つ目の再試行間隔 = 60 分 |
2:45 |
再試行間隔の値は、ディストリビュータの実行スケジュールには影響しません。これらの値は最小の間隔を表します。各試行間の実際の間隔は、もっと長くなる可能性があります。
サーバーで長時間にわたる障害が発生している場合、ディストリビュータが再試行を行わないまま、複数の再試行間隔を超過することがあります。この場合、サーバーがオンラインに戻ったときに、ディストリビュータは有効期限が切れていないディストリビュータの作業項目に対して直ちに再試行を 1 回行います。次に、再試行間隔のスケジュールが再開され、次の再試行間隔に指定された時間だけ待ってから、再度試行を行います。
再試行スケジュールを指定するには
- XML でアプリケーションを定義している場合は、RetrySchedule 要素 (ADF) で各再試行間隔を定義します。
- プログラムでアプリケーションを定義している場合は、ProtocolRetrySchedule オブジェクトで各再試行間隔を定義し、ProtocolRetrySchedules プロパティ (NMO) を使用して、NotificationClassProtocol オブジェクトの ProtocolRetryScheduleCollection に追加します。
配信エラーのログ記録
ディストリビュータは、通知の配信エラーを記述するためにエントリを Windows アプリケーション ログに書き込みます。ディストリビュータがいつどのように配信エラーのイベントをログに記録するかを各配信プロトコルについて構成します。
| 重要 : |
|---|
| Notification Services が外部配信システムから受信するエラーのフィードバックは限定されています。ほとんどのエラーは、一般的な "配信エラー" としてイベント ログに記録されます。配信エラーに一貫性がある場合は、構成に問題がある可能性があります。配信の構成を確認するには、インスタンス構成の配信チャネルの設定とアプリケーション定義のプロトコル フィールドの値を確認します。 |
1 つ目のプロパティでは、エラーがいくつ発生したらディストリビュータがアプリケーション ログにイベントを記録するかを構成できます。2 つ目のプロパティでは、エラーの数とは関係なく、イベントをログに記録する最小間隔を構成できます。これら 2 つの設定により、ディストリビュータがアプリケーション ログに書き込むイベントの数を制御して、短い時間に複数のエラーが発生した場合にアプリケーション ログがいっぱいになるのを防ぐことができます。
たとえば、エラーの数を 5 に設定し、間隔を 10 分に設定した場合は、5 つのエラーが発生すると、ディストリビュータがログにエラーを記録します。10 分後、再度エラーのカウントが始まります。それから新たに 5 つのエラーが発生すると、ディストリビュータがアプリケーション ログにイベントをまた 1 つ書き込みます。
アプリケーションを開発するときには、既定値としてエラーの数を 1 に、間隔を 0 分にすることをお勧めします。ただし、アプリケーションが実際に運用されている場合は、必要なエラー情報を入手しつつ、ログを必要最小限に抑えることができるように、より高い値を使用することを検討してください。
| メモ : |
|---|
| 配信エラーのトラブルシューティングには、ストアド プロシージャの NSDiagnosticDeliveryChannel (Transact-SQL) と NSDiagnosticFailedNotifications (Transact-SQL) を使用できます。 |
配信エラーがいくつ発生したらログにイベントを記録するかを構成するには
- XML でアプリケーションを定義している場合は、FailuresBeforeLoggingEvent 要素 (ADF) で、配信エラーがいくつ発生したらログにイベントを記録するかを定義します。
- プログラムでアプリケーションを定義している場合は、FailuresBeforeEventLog プロパティ (NMO) を使用して、配信エラーがいくつ発生したらログにイベントを記録するかを定義します。
ログにイベントを記録する間隔を構成するには
- XML でアプリケーションを定義している場合は、FailureEventLogInterval 要素 (ADF) で、ログにイベントを記録する間隔を定義します。
- プログラムでアプリケーションを定義している場合は、FailureEventLogInterval プロパティ (NMO) を使用して、ログにイベントを記録する間隔を定義します。
エラーが連続して発生した場合の配信の中止
一時的なネットワークの状態ではなく、長期のネットワーク障害が原因で配信エラーが発生する場合、ディストリビュータは、ネットワークが飽和状態になることを防ぐため、作業項目で配信の実行を中止できます。
作業項目で配信エラーがいくつ連続して発生したら、ディストリビュータでその作業項目の通知をそれ以上配信しないようにするかを指定できます。この制限に達すると、ディストリビュータはアプリケーション ログにメッセージを書き込み、その作業項目を失敗としてマークします。この場合、作業項目には、一度も試行されなかった通知がある可能性があります。再試行スケジュールがある場合は、次の再試行間隔でこの作業項目が取得されて、失敗した通知と一度も試行されなかった通知の両方が再試行されます。
エラーがいくつ連続して発生したら配信を中止するかを構成するには
- XML を使用してアプリケーションを定義している場合は、FailuresBeforeAbort 要素 (ADF) で、連続するエラーの数を定義します。
- プログラムでアプリケーションを定義している場合は、FailuresBeforeAbort プロパティ (NMO) を使用して、連続するエラーの数を定義します。
マルチキャスト受信者の制限
各配信プロトコルでは、単一のマルチキャストを受信できるサブスクライバの数を制限することもできます。マルチキャストの詳細については、「ダイジェスト配信またはマルチキャスト配信の指定」を参照してください。
マルチキャスト受信者の数を制限した場合、ディストリビュータは、その制限に達すると、マルチキャスト受信者の一覧にサブスクライバを追加するのを中止します。その後、新しい一覧を開始して、制限に達するまでその新しい一覧にサブスクライバを追加します。作業項目内のすべてのマルチキャスト通知がマルチキャスト受信者の一覧に追加されるまで、このプロセスが繰り返されます。
| 重要 : |
|---|
| マルチキャストの設定は、SQL Server 2005 Standard Edition では利用できません。 |
マルチキャスト受信者の制限を構成するには
- XML でアプリケーションを定義している場合は、MulticastRecipientLimit 要素 (ADF) でマルチキャスト受信者の制限を定義します。
- プログラムでアプリケーションを定義している場合は、MulticastRecipientLimit プロパティ (NMO) を使用してマルチキャスト受信者の制限を定義します。
作業項目のタイムアウトの設定
ディストリビュータは、作業項目を取得すると、コンテンツ フォーマッタを呼び出して通知を書式設定し、配信プロトコルを呼び出して通知をパッケージ化して配信します。作業項目が極端に大きかったり、配信が何らかの理由でブロックされたりすると、作業項目がディストリビュータの 1 つのスレッドを占有して、他の通知の処理を遅らせることがあります。
配信プロトコルに対して作業項目のタイムアウトを指定すると、指定した時間の後にディストリビュータが作業項目を解放します。この場合、作業項目は失敗としてマークされ、配信プロトコルに再試行スケジュールがある場合は再度取得されます。
作業項目のタイムアウトを構成するには
- XML でアプリケーションを定義している場合は、WorkItemTimeout 要素 (ADF) で作業項目のタイムアウト値を定義します。
- プログラムでアプリケーションを定義している場合は、WorkItemTimeout プロパティ (NMO) を使用して作業項目のタイムアウト値を定義します。
参照
概念
その他の技術情報
Notification Services ストアド プロシージャ (Transact-SQL)
配信プロトコルの構成
通知クラスの定義
Notification Services アプリケーションの定義