SQL Server の設計に関する考慮事項

System Center Operations Manager では、運用、データ ウェアハウス、ACS 監査データベースをサポートするために、Microsoft SQL Server を実行しているサーバーのインスタンスにアクセスする必要があります。 運用データベースとデータ ウェアハウス データベースは、管理グループに最初の管理サーバーを展開するときに必要であり、作成されますが、ACS データベースは管理グループに ACS コレクターを展開するときに作成されます。

ラボ環境または Operations Manager の小規模な展開では、SQL Server を管理グループの最初の管理サーバーに併置できます。

中規模からエンタープライズ規模の分散展開では、SQL Server インスタンスは専用のスタンドアロン サーバーまたは SQL Server の高可用性構成に配置する必要があります。 どちらの場合も、SQL Server は既に存在している必要があり、最初の管理サーバーまたは ACS コレクターのインストールを開始する前にアクセス可能です。

他のアプリケーション データベースを含む SQL インスタンスから Operations Manager データベースを使用することはお勧めしません。 これは、I/O やその他のハードウェア リソース制限に関する潜在的な問題を回避するためです。

重要

Operations Manager では、Azure SQL Managed Instance や Amazon Relational Database Service (AWS RDS) などの製品を含む、SQL のサービスとしてのプラットフォーム (PaaS) インスタンスはサポートされていません。 Windows マシンにインストールされている SQL Server のインスタンスを使用してください。 唯一の例外は、Azure SQL MI を利用する Azure Monitor SCOM Managed Instance 内であり、再構成できません。

SQL Server 要件

Reporting Server、Operational、Data Warehouse、ACS データベースをホストする System Center Operations Manager バージョンの既存のインストールでは、次のバージョンの SQL Server Enterprise および Standard Edition がサポートされています。

• SQL Server 2022

• 累積的な更新プログラム 8 (CU8) 以降 が含まれた SQL Server 2019 (こちら)

  Note

  • Operations Manager 2022 では、CU8 以降の SQL 2019 がサポートされます。ただし、SQL 2019 RTM はサポートされていません。
  • ODBC 17.3 または 17.10.6、および MSOLEDBSQL 18.2 または 18.7.2 を使用します。

• SQL Server 2017 と累積的な更新プログラム (詳細はこちら)

SQL Server をアップグレードする前に、2017 のアップグレード情報と SQL 2019 のアップグレード情報を参照してください。

Note

• SCOM インフラストラクチャをサポートする次の各 SQL Server コンポーネントは、同じ SQL Server メジャー バージョンである必要があります。
  • SCOM データベース (つまり、OperationManager、OperationManagerDW、SSRS データベース ReportServer & ReportServerTempDB) をホストする SQL Server データベース エンジン インスタンス。
  • SQL Server Reporting Services (SSRS) インスタンス。
• SQL Server 照合順序の設定は、後述の「SQL Server 照合順序設定」セクションで説明するように、サポートされている型のいずれかである必要があります。
• SQL Server フル テキスト検索は、SCOM データベースをホストするすべての SQL Server データベース エンジン インスタンスに必要です。
• Operations Manager データベース コンポーネントでサポートされる Windows Server 2016 インストール オプション (Server Core、デスクトップ エクスペリエンス搭載サーバー、Nano Server) は、SQL Server でサポートされる Windows Server のインストール オプションに基づいています。

Note

System Center Operations Manager レポートは、以前のバージョンのレポート ロール と並べてインストールすることはできません。また、ネイティブ モードでのみインストールする必要があります (SharePoint 統合モードはサポートされていません)。

設計計画には、ハードウェアとソフトウェアに関するその他の考慮事項が適用されます。

• NTFS ファイル形式のコンピューターで SQL Server を実行することをお勧めします。
• 運用およびデータ ウェアハウス データベースには、少なくとも 1024 MB の空きディスク領域が必要です。 これはデータベースの作成時に適用され、セットアップ後に大幅に拡大する可能性があります。
• .NET Framework 4 が必要です。
• .NET Framework 4.8 は Operations Manager 2022 よりサポートされています。
• レポート サーバーは、Windows Server Core ではサポートされていません。

詳細については、「SQL Server のインストールに必要なハードウェアおよびソフトウェア」を参照してください。

Note

