次の方法で共有

メッセージ ボックス データベースのボトルネックの特定

  • [アーティクル]

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

既定では、Spool、TrackingData、または ApplicationQ テーブルのサイズが増加すると、BizTalk サービスによって制限されるようになっています。 これらのテーブルの切り捨てを行う SQL エージェント ジョブが実行されていない場合は、Spool テーブルのサイズが増加し、データベースにさらに負荷がかかるのを防ぐために制限が作動することになります。 以下のパフォーマンス カウンターの状態を確認します。

  • BizTalk:Message Agent (Host Name) Message Delivery Throttling State

  • BizTalk:Message Agent (Host Name) Message Publishing Throttling State

    値 0 は、制限が発生していないことを示します。 値 6 は、データベース サイズの増加に起因する制限が発生していることを示します。 これらのカウンターの値を解釈する方法については、ドキュメントを参照してください。

Spool テーブルのサイズの増加

Spool のサイズが増加し始める原因は複数あります。 その 1 つとして、アプリケーション キューのサイズの増加があります。 この増加には、下流のボトルネックやリソースの競合などさまざまな原因が考えられます。

アプリケーション キューのサイズが小さいにもかかわらず Spool のサイズが大きい場合は、Purge ジョブの処理が追いついているかどうかを確認します。 SQL エージェント サービスが実行されていることを確かめたうえで、以下のジョブが正常に完了しているかどうかを確認してください。

  • MessageBox_Message_Cleanup_BizTalkMessageBoxDb

  • MessageBox_Parts_Cleanup_BizTalkMessageBoxDb

    MessageZeroSum テーブルのサイズが大きい場合は、メッセージの処理 (DeQueue の正常完了とアプリケーション キュー テーブルからのデータの削除) が完了し、該当する行に削除フラグが設定されているものの、 Purge ジョブによるデータの削除が追いついていないことを示します。 その原因の 1 つとして、SQL Server コンピューターで深刻な CPU の競合が発生しており、CPU 不足のため Purge ジョブが適正な処理能力を維持できなくなっていることが考えられます。

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

アプリケーション キューがホストするインフライト移行データは、処理が完了すると DeQueue によってクリーンアップされます。

これらのメッセージの処理が終わると、(該当する行への参照を保持している) Spool のクリーンアップが可能になります。

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

アプリケーション キューのサイズの増加は、アプリケーション キューの排出を担うホスト インスタンスの処理速度が、受信速度 (メッセージが特定のアプリケーション キューに公開される速度) を下回っていることを示します。

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

オーケストレーション キューのサイズが増加するもう 1 つの原因として、メモリの競合が考えられます。これは、長時間実行される多数のオーケストレーション インスタンスがメモリ内ですべて同時にインスタンス化されることを意味します。その結果、メモリ使用量が膨れ上がり、それが間接的な原因となって制限が作動し、メモリ不足が解消されるまでスレッド プールが縮小されます。 送信側のアプリケーション キューのサイズが増加する 1 つの原因としては、(BizTalk から送信される) メッセージを受け取る下流システムの受信速度が十分でないことが挙げられます。 その結果、メッセージが BizTalk システム内に残存してアプリケーション キューのサイズが増加することになり、最終的には制限が作動して受信速度が低減され、システム全体のスループットに影響が及びます。

TrackingData テーブルのサイズの増加

メッセージ ボックス データベースの TrackingData テーブルは移行テーブルであり、インターセプターによってメッセージおよびサービス インスタンス追跡と BAM 追跡の両方の追跡データが書き込まれます。 追跡が無効になっている場合、このテーブルは空になります。 既定では、パイプラインおよびオーケストレーション送受信イベントのメッセージおよびサービス インスタンスの追跡が有効になっています。

メッセージ本文の追跡が有効になっている場合は、メッセージ ボックス サーバー (ホストの追跡を許可する設定になっているホスト) が実行されていることを確認します。 これによってメッセージ ボックス データベースの TrackingData テーブルから BizTalkDTADb テーブルにデータが移動されるため、ボトルネックが軽減されます。

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

TDDS の処理速度が、インターセプターによって TrackingData テーブルにデータが書き込まれる速度を下回っていると、このテーブルのサイズが増加して制限が作動し、最終的には維持可能なスループットにも影響が及びます。 この問題を軽減するには、追跡が有効になった状態で実行されているホストを少なくとも 1 つ存在させるようにします。

それでもデータがたまる場合は、BizTalkDTADb データベースを検証して、データベース サイズの増加が制御不能な性質のものではないことを確認します。 アーカイブおよび削除のジョブが実行されており、その処理速度がデータの到着速度を下回っていないことを確認してください。

Note

BizTalkDTADb テーブルのデータは、アーカイブ化が完了しない限り Purge ジョブで削除できません。

TrackingData テーブルのサイズが増加していないかどうかを確認します。 追跡が有効になった状態で実行されているホスト インスタンス (TDDS) が少なくとも 1 つ存在することを確認してください。 BizTalkDTADb データベースのサイズが大きくなりすぎると、メッセージ ボックス データベースから BizTalkDTADb データベースにデータを移動する TDDS の機能に悪影響が及ぶ可能性があります。

TrackingData テーブルのサイズの増加は、場合によっては制限の作動につながり、維持可能な実行時のスループットに影響を及ぼします。