次の方法で共有

追跡の計画

  • [アーティクル]

メッセージ追跡は、メッセージ本文、メッセージ プロパティ、メタデータなどのメッセージ インスタンスの一部をデータベースに格納するプロセスです。通常はアーカイブ目的です。 追跡されるメッセージ インスタンス パーツは、その後、BizTalk Server管理コンソールの [グループ ハブ] ページからクエリを実行することで表示できます。 アーカイブされたデータにアクセスするだけでなく、ライブ データを表示することもできます。これは、開発またはステージング環境の問題を特定して修正するのに役立つツールです。

メッセージ追跡のプロセスはリソースを大量に消費する可能性があるため、計画を作成する前に、このトピックを確認する必要があります。

追跡の詳細については、「 正常性とアクティビティの追跡 (https://go.microsoft.com/fwlink/?LinkId=154187)」を参照してください。

DTA 消去およびアーカイブ SQL エージェント ジョブの構成と有効化

このジョブは、BizTalk Tracking データベースから古いデータをアーカイブして消去するため、サイズが大きくなりすぎないようにします。 これは、正常なBizTalk Serverシステムに不可欠です。 大規模な追跡データベースは、追跡ホストとその追跡データベースに対してクエリを実行するその他のプロセスのパフォーマンスに影響を与え始めます。

  • DTA 消去およびアーカイブ SQL エージェント ジョブが正しく構成され、有効にされ、正常に完了していることを確認します。 アーカイブ ファイルを書き込むことができるディレクトリを含むように構成する必要があるため、このジョブは既定では有効になっていません。

  • ジョブが受信追跡データが生成されるのと同じ速度で追跡データを消去できることを確認します。 負荷のピーク時にジョブが遅れることは許容されますが、常に追いつくことができるはずです。 消去ジョブが遅れて追いつくことができない場合、BizTalk Tracking データベースは増加し続け、最終的にはパフォーマンスに悪影響が及びます。

  • 論理的な消去とハード 消去のパラメーターを確認して、データを十分な長さに保ちながら長すぎないことを確認します。 これらのパラメーターの詳細については、「 BizTalk 追跡データベースのアーカイブと消去 (https://go.microsoft.com/fwlink/?LinkID=153816)」を参照してください。

  • 古いデータを消去するだけで済み、最初にアーカイブする必要がない場合は、ストアド プロシージャ "dtasp_PurgeTrackingDatabase" を呼び出すように SQL エージェント ジョブを変更します。 これにより、アーカイブステップがスキップされ、消去が行われます。 このストアド プロシージャの詳細と、それを使用するように SQL エージェント ジョブを変更する方法については、「 How to Purge Data from the BizTalk Tracking Database ()」 (BizTalk 追跡データベースからデータを消去する方法 )https://go.microsoft.com/fwlink/?LinkID=153817 を参照してください。

  • BizTalk Tracking データベース アーカイブ ファイルを保持する必要がある場合は、それらを正常に復元して使用するためのプロセスがあることを確認してください。

  • 性能上の問題があり、BizTalk 追跡データベースを削除することで一時的に対処している場合、追跡情報を収集しないように BizTalk を構成するには、グローバル追跡を無効にすることを検討してください。 グローバル追跡を無効にする方法については、「グローバル追跡 を無効にする方法 (https://go.microsoft.com/fwlink/?LinkID=154193)」を参照してください。

専用追跡ホストの作成

BizTalk Server管理コンソールでホストに対して [ホストの追跡を許可する] オプションが有効になっている場合、そのホストのインスタンスは追跡データ デコード サービス (TDDS) を実行して、追跡データを BizTalk Server MessageBox データベースから BizTalk Tracking データベースに移動します。 TDDS はリソースを大量に消費する可能性があるため、[ホスト追跡の許可] オプションが有効になっており、他のBizTalk Serverプロセス (アダプターやオーケストレーションなど) を実行しない "専用" 追跡ホストを作成することを検討してください。 BizTalk グループに複数の BizTalk サーバーが含まれている場合は、TDDS の高可用性を提供するために、グループ内の各サーバーにこのホストのインスタンスを作成することもベスト プラクティスと見なされます。

持続可能な追跡の最大スループットを測定するためのテスト

広範なメッセージ追跡はリソースを大量に消費するアクティビティであり、適切に管理されていない場合は、BizTalk Server環境のパフォーマンスに非常に悪影響を及ぼす可能性があります。 したがって、システムが持続可能であり、特定のメッセージ フロー レートで無期限に実行されるように、BizTalk Server環境の最大持続可能な追跡スループットを測定する必要があります。 持続可能な追跡の最大スループットの測定の詳細については、「 最大持続可能な追跡スループットの測定 (https://go.microsoft.com/fwlink/?LinkID=153815)」を参照してください。

追跡のベスト プラクティス

  • 計画中に追跡する必要がある情報を決定 する: プロジェクトをデプロイした後に追跡オプションを設定し、必要な情報のみを提供するように追跡データの量を制限できるように、計画段階で追跡する必要がある情報を決定する必要があります。

  • すべてのメッセージを追跡しない: メッセージに触れるたびに、BizTalk Serverは別のコピーを作成するため、すべてのメッセージを追跡しないことをお勧めします。 代わりに、特定のポートのみを追跡してスコープを絞り込むことができます。 これにより、システムのパフォーマンスを最大化し、データベースを整理した状態に保つことができます。

  • パイプラインではなく送信ポートと受信ポートの追跡を設定する: パイプラインで追跡オプションを設定する場合は、パイプラインを使用するすべてのポートに対して追跡オプションをグローバルに設定します。 これにより、意図したデータよりもはるかに多くのデータが追跡され、システムのパフォーマンスが低下する可能性があります。 代わりに、送信ポートと受信ポートで追跡オプションを設定できます。

  • BizTalk Tracking データベースのサイズを変更する場合は、さまざまな要因を考慮してください。

    • BizTalk Tracking データベースのサイズを変更する場合は、計算にコンティンジェンシー乗数を追加して、インデックス サイズなどのSQL Server要因を考慮します。

    • BizTalk Tracking データベース内のメッセージのサイズを決定する場合は、メッセージ のサイズと比較してメッセージ のサイズが大きい場合は、メッセージ コンテキストの平均サイズをメッセージ サイズに追加します。

    • BizTalk Tracking データベース内のメッセージのサイズを制限するには、昇格するプロパティの数を制限します。 昇格されたプロパティは、ルーティングのために必要な場合にのみ使用する必要があります。それ以外の場合は、識別フィールドを使用してください。

    • オーケストレーションの [図形の開始と終了 ] オプションが有効になっている場合は、各オーケストレーション インスタンスの各図形の start イベントと stop イベントが BizTalk Tracking データベースに保存されることを考慮してください。