Operations Manager ではインストール中にWindows 認証のみを使用しますが、ローカル アカウントに db_owner ロールがない場合でも、SQL 混合モード認証設定は引き続き機能します。 db_ownerロールを持つローカル アカウントは、System Center Operations Manager で問題を引き起こすことがわかっています。 製品をインストールする前に、すべてのローカル アカウントから db_owner ロールを削除し、インストール後に db_owner ロールをローカル アカウントに追加しないでください。

SQL Server 照合順序の設定

System Center Operations Manager では、次の SQL Server 照合順序と Windows 照合順序がサポートされています。

Note

操作の比較またはコピーの互換性の問題を回避するために、SQL と Operations Manager DB に同じ照合順序を使用することをお勧めします。

SQL Server の照合順序

• SQL_Latin1_General_CP1_CI_AS

[Windows 照合順序]

• Latin1_General_100_CI_AS
• French_CI_AS
• French_100_CI_AS
• Cyrillic_General_CI_AS
• Chinese_PRC_CI_AS
• Chinese_Simplified_Pinyin_100_CI_AS
• Chinese_Traditional_Stroke_Count_100_CI_AS
• Japanese_CI_AS
• Japanese_XJIS_100_CI_AS
• Traditional_Spanish_CI_AS
• Modern_Spanish_100_CI_AS
• Latin1_General_CI_AS
• Cyrillic_General_100_CI_AS
• Korean_100_CI_AS
• Czech_100_CI_AS
• Hungarian_100_CI_AS
• Polish_100_CI_AS
• Finnish_Swedish_100_CI_AS

前述のサポートされている照合順序のいずれかで SQL Server インスタンスが構成されていない場合、Operations Manager セットアップの新しいセットアップの実行は失敗します。 ただし、インプレース アップグレードは正常に完了します。

ファイアウォールの構成

Operations Manager は、SQL Server に依存してデータベースをホストし、履歴の運用データを分析して表示するレポート プラットフォームを提供します。 管理サーバー、操作、および Web コンソールの役割は、SQL Server と正常に通信できる必要があります。また、環境を正しく構成するには、通信パスとポートを理解することが重要です。

Operations Manager データベースのフェールオーバー機能を提供するために SQL Always On 可用性グループを必要とする分散デプロイを設計する場合は、ファイアウォールのセキュリティ戦略に追加のファイアウォール構成設定を含める必要があります。

次の表は、Operations Manager 管理グループのサーバー ロールが正常に通信するために、少なくとも許可する必要がある SQL Server に必要なファイアウォール ポートを特定するのに役立ちます。

シナリオ	ポート	方向	Operations Manager ロール
Operations Manager データベースをホストする SQL Server	TCP 1433 *	受信	管理サーバーと Web コンソール (Application Advisor およびアプリケーション診断用)
SQL Server Browser サービス	UDP 1434	受信	Management サーバー
SQL Server 専用管理者接続	TCP 1434	受信	Management サーバー
SQL Server で使用される追加のポート - Microsoft リモート プロシージャ コール (MS RPC) - Windows Management Instrumentation (WMI) - Microsoft 分散トランザクション コーディネーター (MS DTC)	TCP 135	受信	Management サーバー
SQL Server Always On 可用性グループ リスナー	管理者が構成したポート	受信	Management サーバー
Operations Manager Reporting Server をホストする SQL Server Reporting Services	TCP 80 (既定値)/443 (SSL)	受信	管理サーバーとオペレーション コンソール

* TCP 1433 はデータベース エンジンの既定インスタンスの標準ポートです。スタンドアロン SQL Server で名前付きインスタンスを作成する場合、あるいは SQL Always On 可用性グループを展開している場合、カスタム ポートが定義されます。ファイアウォールを正しく構成し、設定時にこの情報を入力するために、このカスタム ポートを参照用に記録します。

SQL Server のファイアウォール要件の詳細については、「SQL Server アクセスを許可するように Windows ファイアウォールを構成する」を参照してください。

容量とストレージに関する考慮事項

Operations Manager データベース

Operations Manager データベースは、日常的な監視に Operations Manager で必要なすべてのデータを含む SQL Server データベースです。 データベース サーバーのサイズ設定と構成は、管理グループの全体的なパフォーマンスにとって重要です。 Operations Manager データベースで使用される最も重要なリソースはストレージ サブシステムですが、CPU と RAM も重要です。

Operations Manager データベースの負荷に影響を与える要因は次のとおりです。

