BizTalk Server データベースの保守とトラブルシューティング

[アーティクル]
05/11/2023

この記事では、BizTalk Server データベースの保守およびトラブルシューティングを行う方法について詳しく説明します。

元の製品バージョン: BizTalk Server データベース
元の KB 番号: 952555

まとめ

BizTalk Server メッセージング環境を成功させるには、Microsoft BizTalk Server データベースの正常性が重要です。この記事では、BizTalk Server データベースを操作する際に考慮すべき重要な事項について説明します。このような考慮事項には次のようなものがあります。

auto update statisticsとauto create statistics SQL Server のオプションを無効にする必要があります。
max degree of parallelism (MAXDOP) オプションを正しく設定する必要があります。
BizTalk Server インデックスを再構築できるタイミングを決定します。
ロック、デッドロック、またはブロックが発生する可能性があります。
大規模なデータベースまたはテーブルで問題が発生する可能性があります。
BizTalk SQL Server エージェントジョブ。
サービスインスタンスが中断される可能性があります。
SQL Server と BizTalk Server のパフォーマンスの問題が発生する可能性があります。
BizTalk Server のベストプラクティスに従う必要があります。

はじめに

この記事では、BizTalk Server データベースを維持する方法と、BizTalk Server データベースの問題をトラブルシューティングする方法について説明します。

統計の自動作成と統計の自動更新オプションを無効にする必要があります

BizTalkMsgBoxDb データベースでは、auto create statisticsオプションとauto update statisticsオプションを無効のままにしておく必要があります。これらの設定が無効になっているかどうかを確認するには、SQL Server で次のストアドプロシージャを実行します。

EXEC sp_dboption 'BizTalkMsgBoxDB', 'auto create statistics'
EXEC sp_dboption 'BizTalkMsgBoxDB', 'auto update statistics'

現在の設定を offに設定する必要があります。この設定が on に設定されている場合は、SQL Server で次のストアドプロシージャを実行して無効にします。

EXEC sp_dboption 'BizTalkMsgBoxDB', 'auto create statistics', 'off'
EXEC sp_dboption 'BizTalkMsgBoxDB', 'auto update statistics', 'off'

Max Degree of Parallelism プロパティを正しく設定する必要があります

SQL Server を実行し、 BizTalkMsgBoxDb データベースをホストしているコンピューターで、並列処理の最大 run_value 度と config_value プロパティを 1 の値に設定します。以降の SQL バージョンでは、SQL インスタンスごとではなく、データベースごとにこの設定を指定することもできます。詳細については、「 SET MAXDOP」を参照してください。 max degree of parallelism設定を確認するには、SQL Server の Master データベースに対して次のストアドプロシージャを実行します。

EXEC sp_configure 'show advanced options', 1;
GO
EXEC sp_configure 'max degree of parallelism'

run_valueプロパティとconfig_value プロパティの値が 1 に設定されていない場合は、SQL Server で次のストアドプロシージャを実行して、1 に設定します。

EXEC sp_configure 'show advanced options', 1;
GO
RECONFIGURE WITH OVERRIDE;
GO
EXEC sp_configure 'max degree of parallelism', 1;
GO
RECONFIGURE WITH OVERRIDE;
GO

BizTalk Server インデックスを再構築できるタイミングを決定する

ほとんどの BizTalk Server インデックスはクラスター化されています (インデックス ID: 1)。 DBCC SHOWCONTIG SQL Server ステートメントを使用して、BizTalk Server テーブルの断片化情報を表示できます。

BizTalk Server インデックスは GUID ベースです。そのため、断片化は通常発生します。 DBCC SHOWCONTIG ステートメントによって返されるスキャン密度の値が 30% 未満の場合、ダウンタイム中に BizTalk Server インデックスを再構築できます。

多くの BizTalk Server テーブルには、 DataType 定義を使用する列が含まれています。オンラインインデックス作成は、これらの列では実行できません。そのため、BizTalk Server がデータを処理している間は、BizTalk Server インデックスを再構築しないでください。

ロック、デッドロック、またはブロックが発生する可能性がある

