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

  • [アーティクル]

重要

このバージョンの Operations Manager はサポート終了に達しました。 Operations Manager 2022 にアップグレードすることをお勧めします。

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 や他のハードウェア リソースの制限事項に関する潜在的な問題を回避するためです。

SQL Server の要件

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

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

    Note

    • Operations Manager 2019 では、CU8 以降の SQL 2019 がサポートされています。ただし、SQL 2019 RTM はサポートされていません。
    • ODBC 17.3 から 17.9、MSOLEDBSQL 18.2 から 18.6.3 を使用します。

  • SQL Server 2022 (Operations Manager 2022 UR1 からサポート)

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

    Note

    • Operations Manager 2022 では、CU8 以降の SQL 2019 がサポートされています。ただし、SQL 2019 RTM はサポートされていません。
    • ODBC 17.3 から 17.9、MSOLEDBSQL 18.2 から 18.6.3 を使用します。
  • SQL Server 2017 と累積的な更新プログラム (詳細)
  • SQL Server 2016 および各 Service Pack (詳細)
  • SQL Server 2017 と累積的な更新プログラム (詳細)

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

  • SQL Server 2017 と累積的な更新プログラム (詳細)
  • SQL Server 2016 および各 Service Pack (詳細)

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

SQL Server 2017 にアップグレードする前に、2017 のアップグレード情報に関する記事をご覧ください。

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

  • SQL Server 2016 および各 Service Pack (詳細)

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

  • SQL Server 2016 および各 Service Pack (詳細)
  • SQL Server 2014 および各 Service Pack (詳細)
  • SQL Server 2012 および各 Service Pack (詳細)

Note

  • SCOM インフラストラクチャをサポートする次の各 SQL Server コンポーネントは、同じ SQL Server メジャー バージョンである必要があります。
    • SQL Server SCOM データベース (つまり、OperationManager、OperationManagerDW、SSRS データベースReportServerServerTempDB&) をホストしているデータベース エンジン インスタンスです。
    • 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 2014 または 2016 のインストールに必要なハードウェアおよびソフトウェアに関する記事を参照してください。

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

Note

オペレーション データベースの初期インストール中は、Operations Manager オペレーション データベースをホストする SQL Server 上の Windows 認証だけを使用してください。 運用データベースの初回インストール時にSQL Server認証モードを使用すると問題が発生する可能性があるため、混合モード (Windows 認証とSQL Server認証) を使用しないでください。 Operations Manager オペレーション データベースをホストしているSQL Serverでは混合モード セキュリティを有効にすることはできますが、データベースとのすべての連絡先が Windows アカウントのみを使用して行われるので、サポートされていません。

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 可用性グループでホストできます。

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

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 データベースを追加できます。

Note

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

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

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

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

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

これらの設定を使用すれば、別のサブネット内のノードにフェールオーバーするときに、新しい IP アドレスでクラスター名の回復および解決を迅速に行うことができます。

SQL ノードのいずれか 1 つに対して次の 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"

リスナー名で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>

クラスター化されたインスタンスまたは 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 容量を評価します。 製品グループの File Server チームのメンバーによって作成された次のブログ記事では、このツールを使用して 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

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

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

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

Note

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

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

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

    Note

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

  • NUMA が構成されているサーバーの場合、MAXDOP は各 NUMA ノードに割り当てられている CPU の数を超えないようにする必要があります。

  • ハイパースレッディングが有効になっているサーバーの場合、MAXDOP 値は物理プロセッサの数を超えないようにしてください。

  • NUMA が構成され、ハイパースレッディングが有効になっているサーバーの場合、MAXDOP 値は NUMA ノードあたりの物理プロセッサ数を超えないようにしてください。

sys.dm_os_tasks に問い合わせることで、並列 worker の数を監視できます。
このサーバーのハードウェア構成は、HP Blade G6、24 個のコア プロセッサ、196 GB の RAM でした。 Operations Manager データベースをホストするインスタンスの MAXMEM 設定は 64 GB でした。 このセクションで提案されている最適化を実行すると、パフォーマンスが改善しました。 ただし、クエリの並列処理のボトルネックは引き続き存在します。 さまざまな値を試したところ、MAXDOP=4 を設定したときに最適なパフォーマンスが得られました。