• 運用データの収集率。 運用データは、エージェントによって収集されたすべてのイベント、アラート、状態の変更、およびパフォーマンス データで構成されます。 Operations Manager データベースで使用されるリソースのほとんどは、システムに入ってくると、このデータをディスクに書き込むのに使用されます。 追加の管理パックがインポートされ、追加のエージェントが追加されると、収集される運用データの割合が増加する傾向があります。 エージェントが監視しているコンピューターの種類も、運用データ収集の全体的な速度を決定するときに使用される重要な要素です。 たとえば、ビジネスクリティカルなデスクトップ コンピューターを監視しているエージェントは、多数のデータベースを持つ SQL Server のインスタンスを実行しているサーバーを監視するエージェントよりも収集するデータが少ないと予想できます。
• インスタンス領域の変更率。 Operations Manager データベースでこのデータを更新すると、新しい運用データの書き込みに比べてコストがかかります。 さらに、インスタンス領域データが変更されると、管理サーバーは、構成とグループの変更を計算するために Operations Manager データベースに対して追加のクエリを実行します。 追加の管理パックを管理グループにインポートすると、インスタンス領域の変更率が増加します。 管理グループに新しいエージェントを追加すると、インスタンス領域の変更率も一時的に増加します。
• 同時に実行されているオペレーション コンソールとその他の SDK 接続の数。 各オペレーション コンソールは、Operations Manager データベースからデータを読み取ります。 このデータのクエリを実行すると、大量のストレージ I/O リソース、CPU 時間、RAM が消費される可能性があります。 イベント ビュー、状態ビュー、アラート ビュー、パフォーマンス データ ビューに大量の操作データを表示するオペレーション コンソールでは、データベースの負荷が最も大きくなる傾向があります。

Operations Manager データベースは管理グループの単一障害原因であるため、SQL Server Always On 可用性グループやフェールオーバー クラスター インスタンスなどのサポートされているフェールオーバー構成を使用して高可用性を実現できます。

構成後に変更を加えることなく、既存の SQL Always-On セットアップを使用して Operations Manager データベースを設定およびアップグレードできます。

Operations Manager データベースで SQL Broker を有効にする

System Center Operations Manager は、すべてのタスク操作を実装するために SQL Server Service Broker に依存します。 SQL Server Service Broker が無効になっている場合、すべてのタスク操作が影響を受けます。 結果の動作は、開始されるタスクによって異なる場合があります。 そのため、System Center Operations Manager のタスクで予期しない動作が発生した場合は常に、SQL Server Service Broker の状態を確認することが重要です。

SQL Server Service Broker を有効にするには、次の手順に従います。

1. SQL クエリ を実行します。

   SELECT is_broker_enabled FROM sys.databases WHERE name='OperationsManager'
   

2. フィールドに表示is_broker_enabledされる値が 1 (1) の場合は、この手順をスキップします。 それ以外の場合は、次の SQL クエリを実行します。

   ALTER DATABASE OperationsManager SET SINGLE_USER WITH ROLLBACK IMMEDIATE
   ALTER DATABASE OperationsManager SET ENABLE_BROKER
   ALTER DATABASE OperationsManager SET MULTI_USER
   

Operations Manager データ ウェアハウス データベース

System Center - Operations Manager は、ほぼリアルタイムでレポート データ ウェアハウスにデータを挿入します。このサーバーには、レポート データ ウェアハウスに収集されるすべてのデータの書き込みをサポートする十分な容量が必要です。 Operations Manager データベースと同様に、レポート データ ウェアハウスの最も重要なリソースはストレージ I/O サブシステムです。 ほとんどのシステムでは、レポート データ ウェアハウスの負荷は Operations Manager データベースに似ていますが、異なる場合があります。 さらに、レポートによってレポート データ ウェアハウスに配置されるワークロードは、Operations Manager データベースに対するオペレーション コンソールの使用状況による負荷とは異なります。

レポート データ ウェアハウスの負荷に影響を与える要因は次のとおりです。

• 運用データの収集率。 より効率的なレポート作成を可能にするために、レポート データ ウェアハウスは、限られた量の生データに加えて集計データを計算して格納します。 この追加の作業を行うと、レポート データ ウェアハウスへの運用データ収集のコストが Operations Manager データベースよりも若干高くなります。 通常、この追加コストは、レポート データ ウェアハウスと Operations Manager データベースによる検出データの処理コストの削減によってバランスが取られます。
• 同時レポート ユーザーまたはスケジュールされたレポート生成の数。 レポートは大量のデータを要約する場合が多いため、各レポート ユーザーはシステムに大きな負荷を加えることができます。 同時に実行されるレポートの数と実行されるレポートの種類は、両方とも全体的な容量のニーズに影響します。 一般に、大きな日付範囲または多数のオブジェクトに対してクエリを実行するレポートには、追加のシステム リソースが必要です。