通常、ロックとブロックは BizTalk Server 環境で発生します。ただし、これらのロックまたはブロックは長時間保持されません。したがって、ブロックとデッドロックは潜在的な問題を示します。

大規模なデータベースまたはテーブルで問題が発生する可能性があります

BizTalkMsgBoxDb データベースが大きくなると、パフォーマンスの問題が発生する可能性があります。理想的には、 BizTalkMsgBoxDb データベースがデータを保持しないようにする必要があります。データが処理されるか、BizTalkDTADbまたは BAM データベースに移動されるまで、BizTalkMsgBoxDb データベースはバッファーと見なす必要があります。

バックエンドで強力な SQL Server を使用し、実行時間の長いオーケストレーションが多数ある環境には、5 GB を超える BizTalkMsgBoxDb データベースが存在する場合があります。実行時間の長いオーケストレーションを使用しない大量の環境には、5 GB よりもはるかに小さい BizTalkMsgBoxDb データベースが必要です。

BizTalkDTADb データベースのサイズが設定されていません。ただし、パフォーマンスが低下した場合、データベースが大きすぎる可能性があります。 20 GB が大きすぎると見なされるお客様もいますが、200 GB の場合は、複数の CPU、大量のメモリ、高速なネットワークとストレージで実行されている非常に強力な SQL サーバーで問題なく動作する場合があります。大規模な BizTalk Server データベースがある場合は、次の問題が発生する可能性があります。

BizTalkMsgBoxDb データベースは増え続けています。ただし、ログファイルとデータサイズの両方が大きいままです。
BizTalk Server では、単純なメッセージフローシナリオでも処理に通常よりも長い時間がかかります。
BizTalk 管理コンソールまたは正常性およびアクティビティ追跡 (HAT) クエリは通常よりも長い時間がかかり、タイムアウトになる場合があります。
データベースログファイルが切り捨てられることはありません。
BizTalk SQL Server エージェントジョブの実行速度が通常よりも遅くなります。
一部のテーブルは、通常のテーブルサイズと比較して大きいか、行が多すぎます。

データベースはさまざまな理由で大きくなる可能性があります。これらの理由には、次のようなものがあります。

BizTalk SQL Server エージェントジョブが実行されていない
多数の中断されたインスタンス
ディスクの障害
追跡
調整
SQL Server のパフォーマンス
ネットワーク待機時間

データの問題が発生しているかどうかを判断するために、環境内で想定される内容がわかっていることを確認します。

既定では、既定のホストで追跡が有効になっています。 BizTalk では、1 つのホストで [ホストの追跡を許可する] オプションをオンにする必要があります。追跡が有効になっている場合、追跡データデコードサービス (TDDS) は、追跡イベントデータを BizTalkMsgBoxDb データベースから BizTalkDTADb データベースに移動します。追跡ホストが停止した場合、TDDS はデータを BizTalkDTADb データベースに移動せず、BizTalkMsgBoxDb データベース内のTrackingData_x_x テーブルが拡大します。

1 つのホストを追跡専用にすることをお勧めします。 TDDS が大量のシナリオで新しい追跡イベントを維持できるようにするには、1 つの追跡ホストの複数のインスタンスを作成します。複数の追跡ホストを存在させる必要はありません。

テーブル内に行が多すぎる可能性があります。設定された行数が多すぎます。さらに、この行数は、テーブルに格納されるデータの種類によって異なります。たとえば、100 万行を超える dta_DebugTrace テーブルの行が多すぎる可能性があります。 200,000 行を超える <HostName>Q_Suspended テーブルの行が多すぎる可能性があります。

適切な BizTalk SQL Server エージェントジョブを使用する

BizTalk SQL Server エージェントジョブは、BizTalk Server データベースを管理し、高パフォーマンスを維持するために重要です。

バックアップ BizTalk Server SQL Server エージェントジョブは、SQL Server エージェントおよび BizTalkServer ホストインスタンスの起動時に BizTalk Server データベースをバックアップする唯一のサポートされている方法です。このジョブでは、すべての BizTalk Server データベースで完全復旧モデルを使用する必要があります。このジョブは、正常な BizTalk Server 環境用に構成する必要があります。 SQL Server メソッドを使用すると、SQL Server エージェントが停止し、すべての BizTalk Server ホストインスタンスが停止した場合にのみ、BizTalk Server データベースをバックアップできます。

MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb SQL Server エージェントジョブは無限に実行されます。そのため、SQL Server エージェントジョブ履歴には正常な完了は表示されません。エラーが発生した場合、ジョブは 1 分以内に再起動され、無限に実行され続けます。そのため、エラーを無視しても問題ありません。さらに、ジョブ履歴をクリアできます。このジョブが常に失敗して再起動することがジョブ履歴から報告される場合にのみ、心配する必要があります。

MessageBox_Message_Cleanup_BizTalkMsgBoxDb SQL Server エージェントジョブは、MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb SQL Server エージェントジョブによって開始されるため、有効にしてはならない唯一の BizTalk Server ジョブです。

DTA 消去およびアーカイブ SQL Server エージェントジョブは、追跡対象のメッセージを消去およびアーカイブすることによって、BizTalkDTADb データベースを維持するのに役立ちます。このジョブは、テーブル内のすべての行を読み取り、タイムスタンプを比較して、レコードを削除する必要があるかどうかを判断します。

MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb SQL Server エージェントジョブを除くすべての BizTalk SQL Server エージェントジョブが正常に実行されている必要があります。

サービスインスタンスが中断される可能性がある

サービスインスタンスは中断 (再開可能) または中断 (再開不可) できます。これらのサービスインスタンスには、メッセージング、オーケストレーション、またはポートがあります。

これらのサービスインスタンスにより、 BizTalkMsgBoxDb データベースが不必要に増大し、終了する可能性があります。グループハブを使用して、メッセージの照会、再開、または終了を行うことができます。また、Terminate.vbs スクリプトまたは BizTalk ヘルスモニター (BHM) ツールを使用して、BizTalk データベースのクエリ、消去、保守を行うこともできます。状況によっては、孤立したメッセージやゾンビメッセージがシステムに残ることがあります。 BHM ツールは、このような状況を修正するのに役立ちます。

Terminate.vbs スクリプトの詳細については、「中断されたサービスインスタンスの移動」を参照してください。

キャッシュインスタンスは Group Hub ページには表示されません。また、インスタンスを一時停止または終了することはできません。この制限は、テーブルの増加の一般的な原因です。 BizTalk Server 2006 のキャッシュサービスインスタンスの新しいゾンビメッセージを防ぐには、マイクロソフトサポート技術情報の記事936536に修正プログラムをインストールします。この問題は、BizTalk Server 2006 R2 以降のバージョンで修正されています。

Note

ゾンビメッセージは、ルーティングされたが使用されなかったメッセージです。

ゾンビメッセージの説明については、次の MSDN Web サイトを参照してください: BizTalk Core Engine の WebLog

SQL Server と BizTalk Server のパフォーマンスの問題が発生する可能性があります

BizTalk Server は、1 分以内に SQL Server に対して数百の短い迅速なトランザクションを行います。 SQL Server がこのアクティビティを維持できない場合、BizTalk Server でパフォーマンスの問題が発生する可能性があります。パフォーマンスモニターで、PhysicalDisk パフォーマンスオブジェクトの Avg.Disk sec/Read、Avg.Disk sec/Transfer、および Avg. Disk sec/Write パフォーマンスモニターカウンターを監視します。最適な値は 10 ミリ秒 (ミリ秒) 未満です。 20 ミリ秒以上の値は、パフォーマンスが低いと見なされます。

BizTalk Server のベストプラクティス

SQL Server でSQL Server エージェントを開始します。 SQL Server エージェントが停止すると、データベースのメンテナンスを担当する組み込みの BizTalk SQL Server エージェントジョブを実行できません。この動作によりデータベースが増加し、この増加によってパフォーマンスの問題が発生する可能性があります。

