次の方法で共有

メッセージ ボックス データベースのボトルネックを特定する方法

MessageBox データベースのボトルネックを特定するには、まず、SQL-Server-Agent サービスが開始されていることを確認します。 サービスの起動状態を手動から自動に変更して、サーバーが再起動されるとサービスが自動的に再起動されるようにします。

既定では、Spool、TrackingData、または ApplicationQ テーブルが拡大すると、BizTalk サービスが調整されます。 これらのテーブルは SQL-Agent ジョブによって整理されます。このジョブが実行されていない場合は、スプールが拡大し、制限が始まり、データベースを追加のプレッシャーから守ります。 次のパフォーマンス カウンターの状態を確認します。

スプールテーブルの成長

スプールは、複数の理由で成長を開始できます。 スプールの増加の理由の 1 つは、アプリケーション キューが増加している場合です。 ダウンストリームのボトルネックやリソースの競合などの理由で増加する可能性があります。

アプリケーション キューが小さく、スプールがまだ大きい場合は、消去ジョブが追いついていることを確認します。 SQL-Agent サービスが実行されていることを確認し、次のジョブが正常に完了していることを確認します。

  • MessageBox_Message_Cleanup_BizTalkMessageBoxDb

  • MessageBox_Parts_Cleanup_BizTalkMessageBoxDb

    MessageZeroSum テーブルが大きい場合は、メッセージが処理されたことを示します。 つまり、DeQueue が正常に完了し、アプリケーション キュー テーブルからデータが削除され、行に削除のフラグが設定されています。 しかしながら、消去ジョブはデータ削除のプロセスに追いついていません。 これは、SQL Server を実行しているコンピューターで重大な CPU 競合が発生し、CPU 不足が原因で消去ジョブが維持される機能に影響を与える場合に発生する可能性があります。

アプリケーション キュー テーブルの増加

アプリケーション キューは、処理されると DeQueue によってクリーンアップされる、実行中の遷移データをホストします。

これらのメッセージが処理されると、スプール テーブル (これらの行への参照を保持) をクリーンアップできます。

たとえば、RxHostQ はオーケストレーション PxHostQ にデータを発行します。 このキューは、Spool テーブル内の行を参照する送信先の TxHostQ にデータを公開します。 特定の HostQ のメッセージがシステムを介して正常に処理されると、これらの行は DeQueue によって削除されます。 これらの行が削除されると、スプール (これらの行によって参照されなくなったもの) を消去ジョブでクリーンアップできるようになります。

アプリケーション キューの増加は、アプリケーション キューのドレインを担当するホスト インスタンスが受信レートに対応できないことを示します。

たとえば、オーケストレーション アプリケーション キュー (PxHostQ) は、オーケストレーションの処理を担当するサーバーが CPU にバインドされており、それ以上高速に処理できないために拡張される可能性があります。 ただし、受信側サーバーの速度が速い場合は、オーケストレーション サーバーが処理できるよりも高速に発行され、アプリケーション キューが増加する可能性があります。

オーケストレーション キューの増加のもう 1 つの理由は、メモリの競合が原因である可能性があります。 複数の長時間実行されるオーケストレーション インスタンスがメモリ内で同時にインスタンス化されると、メモリの過剰消費によってスロットリングが発生し、メモリ圧が解消されるまでスレッド プールの縮小を引き起こします。

アプリケーションの送信キューが大きくなる理由は、ダウンストリーム システムが (BizTalk Server からの送信) メッセージを十分に高速に受信できない場合です。 したがって、メッセージは引き続き BizTalk システム内に存在し、アプリケーション キューの増加を引き起こします。 これにより、調整が開始され、システムの全体的なスループットに影響を与える受信速度が低下する可能性があります。

TrackingData テーブルの増加

MessageBox データベースの TrackingData テーブルは、インターセプターが正常性とアクティビティ (HAT) とビジネス アクティビティ監視 (BAM) 追跡の両方の追跡データを書き込む移行テーブルです。 追跡が無効になっている場合、このテーブルは空である必要があります。 既定では、パイプラインとオーケストレーションの In/Out イベントに対して HAT 追跡が有効になっています。

メッセージ本文の追跡が有効になっている場合は、メッセージ ボックス データベース サーバー (つまり、"ホスト追跡を許可する" ホスト) が実行されていることを確認します。 "ホスト追跡を許可する" を持つホストが実行されていることを確認すると、ホストがメッセージ ボックス データベースの TrackingData テーブルから BizTalk Tracking データベース テーブルにデータを移動する場合にボトルネックが発生する可能性が低くなります。

昇格されたプロパティやメッセージ本文の追跡など、カスタム HAT 追跡を有効にすることで、カスタム イベントを追跡できます。 HAT 追跡データに加えて、BAM データも TrackingData テーブルに書き込まれます。 追跡データ デコード サービス (追跡が有効になっているホスト インスタンスで実行される TDDS) は、このデータをメッセージ ボックス データベースから BizTalk 追跡および BAM プライマリ インポート データベースに移動する役割を担います。 その後、データが正常に移動されると、TDDS はこのデータを削除します。 メッセージ本文追跡データは、SQL-Agent ジョブ TrackedMessages_Copy_BizTalkMsgBoxDbによって個別に移動されます。

TDDS がインターセプターが TrackingData テーブルにデータを書き込む速度に対応できない場合、このテーブルは増加し、調整が開始されます。 これは、持続可能なスループットに影響します。 この問題を軽減するには、追跡を有効にして少なくとも 1 つのホストが実行されていることを確認します。

データが引き続き構築される場合は、BizTalk 追跡データベースが制御できない状態にならないようにします。 また、アーカイブジョブと消去ジョブが実行されており、データが到着する速度に対応できることを確認します。

注

既定では、このデータがアーカイブされるまで、消去ジョブは BizTalk 追跡データベース テーブルからデータを削除できません。 追跡データをアーカイブする必要がない場合は、「BizTalk 追跡データベースからデータを消去する方法 (https://go.microsoft.com/fwlink/?LinkID=153817)」の手順に従って、アーカイブせずに BizTalk 追跡データベースを消去するようにジョブを変更できます。

こちらもご覧ください

データベース層のボトルネック