次の方法で共有

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

  • [アーティクル]

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

既定では、Spool、TrackingData、または ApplicationQ テーブルが大きくなると、BizTalk サービスは調整されます。 これらのテーブルは、SQL-Agent ジョブによって排除されます。このジョブが実行されていない場合、Spool が増加し、調整が開始され、データベースが追加の負荷から保護されます。 以下のパフォーマンス カウンターの状態を確認します。

スプール テーブルの拡張

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

アプリケーション キューが小さく、スプールがまだ大きい場合は、消去ジョブが維持されていることを確認します。 SQL エージェント サービスが実行されていることを確かめたうえで、以下のジョブが正常に完了しているかどうかを確認してください。

  • MessageBox_Message_Cleanup_BizTalkMessageBoxDb

  • MessageBox_Parts_Cleanup_BizTalkMessageBoxDb

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

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

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

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

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

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

たとえば、オーケストレーションの処理を担うサーバーが CPU に依存していて処理を高速化できないことが原因で、オーケストレーション アプリケーション キュー (PxHostQ) のサイズが増加する場合があります。 ただし、受信サーバーが高速の場合は、オーケストレーション サーバーが処理できるよりも高速に発行され、アプリケーション キューが増加する可能性があります。

オーケストレーション キューの増加のもう 1 つの理由は、メモリの競合が原因である可能性があります。 実行時間の長いオーケストレーション インスタンスの多くがメモリ内で同時にインスタンス化されると、メモリの肥大化によって間接的に調整が発生し、メモリ不足が解消されるまでスレッド プールが縮小されます。

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

TrackingData テーブルの増加

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

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

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

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

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

Note

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

参照

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