SQL Server ログデータベースファイル (LDF) ファイルとメインデータベースファイル (MDF) ファイルを別のドライブに配置します。 BizTalkMsgBoxDbデータベースとBizTalkDTADb データベースの LDF ファイルと MDF ファイルが同じドライブ上にある場合、ディスクの競合が発生する可能性があります。

メッセージ本文の追跡のメリットがない場合は、この機能を有効にしないでください。ただし、ソリューションの開発とトラブルシューティングを行う際は、メッセージ本文の追跡を有効にすることをお勧めします。これを行う場合は、完了時にメッセージ本文の追跡を無効にしてください。メッセージ本文の追跡を有効にすると、BizTalk Server データベースが拡張されます。メッセージ本文の追跡を有効にする必要があるビジネスニーズがある場合は、TrackedMessages_Copy_BizTalkMsgBoxDbおよび DTA Purge and Archive SQL Server エージェントジョブが正常に実行されていることを確認します。

通常、トランザクションログが小さいほどパフォーマンスが向上します。トランザクションログを小さくするには、バックアップ BizTalk Server SQL Server エージェントジョブをより頻繁に実行するように構成します。

BizTalkMgmtDb データベースのsp_ForceFullBackup ストアドプロシージャを使用して、データファイルとログファイルのアドホック完全バックアップを実行することもできます。ストアドプロシージャは、 adm_ForceFullBackup テーブルを値 1 で更新します。次に BizTalk Server のバックアップジョブを実行すると、データベースの完全バックアップセットが作成されます。

BizTalk ヘルスモニター (BHM) ツールを使用して、既存の BizTalk Server 展開を評価できます。 BHM は、データベース関連の多数のチェックを実行します。

トラブルシューティング

BizTalk Server SQL Server データベースの最適なトラブルシューティング手順は、ブロックやデッドロックなどのデータベースの問題の種類によって異なります。 BizTalk Server データベースの問題をトラブルシューティングするには、次の手順に従います。

手順 1: 必要なすべての BizTalk SQL Server エージェントジョブを有効にして実行する

MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb ジョブを除くすべての BizTalk SQL Server エージェントジョブを有効にし、正常に実行する必要があります。他のジョブを無効にしないでください。

エラーが発生した場合は、SQL Server の View History オプションを使用してエラー情報を表示し、それに応じてエラーのトラブルシューティングを行います。 MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb SQL Server エージェントジョブは無限に実行されます。そのため、ジョブ履歴でジョブが絶えず失敗して再起動することが報告される場合にのみ、心配する必要があります。

手順 2: BizTalk ヘルスモニター (BHM)/MsgBoxViewer ツールを使用する

問題の再現中に BHM レポートを収集します。

BHM ツールは、テーブルサイズと行数に関する詳細情報を含む HTML レポートを提供するため、トラブルシューティングに役立ちます。このレポートは、BizTalk Server が調整されているかどうかを判断するのにも役立ちます。さらに、このツールは、BizTalk Server データベースと BizTalk Server 構成のスナップショットビューを提供します。

BizTalk Server での調整の詳細については、「 BizTalk Server でホストの調整を実装する方法を参照してください。

BizTalk Server の実行速度が通常よりも遅い場合は、BHM ツールを実行し、生成された HTML レポートで問題がないかどうかを確認します。 Summary セクションには、警告が黄色で表示され、潜在的な問題が赤で一覧表示されます。

さらに、BHM ツールの出力を使用して、どのテーブルが最も大きく、最も多くのレコードを持っているかを判断できます。次の表に、通常は最も大きい BizTalk Server テーブルを示します。このデータを使用して、潜在的な問題が存在する可能性がある場所を特定できます。

