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

[アーティクル]
07/21/2023

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

SQL Server の構成

手順	リファレンス
データベースファイルのディスク I/O 競合BizTalk Server監視して削減します。	- データとトランザクションログファイルが格納されているディスクのディスク I/O 使用率を事前に監視することをお勧めします。 - ディスク I/O 競合が問題になる可能性を減らすために、これらの各データファイルとトランザクションログファイルを専用ドライブに配置することをお勧めします。 - MessageBox and 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 MessageBox データベースの統計情報をSQL Serverします。 - データベースインデックスの再構築と最適化をSQL Serverします。	変更しない SQL Server の設定
SQL Serverのすべてのインスタンスのスタートアップパラメーターとしてトレースフラグ 1118 (TF1118) を有効にします。	TF1118 を実装すると、ほぼすべての単一ページ割り当てを削除することで、SQL Server インスタンス間の競合を減らすことができます。詳細については、Microsoft サポート技術情報の記事「tempdb データベースのコンカレンシーの機能強化」を参照してください。メモ： TF1118 の詳細については、「TF1118 に関する誤解」を参照してください。このリンクのコンテンツは Microsoft によって所有されておらず、Microsoft はコンテンツの正確性を保証するものではありません。
tempdb データベースを、BizTalk Serverで使用される各SQL Server インスタンス上の等しいサイズの複数のデータファイルに分割します。	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 インスタンスの "min server memory" オプションと "max server memory" オプションを設定して、SQL Serverに割り当てる固定量のメモリを指定することをお勧めします。この場合は、'min 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 マスターシークレットもホストしている場合は、エンタープライズシングル Sign-On サービスを実行するのに十分なメモリがあることを確認するために、この値を調整する必要がある場合があります。
BizTalk 追跡データベースのサイズを考慮する	- BizTalk Tracking (DTA) データベース内のメッセージのサイズを決定する場合は、メッセージのサイズと比較してメッセージコンテキストの平均サイズをメッセージサイズに追加します。 - BizTalk Tracking データベース内のメッセージのサイズを制限するには、昇格するプロパティの数を制限します。 - オーケストレーションデバッガーオプションが有効になっている場合は、オーケストレーション内の各図形の状態が BizTalk Tracking データベースに保存されていることを考慮してください。

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 Tracking データベースから古いデータをアーカイブおよび消去するため、制御できない状態に保たれます。これは、正常なBizTalk Server システムに不可欠です。詳細については、「追跡データの消去とアーカイブ」を参照してください。

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

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

ディザスターリカバリー SQL Serverログ配布の使用

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

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

手順	リファレンス
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 追跡データベースからデータを消去する」を参照してください。

次へ