チェックリスト: BizTalk Server のメンテナンスとトラブルシューティング

BizTalk Serverデータベースとその正常性は、BizTalk Serverデータベース メッセージング環境を成功させるために非常に重要です。 このトピックでは、BizTalk Server データベースの保守またはトラブルシューティングを行うときに従う必要がある手順を示します。

• BizTalk Server データベースのメンテナンス

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

BizTalk Server データベースのメンテナンス

• [統計の自動更新] オプションと [統計の自動作成] オプションを無効にします (BizTalk Server MessageBox データベースにのみ適用されます)。 既定では、これらの設定は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 の値に設定します。 [並列処理の最大次数] 設定をチェックするには、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 MessageBox データベースのサイズは、通常、約 5 GB 以下にする必要があります。 BizTalkMsgBoxDb データベースはデータを保持しないようにし、データが処理されるか BizTalkDTADb データベースに移動されるまでバッファーと見なす必要があります。 強力なSQL Server バックエンドと多数の長時間実行されるオーケストレーションを備えた環境では、5 GB を超える BizTalkMsgBoxDb データベースを使用できます。 実行時間の長いオーケストレーションがないボリュームの高い環境では、5 GB よりもはるかに小さいBizTalk Server MessageBox データベースを使用する必要があります。

  BizTalk Server追跡データベースのサイズは大きく異なる場合がありますが、クエリのパフォーマンスが大幅に低下すると、追跡データベースが大きすぎる可能性があります。 経験則として、15 から 20 GB を超えるBizTalk Server追跡データベースは大きすぎると見なされ、パフォーマンスに悪影響を与える可能性があります。

  次の問題は、大きすぎるBizTalk Serverデータベースに起因する可能性があります。

  • BizTalk Server MessageBox データベースは引き続き拡大しますが、データ サイズ (ログ ファイルだけでなく) は大きいままです。 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 MessageBox データベースから BizTalk Server 追跡データベースに移動します。 ホスト追跡を許可するオプションを使用して構成されているBizTalk Serverホストがない場合、または追跡ホストが停止している場合、TDDS は実行されず、BizTalk Server MessageBox データベース内のTrackingData_x_x テーブルはオフになります。

  そのため、専用のBizTalk Server ホストを [ホストの追跡を許可する] オプションを使用して構成する必要があります。 専用追跡ホストの構成の詳細については、「専用追跡ホスト の構成」を参照してください。

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

• 正しい BizTalk SQL Server エージェント ジョブを使用します。

  BizTalk Server データベースを管理し、最適なパフォーマンスを維持するには、BizTalk Server SQL エージェント ジョブの実行が重要です。

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

    SQL Agent Backup 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 での SQL Server エージェント ジョブの説明

• 中断されたインスタンスを監視して終了します。

  サービス インスタンスは、中断 (再開可能) または中断 (再開不可) できます。 これらのサービス インスタンスには、メッセージング、オーケストレーション、またはポートがあります。 BizTalk Serverでは、BizTalk Server管理コンソールの [グループ ハブ] ページを使用するか、Terminate.vbs スクリプトを使用して、これらのインスタンスの終了と削除を行うことができます。 Terminate.vbs スクリプトの詳細については、「 中断されたサービス インスタンスの削除」を参照してください。

  ターミネータ ツールを使用して、中断されたインスタンスを削除することもできます。 ターミネータ ツールは、BizTalk ヘルス モニターに含まれています。

  "orphans" と "ゾンビ" という用語は、多くの場合、同じ意味で使用されます。 孤立したメッセージまたはゾンビ メッセージは、関連付けられたサービス インスタンスを持たないメッセージです。通常は、メッセージを受信する前にサービス インスタンスが終了したためです。 孤立したサービスまたはゾンビ サービスは、関連付けられたメッセージを持たないサービスです。 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の [履歴の表示] オプションを使用してエラー情報を表示し、それに応じてエラーのトラブルシューティングを行います。 MessageBox _Message_ManageRefCountLog_BizTalkMsgBoxDb SQL Server エージェント ジョブは無限に実行されます。 したがって、ジョブ履歴でジョブが常に失敗して再起動することが報告される場合にのみ、心配する必要があります。