テーブル	説明
`<HostName>Q_Suspended`	このテーブルには、特定のホストの中断されたインスタンスに関連付けられている `Spool` テーブル内のメッセージへの参照が含まれています。このテーブルは、 `BizTalkMsgBoxDb` データベースにあります。
`<HostName>Q`	このテーブルには、特定のホストに関連付けられている `Spool` テーブル内のメッセージへの参照が含まれており、中断されません。このテーブルは、 `BizTalkMsgBoxDb` データベースにあります。
`Spool` `Parts` `Fragments`	これらのテーブルは、実際のメッセージデータを `BizTalkMsgBoxDb` データベースに格納します。
`Instances`	このテーブルには、すべてのインスタンスとその現在の状態が `BizTalkMsgBoxDb` データベースに格納されます。
`TrackingData_0_x`	これらの 4 つのテーブルには、TDDS 用の `BizTalkMsgBoxDb` データベースにビジネスアクティビティ監視 (BAM) 追跡イベントが格納され、イベントが `BAMPrimaryImport` データベースに移動されます。
`TrackingData_1_x`	これらの 4 つのテーブルは、TDDS の `BizTalkMsgBoxDb` データベースに追跡されたイベントを格納して、イベントを `BizTalkDTADB` データベースに移動します。
`Tracking_Fragmentsx` `Tracking_Partsx` `Tracking_Spoolx`	これらのテーブルのそれぞれ 2 つは、 `BizTalkMsgBoxDb` データベースと `BizTalkDTADb` データベースにあります。 1 つはオンラインで、もう 1 つはオフラインです。 BizTalk Server 2004 SP2 以降のバージョンでは、`TrackedMessages_Copy_BizTalkMsgBoxDb` SQL Server エージェントジョブは追跡対象のメッセージ本文を`BizTalkDTADb` データベース内のこれらのテーブルに直接移動します。 BizTalk Server 2004 Service Pack 1 (SP1) 以前のバージョンの BizTalk Server 2004 では、`TrackedMessages_Copy_BizTalkMsgBoxDb` SQL Server エージェントジョブは追跡されたメッセージ本文を`BizTalkMsgBoxDb` データベースのこれらのテーブルにコピーします。 `TrackingSpool_Cleanup_BizTalkMsgBoxDb` SQL Server エージェントジョブはオフラインテーブルを消去し、テーブルをオンラインにしますが、ジョブはオンラインテーブルもオフラインにします。
`dta_ServiceInstances`	このテーブルには、サービスインスタンスの追跡イベントが `BizTalkDTADb` データベースに格納されます。このテーブルが大きい場合は、 `BizTalkDTADb` データベースが大きくなる可能性があります。
`dta_DebugTrace`	次の表は、BizTalkDTADb データベースにオーケストレーションデバッガーイベントを格納します。
`dta_MessageInOutEvents`	このテーブルは、追跡対象のイベントメッセージを `BizTalkDTADb` データベースに格納します。これらの追跡されるイベントメッセージには、メッセージコンテキスト情報が含まれます。
`dta_ServiceInstanceExceptions`	次の表は、中断されたサービスインスタンスのエラー情報を `BizTalkDTADb` データベースに格納します。

次のシナリオで考えてみましょう。

<HostName>Q_Suspended テーブル

<HostName>Q_Suspended テーブルに多数のレコードがある場合、テーブルは、Group Hub または HAT に表示される有効な中断されたインスタンスである可能性があります。これらのインスタンスは終了できます。これらのインスタンスが Group Hub または HAT に表示されない場合、インスタンスはインスタンスまたは孤立したルーティングエラーレポートをキャッシュしている可能性があります。中断されたインスタンスが終了すると、このテーブル内の項目と、 Spool テーブルおよび Instances テーブル内の関連する行がクリーンアップされます。

このシナリオでは、中断されたインスタンスを再開または終了することによって処理します。 BHM ツールも使用できます。
<HostName>Q テーブル

<HostName>Q テーブルに多数のレコードがある場合は、次の種類のインスタンスが存在する可能性があります。
- すぐに実行できるインスタンス
- アクティブなインスタンス
- 退避されたインスタンス BizTalk Server には、インスタンスを "キャッチアップ" して処理する時間が必要です。
このテーブルは、受信処理速度が処理の送信レートを上回ると大きくなる可能性があります。このシナリオは、大規模な BizTalkDTADb データベースや SQL Server ディスクの遅延など、別の問題が発生した場合に発生する可能性があります。
Spoolテーブル、 Partsテーブル、 Fragments テーブル