最初のデータベース サイズ調整

デプロイ後の最初の数か月以内に、Operations Manager データベース (特に運用およびデータ ウェアハウス データベース) の将来の増加を見積もすることは、簡単な演習ではありません。 Operations Manager のサイズ設定ヘルパーは、ラボでのテストから製品グループによって派生した式に基づいて潜在的な成長を見積もる際に妥当ですが、いくつかの要因を考慮していないため、近い期間と長期的な成長に影響を与える可能性があります。

サイズ設定ヘルパーで提案されているように、初期データベース サイズは、断片化と対応するオーバーヘッドを減らすために予測サイズに割り当てる必要があります。これは、運用データベースとData Warehouse データベースのセットアップ時に指定できます。 設定時に十分なストレージ領域が利用できない場合、SQL Management Studio を利用することで、後でデータベースを拡張できます。それからインデックスを再作成し、適宜デフラグし、最適化できます。 この推奨事項は、ACS データベースにも適用されます。

オペレーション データベースとデータ ウェアハウス データベースの増加は、先を見越し、毎日あるいは毎週のペースで監視してください。 これは、予期しない大幅な増加のスプリアスを特定し、管理パック ワークフローのバグ (検出ルール、パフォーマンス、イベント収集ルール、監視またはアラート ルール)、またはリリース管理プロセスのテストおよび品質保証フェーズ中に特定されなかった管理パックのその他の症状が原因かどうかを判断するためにトラブルシューティングを開始するために必要です。

データベースの自動拡張

ディスクに予約されているデータベース ファイルのサイズがいっぱいになると、SQL Serverはサイズをパーセンテージまたは一定の量だけ自動的に増やすことができます。 さらに、最大データベース サイズを構成して、ディスク上で使用可能なすべての領域が不足しないようにすることができます。 既定では、Operations Manager データベースは自動拡張を有効にして構成されていません。Data Warehouseデータベースと ACS データベースのみが存在します。

自動拡張は、突然の増加という不測の事態に備えるためにのみ利用します。 自動拡張ではパフォーマンス ペナルティが利用されます。トランザクション数の多いデータベースを扱うとき、このペナルティを考慮します。 パフォーマンス ペナルティに含まれる項目:

  • 適切な増分を指定しない場合のログ ファイルまたはデータベースの断片化。
  • 使用可能なログ領域よりも多くのログ領域を必要とするトランザクションを実行し、そのデータベースのトランザクション ログの自動拡張オプションを有効にした場合、トランザクションが完了するまでの時間には、トランザクション ログが構成された量だけ増加するまでの時間が含まれます。
  • ログの拡張を必要とする大きなトランザクションを実行すると、トランザクション ログへの書き込みを必要とするその他のトランザクションは拡張の完了を待つ必要があります。

自動拡張オプションと自動圧縮オプションを組み合わせた場合、不必要なオーバーヘッドが生まれる可能性があります。 拡大および縮小操作をトリガーするしきい値によって、サイズの変更が頻繁に発生しないようにします。 たとえば、コミット時にトランザクション ログを 100 MB 増やすトランザクションを実行するとします。 その後しばらくしてから、自動圧縮が始動し、トランザクション ログを 100 MB 減らします。 次に、同じトランザクションを実行すると、トランザクション ログが再び 100 MB 増加します。 この例では、不要なオーバーヘッドを作成し、ログ ファイルの断片化が発生する可能性があり、どちらかがパフォーマンスに悪影響を与える可能性があります。

この 2 つの設定は慎重に構成することをお勧めします。 実際、特定の構成はご利用の環境に依存します。 一般に、ディスクの断片化を減らすために、データベース サイズを固定量だけ増やすことをお勧めします。 次の図をご覧ください。自動拡張が必要になるたびに 1024 MB 増えるようにデータベースが構成されています。

クラスター フェールオーバー ポリシー

