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

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

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

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

他のアプリケーション データベースを含む 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 の要件

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

• SQL Server 2022

• 累積的な更新プログラム 8 (CU8) 以降で 2019 年をSQL Serverします(詳細はこちら)

  注意

  • Operations Manager 2022 では、CU8 以降の SQL 2019 がサポートされています。ただし、SQL 2019 RTM はサポートされていません。
  • ODBC 17.3 以降、および MSOLEDBSQL 18.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 のインストール オプションに基づいています。

注意

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

設計では、ハードウェアとソフトウェアの付加的な考慮事項が適用されます。

• SQL Server は NTFS ファイル形式のコンピューターで実行することが推奨されます。
• オペレーション データベースとデータ ウェアハウス データベースの場合、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 の照合順序

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

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 で必要なファイアウォール ポートを特定するとき、次の表が役に立ちます。

通信の種類	Port	Direction	Operations Manager ロール
Operations Manager データベースをホストする SQL Server	TCP 1433 *	着信	管理サーバーと Web コンソール (Application Advisor と Application Diagnostics 用)
SQL Server Browser サービス	UDP 1434	着信	管理サーバー
SQL Server 専用管理者接続	TCP 1434	着信	管理サーバー
SQL Server で使用される追加のポート - Microsoft リモート プロシージャ呼び出し (MS RPC) - Windows Management Instrumentation (WMI) - Microsoft 分散トランザクション コーディネーター サービス (MS DTC)	TCP 135	着信	管理サーバー
SQL Server AlwaysOn 可用性グループ リスナー	管理者構成ポート	受信	管理サーバー
Operations Manager Reporting Server をホストしている SQL Server Reporting Services	TCP 80 (既定)/443 (SSL)	受信	管理サーバーとオペレーション コンソール

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

SQL Server のファイアウォール要件の詳細な概要が必要な場合、「Configure the Windows Firewall to Allow SQL Server Access」 (Windows ファイアウォールを構成し、SQL Server アクセスを許可する) を参照してください。

容量と記憶域に関する考慮事項

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 AlwaysOn 可用性グループやフェールオーバー クラスター インスタンスなど、サポートされているフェールオーバー構成を利用し、可用性を高めることができます。

構成後に変更を加えることなく、既存の 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 のタスクに関して予期しない動作が観察された場合は、常に Service Broker SQL Serverの状態をチェックすることが重要です。

SQL Server Service Broker を有効にするには、次の手順を実行します。

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

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