Spool、Parts、およびFragmentsテーブルに多数のレコードがある場合、多くのメッセージが現在アクティブ、退避、または中断されています。これらのテーブルのサイズ、パーツ数、断片化設定によっては、1 つのメッセージでこれらすべてのテーブルが生成される場合があります。各メッセージには、 Spool テーブルに 1 行、 Parts テーブルに少なくとも 1 つの行があります。
Instances テーブル

BizTalk 管理者は、多数の中断されたインスタンスを Instances テーブルに保持できないようにする必要があります。退避したインスタンスは、ビジネスロジックで実行時間の長いオーケストレーションが必要な場合にのみ残る必要があります。 1 つのサービスインスタンスを、 Spool テーブル上の多数のメッセージに関連付けることができることに注意してください。
TrackingData_x_x テーブル

TrackingData_x_x テーブルが大きい場合、追跡ホスト (TDDS) は正常に実行されません。追跡ホストインスタンスが実行されている場合は、BizTalkDTADb データベースのイベントログとTDDS_FailedTrackingData テーブルでエラー情報を確認します。 BizTalk の状態が 6 (大規模なデータベース) で調整されている場合、データが必要ない場合は、BizTalk ターミネータツールを使用してこれらのテーブルを切り捨てることもできます。

BizTalkMsgBoxDb TrackingData_x_xテーブルのシーケンス番号とBAMPrimaryImportテーブルまたはBizTalkDTADb TDDS_StreamStatusテーブルの間に大きなギャップがある場合、TDDS はBizTalkMsgBoxDb データベースからデータを移動しない可能性があります。これを修正するには、BHM ツールを使用してこれらのテーブルを消去し、シーケンス番号をリセットします。
dta_DebugTrace テーブルと dta_MessageInOutEvents テーブル

dta_DebugTrace テーブルは、オーケストレーションで Shape の開始と終了が有効になっているときに設定されます。 dta_DebugTrace テーブルに多数のレコードがある場合、これらのオーケストレーションデバッグイベントが使用されているか、使用されていました。オーケストレーションのデバッグが通常の操作に必要ない場合は、Orchestration プロパティの Shape の開始と終了チェックボックスをオフにします。

dta_MessageInOutEvents テーブルは、オーケストレーションやパイプラインで Message の送受信が有効になっている場合に設定されます。これらの追跡イベントが必要ない場合は、オーケストレーションやパイプラインのプロパティでこのオプションのチェックボックスをオフにします。

これらのトレースイベントが無効になっている場合、またはバックログが BizTalkMsgBoxDb データベースに存在する場合、TDDS は引き続きこれらのテーブルにこのデータを移動するため、これらのテーブルが拡大し続ける可能性があります。

既定では、グローバル追跡が有効になっています。グローバル追跡が必要ない場合は、無効にすることができます。詳細については、「グローバル追跡をオフにする方法を参照してください。

BizTalkDTADb データベース内のdta_DebugTrace テーブルやdta_messageInOutEvents テーブルが大きすぎる場合は、追跡ホストを停止した後でテーブルを手動で切り捨てることができます。 BHM ツールもこの機能を提供します。

BizTalkMsgBoxDb データベース内のすべての追跡テーブルを切り捨てるには、BHM ツールを使用します。 BHM ツールは、Microsoft ダウンロードセンターで外部から入手できます。

データベースのサイズ変更ガイドラインの追跡の詳細については、MSDN Web サイトの「 Tracking Database Sizing Guidelines」を参照してください。
dta_ServiceInstanceExceptions テーブル

通常、 dta_ServiceInstanceExceptions テーブルは、インスタンスが定期的に中断されている環境では大きくなります。

手順 3: デッドロックシナリオを調査する

デッドロックシナリオでは、SQL Server で DBCC トレースを有効にして、デッドロック情報が SQLERROR ログに書き込まれるようにします。

SQL Server 2005 以降のバージョンでは、次のステートメントを実行します。

DBCC TRACEON (1222,-1)

SQL Server 2000 で、次のステートメントを実行します。

DBCC TRACEON (1204)

