完璧な世界では、メッセージ ボックス データベースに発行されるとすぐにすべてのメッセージが処理され、配信され、メッセージ ボックス データベースが過剰なサイズに拡大することはありません。 メッセージ ボックス内で参照されなくなったメッセージは、メッセージ ボックス データベース テーブルを定期的にクリーンアップする SQL エージェント ジョブによって直ちに削除されます。
ただし、実際のシナリオでは、通常、メッセージは予測可能な線形形式で受信されず、SQL エージェント ジョブで MessageBox データベース テーブルをクリーンアップするのに時間が必要です。
したがって、一部のシナリオでは次のようになります。MessageBox は非常に迅速に大きくなる可能性があります。
次の項目により、MessageBox が過度に大きくなり、全体的なパフォーマンスが低下する可能性があります。
[ホストの追跡を許可する] オプションが設定されている Biztalk ホスト インスタンスが停止しています。 これは、メッセージ ボックス データベースから Biztalk Tracking データベース (BizTalkDTADb) への追跡データの移動を担当するホストです。
SQL Server エージェントが実行されていません これは、メッセージ ボックス データベースから BizTalkDTADb データベースにデータを移動する SQL ジョブが実行されていない場合に発生する可能性があります [その後、移動されたデータをメッセージ ボックスに消去する] が実行されていません。 この問題を回避するには、SQL エージェント サービスが常に実行されていることが不可欠です。
SQL Server ジョブが無効になっている SQL Server エージェントが実行されている場合でも、既定の SQL Server ジョブを無効にすることが不可欠です。
BizTalkDTADb データベースが過度に大きくなる これは、BizTalkDTADb データベースが非常に大きくなり、BizTalkDTADb データベースへの挿入に時間がかかる場合に発生する可能性があります。 この場合、追跡データ配信サービス (TDDS) によるデータの移動が遅くなり、MessageBox データベースにバックログが作成されます。 この問題を回避するには、BizTalkDTADb データベースで SQL Server アーカイブを実行し、ジョブを定期的に消去することが重要です。
過剰なディスク I/O 待機時間 メッセージ ボックス データベースへのデータの受信速度が、システムが BizTalkDTADb データベースにデータを処理して移動できる速度よりも速い場合、バックログは MessageBox データベースに構築できます。 バックログが継続的に拡大し続ける場合、これは非常に深刻な問題であり、システムのパフォーマンスは時間の経過とともに低下します。 この問題を軽減する 1 つの方法は、より高速なディスクをインストールするか、ハードウェアをアップグレードして、システムが時間の経過と同時に発生したメッセージ バックログから回復できるようにすることです。
将来の計画
上記のすべてのベスト プラクティスに従っても、時間の経過と同時に、BizTalkDTADb データベースに移動される追跡データの量は非常に大きくなります。 システムが引き続き最適なパフォーマンスを維持できるように、追跡データを定期的にアーカイブするデータベース メンテナンス プランを実装することが重要です。
BizTalkDTADb データベースに保持できる履歴データの量は、システム経由でプッシュされるメッセージの量によって異なります。 負荷が高くスループットが高くないシステムの場合、このデータベースは低速な速度で増加し、BizTalkDTADb データベースでより多くの履歴データを保持できます。
実行時のパフォーマンスを犠牲にしないように、BizTalkDTADb データベースに最小限のデータを保持することをお勧めします。