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

[アーティクル]
11/06/2024

System Center Operations Manager は、Microsoft SQL Server を利用して、運用、データウェアハウス、ACS 監査データベースをサポートします。これらのデータベースは不可欠であり、管理グループ内の最初の管理サーバーまたは ACS コレクターの展開中に作成されます。

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

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

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

重要

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 がサポートされています。

minimum Cumulative Update 8 (CU8) 以降の更新プログラムを含む SQL Server 2019 こちら
SQL Server 2016 と利用可能な最新の更新プログラムこちら

minimum Cumulative Update 11 (CU11) 以降の更新プログラムを含む SQL Server 2022 こちら
minimum Cumulative Update 8 (CU8) 以降の更新プログラムを含む SQL Server 2019 こちら
利用可能な最新の更新プログラムを含む SQL Server 2017 こちら

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

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

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

SQL Server 2016 と利用可能な最新の更新プログラムこちら
SQL Server 2014 と利用可能な最新の更新プログラムこちら
SQL Server 2012 および利用可能な最新の更新プログラムこちら

SQL Server ドライバー

OLE DB と ODBC SQL Server ドライバーは、すべて管理サーバーと Web コンソールサーバーにインストールする必要があります。これらのコンポーネントはデータベースと直接インターフェイスし、これらのドライバーによって SQL への API レベルのアクセスが許可されるためです。

暗号化された SQL Server 接続を利用することをお勧めします。その場合は、最新バージョンの SQL ドライバーをインストールする必要があります。

Microsoft OLE DB Driver 最新バージョン。
Microsoft ODBC ドライバー最新バージョン。

SQL 接続暗号化の構成の詳細については、接続を暗号化するための SQL Server データベースエンジンの構成に関するページを参照してください。

暗号化された SQL 接続使用場合は、暗号化を適用しない SQL ドライバーの以前のリリースを使用します。

Microsoft ODBC Driver バージョン 17.10.6。
Microsoft OLE DB Driver バージョン 18.7.4。

SQL Server の更新プログラム

Operations Manager インフラストラクチャをサポートする次の各 SQL Server コンポーネントは、同じ SQL Server メジャーバージョンである必要があります。

次のような Operations Manager データベースをホストする SQL Server データベースエンジンインスタンス。
- OperationManager
- OperationManagerDW
- SSRS データベース ReportServer と ReportServerTempDB
SQL Server Reporting Services (SSRS) インスタンス。

SQL Server 認証モード

既定では、SQL は混合モード認証構成で動作します。ただし、Operations Manager では、SQL Server との通信にWindows 認証のみが使用されます。既定のままにすると、ローカルアカウントに db_owner ロールがない場合でも、SQL 混合モード認証設定は引き続き機能します。 db_owner ロールを持つローカルアカウントは、Operations Manager で問題を引き起こすことがわかっています。

製品をインストールする前に、すべてのローカルアカウントから db_owner ロールを削除することを強くお勧めします。また、インストール後に db_owner ロールをローカルアカウントに追加しないことを強くお勧めします。

その他の考慮事項

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

NTFS ファイル形式の SQL ディスクを使用することをお勧めします。
運用データベースとデータウェアハウスデータベースには少なくとも 1 GB の空きディスク領域が必要です。これは、データベースの作成時に適用されます。 データベースのディスク使用率は、セットアップ後に大幅に増加しますこの基本要件を超える十分な空きディスク領域があることを確認してください。
.NET Framework 4 が必要です。
.NET Framework 4.8 は Operations Manager 2022 よりサポートされています。
レポートサーバーは、Windows Server Core ではサポートされていません。
SQL Server 照合順序の設定は、「 SQL Server 照合順序の設定」セクションで説明されているように、サポートされている種類のいずれかである必要があります。
Operations Manager データベースをホストするすべての SQL Server データベースエンジンインスタンスには、SQL Server フルテキスト検索が必要です。
Operations Manager データベースコンポーネントでサポートされる Windows Server インストールオプション (Server Core、デスクトップエクスペリエンス搭載サーバー、Nano Server) は、SQL Server でサポートされているインストールオプションに基づいています。

詳細については、「SQL Server のインストールと計画」の「ハードウェアとソフトウェアの要件」セクションを参照してください。 SQL Server のインストールを計画する

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 と正常に通信できる必要があります。また、環境を正しく構成するには、通信パスとポートを理解することが重要です。

SQL Always On 可用性グループを使用する分散デプロイを設計する場合は、ファイアウォールのセキュリティ戦略に追加のファイアウォール構成設定を含める必要があります。

次の表は、管理サーバーがデータベースと通信するために 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)	着信	管理サーバーとオペレーションコンソール

Note

