BizTalk Server データベースの保守とトラブルシューティング
この記事では、BizTalk Server データベースの保守とトラブルシューティングを行う方法について詳しく説明します。
元の製品バージョン: BizTalk Server データベース
元の KB 番号: 952555
概要
Microsoft BizTalk Server データベースの正常性は、BizTalk Server メッセージング環境を成功させるために重要です。 この記事では、BizTalk Server データベースを操作するときに考慮すべき重要事項について説明します。 これらの考慮事項には、次のものが含まれます。
- オプションと
auto create statistics
SQL Server オプションをauto update statistics
無効にする必要があります。 - (MAXDOP) オプションを
max degree of parallelism
正しく設定する必要があります。 - BizTalk Serverインデックスを再構築できるタイミングを決定します。
- ロック、デッドロック、またはブロックが発生する可能性があります。
- 大規模なデータベースまたはテーブルで問題が発生する可能性があります。
- BizTalk SQL Server エージェント ジョブ。
- サービス インスタンスが中断される可能性があります。
- SQL ServerとBizTalk Serverパフォーマンスの問題が発生する可能性があります。
- BizTalk Serverのベスト プラクティスに従う必要があります。
概要
この記事では、BizTalk Server データベースを管理する方法と、データベースの問題BizTalk Serverトラブルシューティングする方法について説明します。
統計の自動作成と統計の自動更新オプションを無効にする必要があります
データベースでは、 オプションと auto update statistics
オプションをauto create statistics
無効にBizTalkMsgBoxDb
しておく必要があります。 これらの設定が無効かどうかを判断するには、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'
並列処理の最大次数プロパティを正しく設定する必要があります
SQL Serverを実行し、データベースをBizTalkMsgBoxDb
ホストしているコンピューターで、並列処理run_value
とconfig_value
プロパティの最大次数を 1 に設定します。 以降の SQL バージョンでは、SQL インスタンスごとではなく、データベースごとにこの設定を指定することもできます。 詳細については、「 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)。 SQL Server ステートメントをDBCC SHOWCONTIG
使用して、BizTalk Server テーブルの断片化情報を表示できます。
BizTalk Serverインデックスは GUID ベースです。 したがって、断片化は通常発生します。 ステートメントによってDBCC SHOWCONTIG
返されるスキャン密度の値が 30% 未満の場合は、ダウンタイム中にBizTalk Serverインデックスを再構築できます。
多くのBizTalk Serverテーブルには、定義を使用DataType
する列が含まれています。 これらの列では、オンライン インデックス作成を実行できません。 そのため、データを処理する間は、BizTalk ServerインデックスBizTalk Server再構築しないでください。
ロック、デッドロック、またはブロックが発生する可能性があります
通常、ロックとブロックはBizTalk Server環境で発生します。 ただし、これらのロックまたはブロックは長時間保持されません。 そのため、ブロックとデッドロックは、潜在的な問題を示します。
大規模なデータベースまたはテーブルで問題が発生する可能性があります
データベースが大きくなると、パフォーマンスの BizTalkMsgBoxDb
問題が発生する可能性があります。 理想的には、データベースが BizTalkMsgBoxDb
データを保持しないようにする必要があります。 データが BizTalkMsgBoxDb
処理されるか、または BAM データベースに移動 BizTalkDTADb
されるまで、データベースはバッファーと見なす必要があります。
バックエンドで強力なSQL Serverを使用し、実行時間の長いオーケストレーションの多くを使用する環境には、5 GB を超えるデータベースが存在BizTalkMsgBoxDb
する場合があります。 実行時間の長いオーケストレーションを使用しない大量の環境には BizTalkMsgBoxDb
、5 GB よりもはるかに小さいデータベースが必要です。
データベースの BizTalkDTADb
サイズは設定されていません。 ただし、パフォーマンスが低下すると、データベースが大きすぎる可能性があります。 20 GB が大きすぎると見なされるお客様もいますが、200 GB の場合は、複数の CPU、大量のメモリ、高速なネットワークとストレージで実行されている非常に強力な SQL サーバーで問題なく動作する場合があります。 大規模なBizTalk Server データベースがある場合は、次の問題が発生する可能性があります。
データベースは
BizTalkMsgBoxDb
引き続き拡張されます。 ただし、ログ ファイルとデータ サイズの両方が大きいままです。BizTalk Serverは、単純なメッセージ フロー シナリオでも処理するのに通常より長い時間がかかります。
BizTalk 管理コンソールまたは正常性とアクティビティ追跡 (HAT) クエリは通常よりも長い時間がかかり、タイムアウトになる可能性があります。
データベース ログ ファイルが切り捨てられることはありません。
BizTalk SQL Server エージェント ジョブの実行速度が通常よりも遅くなります。
一部のテーブルは、通常のテーブル サイズと比較して大きい、または行が多すぎます。
データベースはさまざまな理由で大きくなる可能性があります。 これらの理由には、次のものが含まれる場合があります。
- BizTalk SQL Server エージェント ジョブが実行されていません
- 中断されたインスタンスの数が多い
- ディスクエラー
- Tracking
- 調整
- SQL Server のパフォーマンス
- ネットワーク待機時間
データの問題が発生しているかどうかを判断するには、環境内で何が予想されるかがわかっていることを確認してください。
既定では、既定のホストで追跡が有効になっています。 BizTalk では、1 つのホストで [ホストの追跡を許可する] オプションをオンにする必要があります。 追跡が有効になっている場合、追跡データ デコード サービス (TDDS) は、追跡イベント データを BizTalkMsgBoxDb
データベースからデータベースに BizTalkDTADb
移動します。 追跡ホストが停止した場合、TDDS はデータをデータベースにBizTalkDTADb
移動せず、データベース内のTrackingData_x_x
BizTalkMsgBoxDb
テーブルは拡大します。
1 つのホストを追跡専用にすることをお勧めします。 TDDS が大量のシナリオで新しい追跡イベントを維持できるようにするには、1 つの追跡ホストの複数のインスタンスを作成します。 複数の追跡ホストを存在させる必要があります。
テーブルに行が多すぎる可能性があります。 設定された行数が多すぎます。 さらに、この行数は、テーブルに格納されるデータの種類によって異なります。 たとえば、 dta_DebugTrace
100 万行を超えるテーブルの行が多すぎる可能性があります。 <HostName>Q_Suspended
200,000 行を超えるテーブルの行が多すぎる可能性があります。
正しい 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 データベースをバックアップできます。
SQL Server エージェント ジョブはMessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb
無限に実行されます。 したがって、SQL Server エージェントジョブ履歴には正常な完了は表示されません。 エラーが発生した場合、ジョブは 1 分以内に再起動され、無限に実行されます。 そのため、エラーは無視しても問題ありません。 さらに、ジョブ履歴をクリアすることもできます。 このジョブが常に失敗して再起動することがジョブ履歴から報告される場合にのみ、心配する必要があります。
MessageBox_Message_Cleanup_BizTalkMsgBoxDb
SQL Server エージェント ジョブは、SQL Server エージェント ジョブによってMessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb
開始されるため、有効にしてはならない唯一のBizTalk Server ジョブです。
DTA 消去およびアーカイブ SQL Server エージェント ジョブは、追跡対象のメッセージをBizTalkDTADb
消去してアーカイブすることで、データベースを維持するのに役立ちます。 このジョブは、テーブル内のすべての行を読み取り、タイム スタンプを比較して、レコードを削除するかどうかを判断します。
SQL Server エージェント ジョブをMessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb
除くすべての BizTalk SQL Server エージェント ジョブが正常に実行されている必要があります。
サービス インスタンスが中断される可能性がある
サービス インスタンスは、中断 (再開可能) または中断 (再開不可) できます。 これらのサービス インスタンスには、メッセージング、オーケストレーション、またはポートがあります。
これらのサービス インスタンスを使用すると、データベースが BizTalkMsgBoxDb
不必要に増大し、終了する可能性があります。 グループ ハブを使用して、メッセージの照会、再開、または終了を行うことができます。 また、Terminate.vbs スクリプトまたは BizTalk ヘルス モニター (BHM) ツールを使用して、BizTalk データベースのクエリ、消去、保守を行うこともできます。 状況によっては、孤立したメッセージやゾンビ メッセージがシステムに残っている可能性があります。 BHM ツールは、このような状況を修正するのに役立ちます。
Terminate.vbs スクリプトの詳細については、「中断されたサービス インスタンスの削除」を参照してください。
キャッシュ インスタンスは [グループ ハブ] ページに表示されません。また、インスタンスを一時停止または終了することはできません。 この制限は、テーブルの増加の一般的な原因です。 BizTalk Server 2006 のキャッシュ サービス インスタンスに対する新しいゾンビ メッセージを防ぐには、Microsoft サポート技術情報の記事936536の修正プログラムをインストールします。 この問題は、BizTalk Server 2006 R2 以降のバージョンで修正されています。
注:
ゾンビ メッセージは、ルーティングされたが使用されなかったメッセージです。
ゾンビ メッセージの説明については、次の 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) ファイルを別のドライブに配置します。 データベースと データベースの LDF ファイルと MDF ファイル BizTalkMsgBoxDb
が同じドライブ上にある場合 BizTalkDTADb
、ディスクの競合が発生する可能性があります。
メッセージ本文の追跡の恩恵を受けない場合は、この機能を有効にしないでください。 ただし、ソリューションの開発とトラブルシューティングを行う際に、メッセージ本文の追跡を有効にすることをお勧めします。 これを行う場合は、完了したときにメッセージ本文の追跡を無効にしてください。 メッセージ本文の追跡を有効にすると、BizTalk Server データベースが拡張されます。 メッセージ本文の追跡を有効にする必要があるビジネス上のニーズがある場合は、ジョブが正常に実行されていることを確認し、DTA 消去およびアーカイブ SQL Server エージェントジョブが正常に実行されていることをTrackedMessages_Copy_BizTalkMsgBoxDb
確認します。
通常、トランザクション ログが小さいほどパフォーマンスが向上します。 トランザクション ログを小さくするには、バックアップ BizTalk Server SQL Server エージェント ジョブをより頻繁に実行するように構成します。
sp_ForceFullBackup
データベース内のストアド プロシージャをBizTalkMgmtDb
使用して、データ ファイルとログ ファイルのアドホックな完全バックアップを実行することもできます。 ストアド プロシージャは、値 1 で adm_ForceFullBackup
テーブルを更新します。 次に Backup BizTalk Server ジョブを実行すると、データベースの完全バックアップ セットが作成されます。
BizTalk ヘルス モニター (BHM) ツールを使用して、既存のBizTalk Serverデプロイを評価できます。 BHM は、データベース関連の多数のチェックを実行します。
トラブルシューティング
BizTalk Server SQL Server データベースに最適なトラブルシューティング手順は、ブロックやデッドロックなどのデータベースの問題の種類によって異なります。 BizTalk Server データベースの問題のトラブルシューティングを行うには、次の手順に従います。
手順 1: 必要なすべての BizTalk SQL Server エージェント ジョブを有効にして実行する
ジョブを除くすべての BizTalk SQL Server エージェント ジョブをMessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb
有効にして正常に実行する必要があります。 他のジョブを無効にしないでください。
エラーが発生した場合は、SQL Serverの [履歴の表示] オプションを使用してエラー情報を表示し、それに応じてエラーのトラブルシューティングを行います。 SQL Server エージェント ジョブはMessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb
無限に実行されます。 したがって、ジョブ履歴でジョブが常に失敗して再起動することが報告される場合にのみ、心配する必要があります。
手順 2: BizTalk ヘルス モニター (BHM)/MsgBoxViewer ツールを使用する
問題の再現中に BHM レポートを収集します。
BHM ツールは、テーブル サイズと行数に関する詳細情報を含む HTML レポートを提供するため、トラブルシューティングに役立ちます。 レポートは、BizTalk Serverが調整されているかどうかを判断するのにも役立ちます。 さらに、ツールは、BizTalk Server データベースとBizTalk Server構成のスナップショットビューを提供します。
BizTalk Serverでの調整の詳細については、「BizTalk Serverでホストの調整を実装する方法」を参照してください。
BizTalk Serverが通常よりも遅く実行されている場合は、BHM ツールを実行し、生成された HTML レポートで問題がないか確認します。 [ 概要] セクションには、警告が黄色で表示され、潜在的な問題が赤で一覧表示されます。
さらに、BHM ツールの出力を使用して、どのテーブルが最も大きく、最もレコードが多いかを判断できます。 次の表は、通常、最も大きくなるBizTalk Serverテーブルの一覧です。 このデータを使用して、潜在的な問題が存在する可能性がある場所を特定できます。
Table | 説明 |
---|---|
<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 これらのテーブルにコピーします。 SQL Server エージェント ジョブはTrackingSpool_Cleanup_BizTalkMsgBoxDb オフライン テーブルを消去し、テーブルをオンラインにしますが、ジョブはオンライン テーブルもオフラインにします。 |
dta_ServiceInstances |
このテーブルには、データベース内のサービス インスタンスの追跡イベントが BizTalkDTADb 格納されます。 このテーブルが大きい場合、 BizTalkDTADb データベースはおそらく大きくなります。 |
dta_DebugTrace |
次の表は、BizTalkDTADb データベースにオーケストレーション デバッガー イベントを格納します。 |
dta_MessageInOutEvents |
このテーブルは、追跡されたイベント メッセージをデータベースに BizTalkDTADb 格納します。 追跡されるこれらのイベント メッセージには、メッセージ コンテキスト情報が含まれます。 |
dta_ServiceInstanceExceptions |
このテーブルは、中断されたサービス インスタンスのエラー情報をデータベースに BizTalkDTADb 格納します。 |
以下のシナリオについて検討します。
<HostName>Q_Suspended
テーブルテーブルに多数の
<HostName>Q_Suspended
レコードがある場合、テーブルは 、グループ ハブ または HAT に表示される有効な一時停止インスタンスである可能性があります。 これらのインスタンスは終了できます。 これらのインスタンスが Group Hub または HAT に表示されない場合、インスタンスはインスタンスまたは孤立したルーティング エラー レポートをキャッシュしている可能性があります。 中断されたインスタンスが終了すると、このテーブル内の項目と、 およびInstances
テーブル内のSpool
関連する行がクリーンアップされます。このシナリオでは、中断されたインスタンスを再開または終了することによって処理します。 BHMツールも使用できます。
<HostName>Q
テーブルテーブルに多数の
<HostName>Q
レコードがある場合は、次の種類のインスタンスが存在する可能性があります。- すぐに実行できるインスタンス
- アクティブ インスタンス
- 退避されたインスタンスBizTalk Server、インスタンスを "キャッチアップ" して処理する時間が必要です。
このテーブルは、処理の受信レートが処理の送信レートを上回ると大きくなる可能性があります。 このシナリオは、大規模
BizTalkDTADb
なデータベースやSQL Serverディスクの遅延など、別の問題が発生した場合に発生する可能性があります。Spool
、Parts
、およびFragments
テーブル、
Parts
、およびFragments
テーブルに多数のSpool
レコードがある場合、多くのメッセージが現在アクティブ、退避、または中断されています。 サイズ、パーツの数、およびこれらのテーブルの断片化設定に応じて、1 つのメッセージでこれらすべてのテーブルが生成される場合があります。 各メッセージには、テーブル内に 1 つの行と、テーブル内Spool
の少なくとも 1 つの行がありますParts
。Instances
テーブルBizTalk 管理者は、多数の中断されたインスタンスをテーブルに
Instances
残すことはできません。 退避されたインスタンスは、ビジネス ロジックで実行時間の長いオーケストレーションが必要な場合にのみ残る必要があります。 1 つのサービス インスタンスをテーブル上の多数のメッセージにSpool
関連付けることができることに注意してください。TrackingData_x_x
テーブルテーブルが
TrackingData_x_x
大きい場合、追跡ホスト (TDDS) は正常に実行されません。 追跡ホスト インスタンスが実行されている場合は、イベント ログとデータベース内のTDDS_FailedTrackingData
テーブルでエラー情報をBizTalkDTADb
確認します。 BizTalk の状態が 6 (大規模なデータベース) で調整されている場合、データが必要ない場合は、BizTalk ターミネータ ツールを使用してこれらのテーブルを切り捨てることもできます。テーブル内のシーケンス番号と
BAMPrimaryImport
またはTDDS_StreamStatus
BizTalkDTADb
テーブルの間にBizTalkMsgBoxDb
TrackingData_x_x
大きなギャップがある場合、TDDS によってデータベースからBizTalkMsgBoxDb
データが移動されない可能性があります。 これを修正するには、BHM ツールを使用してこれらのテーブルを消去し、シーケンス番号をリセットします。dta_DebugTrace
テーブルとdta_MessageInOutEvents
テーブルオーケストレーションで図形の
dta_DebugTrace
開始と終了が有効になっている場合、テーブルが設定されます。 テーブルに多数のdta_DebugTrace
レコードがある場合、これらのオーケストレーション デバッグ イベントが使用されているか、使用されていました。 オーケストレーションのデバッグが通常の操作に必要ない場合は、[オーケストレーション] プロパティの [図形の開始と終了チェック] ボックスをオフにします。dta_MessageInOutEvents
オーケストレーションやパイプラインでメッセージの送受信が有効になっている場合、テーブルに値が設定されます。 これらの追跡イベントが必要ない場合は、オーケストレーションまたはパイプラインのプロパティで、このオプションの [チェック] ボックスをオフにします。これらのトレース イベントが無効になっている場合、またはバックログがデータベースに
BizTalkMsgBoxDb
存在する場合は、TDDS によって引き続きこのデータがこれらのテーブルに移動されるため、これらのテーブルは引き続き増加する可能性があります。既定では、グローバル追跡が有効になっています。 グローバル追跡が必要ない場合は、無効にすることができます。 詳細については、「 グローバル追跡を無効にする方法」を参照してください。
データベース内の
dta_DebugTrace
テーブルやテーブルBizTalkDTADb
がdta_messageInOutEvents
大きすぎる場合は、追跡ホストを停止した後にテーブルを手動で切り捨てることができます。 BHM ツールもこの機能を提供します。データベース内のすべての追跡テーブルを
BizTalkMsgBoxDb
切り捨てるには、BHM ツールを使用します。 BHM ツールは、Microsoft ダウンロード センターで外部から入手できます。データベースサイズ設定ガイドラインの追跡の詳細については、次の MSDN Web サイト「 データベースサイズ設定ガイドラインの追跡」を参照してください。
dta_ServiceInstanceExceptions
テーブル通常、テーブルは
dta_ServiceInstanceExceptions
、インスタンスが定期的に中断されている環境では大きくなります。
手順 3: デッドロック シナリオを調査する
デッドロックシナリオでは、SQL Serverで DBCC トレースを有効にして、デッドロック情報が SQLERROR ログに書き込まれるようにします。
SQL Server 2005 以降のバージョンでは、次のステートメントを実行します。
DBCC TRACEON (1222,-1)
SQL Server 2000 では、次のステートメントを実行します。
DBCC TRACEON (1204)
さらに、PSSDiag ユーティリティを使用して、イベントと Chain イベントの Lock:Deadlock
データを Lock:Deadlock
収集します。
データベース 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 を決定できます。
ブロックされたプロセスのしきい値設定の詳細については、「ブロックされたプロセスのしきい値サーバー構成オプション」を参照してください。
注:
SQL Serverでロックまたはブロックの問題が発生した場合は、Microsoft カスタマー サポート サービスにお問い合わせください。 Microsoft カスタマー サポート サービスは、正しい PSSDiag ユーティリティ オプションの構成に役立ちます。
手順 5: 最新のBizTalk Server Service Pack と累積的な更新プログラムをインストールする
以降BizTalk Serverバージョンが累積的な更新プログラム (CU) モデルに移行されました。 累積的な更新プログラムには、最新の修正プログラムが含まれます。
すべてのデータを削除する
データベースが大きすぎる場合、またはすべてのデータを削除する方法が推奨される場合は、すべてのデータを削除できます。
注意
データがビジネス クリティカルな環境、またはデータが必要な場合は、このメソッドを使用しないでください。
BizTalkMsgBoxDb データベースの消去手順
データベース内のすべてのデータをBizTalkMsgBoxDb
削除するには、BizTalk ヘルス モニター (BHM) ツールを使用します。
BizTalkDTADb データベースの消去オプション
データベースからすべてのデータをBizTalkDTADb
削除するには、BizTalk ヘルス モニター (BHM) ツールを使用します。 それ以外の場合は、次のいずれかの方法を使用します。
注:
どちらの方法でもすべてのメッセージが削除されますが、メソッド 2 の方が高速です。
メソッド 1:
すべてのBizTalk Server データベースをバックアップします。
ストアド プロシージャを
dtasp_PurgeAllCompletedTrackingData
実行します。 ストアド プロシージャのdtasp_PurgeAllCompletedTrackingData
詳細については、「 BizTalk 追跡データベースからデータを手動で消去する方法」を参照してください。注:
このアクションにより、完了したすべてのメッセージが削除されます。
メソッド 2:
すべての BizTalk データベースをバックアップします。
ストアド プロシージャを
dtasp_CleanHMData
実行します。 このオプションは、データベースにBizTalkDTADb
削除する必要がある不完全なインスタンスが多数含まれている場合にのみ使用します。これを行うには、次の手順を実行します。
- すべての BizTalk ホスト、サービス、およびカスタム分離アダプターを停止します。 HTTP または SOAP アダプターを使用する場合は、IIS サービスを再起動します。
- データベースで
dtasp_CleanHMData
ストアド プロシージャを実行しますBizTalkDTADb
。 - すべてのホストとBizTalk Server サービスを再起動します。
BizTalk Server 2004-only 手順
注:
追跡データが必要な場合は、データベースをBizTalkDTADb
バックアップし、データベースを別のSQL Serverに復元してから、元BizTalkDTADb
のデータベースを消去します。
BHM データまたは PSSDiag 出力の分析に関するヘルプが必要な場合は、Microsoft カスタマー サポート サービスにお問い合わせください。 カスタマー サポート サービスの電話番号とサポート コストに関する情報の完全な一覧については、Microsoft サポートにお問い合わせください。
注:
カスタマー サポート サービスに問い合わせる前に、BHM レポート データ、PSSDiag 出力、更新されたイベント ログ (.evt ファイル) を圧縮します。 これらのファイルは、BizTalk Server サポート エンジニアに送信する必要がある場合があります。
適用対象
- BizTalk Server 2009
- BizTalk Server 2010
- BizTalk Server 2013
- BizTalk Server 2013 R2
- BizTalk Server 2016
- BizTalk Server 2020