BizTalk Server データベースとその正常性は、BizTalk Server データベース メッセージング環境を成功させるために非常に重要です。 このトピックでは、BizTalk Server データベースの保守またはトラブルシューティングを行うときに従う必要がある手順を示します。
BizTalk Server データベースの管理
[ 統計の自動更新 ] オプションと [ 統計の自動作成 ] オプションを無効にします (BizTalk Server メッセージ ボックス データベースにのみ適用されます)。 既定では、これらの設定は BizTalk Server 構成の一部として構成されます。 これらの設定は変更しないでください。
これらの設定が無効になっているかどうかを確認するには、SQL Server で次のストアド プロシージャを実行します。
SELECT DATABASEPROPERTYEX('BizTalkMsgBoxDB', 'IsAutoCreateStatistics') AS IsAutoCreateStatistics SELECT DATABASEPROPERTYEX('BizTalkMsgBoxDB', 'IsAutoUpdateStatistics') AS IsAutoUpdateStatistics設定が無効であることを示すには、返される値は 0 にする必要があります。 0 が返されない場合は、SQL Server で次を実行して設定を無効にします。
ALTER DATABASE BizTalkMsgBoxDB SET AUTO_CREATE_STATISTICS OFF ALTER DATABASE BizTalkMsgBoxDB SET AUTO_UPDATE_STATISTICS OFFこれらの設定の詳細については、「 BizTalk Server で BizTalkMsgBoxDb データベースに接続しようとすると、ブロック、デッドロック状態、またはその他の SQL Server の問題が発生する」を参照してください。
Max Degree of Parallelism プロパティを設定します。 既定では、この設定は BizTalk Server 構成の一部として構成されます。 これらの設定は変更しないでください。
Max Degree of Parallelism run_value プロパティと config_value プロパティを、BizTalk Server MessageBox データベースをホストする SQL Server インスタンス上の 1 (1) の値に設定します。 並列処理の最大次数の設定を確認するには、SQL Server の Master データベースに対して次のストアド プロシージャを実行します。
exec sp_configure 'max degree of parallelism'run_valueとconfig_valueの値が 1 に設定されていない場合は、SQL Server で次のストアド プロシージャを実行します。
exec sp_configure 'max degree of parallelism', '1' reconfigure with override並列処理の最大限度設定が BizTalk Server に与える影響の詳細については、「BizTalk Server で BizTalkMsgBoxDb データベースに接続しようとすると、ブロック、デッドロック状態、またはその他の SQL Server の問題が発生する」を参照してください。
BizTalk Server インデックスを再構築できるタイミングを決定します。
BizTalk Server データベースのインデックスのほとんどはクラスター化されています (インデックス ID: 1)。 DBCC SHOWCONTIG コマンドを使用すると、BizTalk Server データベース内のテーブルの断片化情報を表示できます。 これらのインデックスは GUID ベースであるため、断片化が発生するのは正常です。 DBCC SHOWCONTIG のスキャン密度の値が 30%未満の場合、ダウンタイム中にインデックスを再構築できます。 BizTalk Server データベースの多くのテーブルには、オンライン インデックス作成を実行できない DataType 定義を使用する列が含まれています。 そのため、BizTalk がデータを処理している間は、BizTalk Server データベース内のテーブルのインデックスを再構築しないでください。
BizTalk インデックスを再構築する方法の詳細については、「BizTalk Server で BizTalkMsgBoxDb データベースに接続しようとすると、ブロック、デッドロック状態、またはその他の SQL Server の問題が発生する」を参照してください。
sys.dm_db_index_physical_stats関数を使用して、SQL Server で断片化情報を検索することもできます。 詳細については、「 sys.dm_db_index_physical_stats (Transact-SQL)」を参照してください。
データベースでロック、ブロック、またはデッドロックを監視します。
これは、BizTalk Server で使用される SQL Server データベースでロックとブロックが発生すると想定される動作です。 ただし、これらのロックまたはブロックを長期間継続することは想定されていません。 BizTalk Server で使用される SQL Server データベースの拡張ブロックとデッドロックは、潜在的な問題のインジケーターです。
BizTalk Server で使用される SQL Server データベースでのデッドロックとブロックの現在の既知の原因については、「BizTalk Server で BizTalkMsgBoxDb データベースに接続しようとすると、ブロック、デッドロック状態、またはその他の SQL Server の問題が発生する」を参照してください。
データベースとテーブルのサイズを監視します。
BizTalk Server メッセージ ボックス データベースのサイズは、通常、約 5 GB 以下にする必要があります。 BizTalkMsgBoxDb データベースはデータを保持せず、データが処理されるか BizTalkDTADb データベースに移動されるまでバッファーと見なす必要があります。 強力な SQL Server バックエンドを備え、実行時間の長いオーケストレーションが多数ある環境には、5 GB を超える BizTalkMsgBoxDb データベースが含まれる場合があります。 実行時間の長いオーケストレーションがない大量の環境では、BizTalk Server MessageBox データベースが 5 GB よりもはるかに小さい必要があります。
BizTalk Server 追跡データベースのサイズは大きく異なる場合がありますが、クエリのパフォーマンスが大幅に低下すると、追跡データベースが大きすぎる可能性があります。 通常、15 ~ 20 GB を超える BizTalk Server 追跡データベースは大きすぎると見なされ、パフォーマンスに悪影響を与える可能性があります。
次の問題は、大きすぎる BizTalk Server データベースに起因する可能性があります。
- BizTalk Server メッセージ ボックス データベースは、(ログ ファイルだけでなく) データ サイズが大きいまま、引き続き拡大します。 BizTalk Server では、単純なメッセージ フロー シナリオであっても処理に通常よりも長い時間がかかります。
- グループ ハブクエリは通常よりも長い時間がかかり、タイムアウトになる場合もあります。
- データベース ログ ファイルが切り捨てられることはありません。
- BizTalk SQL エージェント ジョブの実行速度が通常よりも遅くなります。
- 一部のテーブルは、通常と比べてかなり大きいか、行が多すぎます。
BizTalk Server データベースは、次のようないくつかの理由で大きくなる可能性があります。
- BizTalk SQL エージェント ジョブが実行されていない
- 過度に中断されたメッセージまたはサービス インスタンス
- ディスクの障害
- 高レベルの追跡
- BizTalk Server のスロットリング
- SQL Server のパフォーマンスの低下
- ネットワーク遅延の問題
同様に、テーブル内の行が多すぎる可能性があります。 行数が多すぎるという定義はありません。 さらに、この行数は、テーブルに格納されるデータの種類によって異なります。 たとえば、100 万行を超える dta_DebugTrace テーブルの行が多すぎる可能性があります。 200,000 行を超える HostNameQ_Suspended テーブルの 行が多すぎる可能性があります。
データの問題が発生しているかどうかを判断するために、環境内で想定される内容がわかっていることを確認します。
BizTalk Server ホストで追跡を有効にします。
既定では、既定のホストで追跡が有効になっています。 BizTalk では、1 つのホストで [ ホストの追跡を許可する ] オプションをオンにする必要があります。 追跡が有効になっている場合、追跡データ デコード サービス (TDDS) は、追跡イベント データを BizTalk Server メッセージ ボックス データベースから BizTalk Server 追跡データベースに移動します。 ホスト 追跡を許可 するオプションを使用して BizTalk Server ホストが構成されていない場合、または追跡ホストが停止している場合、TDDS は実行されず、BizTalk Server MessageBox データベース内のTrackingData_x_x テーブルはオフになります。
そのため、専用の BizTalk Server ホストは、[ホストの追跡を許可する ] オプションを使用して構成する必要があります。 専用追跡ホストの構成の詳細については、「専用追跡ホスト の構成」を参照してください。
TDDS が大量のシナリオで新しい追跡イベントを維持できるようにするには、1 つの追跡ホストの複数のインスタンスを作成できますが、追跡用に複数のホストを構成する必要はありません。
正しい BizTalk SQL Server エージェント ジョブを使用します。
BizTalk Server SQL エージェント ジョブの実行は、BizTalk Server データベースを管理し、最適なパフォーマンスを維持するために重要です。
BizTalk Server SQL Server エージェント のバックアップ ジョブは、BizTalk Server データベースをバックアップするためにサポートされている唯一の方法です。 このジョブでは、完全復旧モデルを使用するようにすべての BizTalk Server データベースを設定する必要があります。 このジョブは、正常な BizTalk Server 環境用に構成する必要があります。 SQL Server サービスが停止され、すべての BizTalk Server プロセスが停止されている場合にのみ、SQL Server メソッドを使用して BizTalk Server データベースをバックアップできます。
SQL エージェント バックアップ BizTalk Server ジョブを構成するときに SQL Server の完全復旧モデルを使用する方法の詳細については、「完全復旧モデルでのログ配布またはバックアップ」を参照してください。
MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb SQL Server エージェント ジョブは、無期限に実行するように設計されています。 その結果、SQL エージェント ジョブ履歴は、この SQL エージェント ジョブが正常に完了したことを示していない可能性があります。この動作は仕様です。 エラーが発生した場合、ジョブは 1 分以内に再起動し、無状態で実行を続けます。 そのため、通常、このジョブのエラー通知は無視できます。
MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb SQL Server エージェント ジョブのジョブ履歴で、このジョブが常に失敗し、再起動していることが示されている場合は、失敗/再起動サイクルの原因をさらに調査する必要があります。
MessageBox_Message_Cleanup_BizTalkMsgBoxDb SQL Server エージェント ジョブは、MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb ジョブによって開始されるため、手動で有効にしてはならない唯一のジョブです。
DTA 消去およびアーカイブ SQL Server エージェント ジョブは、追跡対象メッセージを削除およびアーカイブすることによって、BizTalk Server 追跡データベースを維持します。 このジョブは、テーブル内のすべての行を読み取り、各行のタイムスタンプを比較して、レコードを削除する必要があるかどうかを判断します。
BizTalk Server SQL Server エージェント ジョブのトラブルシューティングを行うときは、MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDbを除くすべての SQL エージェント ジョブがエラーなしで完了していることを確認します。
SQL Server で使用される BizTalk Server SQL エージェント ジョブの詳細については、以下を参照してください。
中断されたインスタンスを監視して終了します。
サービス インスタンスは中断 (再開可能) または中断 (再開不可) できます。 これらのサービス インスタンスには、メッセージング、オーケストレーション、またはポートがあります。 BizTalk Server は、BizTalk Server 管理コンソールの [グループ ハブ] ページを使用するか、Terminate.vbs スクリプトを使用して、これらのインスタンスの終了と削除に対応します。 Terminate.vbs スクリプトの詳細については、「 中断されたサービス インスタンスの削除」を参照してください。
ターミネータ ツールを使用して、中断されたインスタンスを削除することもできます。 ターミネータ ツールは、 BizTalk Health Monitor に含まれています。
"orphans" と "zombies" という用語は、多くの場合、同じ意味で使用されます。 孤立したメッセージまたはゾンビ メッセージは、関連付けられたサービス インスタンスを持たないメッセージです。通常、サービス インスタンスはメッセージを受信する前に終了しているためです。 孤立したサービスまたはゾンビ サービスは、関連付けられたメッセージを持たないサービスです。 BizTalk Server のゾンビ メッセージとサービス インスタンスの詳細については、「BizTalk Server のゾンビ」を参照してください。
PhysicalDisk パフォーマンス オブジェクトのパフォーマンス カウンターを監視します。
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 データベースの高可用性の詳細については、「 BizTalk Server データベースの高可用性の提供」を参照してください。
BizTalk Server データベースのベスト プラクティスに従います。 BizTalk Server データベースの管理に関するベスト プラクティスを参照してください。
BizTalk Server データベースのトラブルシューティング
BizTalk Server データベースに関する問題をトラブルシューティングするには、次のタスクを実行します。
必要なすべての BizTalk SQL Server エージェント ジョブが有効になっており、実行されていることを確認します。
MessageBox_Message_ManageRefCountLog_BizTalkMsgBoxDb ジョブを除くすべての BizTalk SQL Server エージェント ジョブを有効にし、正常に実行する必要があります。 他のジョブを無効にしないでください。
エラーが発生した場合は、SQL Server の View History オプションを使用してエラー情報を表示し、それに応じてエラーのトラブルシューティングを行います。 メッセージ ボックス _Message_ManageRefCountLog_BizTalkMsgBoxDb SQL Server エージェント ジョブは無限に実行されることを覚えておいてください。 そのため、ジョブ履歴がジョブの絶え間ない失敗と再起動を報告している場合に限って、心配する必要があります。MsgBoxViewer ツールを使用して、BizTalk MessageBox やその他のデータベースを分析します。
MsgBoxViewer ツールは、 BizTalk Health Monitor に含まれています。 MsgBoxViewer ツールは、テーブルのサイズと行数に関する詳細情報を含む HTML レポートを提供するため、トラブルシューティングに役立ちます。 このレポートは、BizTalk Server がスロットリングされているかどうかを判断するのにも役立ちます。 さらに、このツールは、BizTalk Server データベースと BizTalk Server 構成のスナップショットを提供します。
BizTalk Server の実行速度が通常よりも遅い場合は、MsgBoxViewer ツールを実行し、[ 省略可能な クエリ] タブですべてのクエリをクリックして選択し、生成された HTML レポートで問題がないかどうかを確認します。 [概要レポート] セクションには、警告が黄色で表示され、潜在的な問題が赤で一覧表示されます。
さらに、MsgBoxViewer ツールを使用して、どのテーブルが最も大きく、レコードが多いかを判断できます。 通常、大きなテーブルを拡大するテーブルの一覧と、それらのテーブルを管理する方法については、「 大きく成長する BizTalk Server データベース テーブル」を参照してください。
MsgBoxViewer ツールによって識別される問題がある場合は、ターミネータ ツールを使用して解決します。
ターミネータ ツールは、 BizTalk Health Monitor に含まれています。 このツールを使用すると、BizTalk MsgBoxViewer ツールで特定された問題を簡単に解決できます。
デッドロックのシナリオを調査します。
デッドロック シナリオでは、SQL Server で DBCC トレースを有効にして、デッドロック情報が SQLERROR ログに書き込まれるようにします。 SQL Server で、次のステートメントを実行して、デッドロック シナリオの DBCC トレースを有効にします。
DBCC TRACEON (1222,-1)PSSDIAG ユーティリティを使用して、 Lock:Deadlock イベントおよび Lock:DeadlockChain イベントのデータを収集することもできます。 詳細については、 PSSDIAG データ収集ユーティリティーを参照してください。
BizTalkMsgBoxDB データベースは、大量かつトランザクションの多いオンライン トランザクション処理 (OLTP) データベースです。 このようなデータベースでは、一部のデッドロックが予想され、このデッドロックは BizTalk Server エンジンによって内部的に処理されます。 この動作が発生すると、エラー ログにエラーが一覧表示されません。 デッドロック シナリオを調査する場合、出力で調査しているデッドロックは、イベント ログのデッドロック エラーと関連付ける必要があります。
ブロックされたプロセスを探します。
SQL Server のアクティビティ モニターを使用して、ロック システム プロセスのサーバー プロセス識別子 (SPID) を取得できます。 その後、SQL Profiler を実行して、ロック SPID で実行されている SQL ステートメントを特定できます。 PSSDIAG ユーティリティを使用して、SQL Server のロックとブロックの問題のトラブルシューティングを行うことができます。 このユーティリティは、ブロッキング スクリプトが有効になっているすべての Transact-SQL イベントをキャプチャします。 詳細については、PSSDIAG データ収集ユーティリティーを参照してください。
SQL Server では、 ブロックされたプロセスのしきい値 の設定を指定して、指定したしきい値より長くブロックしている SPID または SPID を決定できます。 ブロックされたプロセスしきい値オプションの詳細については、「 ブロックされたプロセスしきい値オプション」を参照してください。
SQL Server でロックまたはブロックの問題が発生した場合は、Microsoft カスタマー サポート サービスにお問い合わせください。
不要なデータをすべて削除します。
データベースのサイズが大きくなりすぎて、データベースに含まれるデータが不要になった場合は、データを削除することをお勧めします。 注意： データがビジネス クリティカルな環境や、データが必要な場合は、このメソッドを使用しないでください。
BizTalkMsgBox データベースを消去するには:
BizTalk Health Monitor に含まれているターミネータ ツールをダウンロードしてインストールします。
「テスト環境で MessageBox データベースからデータを手動で消去する方法」の手順に従って、BizTalk MessageBox データベースにbts_CleanupMsgboxストアド プロシージャを作成します。
ターミネータ ツールを使用して、bts_CleanupMsgbox ストアド プロシージャを実行し、BizTalk MessageBox データベースを消去します。
bts_CleanupMsgbox ストアド プロシージャは、データを削除します。 運用環境でこのストアド プロシージャを実行するときは注意してください。
すべてのホストと BizTalk Server サービスを再起動します。
BizTalkDTADb データベースを消去するには:
方法 1
- すべての BizTalk Server データベースをバックアップします。
- dtasp_PurgeAllCompletedTrackingData ストアド プロシージャを実行します。 ストアド プロシージャの詳細については、「 BizTalk 追跡データベースからデータを手動で消去する方法」を参照してください。
方法 2: BizTalkDTADb データベースに削除する必要がある不完全なインスタンスが多数含まれている場合にのみ、このオプションを使用します。
- すべての BizTalk Server データベースをバックアップします。
- すべての BizTalk ホスト、サービス、およびカスタム分離アダプターを停止します。 HTTP または SOAP アダプターを使用する場合は、IIS サービスを再起動します。
- BizTalkDTADb データベースで dtasp_CleanHMData ストアド プロシージャを実行します。
- すべてのホストと BizTalk Server サービスを再起動します。
追跡データが必要な場合は、BizTalkDTADb データベースをバックアップし、データベースを別の SQL Server に復元してから、元の BizTalkDTADb データベースを消去します。
MsgBoxViewer データまたは PSSDIAG 出力の分析に関するヘルプが必要な場合は、Microsoft カスタマー サポート サービスにお問い合わせください。 カスタマー サポート サービスに問い合わせる前に、MsgBoxViewer データ、PSSDIAG 出力、更新されたイベント ログ (.evt ファイル) を圧縮します。 これらのファイルを BizTalk Server サポート エンジニアに送信する必要がある場合があります。