チェックリスト: SQL Server の構成

2025-06-05

BizTalk Server 運用環境で使用するために SQL Server を準備するときに従う手順。

SQL Server の構成

ステップス	リファレンス
BizTalk Server データベースファイルのディスク I/O の競合を監視および削減します。	- データファイルとトランザクションログファイルを含むディスクのディスク I/O 使用率を事前に監視することをお勧めします。 - ディスク I/O の競合が問題になる可能性を減らすために、これらの各データファイルとトランザクションログファイルを専用ドライブに配置することをお勧めします。 - MessageBox および Tracking (DTA) データベースを分離し、異なる物理ディスク上のデータベースファイルとトランザクションログファイルを分離することで、ディスク I/O の競合を減らすことができます。詳細については、「データベース IO 競合の監視と削減」を参照してください。
SQL Server が適切に配置されたディスクパーティションに構成されていることを確認する	ディスクパーティションを適切に配置すると、待機時間が大幅に短縮され、SQL Server のパフォーマンスが向上し、BizTalk Server のパフォーマンスが向上する可能性があります。一方、配置されていないディスクパーティションは I/O のパフォーマンスに悪影響を及ぼし、SQL Server と BizTalk Server のパフォーマンスが低下する可能性があります。適切に配置されたディスクパーティションがパフォーマンスに与える影響の詳細については、「 SQL Server のディスクパーティションの配置のベストプラクティス」を参照してください。
SQL Server Profiler で監視するイベントを保持する	SQL Server プロファイラーでは、関心のあるイベントだけを監視できます。トレースが大きすぎる場合は、必要な情報に基づいてトレースをフィルター処理して、イベントデータのサブセットのみが収集されるようにすることができます。監視するイベントが多すぎると、サーバーと監視プロセスのオーバーヘッドが増え、トレースファイルやトレーステーブルが非常に大きくなる可能性があります。特に、監視プロセスを長期にわたって実行する場合はこの可能性が高くなります。
DTC ログファイルのディスク I/O の競合を監視して減らします。	DTC ログファイルディスク IO 競合の監視と削減
SQL Server データベースの高可用性を提供します。	データベースの可用性の計画
フェールオーバーシナリオについては、アクティブ/アクティブ SQL Server クラスターの構成を確認します。	フェールオーバーシナリオの SQL Server クラスター構成の確認とテスト
次の場合は、既定の構成設定を使用します。 - 並列処理の最大次数 (MDOP)。 - BizTalk Server メッセージボックスデータベースの SQL Server 統計。 - SQL Server データベースインデックスの再構築と最適化。	変更しない SQL Server の設定
SQL Server のすべてのインスタンスのスタートアップパラメーターとしてトレースフラグ 1118 (TF1118) を有効にします。	TF1118 を実装すると、ほぼすべての単一ページ割り当てを削除することで、SQL Server インスタンス間の競合を減らすことができます。詳細については、 tempdb データベースのコンカレンシーの機能強化に関するマイクロソフトサポート技術情報の記事を参照してください。手記： TF1118 の詳細については、 TF1118 に関する誤解を参照してください。このリンクのコンテンツは Microsoft が所有していないため、Microsoft はコンテンツの正確性を保証しません。
BizTalk Server で使用される各 SQL Server インスタンス上の同じサイズの複数のデータファイルに tempdb データベースを分割します。	tempdb に使用されるデータファイルのサイズが等しいことを確認します。 SQL Server で使用されるプロポーショナルフィルアルゴリズムはデータファイルのサイズに基づいているため、これは重要です。データファイルが等しくないサイズで作成された場合、プロポーショナルフィルアルゴリズムは、すべてのファイル間で割り当てを分散するのではなく、グローバル割り当てマップ (GAM) 割り当てに最大のファイルを使用するため、複数のデータファイルを作成する目的が失われます。一般的なガイドラインとして、サーバー上の CPU ごとに 1 つのデータファイルを作成し、必要に応じてファイルの数を上下に調整します。デュアルコア CPU は 2 つの CPU と見なされることに注意してください。どのような場合でも、コンピューターで使用可能な追加コアの数に関係なく、データファイルの数が 8 を超えてはなりません。 tempdb ファイルの詳細については、「 tempdb のパフォーマンスの最適化」を参照してください。
最小および最大サーバーメモリを、BizTalk Server データベースをホストする SQL Server インスタンス上の同じ値に設定します。	BizTalk Server データベースをホストする SQL Server を実行するコンピューターは、SQL Server の実行専用にする必要があります。 BizTalk Server データベースをホストする SQL Server を実行しているコンピューターが SQL Server の実行専用である場合は、SQL Server に割り当てる固定メモリ量を指定するために、各 SQL Server インスタンスの "最小サーバーメモリ" オプションと "max server memory" オプションを設定することをお勧めします。この場合は、"最小サーバーメモリ" と "max server memory" を同じ値 (SQL Server が使用する物理メモリの最大量と同じ) に設定する必要があります。これにより、SQL Server でこれらの値を動的に管理する場合に使用されるオーバーヘッドが軽減されます。 SQL Server を実行している各コンピューターで次の T-SQL コマンドを実行して、SQL Server に割り当てる固定メモリ量を指定します。 sp_configure 'Max Server memory (MB)',(max size in MB) sp_configure 'Min Server memory (MB)',(min size in MB) SQL Server のメモリ量を設定する前に、Windows Server に必要なメモリを物理メモリの合計から減算して、適切なメモリ設定を決定します。これは、SQL Server に割り当てることができるメモリの最大量です。手記： BizTalk Server データベースをホストする SQL Server を実行しているコンピューターで、「マスターシークレットサーバーのクラスタリング」の説明に従って Enterprise Single Sign-On マスターシークレットもホストしている場合は、この値を調整して、Enterprise Single Sign-On Service を実行するための十分なメモリを確保する必要があります。
BizTalk 追跡データベースのサイズを考慮する	- BizTalk Tracking (DTA) データベース内のメッセージのサイズを決定する場合は、メッセージコンテキストの平均サイズをメッセージサイズに追加します (メッセージサイズと比較して大きい場合)。 - メッセージのサイズを BizTalk Tracking データベース内で制限するには、昇格するプロパティの数を制限します。 - オーケストレーションデバッガーオプションが有効になっている場合は、オーケストレーション内の各図形の状態が BizTalk 追跡データベースに保存されていることを考慮してください。