• MsgBoxViewer ツールを使用して、BizTalk MessageBox およびその他のデータベースを分析します。

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

  BizTalk Serverの実行速度が通常よりも遅い場合は、MsgBoxViewer ツールを実行し、[オプション のクエリ] タブですべてのクエリをクリックして選択し、生成された HTML レポートで問題がないか確認します。 [ 概要レポート] セクションには、警告が黄色で表示され、潜在的な問題が赤で一覧表示されます。

  さらに、MsgBoxViewer ツールを使用して、どのテーブルが最も大きく、レコードが最も多いかを判断できます。 通常、大きなテーブルを拡張するテーブルの一覧と、それらのテーブルを管理する方法については、「大きく成長するBizTalk Server データベース テーブル」を参照してください。

• MsgBoxViewer ツールによって識別される問題がある場合は、ターミネータ ツールを使用して解決します。

  ターミネータ ツールは、BizTalk ヘルス モニターに含まれています。 このツールを使用すると、BizTalk MsgBoxViewer ツールで特定された問題を簡単に解決できます。

• デッドロックのシナリオを調査します。

  デッドロック シナリオでは、デッドロック情報が SQLERROR ログに書き込まれるように、SQL Serverで DBCC トレースを有効にします。 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 データベースを消去するには:

  1. BizTalk ヘルス モニターに含まれているターミネータ ツールをダウンロードしてインストールします。

  2. 「テスト環境で MessageBox データベースからデータを手動で消去する方法」トピックの手順に従って、BizTalk MessageBox データベースにbts_CleanupMsgboxストアド プロシージャを作成します。

  3. ターミネータ ツールを使用して、bts_CleanupMsgbox ストアド プロシージャを実行し、BizTalk MessageBox データベースを消去します。

     bts_CleanupMsgbox ストアド プロシージャはデータを削除します。 運用環境でこのストアド プロシージャを実行する場合は注意してください。

  4. すべてのホストとBizTalk Server サービスを再起動します。

  BizTalkDTADb データベースを消去するには:

  • 方法 1

    1. すべてのBizTalk Server データベースをバックアップします。
    2. dtasp_PurgeAllCompletedTrackingData ストアド プロシージャを実行します。 ストアド プロシージャの詳細については、「 BizTalk 追跡データベースからデータを手動で消去する方法」を参照してください。

  • 方法 2: BizTalkDTADb データベースに削除する必要がある不完全なインスタンスが多数含まれている場合にのみ、このオプションを使用します。

    1. すべてのBizTalk Server データベースをバックアップします。
    2. すべての BizTalk ホスト、サービス、およびカスタム分離アダプターを停止します。 HTTP または SOAP アダプターを使用する場合は、IIS サービスを再起動します。
    3. BizTalkDTADb データベースで dtasp_CleanHMData ストアド プロシージャを実行します。
    4. すべてのホストとBizTalk Server サービスを再起動します。

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

MsgBoxViewer データまたは PSSDIAG 出力の分析に関するヘルプが必要な場合は、Microsoft カスタマー サポート サービスにお問い合わせください。 カスタマー サポート サービスに問い合わせる前に、MsgBoxViewer データ、PSSDIAG 出力、および更新されたイベント ログ (.evt ファイル) を圧縮します。 これらのファイルは、BizTalk Server サポート エンジニアに送信する必要がある場合があります。

次へ

• BizTalk Server データベースを保守する場合のベスト プラクティス

• BizTalk Server データベース テーブルの大規模な成長

• トラブルシューティング用のツールとユーティリティ

参照

変更しない SQL Server の設定