これらの要因に基づいて、レポート データ ウェアハウスのサイズを設定するときに考慮すべきいくつかの推奨プラクティスがあります。

• 適切なストレージ サブシステムを選択します。 レポート データ ウェアハウスは管理グループ全体のデータ フローに不可欠な部分であるため、レポート データ ウェアハウスに適したストレージ サブシステムを選択することが重要です。 Operations Manager データベースと同様に、多くの場合、RAID 0 + 1 が最適な選択肢です。 一般に、レポート データ ウェアハウスのストレージ サブシステムは、Operations Manager データベースのストレージ サブシステムに似ている必要があります。また、Operations Manager データベースに適用されるガイダンスは、レポート データ ウェアハウスにも適用されます。
• データ ログとトランザクション ログの適切な配置を検討してください。 Operations Manager データベースに関しては、多くの場合、エージェントの数をスケールアップするときに、SQL データとトランザクション ログを分離することが適切な選択肢です。 Operations Manager データベースとレポート データ ウェアハウスの両方が同じサーバー上にあり、データとトランザクション ログを分離する場合は、レポート データ ウェアハウスとは別の物理ボリュームとディスク スピンドルに Operations Manager データベースのトランザクション ログを配置して、メリットを得る必要があります。 Operations Manager データベースとレポート データ ウェアハウスのデータ ファイルは、ボリュームが十分な容量を提供し、ディスク I/O パフォーマンスが監視およびレポート機能に悪影響を与えない限り、同じ物理ボリュームを共有できます。
• Operations Manager データベースとは別のサーバーにレポート データ ウェアハウスを配置することを検討してください。 小規模な展開では、多くの場合、Operations Manager データベースと Reporting データ ウェアハウスを同じサーバーに統合できますが、エージェントの数と受信操作データの量をスケールアップするときに、それらを分離すると便利です。 レポート データ ウェアハウスとレポート サーバーが Operations Manager データベースとは別のサーバー上にある場合、レポートのパフォーマンスが向上します。

Operations Manager データ ウェアハウス データベースは、管理グループの単一障害原因であるため、SQL Server Always On 可用性グループやフェールオーバー クラスター インスタンスなどのサポートされているフェールオーバー構成を使用して高可用性を実現できます。

SQL Server AlwaysOn

SQL Server Always On 可用性グループは、個別のユーザー データベース (可用性データベース) のフェールオーバー環境をサポートします。 可用性データベースの各セットは、可用性レプリカによりホストされます。

System Center 2016 以降 - Operations Manager では、データベースの高可用性を実現するために、フェールオーバー クラスタリングよりも SQL Always On が推奨されます。 ネイティブ モードの Reporting Services インストールを除くすべてのデータベースは、2 つのデータベースを使用して永続データ ストレージを一時ストレージ要件から分離し、AlwaysOn 可用性グループでホストできます。

Operations Manager 2022 では、構成後に変更を加えることなく、既存の SQL Always-On セットアップを使用して Operations Manager データベースを設定およびアップグレードできます。

可用性グループを設定するには、Windows Server フェールオーバー クラスタリング (WSFC) クラスターをデプロイして可用性レプリカをホストし、クラスター ノードで Always On を有効にする必要があります。 その後、Operations Manager SQL Server データベースを可用性データベースとして追加できます。

• Always On の前提条件の詳細を 確認します。
• Always On 可用性グループの WSFC の設定の詳細 について説明します。
• 可用性グループの設定について詳しくは、こちらをご覧ください。

Note

SQL Always On に参加している SQL サーバー ノードに Operations Manager をデプロイした後、CLR の厳密なセキュリティを有効にするには、各 Operations Manager データベースで SQL スクリプトを実行します。

Multisubnet 文字列

Operations Manager では、接続文字列キーワード (MultiSubnetFailover=True) はサポートされていません。 可用性グループには、クロスサイト フェールオーバー構成で展開する場合など、異なるサブネットの複数の IP アドレスに応じてリスナー名 (WSFC クラスター マネージャーのネットワーク名またはクライアント アクセス ポイントと呼ばれます) があるため、管理サーバーから可用性グループ リスナーへのクライアント接続要求は接続タイムアウトに達します。