2. is_broker_enabled フィールドに表示される値が is_broker_enabled (数字の 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 AlwaysOn 可用性グループやフェールオーバー クラスター インスタンスなど、サポートされているフェールオーバー構成を利用し、可用性を高めることができます。

SQL Server AlwaysOn

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

System Center 2016 以降の Operations Manager の場合、SQL AlwaysOn の方がフェールオーバー クラスタリングより高い可用性をデータベースに提供します。 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 スクリプトを実行します。

マルチサブネットの文字列

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

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

1. 可用性グループ リスナーのネットワーク名を設定して、1 つのアクティブな IP アドレスのみを DNS に登録します。
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 データ アクセス サービスが再起動されないように、管理サーバーで自動復旧機能を有効にする必要があります。 この構成方法の詳細については、サポート技術情報の「The System Center Management service stops responding after an instance of SQL Server goes offline」 (System Center Management サービスは、SQL Server のインスタンスがオフラインになった後に応答を停止する) を参照してください。

SQL Server を最適化する

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

• LUN のスピンドルの割り当てが不十分であり、Operations Manager の IO 要件をサポートできない。
• トランザクション ログとデータベース ファイルを同じボリュームでホストしている。 これら 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 によるブログ記事「How much memory does my SQL Server actually need? (sqlskills.com)」(実際に SQL Server に必要なメモリはどれくらいか) のものです。

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

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

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

min server memory には、少なくとも 4 GB の RAM を指定することをお勧めします。 Operations Manager データベース (オペレーション、データ ウェアハウス、ACS) のいずれかをホストする SQL ノードごとにこれを行う必要があります。

max server memory については、最初に次のように合計を予約することをお勧めします。

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

これらの値を設定したら、Windows の [Memory\使用可能バイト (MB)] カウンタを監視して、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 秒ごとに増加します。キャッシュが増加すると、SQL Server Buffer Manager のページ読み取り/秒の値は低くなります。また、物理ディスクのディスク読み取り数/秒も低いままです。

環境のベースラインを理解したら、 max server memory を 1 GB 減らすことができます。これにより、パフォーマンスカウンターにどのように影響するかを確認できます (最初のキャッシュをフラッシュした後)。 メトリックが引き続き許容される場合は、さらに 1 GB 減らし、もう一度監視して、理想的な構成が決まるまで、必要に応じて繰り返します。

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

TempDB の最適化

tempdb データベースのサイズと物理的配置は Operations Manager のパフォーマンスに影響を与えます。 たとえば、tempdb に定義されているサイズが小さすぎる場合、SQL Server のインスタンスを再起動するたびに作業負荷をサポートするために必要なサイズに tempdb を自動増加することにシステム処理負荷の一部が占められる可能性があります。 最適な tempdb パフォーマンスを得るためには、運用環境で次のように tempdb を構成することが推奨されます。

• tempdb の回復モデルを SIMPLE に設定します。 このモデルは自動的にログ領域を再要求し、領域要件を少ない状態で維持します。
• すべての tempdb ファイルの領域を事前に割り当てます。環境における典型的な作業負荷に対応するために十分な大きさを持つ値にファイル サイズを設定します。 tempdb があまりにも頻繁に拡大させる状況が回避されます。そのような状況では、パフォーマンスに影響が出ることがあります。 tempdb データベースには自動増加を設定できますが、自動増加は例外に対してディスク領域を増加するときに使用してください。
• ディスク帯域幅を最大化するために必要な数のファイルを作成します。 複数のファイルを使用すると、tempdb のストレージ競合が減り、拡張性が改善されます。 ただし、パフォーマンスが低下し、管理オーバーヘッドが増加する可能性があるため、作成するファイルが多すぎないようにしてください。 一般的なガイドラインとしては、サーバー上の (アフィニティ マスク設定があれば、それを担う) 論理プロセッサ 1 つにつきデータ ファイルを 1 つ作成します。それから必要に応じてファイル数を増やしたり、減らしたりします。 一般的なルールとしては、論理プロセッサの数が 8 以下の場合、論理プロセッサと同じ数のデータ ファイルを使用します。 論理プロセッサの数が 8 より多い場合、8 つのデータ ファイルを使用します。競合が続くようであれば、競合が許容できるレベルになるまでデータ ファイルの数を 4 の倍数単位で増やします (最大で論理プロセッサの数まで)。あるいは、作業負荷/コードを変更します。 競合が軽減されない場合は、データ ファイルの数を増やす必要がある場合があります。
• 各データ ファイルのサイズを同じにして、最適なプロポーショナル フィル パフォーマンスを実現します。 データ ファイルのサイズを等しくすることが重要です。比例書き込みアルゴリズムはファイルのサイズに基づくためです。 データ ファイルが異なるサイズで作成されると、比例書き込みアルゴリズムは、すべてのファイルに割り当てせず、一番大きいファイルを GAM 割り当てに使用しようとします。そのため、複数のデータ ファイルを作成する目的にそぐわなくなります。
• 最適なパフォーマンスを得るために、ソリッドステート ドライブを利用し、高速の I/O サブシステムに tempdb データベースを置きます。 たくさんのディスクが直接接続されている場合、ディスク ストライピングを使用します。
• ユーザー データベースで使用されているディスクとは異なるディスクに 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 ページで競合がなくなります。

注意

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

並列処理の最大限度

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

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

複数のマイクロプロセッサまたは CPU を持つコンピューターで SQL Server が実行されている場合、並列実行のたびに、並列処理の最良限度、つまり、1 つのステートメントを実行するために使用されるプロセッサの数が検出されます。 既定では、このオプションのその値は 0 です。SQL Server は並列処理の最大限度を決定できます。

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

注意

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

• サーバーで 8 個より多いプロセッサが使用される場合、MAXDOP=8 という構成を使用します。
• 8 個以下のプロセッサを使用するサーバーの場合は、MAXDOP=0 から N の構成を使用します。

  注意

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