3


0

SQL Server Service Brokerのメッセージキューにメッセージを書き込むストアドプロシージャがあります。 問題が発生してメッセージがメッセージキューに格納されない場合は、ストアドプロシージャからエラーメッセージを返す必要があります。 私が見ている問題は、SQL Server Service Brokerが無効になっていても(キューにメッセージを書き込むことができないことをテストしようとしている方法です)キュー上のメッセージ

SQL Server Brokerメッセージキューへのメッセージの書き込みに失敗したかどうかを検出する方法を知っている人はいますか

1 Answer


20


Service Brokerはメッセージをターゲットキューに入れません。 代わりにデータベース送信キュー( sys.transmission_queue)に入れられます。 SENDがコミットされた後、メッセージはバックグラウンドトランスミッタによってピックアップされ、ルーティングは解決され、メッセージはその宛先に配信されます。

宛先が同じインスタンス内にある場合は、SENDステートメント自体の実行中にショートカット配信パスが試行されます。この場合、メッセージは宛先キューに直接配置されます。 エンキューが失敗すると、メッセージは返送されて通常の配信パスに配置されます。 sys.trasnmission_queuに入れてください。 sys.transmission_queue`に詰まっているメッセージは、そのメッセージが配送できなかった理由を説明する transmission_status`を持ちます。 システムは自動的にこれらのメッセージを再試行します。

SENDがエラーを返すことができるのは、メッセージが_sent_になることができないときだけです。 これは、閉じた会話で SEND`を実行しようとした場合や、メッセージを sys.transmission_queue`に受け入れられないようにするブローカ以外のエラー(データベースの読み取り専用、ログフル、メモリ不足など)がある場合です。

ローカル配信が非同期で疎結合である場合でも、このようなマッキングの動作は意図的であり、宛先キューがローカルの場合と宛先キューがリモートの場合は同じ動作をすることでアプリケーションを支援するように設計されています。

Service Brokerでエラーを処理する方法は、応答について自分のキューを確認することです。 目的地サービスがあなたのメッセージを積極的に拒絶するならば(すなわち。 アクセスが拒否された、またはXML形式が不正であった、またはサービス契約違反が発生した場合、エラーで会話が終了し、エラーメッセージが自分のキューに返されます。 メッセージを単純に配信できない場合は、メッセージが期限切れになるまで送信キューに留まり、その後会話はエラーで終了し、再びエラーメッセージが自分のキューに入れられます。 `BEGIN CONVERSATION`で指定された有効期限が切れるとメッセージはタイムアウトします。

そのため、ブローカーを無効にしても、メッセージは受け入れられますが配信されません。 それは変換キューに入れられます。 データベースでブローカーを有効にするとすぐに、そのメッセージがピックアップされて配信されます。 この振る舞いは、配信の信頼性が主な関心事である場合には、アプリケーション作成をはるかに簡単にします。 目的地が利用できないとしても、アプリは単にメッセージ_will_がそこに到着することを知っているだけで送信します。 メッセージの配信に数時間、数日、または数週間かかる場合でも、サービスのメンテナンスのために停止されます。 配信のタイミングにも関係するアプリケーションの場合は、会話の有効期間を指定する必要があります。 システムはこの有効期間内にメッセージを配信しようとするか、あきらめます。 あきらめた場合は、エラーメッセージ(会話タイムアウトエラー)をエンキューすることによって送信者に通知します。

またアプリケーションは応答を待つべきではありません。 彼らは SEND、` COMMIT`そして続けるべきであり、_イベントドリブン_です。 ターゲットが応答を送り返したとき、または基盤となるインフラストラクチャがエラーを通知したとき、アプリケーションは自身のキューにメッセージを取得し、そのメッセージに_反応するはずです。