マルチサブネット環境の可用性グループにサーバー ノードをデプロイした場合に、この制限を回避するために推奨される方法は、次の操作です。

1. 可用性グループ リスナーのネットワーク名を、DNS に 1 つのアクティブな IP アドレスのみを登録するように設定します。
2. 登録済みの DNS レコードに低い TTL 値を使用するようにクラスターを構成します。

これらの設定を使用すると、別のサブネット内のノードにフェールオーバーするときに、新しい IP アドレスを使用したクラスター名の迅速な復旧と解決が可能になります。

いずれかの SQL ノードで次の PowerShell コマンドを実行して、その設定を変更します。

Import-Module FailoverClusters
Get-ClusterResource "Cluster Name"|Set-ClusterParameter RegisterAllProvidersIP 0
Get-ClusterResource "Cluster Name"|Set-ClusterParameter HostRecordTTL 300
Stop-ClusterResource "Cluster Name"
Start-ClusterResource "Cluster Name"
Start-ClusterGroup "Cluster Name"

リスナー名で Always On を使用している場合は、リスナーでこれらの構成を変更する必要もあります。 可用性グループ リスナーの構成の詳細については、「可用性グループ リスナーの構成 - SQL Server Always On」のドキュメント を参照してください。

リスナーを現在ホストしている SQL ノードで次の PowerShell コマンドを実行して、その設定を変更します。

Import-Module FailoverClusters
Get-ClusterResource <Listener Cluster Resource name> | Set-ClusterParameter RegisterAllProvidersIP 0
Get-ClusterResource <Listener Cluster Resource name> | Set-ClusterParameter HostRecordTTL 300
Stop-ClusterResource <Listener Cluster Resource name>
Start-ClusterResource <Listener Cluster Resource name>
Start-ClusterGroup <Listener Cluster Group name>

高可用性のためにクラスター化または Always On SQL インスタンスを使用する場合は、ノード間のフェールオーバーが発生するたびに Operations Manager データ アクセス サービスが再起動されないように、管理サーバーで自動復旧機能を有効にする必要があります。 これを構成する方法については、次の KB 記事 を参照してください。System Center Management サービスは、SQL Server のインスタンスがオフラインになった後に応答を停止します。

SQL Server の最適化

一般に、お客様との以前のデプロイエクスペリエンスでは、パフォーマンスの問題は、通常、SQL Server 自体でのリソース使用率 (つまり、プロセッサまたはメモリ) が高い場合には発生しないことが示されています。むしろ、ストレージ サブシステムの構成に直接関連します。 パフォーマンスのボトルネックは、一般に、SQL Server データベース インスタンス用にプロビジョニングされたストレージで推奨される構成ガイダンスに従っていない場合に発生します。 次に例を示します。

• Operations Manager の IO 要件をサポートするために LUN に対するスピンドルの割り当てが不十分です。
• 同じボリューム上のトランザクション ログとデータベース ファイルをホストします。 これら 2 つのワークロードには、IO と待機時間の特性が異なります。
• TempDB の構成は、配置、サイズ設定などについて正しくありません。
• データベース トランザクション ログ、データベース ファイル、および TempDB をホストするボリュームのディスク パーティションの位置が正しく配置されなかっています。
• データベースおよびトランザクション ログ ファイルに AUTOGROW を使用する、クエリの並列処理用の MAXDOP 設定、CPU コアごとに複数の TempDB データ ファイルを作成するなど、基本的な SQL Server 構成を見落とします。

記憶域の構成は、Operations Manager の SQL Server 展開にとって重要なコンポーネントの 1 つです。 データベース サーバーは、厳密なデータベース読み取り/書き込みアクティビティとトランザクション ログ処理により、I/O が頻繁にバインドされる傾向があります。 Operations Manager の I/O 動作パターンは、通常、80% の書き込みと 20% の読み取りです。 その結果、I/O サブシステムを不適切に構成すると、SQL Server システムのパフォーマンスと動作が低下し、Operations Manager で顕著になる可能性があります。

SQL Server をデプロイする前に IO サブシステムのスループット テストを実行して、SQL Server の設計をテストすることが重要です。 これらのテストで、許容可能な待機時間で IO 要件を達成できることを確認します。 Diskspd ユーティリティを使用して、SQL Server をサポートするストレージ サブシステムの I/O 容量を評価します。 次のブログ記事は、製品グループのファイル サーバー チームのメンバーによって作成され、PowerShell コードでこのツールを使用してストレス テストを実行し、PerfMon を使用して結果をキャプチャする方法に関する詳細なガイダンスと推奨事項を提供します。 Operations Manager のサイズ測定ヘルパーも最初のガイダンスとして参照できます。