さらに、PSSDiag ユーティリティを使用して、 Lock:Deadlock イベントと Lock:Deadlock Chain イベントに関するデータを収集します。

BizTalkMsgBoxDB データベースは、大量でトランザクションの多いオンライントランザクション処理 (OLTP) データベースです。一部のデッドロックが予想され、このデッドロックは BizTalk Server エンジンによって内部的に処理されます。この動作が発生すると、エラーログにエラーが一覧表示されません。デッドロックシナリオを調査する場合、出力で調査しているデッドロックは、イベントログのデッドロックエラーと関連付ける必要があります。

dequeue コマンドと一部のSQL Server エージェントジョブがデッドロックする必要があります。通常、これらのジョブはデッドロックの対象として選択されます。これらのジョブはデッドロックトレースに表示されます。ただし、エラーはイベントログに一覧表示されません。そのため、このデッドロックが予想され、これらのジョブでのデッドロックを無視しても問題ありません。

デッドロックトレースで頻繁にデッドロックが発生し、関連するエラーがイベントログに一覧表示されている場合は、デッドロックが必要になることがあります。

手順 4: ブロックされたプロセスを探す

SQL Server のアクティビティモニターを使用して、ロックシステムプロセスのサーバープロセス識別子 (SPID) を取得します。次に、SQL Profiler を実行して、ロック SPID で実行されている SQL ステートメントを特定します。

SQL Server のロックとブロックの問題をトラブルシューティングするには、PSSDiag for SQL ユーティリティを使用して、ブロックスクリプトが有効になっている Transact-SQL イベントをすべてキャプチャします。

SQL Server 2005 以降のバージョンでは、 ブロックされたプロセスのしきい値 設定を指定して、指定したしきい値より長くブロックしている SPID または SPID を特定できます。

ブロックされたプロセスのしきい値設定の詳細については、「ブロックされたプロセスしきい値サーバー構成オプションを参照してください。

Note

SQL Server でロックまたはブロックの問題が発生した場合は、Microsoft カスタマーサポートサービスにお問い合わせください。 Microsoft カスタマーサポートサービスは、正しい PSSDiag ユーティリティオプションの構成に役立ちます。

手順 5: 最新の BizTalk Server Service Pack と累積的な更新プログラムをインストールする

BizTalk Server の新しいバージョンは、累積的な更新プログラム (CU) モデルに移行しました。累積的な更新プログラムには、最新の修正プログラムが含まれます。

すべてのデータを削除する

データベースが大きすぎる場合、またはすべてのデータを削除する方法が推奨される場合は、すべてのデータを削除できます。

注意事項

データがビジネスクリティカルな環境や、データが必要な場合は、この方法を使用しないでください。

BizTalkMsgBoxDb データベースの消去手順

BizTalkMsgBoxDb データベース内のすべてのデータを削除するには、BizTalk ヘルスモニター (BHM) ツールを使用します。

BizTalkDTADb データベースの消去オプション

BizTalkDTADb データベースからすべてのデータを削除するには、BizTalk ヘルスモニター (BHM) ツールを使用します。それ以外の場合は、次のいずれかの方法を使用します。

Note

どちらの方法もすべてのメッセージを削除しますが、メソッド 2 の方が高速です。

方法 1:
1. すべての BizTalk Server データベースをバックアップします。
2. dtasp_PurgeAllCompletedTrackingData ストアドプロシージャを実行します。 dtasp_PurgeAllCompletedTrackingData ストアドプロシージャの詳細については、「 BizTalk 追跡データベースからデータを手動で消去する方法を参照してください。
  
  Note
  
  このアクションにより、完了したすべてのメッセージが削除されます。
方法 2:
1. すべての BizTalk データベースをバックアップします。
2. dtasp_CleanHMData ストアドプロシージャを実行します。このオプションは、 BizTalkDTADb データベースに、削除する必要がある不完全なインスタンスが多数含まれている場合にのみ使用します。
  
  これを行うには、次の手順を実行します。
  1. すべての BizTalk ホスト、サービス、およびカスタム分離アダプターを停止します。 HTTP または SOAP アダプターを使用する場合は、IIS サービスを再起動します。
  2. BizTalkDTADb データベースでdtasp_CleanHMData ストアドプロシージャを実行します。
  3. すべてのホストと BizTalk Server サービスを再起動します。