TCP 1433 は、データベースエンジンの既定のインスタンスの標準ポートですが、スタンドアロンの SQL Server に名前付きインスタンスを作成する場合、または SQL Always On 可用性グループをデプロイした場合は、カスタムポートが定義されており、ファイアウォールを適切に構成し、セットアップ時にこの情報を入力できるように、参照用に文書化する必要があります。

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

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

Operations Manager データベース

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

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

運用データの収集率。
- 運用データ収集の速度は、インポートされた管理パックの数、追加されたエージェントの数、監視対象のコンピューターの種類などの要因によって影響を受けます。たとえば、ビジネスクリティカルなデスクトップコンピューターを監視するエージェントでは、複数のデータベースを持つ SQL Server を実行しているサーバーを監視するエージェントに比べて収集されるデータが少なくなります。
インスタンス領域の変更率。
- 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 を有効にするには、次の手順に従います。

次の SQL クエリを実行して、ブローカーが既に有効になっているかどうかを確認します。これは、is_broker_enabled フィールドの 1 (1) の結果で示されます。
```
SELECT is_broker_enabled FROM sys.databases WHERE name='OperationsManager'
```

is_broker_enabled フィールドに表示される値が 0 (ゼロ) の場合は、次の SQL ステートメントを実行してブローカーを有効にします。

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

Operations Manager Data Warehouse データベース

Note

Operations Manager Data Warehouse は、"Reporting Data Warehouse" データベースとも呼ばれ、一部のドキュメントでは単に "Data Warehouse" と呼ばれます。

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 データベースとデータウェアハウスを同じサーバーに統合できますが、エージェントの数と受信操作データの量をスケールアップするときに、それらを分離すると便利です。データウェアハウスとレポートサーバーが Operations Manager データベースとは別のサーバー上にある場合、レポートのパフォーマンスが向上します。

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

SQL Server AlwaysOn

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

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

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

Always On の前提条件の詳細。
Always On 可用性グループの WSFC の設定の詳細については。
可用性グループの設定の詳細についてはを参照してください。

ヒント

Operations Manager 2022 以降では、構成後の変更を必要とせずに、既存の SQL Always-On セットアップで Operations Manager データベースを設定およびアップグレードできます。

Always On の前提条件の詳細。
Always On 可用性グループの WSFC の設定の詳細については。
可用性グループの設定の詳細についてはを参照してください。

Note

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

Multisubnet 文字列

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

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

可用性グループリスナーのネットワーク名を、DNS に 1 つのアクティブな IP アドレスのみを登録するように設定します。
登録済みの 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」のドキュメントを参照してください。

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

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 容量を評価します。製品グループのファイルサーバーチームのメンバーが作成した次のブログ記事では、このツールを使用してストレステストを実行する方法に関する詳細なガイダンスと推奨事項 ( DiskSpd、PowerShell、ストレージのパフォーマンス) について説明します。IOPS の測定、ローカルディスクと SMB ファイル共有の両方のスループットと待機時間。

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 は使用可能なシステムリソースに基づいてメモリ要件を動的に変更できます。 min サーバーメモリの既定の設定は 0、max サーバーメモリの既定の設定は 2,147,483,647 MB です。

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

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

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

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 バッファーマネージャーの ページ読み取り/秒 値はキャッシュランプアップ後に低くなります。また、物理ディスク ディスクの読み取り/秒 も低いままです。

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

詳細については、「 Server memory configuration options」を参照してください。

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 のインスタンス上のすべてのデータベースに影響します。

並列処理の最大次数

ヒント

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 の構成を使用します。

ヒント

この構成では、 N はプロセッサの数を表します。
NUMA が構成されているサーバーの場合、MAXDOP は各 NUMA ノードに割り当てられている CPU の数を超えないようにする必要があります。
ハイパースレッディングが有効になっているサーバーの場合、MAXDOP 値は物理プロセッサの数を超えないようにする必要があります。
NUMA が構成され、ハイパースレッディングが有効になっているサーバーの場合、MAXDOP 値は NUMA ノードあたりの物理プロセッサの数を超えないようにする必要があります。

select * from sys.dm_os_tasksクエリを実行して、並列ワーカーの数を監視できます。

この例では、サーバーのハードウェア構成は、24 個のコアプロセッサと 196 GB の RAM を備えた HP Blade G6 でした。 Operations Manager データベースをホストしているインスタンスの MAXMEM 設定は 64 GB でした。このセクションで推奨される最適化を実行すると、パフォーマンスが向上しました。ただし、クエリの並列処理のボトルネックは引き続き保持されます。異なる値をテストした後、MAXDOP=4 を設定することで最も最適なパフォーマンスが見つかりました。

データベースの初期サイズ設定

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

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