NTFS アロケーション ユニット のサイズ

ボリュームの配置 (一般にセクターアラインメントと呼ばれます) は、RAID デバイスでボリュームが作成されるたびに、ファイル システム (NTFS) で実行する必要があります。 これを行わないと、パフォーマンスが大幅に低下する可能性があり、最も一般的には、ストライプ ユニットの境界によるパーティションの不整合の結果です。 また、ハードウェア キャッシュの配置が間違いになり、配列キャッシュが非効率的に使用される可能性もあります。 SQL Server データ ファイルに使用されるパーティションを書式設定するときは、データ、ログ、tempdb に 64 KB のアロケーション ユニット サイズ (つまり、65,536 バイト) を使用することをお勧めします。 ただし、4 KB を超える割り当てユニット サイズを使用すると、ボリュームで NTFS 圧縮を使用できなくなることに注意してください。 SQL Server では圧縮ボリューム上の読み取り専用データがサポートされていますが、推奨されません。

メモリを予約する

Note

このセクションの情報の多くは、ブログ投稿 の Jonathan Kehayias から取得しています。SQL Server で実際に必要なメモリ量はどのくらいですか?(sqlskills.com)。

System Center Operations Manager (またはこの製品以外の他のワークロード) をサポートするために SQL Server に割り当てる物理メモリとプロセッサの適切な量を特定することは必ずしも簡単ではありません。 製品グループによって提供されるサイズ変更計算ツールは、ワークロードのスケールに基づくガイダンスを提供しますが、その推奨事項は、実際のワークロードと構成と一致する場合と合わないラボ環境で実行されるテストに基づいています。

SQL Server を使用すると 、そのプロセスによって予約および使用されるメモリ の最小量と最大量を構成できます。 既定では、SQL Server は使用可能なシステム リソースに基づいてメモリ要件を動的に変更できます。 最小サーバー メモリの既定の設定は 0 で、最大サーバー メモリの既定の設定は 2,147,483,647 MB です。

最大サーバー メモリに適切な値を設定しないと、パフォーマンスとメモリ関連の問題が発生する可能性があります。 多くの要因は、オペレーティング システムが HBA カード、管理エージェント、ウイルス対策リアルタイム スキャンなど、そのシステムで実行されている他のプロセスをサポートできるようにするために、SQL Server に割り当てる必要があるメモリの量に影響します。 十分なメモリが設定されていない場合、OS と SQL はディスクにページングします。 これにより、ディスク I/O が増加し、パフォーマンスがさらに低下し、Operations Manager で目立つ波及効果が生じる可能性があります。

最小サーバー メモリには、少なくとも 4 GB の RAM を指定することをお勧めします。 これは、Operations Manager データベース (運用、データ ウェアハウス、ACS) のいずれかをホストするすべての SQL ノードに対して行う必要があります。

最大サーバー メモリの場合は、最初に次の合計を予約することをお勧めします。

• OS 用の 1 GB の RAM
• インストールされている 4 GB の RAM ごとに 1 GB の RAM (最大 16 GB の RAM)
• インストールされている 8 GB の RAM ごとに 1 GB の RAM (16 GB 以上の RAM)

これらの値を設定したら、Windows の Memory\Available MBytes カウンターを監視して、SQL Server で使用可能なメモリを増やすことができるかどうかを判断します。 Windows は、使用可能な物理メモリが 96 MB で低く実行されていることを通知します。そのため、バッファーを確保するために、カウンターを約 200 ~ 300 MB 未満で実行することが理想的です。 256 GB 以上の RAM を持つサーバーの場合は、1 GB より低く実行されないようにする必要があります。

これらの計算では、他のアプリケーションを考慮するように変更しない限り、SQL Server で使用可能なすべてのメモリを使用できることを前提としています。 OS、他のアプリケーション、SQL Server スレッド スタック、およびその他のマルチページ アロケーターの特定のメモリ要件を考慮してください。 一般的な数式は ((total system memory) – (memory for thread stack) – (OS memory requirements) – (memory for other applications) – (memory for multipage allocators))、スレッド スタックのメモリ = ((max worker threads) (stack size))です。 スタック サイズは、x86 システムの場合は 512 KB、x64 システムの場合は 2 MB、IA64 システムの場合は 4 MB であり、sys.dm_os_sys_infoの max_worker_count 列の最大ワーカー スレッドの値を確認できます。