BizTalk Server 2004 のみの手順

Note

追跡データが必要な場合は、 BizTalkDTADb データベースをバックアップし、データベースを別の SQL Server に復元してから、元の BizTalkDTADb データベースを消去します。

BHM データまたは PSSDiag 出力の分析に関するヘルプが必要な場合は、Microsoft カスタマーサポートサービスにお問い合わせください。カスタマーサポートサービスの電話番号とサポートコストに関する情報の完全な一覧については、「Contact Microsoft サポート」を参照してください。

Note

カスタマーサポートサービスに問い合わせる前に、BHM レポートデータ、PSSDiag 出力、更新されたイベントログ (.evt ファイル) を圧縮します。これらのファイルを BizTalk Server サポートエンジニアに送信する必要がある場合があります。

適用対象

BizTalk Server 2009
BizTalk Server 2010
BizTalk Server 2013
BizTalk Server 2013 R2
BizTalk Server 2016
BizTalk Server 2020

次の方法で共有

BizTalk Server データベースの保守とトラブルシューティング

まとめ

はじめに

統計の自動作成と統計の自動更新オプションを無効にする必要があります

Max Degree of Parallelism プロパティを正しく設定する必要があります

BizTalk Server インデックスを再構築できるタイミングを決定する

ロック、デッドロック、またはブロックが発生する可能性がある

大規模なデータベースまたはテーブルで問題が発生する可能性があります

適切な BizTalk SQL Server エージェントジョブを使用する

サービスインスタンスが中断される可能性がある

SQL Server と BizTalk Server のパフォーマンスの問題が発生する可能性があります

BizTalk Server のベストプラクティス

トラブルシューティング

手順 1: 必要なすべての BizTalk SQL Server エージェントジョブを有効にして実行する

手順 2: BizTalk ヘルスモニター (BHM)/MsgBoxViewer ツールを使用する

手順 3: デッドロックシナリオを調査する

手順 4: ブロックされたプロセスを探す

手順 5: 最新の BizTalk Server Service Pack と累積的な更新プログラムをインストールする

すべてのデータを削除する

BizTalkMsgBoxDb データベースの消去手順

BizTalkDTADb データベースの消去オプション

BizTalk Server 2004 のみの手順

適用対象

その他のリソース

次の方法で共有

BizTalk Server データベースの保守とトラブルシューティング

まとめ

はじめに

統計の自動作成と統計の自動更新オプションを無効にする必要があります

Max Degree of Parallelism プロパティを正しく設定する必要があります

BizTalk Server インデックスを再構築できるタイミングを決定する

ロック、デッドロック、またはブロックが発生する可能性がある

大規模なデータベースまたはテーブルで問題が発生する可能性があります

適切な BizTalk SQL Server エージェント ジョブを使用する

サービス インスタンスが中断される可能性がある

SQL Server と BizTalk Server のパフォーマンスの問題が発生する可能性があります

BizTalk Server のベスト プラクティス

トラブルシューティング

手順 1: 必要なすべての BizTalk SQL Server エージェント ジョブを有効にして実行する

手順 2: BizTalk ヘルス モニター (BHM)/MsgBoxViewer ツールを使用する

手順 3: デッドロックシナリオを調査する

手順 4: ブロックされたプロセスを探す

手順 5: 最新の BizTalk Server Service Pack と累積的な更新プログラムをインストールする

すべてのデータを削除する

BizTalkMsgBoxDb データベースの消去手順

BizTalkDTADb データベースの消去オプション

BizTalk Server 2004 のみの手順

適用対象

その他のリソース

適切な BizTalk SQL Server エージェントジョブを使用する

サービスインスタンスが中断される可能性がある

BizTalk Server のベストプラクティス

手順 1: 必要なすべての BizTalk SQL Server エージェントジョブを有効にして実行する

手順 2: BizTalk ヘルスモニター (BHM)/MsgBoxViewer ツールを使用する