MessageBox データベースのボトルネックを特定するには、まず、SQL-Server-Agent サービスが開始されていることを確認します。 サーバーが再起動された場合でもサービスが自動的に再起動されるように、サービスのスタートアップ状態を手動から自動に変更します。
既定では、Spool、TrackingData、または ApplicationQ テーブルが成長すると、BizTalk サービスがスロットル制御されます。 これらのテーブルは SQL-Agent ジョブによって剪定されますが、このジョブが実行されていない場合は、Spool が増加します。そして、その結果、データベースにさらなる負荷がかかるのを防ぐために調整が作動します。 次のパフォーマンス カウンターの状態を確認します。
BizTalk: メッセージエージェント (ホスト名) メッセージ配信調整の状態
BizTalk:メッセージエージェント (ホスト名) メッセージ発行調整状態
値 0 は、調整が行われないことを示します。 値が6のとき、データベースの増加によりシステムが制限されていることを示します。 これらのカウンターの他の値を解釈する方法については、ドキュメントを参照してください。
スプール テーブルの成長
スプールは、複数の理由で成長を開始できます。 Spool が増加する理由の 1 つは、アプリケーション キューが増加している場合です。 ダウンストリームのボトルネックやリソースの競合など、さまざまな理由で増加する可能性があります。
アプリケーション キューが小さく、スプールがまだ大きい場合は、消去ジョブが維持されていることを確認します。 SQL-Agent サービスが実行されていることを確認し、次のジョブが正常に完了していることを確認します。
MessageBox_Message_Cleanup_BizTalkMessageBoxDb
MessageBox_Parts_Cleanup_BizTalkMessageBoxDb
MessageZeroSum テーブルが大きい場合は、メッセージが処理され (DeQueue が正常に完了し、アプリケーション キュー テーブルからデータが削除されました)、行に削除のフラグが設定されていることを示します。 しかしながら、消去ジョブはデータ削除のプロセスに追いついていません。 その理由の 1 つは、SQL-Server マシンで重大な CPU 競合が発生し、CPU 不足が原因で消去ジョブが維持される機能に影響を与える場合です。
アプリケーション キュー テーブルの増加
アプリケーションキューは、処理中の遷移データをホストし、それが処理されると DeQueue によってクリーンアップされます。
これらのメッセージが処理された後、スプール (これらの行への参照を保持) をクリーンアップできます。
たとえば、RxHostQ はオーケストレーション PxHostQ にデータを発行し、それがさらに TxHostQ にデータを発行して、スプールテーブルの行を参照します。 特定の HostQ のメッセージがシステムを介して正常に処理されると、これらの行は DeQueue によって削除されます。 これらの行が削除されると、スプール (これらの行によって参照されなくなったもの) を消去ジョブでクリーンアップできるようになります。
アプリケーション キューの増加は、アプリケーション キューのドレインを担当するホスト インスタンスが、受信レート、つまりメッセージが特定のアプリケーション キューに発行される速度に追いつくことができないことを示します。
たとえば、オーケストレーション アプリケーション キュー (PxHostQ) は、オーケストレーションの処理を担当するサーバーが CPU にバインドされており、それ以上高速に処理できないために拡張される可能性があります。 ただし、受信側サーバーの速度が速い場合は、オーケストレーション サーバーが処理できるよりも高速に発行され、アプリケーション キューが増加する可能性があります。
オーケストレーション キューが増加するもう 1 つの理由として、多数の長時間実行されるオーケストレーション インスタンスがすべて同時にメモリにインスタンス化されることによる、メモリ競合があります。これによりメモリが膨張し、間接的にスロットルがスレッドプールを縮小させ、メモリ圧が緩和されるまで続く可能性があります。 アプリケーションの送信キューが大きくなる理由の 1 つは、ダウンストリーム システムが (BizTalk からの送信) メッセージを十分に高速に受信できない場合です。 したがって、メッセージは BizTalk システム内に留まり続けるため、アプリケーションキューが増大します。この結果、スロットリングが作動して受信速度が低下し、システム全体のスループットに影響を与えることになります。
TrackingData テーブルの成長
MessageBox データベースの TrackingData テーブルは、インターセプターがメッセージとサービス インスタンスの追跡と BAM 追跡の両方の追跡データを書き込む遷移テーブルです。 追跡が無効になっている場合、このテーブルは空である必要があります。 既定では、パイプラインとオーケストレーションの In/Out イベントに対してメッセージとサービス インスタンスの追跡が有効になっています。
メッセージ本文の追跡が有効になっている場合は、メッセージ ボックス サーバー (つまり、"ホスト追跡を許可" を持つホスト) が実行されていることを確認します。 メッセージ ボックス データベースの TrackingData テーブルから BizTalkDTADb テーブルにデータを移動すると、ボトルネックが軽減されます。
昇格されたプロパティやメッセージ本文の追跡など、カスタム メッセージとサービス インスタンスの追跡を有効にすることで、カスタム イベントを追跡できます。 追跡データに加えて、BAM データもこのテーブルに書き込まれます。 TDDS (追跡が有効になっているホスト) は、このデータをメッセージ ボックス データベースから BizTalkDTADb および BAMPrimaryImport データベースに移動し、正常に移動したら、このデータを削除する必要があります。 メッセージ本文追跡データは、SQL-Agent ジョブ TrackedMessages_Copy_BizTalkMsgBoxDbによって個別に移動されます。
TDDS がインターセプターが TrackingData テーブルにデータを書き込む速度に対応できない場合、このテーブルは増加し、スロットルが開始され、最終的に持続可能なスループットに影響します。 この問題を軽減するには、少なくとも 1 つのホストが追跡を有効にして実行されていることを確認します。
データが引き続き構築される場合は、BizTalkDTADb データベースを確認して、データベースが制御できない状態に拡大されていないことを確認します。 アーカイブおよび消去ジョブが実行中であり、データが到着する速度に対応できることを確認します。
注
このデータがアーカイブされるまで、消去ジョブは BizTalkDTADb テーブルからデータを削除できません。
TrackingData テーブルが拡大されていないことを確認します。 実行中の少なくとも 1 つのホスト インスタンスで追跡が有効になっていることを確認します (TDDS)。 BizTalkDTADb データベースが大きすぎると、TDDS がメッセージ ボックス データベースから BizTalkDTADb データベースにデータを移動する機能に悪影響を及ぼす可能性があります。
TrackingData テーブルの増加により調整が開始され、持続可能なランタイム スループットに影響を与える可能性があります。