これらの考慮事項は、仮想マシンで実行する SQL Server のメモリ要件にも適用されます。 SQL Server はバッファー プール内のデータをキャッシュするように設計されており、通常はできるだけ多くのメモリを使用するため、必要な RAM の最適な量を判断するのは困難な場合があります。 SQL Server インスタンスに割り当てられたメモリを減らすと、最終的には、ディスク I/O アクセスの増加のためにメモリ割り当てが低くなるポイントに達します。

過剰プロビジョニングされた環境で SQL Server メモリを構成するには、まず、SQL Server Buffer Manager のページの平均寿命やページ読み取り/秒、物理ディスク ディスクの読み取り/秒の値など、環境と現在のパフォーマンス メトリックを監視します。 環境に過剰なメモリがある場合、 キャッシュが原因で、ワークロードの低下なしにページの平均寿命 は 1 秒ごとに 1 秒ずつ増加します。SQL Server Buffer Manager ページの読み取り/秒 の値は、キャッシュが増加した後も低くなります。物理ディスク ディスク の読み取り/秒 も低いままです。

環境ベースラインを理解したら、最大サーバー メモリを 1 GB 削減し、(初期キャッシュ フラッシュが沈静化した後) パフォーマンス カウンターに与える影響を確認できます。 メトリックが引き続き許容される場合は、さらに 1 GB 減らしてから、必要に応じて監視し、理想的な構成を決定するまで繰り返します。

詳細については、「サーバー メモリの構成オプション」を参照してください。

TempDB の最適化

tempdb データベースのサイズと物理的な配置は、Operations Manager のパフォーマンスに影響する可能性があります。 たとえば、tempdb に定義されているサイズが小さすぎる場合、SQL Server のインスタンスを再起動するたびに、ワークロードをサポートするために必要なサイズに tempdb を自動拡張することで、システム処理の負荷の一部が占められる可能性があります。 最適な tempdb パフォーマンスを実現するには、運用環境の tempdb に対して次の構成をお勧めします。

• tempdb の復旧モデルを SIMPLE に設定します。 このモデルでは、領域の要件を小さく保つために、ログ領域が自動的に再利用されます。
• すべての tempdb ファイルに対する領域をあらかじめ割り当てるには、環境における一般的なワークロードに十分に対応できる大きさの値にファイル サイズを設定します。 tempdb の展開頻度が高くなりすぎず、パフォーマンスに影響する可能性があります。 tempdb データベースは自動拡張に設定できますが、これは計画外の例外のディスク領域を増やすために使用する必要があります。
• ディスク帯域幅を最大化するために必要な数のファイルを作成します。 複数のファイルを使用すると、tempdb ストレージの競合が減少し、スケーラビリティが向上します。 ただし、パフォーマンスを低下させ、管理オーバーヘッドを増やすことができるため、作成するファイルが多くなりすぎないようにしてください。 一般的なガイドラインとして、サーバー上の論理プロセッサごとに 1 つのデータ ファイルを作成し (アフィニティ マスク設定を表します)、必要に応じてファイルの数を上下に調整します。 一般的なルールとしては、論理プロセッサの数が 8 以下の場合、論理プロセッサと同じ数のデータ ファイルを使用します。 論理プロセッサの数が 8 を超える場合は、8 つのデータ ファイルを使用し、競合が続く場合は、競合が許容できるレベルに減少するか、ワークロード/コードに変更を加えるまで、データ ファイルの数を 4 の倍数 (論理プロセッサの数まで) 増やします。 競合が減らない場合は、データ ファイルの数を増やす必要があります。
• 各データ ファイルのサイズを同じにして、最適なプロポーショナル フィル パフォーマンスを実現します。 プロポーショナル フィル アルゴリズムはファイルのサイズに基づいているため、データ ファイルのサイズを等しくすることが重要です。 データ ファイルが等しくないサイズで作成された場合、プロポーショナル フィル アルゴリズムは、すべてのファイル間で割り当てを分散するのではなく、GAM 割り当てに最大のファイルをより多く使用しようとします。これにより、複数のデータ ファイルを作成する目的が失われます。
• 最適なパフォーマンスを得るためのソリッド ステート ドライブを使用して、tempdb データベースを高速 I/O サブシステムに配置します。 直接アタッチされたディスクが多数ある場合は、ディスク ストライピングを使用します。
• ユーザー データベースによって使用されるディスクとは異なるディスクに tempdb データベースを配置します。