運用およびデータウェアハウスデータベースの増加を事前に監視するには、毎日または毎週のサイクルで実行する必要があります。これは、予期しない重大な増加のスプリアスを特定し、原因を特定するためにトラブルシューティングを開始するために必要です。これは、管理パックワークフローのバグ (検出ルール、パフォーマンス、イベント収集ルール、監視またはアラートルールなど) によって、またはリリース管理プロセスのテストおよび品質保証フェーズ中に識別されなかった管理パックのその他の症状を特定するために必要です。

データベースの自動拡張

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

予期しない成長のコンティンジェンシーとしてのみ自動拡張に依存します。自動拡張では、高度なトランザクションデータベースを処理するときに考慮する必要があるパフォーマンスの低下が発生します。パフォーマンスの低下は次のとおりです。

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

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

これら 2 つの設定は慎重に構成してください。特定の構成は実際には環境によって異なります。一般的な推奨事項は、ディスクの断片化を減らすために、データベースサイズを固定量増やすことです。たとえば、次の図を参照してください。自動拡張が必要になるたびに、データベースが 1,024 MB 増加するように構成されています。

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

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

これらの既定の設定は、ほとんどのお客様に最適な動作を提供します。ただし、クラスターがインチから数マイル離れた場所まで拡張されると、ノード間のネットワークコンポーネントが増え、信頼性が低くなる可能性があります。もう 1 つの要因は、冗長コンポーネント (デュアル電源、NIC チーミング、マルチパス I/O など) を介した回復性の強化と相まって、コモディティサーバーの品質が絶えず向上していることです。非冗長なハードウェア障害の数は非常にまれである可能性があります。ハード障害の頻度が低い場合があるため、一時的な障害に備えてクラスターを調整したい場合があります。一部のお客様は、ノード間の短いネットワーク障害に対する回復性が高くなります。既定の障害しきい値を増やすと、短時間続く短いネットワークの問題に対する感度を低下させることができます。

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

SQL Server の仮想化

仮想環境では、パフォーマンス上の理由から、オペレーションデータベースとデータウェアハウスデータベースは、仮想ディスクではなく、直接接続されたストレージに格納することをお勧めします。 Operations Manager 2012 用にリリースされた Operations Manager サイズ変更ヘルパーユーティリティを使用して、必要な IOPS を見積もり、データディスクをストレステストして検証できます。ストレージのパフォーマンスは、 DiskSpd ユーティリティを使用してテストできます。仮想化された Operations Manager 環境に関する追加のガイダンスについては、 Operations Manager 仮想化のサポートも参照してください。

Always On と復旧モデル

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

バックアップ戦略では、環境の詳細を考慮する必要があります。一般的なバックアップスケジュールを次の表に示します。

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

SQL Server レポートサービスの最適化

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

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

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

Note

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

この問題を解決するには:

[SQL Management Studio ] を開きます。
Reporting Services インスタンスに接続します。
オブジェクトエクスプローラーウィンドウでサーバーインスタンスを右クリックします。
プロパティを選択します。
左側のサイドバーで Advanced を選択します。
*.*を AllowedResourceExtensionsForUpload の一覧に追加します。

または、Operations Manager のレポート拡張機能の完全な一覧を SSRS の allow リスト に追加することもできます。一覧については、「解決策 2」を参照してください。 Operations Manager レポートの展開に失敗する

次のステップ

ファイアウォールの内側で (レポート) データウェアハウスをホストするように構成する方法については、「ファイアウォールを越えて (レポート) データウェアハウスを接続するを参照してください。

次の方法で共有

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

SQL Server 要件

SQL Server ドライバー

SQL Server の更新プログラム

SQL Server 認証モード

その他の考慮事項

SQL Server 照合順序の設定

SQL Server の照合順序

[Windows 照合順序]

ファイアウォールの構成

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

Operations Manager データベース

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

Operations Manager Data Warehouse データベース

SQL Server AlwaysOn

Multisubnet 文字列

SQL Server の最適化

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

メモリを予約する

TempDB の最適化

並列処理の最大次数

データベースの初期サイズ設定

データベースの自動拡張

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

SQL Server の仮想化

Always On と復旧モデル

SQL Server レポートサービスの最適化

次のステップ

フィードバック

その他のリソース

次の方法で共有

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

SQL Server 要件

SQL Server ドライバー

SQL Server の更新プログラム

SQL Server 認証モード

その他の考慮事項

SQL Server 照合順序の設定

SQL Server の照合順序

[Windows 照合順序]

ファイアウォールの構成

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

Operations Manager データベース

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

Operations Manager Data Warehouse データベース

SQL Server AlwaysOn

Multisubnet 文字列

SQL Server の最適化

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

メモリを予約する

TempDB の最適化

並列処理の最大次数

データベースの初期サイズ設定

データベースの自動拡張

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

SQL Server の仮想化

Always On と復旧モデル

SQL Server レポート サービスの最適化

次のステップ

フィードバック

その他のリソース

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

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

SQL Server レポートサービスの最適化