SQL Server のメンテナンス手順の実行

ステップス	リファレンス
BizTalk Server データベースの自動拡張設定を定義します。	- データベースの自動拡張は、特に MessageBox データベースと Tracking データベースの場合、パーセンテージではなく、固定のメガバイト数に設定する必要があります。 BizTalk Server アプリケーションとスループットによっては、MessageBox データベースと Tracking データベースが非常に大きくなる場合があります。自動拡張がパーセンテージに設定されている場合、自動拡張も同様に大きくなります。 - ファイルの瞬時初期化により、ファイル拡張操作のパフォーマンスへの影響を大幅に軽減できます。 - 理想的には、ファイルグループをサポートするファイルのサイズを事前に割り当て、可能であれば静的サイズに設定する必要があります。詳細については、「データベースの自動拡張設定の定義」を参照してください。
BizTalk Server データベースをバックアップする	- BizTalk Server データベーストランザクションログが無制限に増加しないように、BizTalk Server バックアップジョブを実行することをお勧めします。 - BizTalk Server 環境全体を定期的に復元し、プロセスを慎重に文書化する必要があります。 - 古いバックアップファイルをアーカイブすることをお勧めします。詳細については、「データベースのバックアップ」を参照してください。
BizTalk Server SQL エージェントジョブを監視します。	これらのジョブの正常性を監視し、エラーなしで実行されていることを確認します。詳細については、「 SQL Server エージェントジョブの監視」を参照してください。
BizTalk Server の追跡とアーカイブを有効にする	「DTA 消去とアーカイブ」SQL エージェントジョブは、BizTalk 追跡データベースから古いデータをアーカイブおよび消去し、その成長を制御できない状態になるのを防ぎます。これは、正常な BizTalk Server システムに不可欠です。詳細については、「追跡データの消去とアーカイブ」を参照してください。

BizTalk Server データベースのバックアップ

ステップス	リファレンス
バックアップ BizTalk Server SQL エージェントジョブが構成されていることを確認します。	「バックアップ BizTalk Server ジョブの構成」を参照してください
@DaysToKeep変数で指定された日数より古いバックアップファイルを削除するように、BizTalk Server SQL エージェントのバックアップジョブを構成します。バックアップファイルが削除されていない場合は、時間の経過とともに無制限に拡張され、バックアップファイルを含むディスクがいっぱいになり、限られたディスク領域に関連する問題が発生する可能性があります。	「バックアップ BizTalk Server ジョブの構成」を参照してください
バックアップ BizTalk Server SQL エージェントジョブが有効で実行されていることを確認します。	SQL Server エージェントジョブの監視

ディザスターリカバリーに SQL Server ログ配布を使用する

ステップス	リファレンス
ディザスターリカバリーサーバーに運用環境の負荷を処理する容量があることを確認します。	ディザスターリカバリーのための BizTalk Server ログ配布の使用を参照してください
ディザスターリカバリールーチンの詳細が十分に文書化されていることを確認します。	ディザスターリカバリーのための BizTalk Server ログ配布の使用を参照してください
定期的なテストの一環として、特に新しい BizTalk アプリケーションが運用環境に配置されるため、ディザスターリカバリーサイトへのフェールオーバーを練習します。	ディザスターリカバリーのための BizTalk Server ログ配布の使用を参照してください

BizTalk Server SQL エージェントジョブの監視

ステップス	リファレンス
SQL Server エージェントサービスが実行されていることを確認します。	SQL Server エージェントジョブの監視を参照してください
BizTalk Server によってインストールされた SQL Server エージェントジョブが有効になっており、正常に実行されていることを確認します。	SQL Server エージェントジョブの監視を参照してください
BizTalk Server SQL エージェントジョブがタイムリーに完了していることを確認します。	SQL Server エージェントジョブの監視を参照してください

追跡データの消去とアーカイブ

ステップス	リファレンス
SQL エージェントジョブ "DTA Purge and Archive" が正しく構成され、有効になり、正常に完了していることを確認します。	DTA 消去ジョブとアーカイブジョブの構成を参照してください。
受信追跡データが生成されるのと同じ速度で、ジョブが追跡データを消去できることを確認します。	「持続可能な追跡の最大スループットの測定」を参照してください
論理的な消去とハード消去のパラメーターを確認して、データを最適な期間保持していることを確認します。	BizTalk 追跡データベースのアーカイブと消去を参照してください。
古いデータを消去するだけで済み、最初にアーカイブする必要がない場合は、ストアドプロシージャ "dtasp_PurgeTrackingDatabase" を呼び出す SQL エージェントジョブを変更します。	BizTalk 追跡データベースからのデータの消去を参照してください。

次へ