tempdb を構成するには、次のクエリを実行するか、Management Studio でそのプロパティを変更します。

USE [tempdb]
GO
DBCC SHRINKFILE (N'tempdev' , 8)
GO
USE [master]
GO
ALTER DATABASE [tempdb] MODIFY FILE ( NAME = N'tempdev', NEWNAME = N'tempdb', SIZE = 2097152KB , FILEGROWTH = 512MB )
GO
ALTER DATABASE [tempdb] ADD FILE ( NAME = N'tempdb2', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\tempdb2.mdf' , SIZE = 2097152KB , FILEGROWTH = 512MB )
GO

T-SQL クエリ SELECT * from sys.sysprocesses を実行して、tempdb データベースのページ割り当ての競合を検出します。 システム テーブルの出力では、待機リソースが "2:1:1" (PFS ページ) または "2:1:3" (共有グローバル割り当てマップ ページ) として表示される場合があります。 競合の程度によっては、SQL Server が短時間応答しなくなる可能性もあります。 もう 1 つの方法は、動的管理ビュー [sys.dm_exec_requestまたはsys.dm_os_waiting_tasks] を調べることです。 結果は、これらの要求またはタスクが tempdb リソースを待機しており、sys.sysprocesses クエリの実行時に前に強調表示された値と同様の値を持っていることを示します。

前の推奨事項で割り当ての競合が大幅に減少せず、競合が SGAM ページにある場合は、SQL Server のスタートアップ パラメーターにトレース フラグ -T1118 を実装して、SQL Server のリサイクル後もトレース フラグが有効なままになるようにします。 このトレース フラグの下で、SQL Server は各データベース オブジェクトに完全なエクステントを割り当てて、SGAM ページでの競合を排除します。

Note

このトレース フラグは、SQL Server のインスタンス上のすべてのデータベースに影響します。

並列処理の最大次数

Operations Manager の小規模から中規模の展開に対する SQL Server の既定の構成は、ほとんどのニーズに適しています。 ただし、管理グループのワークロードがエンタープライズ クラスのシナリオ (通常は 2,000 以上のエージェントマネージド システムと高度な監視構成 (高度な代理トランザクションによるサービス レベルの監視、ネットワーク デバイスの監視、クロスプラットフォームなど) に向かってスケールアップする場合は、ドキュメントのこのセクションで説明する SQL Server の構成を最適化する必要があります。 前のガイダンスで説明されていない構成オプションの 1 つは MAXDOP です。

Microsoft SQL Server max degree of parallelism (MAXDOP) 構成オプションは、並列プランでのクエリの実行に使用されるプロセッサの数を制御します。 このオプションは、作業を並列で実行するクエリ プラン演算子に使用されるコンピューティング リソースとスレッド リソースを決定します。 SQL Server が対称マルチプロセッシング (SMP) コンピューター、統一メモリ アクセス (NUMA) コンピューター、またはハイパースレッディング対応プロセッサのいずれに設定されているかに応じて、並列処理の最大限度オプションを適切に構成する必要があります。

SQL Server は、複数のマイクロプロセッサまたは CPU を搭載したコンピューター上で実行する場合、並列プランの実行ごとに、1 つのステートメントを実行するために使用される最適な並列処理の度合い、つまりプロセッサの数を検出します。 既定では、このオプションの値は 0 です。これにより、SQL Server は並列処理の最大次数を決定できます。

Operations Manager で事前に定義されているストアド プロシージャとクエリは、運用、データ ウェアハウス、および監査データベースに関連するため、MAXDOP オプションは含まれません。インストール中にオペレーティング システムに表示されるプロセッサの数を動的に照会する方法はなく、この設定の値をハードコーディングしようともしないため、クエリの実行時に悪影響を及ぼす可能性があります。

Note

並列処理の最大限度構成オプションでは、SQL Server で使用されるプロセッサの数は制限されません。 SQL Server で使用されるプロセッサの数を構成するには、アフィニティ マスク構成オプションを使用します。

• 8 個を超えるプロセッサを使用するサーバーの場合は、次の構成を使用します: MAXDOP=8
• 8 個以下のプロセッサを使用するサーバーの場合は、MAXDOP=0 から N の構成を使用します。

  Note

  この構成では、N はプロセッサの数を表します。