Windows Server フェールオーバー クラスタリングは可用性の高いプラットフォームであり、ネットワーク接続とクラスター内のノードの健全性を常に監視します。 ノードにネットワーク経由で到達できない場合は、復旧アクションが実行され、クラスター内の別のノードでアプリケーションとサービスがオンラインになります。 既定の設定は、サーバーが完全に失われ、"ハード" 障害と見なされる障害に対して最適化されています。 非冗長のハードウェアまたは電源の故障など、回復不可能なエラー シナリオです。 そのような状況では、サーバーが失われ、フェールオーバー クラスタリングがサーバーの喪失をすばやく検出し、クラスター内の別のサーバーですぐに復元することが目標となります。 このようなハードの障害から迅速に回復するために、クラスターの健全性監視は、非常に活動的な初期設定です。 ただし、さまざまなシナリオに柔軟に対応できるように完全に構成できます。

これらの既定の設定は、ほとんどのお客様に最適な動作を提供します。ただし、クラスターがインチから数マイル離れた場所まで拡張されると、クラスターがノード間の追加の信頼できないネットワーク コンポーネントに公開される可能性があります。 別の要因に、汎用的サーバーの質が継続的に向上していることがあります。冗長コンポーネント (二重電源、NIC チーミング、マルチパス I/O など) により弾力性が向上し、非冗長ハードウェアが故障する可能性がかなり低くなっています。 ハードウェアの故障の頻度が減ったため、一時的な故障に備えてクラスターを調整するお客様もいます。ノード間の短時間のネットワーク エラーに対してクラスターの回復力を上げます。 既定のエラーしきい値を増やすことで、短時間だけ続くネットワーク問題に対する感度を下げることができます。

ここには正しい答えがなく、最適化された設定は、特定のビジネス要件とサービス レベル アグリーメントによって異なる場合があることを理解することが重要です。

SQL Server の仮想化

仮想環境では、パフォーマンス上の理由から、運用データベースとデータ ウェアハウス データベースは、仮想ディスクではなく、直接接続されたストレージに格納することをお勧めします。 常に Operations Manager のサイズ測定ヘルパーを使用し、必要な IOPS を見積もり、データ ディスクにストレス テストを実施し、確認してください。 このタスクには SQLIO ツールを使用できます。 仮想化 Operations Manager 環境に関してさらにガイダンスが必要な場合、「Operations Manager 仮想化のサポート」も参照してください。

AlwaysOn と復旧モデル

厳密には最適化ではありませんが、AlwaysOn 可用性グループに関して重要な考慮事項があります。設計上、この機能では “完全” 復旧モデルでデータベースを設定する必要があります。 つまり、完全バックアップが完了するか、トランザクション ログのみが実行されるまで、トランザクション ログは破棄されません。 このため、バックアップ戦略は省略可能ではなく、Operations Manager データベースの AlwaysOn 設計に必要な部分です。 バックアップ方針を導入しない場合、時間の経過と共に、トランザクション ログを含むディスクがいっぱいになります。

バックアップ方針では、ご利用の環境の詳細を考慮する必要があります。 一般的なバックアップ スケジュールは次の表のようになります。

バックアップの種類 スケジュール
トランザクション ログのみ 1 時間おきに
完全 毎週日曜日午前 3 時 00 分

SQL Server Reporting Services を最適化する

Reporting Services インスタンスは、データ ウェアハウス データベースのデータにアクセスする際、プロキシとして機能します。 管理パック内に保存されているテンプレートに基づいてレポートを生成し、表示します。

Reporting Servicesの背後には、ReportServer データベースと ReportServerTempDB データベースをホストする SQL Server Database インスタンスがあります。 このインスタンスのパフォーマンス調整に関する一般的な推奨事項が適用されます。

Note

SQL Server Reporting Services (SSRS) 2017 バージョン 14.0.600.1274 以降では、既定のセキュリティ設定ではリソース拡張機能のアップロードは許可されません。 これにより、レポート コンポーネントの展開中に Operations Manager で ResourceFileFormatNotAllowedException の例外が発生します。

これを解決するには、SQL Management Studio を開き、Reporting Services インスタンスに接続し、[プロパティ][詳細] を開いて、*.* を AllowedResourceExtensionsForUpload の一覧に追加します。 または、SSRS の許可リストに Operations Manager のレポート拡張機能の完全な一覧を追加することもできます。

次のステップ

ファイアウォールの背後にあるレポート データ ウェアハウスをホストする構成方法を理解するには、「ファイアウォール間でレポート データ ウェアハウスを接続する」を参照してください。