ストレージおよび SQL Server の容量計画と構成 (SharePoint Server)

適用対象:2016 2019 Subscription Edition SharePoint in Microsoft 365

このドキュメントの容量計画に関する情報は、SharePoint Server 環境でストレージと SQL Server データベース層を計画して構成するうえで役立つガイドラインを提供するものです。 この情報は、実際のプロパティを使用してマイクロソフトが行ったテストに基づいています。 ただし、実際に得られる結果は、使用する機器やサイトに実装する機能によって変動します。

Microsoft 365 の SharePoint のサイトの記憶域制限を管理する方法について説明します。

テストは、SQL Server 2014 (SP1) では実行されませんでしたが、SQL Server 2016、SQL Server 2017 RTM、または SQL Server 2019 では、これらのテスト結果をガイドとして使用して、ストレージ層とデータベース層SQL Server構成するのに役立ちますSharePoint Server サブスクリプション エディション、2019、または 2016 環境。 SQL Server 2012 を構成して微調整する方法を紹介するトレーニングについては、「SharePoint Server 2013 の SQL Server 2012」を参照してください。 テスト結果は、SharePoint 2013 と同じです。

このドキュメントは、SharePoint Server ファームの実装者とSQL Serverデータベース管理者が共同で使用することを目的としています。SharePoint Server は、データベースが個別のSQL Server データベース管理者によって管理されている環境で実行されることが多いです。 これは、SharePoint Server とSQL Serverの両方について大きな理解を持つものとします。

この記事では、「SharePoint Server 2013 での容量管理と規模設定」に説明されている概念を読者が熟知しているものと仮定しています。

SharePoint Server 2016 以降のストレージとデータベース層の設計と構成

ストレージとデータベース層の設計プロセスは、次のステップに分けて進めることをお勧めします。 これらのセクションでは、各設計ステップの詳細 (ストレージの要件やベスト プラクティスなど) を説明します。

1. ストレージおよび SQL Server の領域と I/O に関する要件を収集する

2. SQL Server のバージョンとエディションを選択する

3. 容量および I/O の要件に基づいてストレージ アーキテクチャを設計する

4. 必要なメモリを見積もる

5. ネットワーク トポロジの要件を把握する

6. SQL Server を構成する

7. ストレージとSQL Serverパフォーマンスの検証と監視

ストレージおよび SQL Server の領域と I/O に関する要件を収集する

ストレージの設計には、SharePoint Server のいくつかの構造上の要素が影響します。 その主な要素として、コンテンツの分量、利用する機能やサービス、ファームの数、可用性のニーズなどを挙げることができます。

ストレージの計画を開始する前に、SharePoint Server で使用できるデータベースについて理解しておくことが大切です。

このセクションの内容

• SharePoint Server で使用されるデータベース

• SQL Server と IOPS について

• コア ストレージおよび IOPS のニーズを見積もる

• サービス アプリケーションの必要なストレージと IOPS を見積もる

• 可用性のニーズを決定する

SharePoint Server で使用されるデータベース

SharePoint サーバー (Subscription Edition、2019、または 2016) と共にインストールされるデータベースは、環境で使用されるサービス アプリケーションによって異なります。 すべての SharePoint Server 環境は、SQL Server システム データベースに依存します。 このセクションでは、SharePoint サーバーと共にインストールされるデータベースの概要を示します。 詳しいデータベース情報は、「データベースの種類と説明 (SharePoint Server)」を参照してください。

SharePoint Server、SQL Server データベース エンジン、および SQL Server Reporting Services (SSRS) のデータベースの中には、特定のロケーションが推奨または指定されているものがあります。 これらのデータベース ロケーションの詳細については、 「データベースの種類と説明 (SharePoint Server)」をご覧ください。 クイック リファレンス ガイド: SharePoint Server 2016 および 2019 データベースは、PDF または Visio ファイルとしてダウンロードできます。

次のデータベースは SharePoint Server のシステム データベースで、自動的にインストールされます。

• 構成

• サーバーの全体管理コンテンツ

• コンテンツ (複数指定可)

次のリストに、データベースが存在する SharePoint Server のサービス アプリケーションを示します。

• App Management Service

• SharePoint 用アプリ

• Business Data Connectivity

• Managed Metadata

• PerformancePoint Service

• Project Server (SharePoint Server 2013 のみ)

• Search Service

  • 検索管理

  • 分析レポート

  • クロール

  • リンク

• Secure Store Service

• SharePoint Translation Services

• SQL Server Power Pivot Service

• State Service

• Subscription Settings Service

• Usage and Health data collection

• User Profile Service

  • プロファイル

  • ソーシャル タグ

  • 同期

• Word Automation Service

次の一覧は、SharePoint Foundation 2013 のデータベースを示しています。

• 構成

• サーバーの全体管理コンテンツ

• コンテンツ (複数指定可)

• App Management Service

• Search service アプリケーション:

  • Search administration

  • 分析レポート (複数指定可)

  • クロール (複数指定可)

  • リンク (複数指定可)

• Secure Store Service

• Subscription Settings Service アプリケーション (Windows PowerShell で有効になっている場合)

• Usage and Health Data Collection Service

• Word Conversion Service

さらにSQL Serverと統合する場合は、次のシナリオのように、環境にさらに多くのデータベースが含まれる場合があります。 SQL Server 2016 RTM Enterprise Edition および SQL Server 2016 SQL Server Analysis Services (SSAS) を使用する場合に限り、SharePoint Server 2016 環境で SQL Server Power Pivot for SharePoint を使用できます。 使用中の場合は、Power Pivot アプリケーション データベースとシステムに対する追加の負荷もサポートする必要があります。 詳細については、新しいホワイト ペーパー「SharePoint 2016 での SQL Server 2016 PowerPivot および Power View の展開」をダウンロードしてください。 複数のサーバー SharePoint Server 2016 ファームでのビジネス インテリジェンスの構成と展開の詳細については、「多層 SharePoint 2016 ファームでの SQL Server 2016 PowerPivot および Power View の展開」をダウンロードしてください。

どの SharePoint Server 2016 環境でも、SQL Server 2016 Reporting Services (SSRS) アドインを使用できます。 アドインを使用している場合は、2 つのSQL Server Reporting Services データベースと、SQL Server Reporting Servicesに必要な追加の負荷をサポートすることを計画します。

• SharePoint 2013 環境に SQL Server 2008 R2 Enterprise Edition と SQL ServerAnalysis Services が含まれていれば、その環境で SQL Server 2012 Power Pivot for SharePoint 2013 を使用できます。 使用中の場合は、Power Pivot アプリケーション データベースとシステムに対する追加の負荷もサポートする必要があります。 詳細については、「 SharePoint ファームでの PowerPivot 展開の計画」、 Power Pivot - 概要と学習とPower View - 概要と学習に関するページを参照してください。

• SharePoint 2013 製品のどの環境でも、SQL Server 2008 R2 Reporting Services (SSRS) プラグインを使用できます。 プラグインを使用している場合は、2 つの SQL Server 2008 R2 Reporting Services データベースと、SQL Server 2008 R2 Reporting Servicesに必要な追加の負荷をサポートすることを計画します。

注:

SQL Server Reporting Services SharePoint Server 2019との統合はサポートされなくなりました。 詳細については、「Reporting Services レポート サーバー (SharePoint モード)」および「SharePoint と Reporting Services サーバーのサポートされている組み合わせ」を参照してください。

SQL Server と IOPS について

SQL Server インスタンスをホストするサーバーでは、I/O サブシステムからできるだけ速やかに応答することが重要です。

高速なディスクやアレイの数が多ければ多いほど、IOPS (1 秒あたりの入出力操作数) が向上すると同時に、すべてのディスクでの遅延が短く抑えられます。

CPU やメモリなどの他の種類のリソースを追加して、I/O サブシステムからの遅い応答を補正することはできません。 ただし、ファーム全体に影響を与え、問題を引き起こす可能性があります。 デプロイ前の待機時間を最小限に抑え、既存のシステムを監視します。

新しいファームをデプロイする前に、Diskspd ユーティリティを使用して I/O サブシステムをベンチマークすることをお勧めします。 このツールは、すべてのバージョンのSQL Serverを持つすべてのWindows Serverバージョンで動作します。 詳細については、「Diskspd ユーティリティ: 信頼性の高いストレージ テスト ツール」を参照してください。

ストレス テストでも、SQL Server に関する貴重な情報が取られます。 詳細については、「DiskSpd を使ったストレージのベンチマーク テスト」をご覧ください。

SQL Server の視点で IOPS 要求を分析する方法の詳細は、「SQL Server データベース アプリケーションでの I/O 特性の分析およびストレージ システムのサイジング」を参照してください。

コア ストレージおよび IOPS のニーズを見積もる

構成ストレージおよび コンテンツ ストレージおよび IOPS は、SharePoint Server を展開する際に必ず計画する必要がある基底のレイヤーです。

構成ストレージおよび IOPS

構成データベースとサーバーの全体管理コンテンツ データベースのストレージ要件は大きくない。 構成データベースには 2 GB、サーバーの全体管理コンテンツ データベースには 1 GB を割り当てることをお勧めします。 時間の経過と同時に、構成データベースは 1 GB を超える可能性があります。 すぐには拡大しません。50,000 個のサイト コレクションごとに約 40 MB 増加します。

構成データベースのトランザクション ログは大きくなる可能性があります。 切り捨てを強制するために、構成データベースのトランザクション ログを定期的にバックアップすることをお勧めします。 SQL Server Always On の可用性グループまたはデータベース ミラーリングを使用している場合は、データベースを完全復旧モードで実行し続ける必要もあります。 詳細については、「トランザクション ログ (SQL サーバー)」を参照してください。

ヒント

完全復旧モデルの使用が必要な SQL Server の高可用性ソリューションを使用していない場合は、構成データベースを単純復旧モデルに変更することを検討してください。

構成データベースとサーバーの全体管理コンテンツ データベースに必要な IOPS はごくわずかです。

コンテンツストレージおよび IOPS

コンテンツ データベースに必要なストレージと IOPS は、正確に見積もることはできません。 当社がテストを行い、以下の情報を提示しているのは、実際の展開の初期サイズを決める見積もりの基礎として利用していただくためです。 環境の運用中は、実際の環境から得られるデータに基づいて必要な容量を再検討する必要があります。

容量計画の全般的な手順の詳細については、「SharePoint Server 2013 での容量管理と規模設定」をご覧ください。

コンテンツ データベースのストレージを見積もる

以下の手順は、ログ ファイルを考慮しないで、コンテンツ データベースに必要なおおよそのストレージを見積もる方法を示しています。

1. 以下の式を使用してコンテンツ データベースのサイズを見積もります。

   データベース サイズ = ((D x V) x S) + (10 KB x (L + (V x D)))

   注:

   式中の値 10 KB という値は、SharePoint Server で必要とされるメタデータの大きさをざっと見積もった定数です。 メタデータを多用するシステムでは、この定数の値をこれより大きくしたほうがよいこともあります。

2. ドキュメント数の推定値を計算します。 この値は、式中の D に相当します。

   ドキュメント数を計算する方法は、使用する機能によって決まります。 たとえば、個人用サイト またはグループ作業のサイトでは、1 ユーザーあたりのドキュメント数を推定し、その値にユーザー数を乗じて推定値を計算することをお勧めします。 レコード管理サイトやコンテンツ発行サイトでは、ある特定のプロセスによって管理され生成されるドキュメントの数を計算することになるでしょう。

   現在のシステムから移行する場合は、現在の成長率と使用状況に基づいて推定するほうが簡単です。 新しいシステムを構築する場合は、既存のファイル共有やその他のリポジトリを調べ、その使用率に基づいて値を推定してください。

3. 保存するドキュメントの平均的なサイズを推定します。 この値は、式中の S に相当します。 種類ごとまたはサイト グループごとに平均値を推定すると効果的です。 個人用サイト、メディア リポジトリ、部門ポータルによって、平均的なファイル サイズは、大きく異なる可能性があります。

4. 環境内のリスト項目の数を見積もります。 この値は、式中の L に相当します。

   リスト項目数の見積もるのはドキュメントの場合ほど簡単ではありません。 通常、ドキュメント数 (D) の 3 倍の見積もりを使用しますが、推定式はサイトの使用方法によって異なります。

5. バージョン数の概数を決定します。 ライブラリ内のドキュメントが平均していくつのバージョンを持つかを推定してください。 この値は、通常、最大許容バージョン数よりもかなり小さくなります。 この値は、式中の V に相当します。

   V の値はゼロよりも大きくする必要があります。

たとえば、次の表の式と特性を使用して、コラボレーション環境のコンテンツ データベース内のデータ ファイルに必要なストレージ領域を見積もります。 その結果、約 105 GB が必要になります。

Input	Value
ドキュメント数 (D)	200,000 10,000 ユーザー × 20 ドキュメントと仮定して計算
ドキュメントの平均サイズ (S)	250 KB
リスト項目数 (L)	600,000
最新版以外のバージョン数 (V)	2 最大許容バージョン数を 10 と仮定

データベース サイズ = (((200,000 x 2)) × 250) + ((10 KB × (600,000 + (200,000 x 2))) = 110,000,000 KB または 105 GB

注:

SharePoint Server での効率的なファイル入出力とは、ファイルを分割して個別に保存または更新するストレージ方法です。 これらのファイルはユーザーがファイルを要求すると送られます。 この方法で入出力パフォーマンスは向上しますが、通常はファイル サイズが増えることはありません。 ただし、サイズの小さいファイルは必要とされるディスク ストレージがわずかに増えることがあります。

コンテンツ データベースのサイズに影響する機能

以下の SharePoint Server 機能は、コンテンツ データベースのサイズに影響を与えることがあります。

• ごみ箱 ドキュメントは、第 1 段階と第 2 段階の両方のごみ箱から完全に削除されるまでは、コンテンツ データベース内の領域を消費します。 毎月どれだけドキュメントが削除されるかを計算して、コンテンツ データベースのサイズに対するごみ箱の影響を判断してください。

• 監査 監査データは、特に、監査レポートの表示がオンの場合、急速に増大してコンテンツ データベース内の領域を大量に消費することがあります。 監査データが無制限に増えるのを放置しないで、規制や内部統制の条件を満たすイベントについてだけ監査を有効にすることをお勧めします。 次のガイドラインに従って、監査データのために取っておく必要がある領域を見積もってください。

  • サイトに必要な新しい監査エントリの個数を見積もり、その値に 2 KB を掛ける(生成されるエントリのサイズは最大 4 KB で、平均サイズはおよそ 1 KB)。

  • 割り当てる領域の大きさに基づき、監査ログを保持しておく日数を計算する。

注:

Office Online Server は、Office Web Apps Server の次のバージョンです。 SharePoint Server 2016、2019 でOffice Online Serverを使用しても、Subscription Edition はコンテンツ データベースのサイズに影響しません。 お使いの SharePoint Server 2016 ファームに Office Online Server を展開するには、「Deploy Office Online Server」を参照してください。

コンテンツ データベースに必要な IOPS を見積もる

コンテンツ データベースの IOPS 要件は、環境の使用方法、使用可能なディスク領域、および使用しているサーバーの数によって異なります。 一般的には、実際の環境で予想されるワークロードを、Microsoft においてテストされたソリューションのいずれかと比較することをお勧めします。 詳細および新しいバージョンの SharePoint に適用できる方法については、「 パフォーマンスと容量のテストの結果と推奨事項 (SharePoint Server 2013)」を参照してください。

テストの結果、コンテンツ データベースは 0.05 IOPS/GB～約 0.2 IOPS/GB 程度になりやすいことがわかりました。 また、上端を 0.5 IOPS/GB に増やすのがベスト プラクティスだということも把握しました。 この割合の増加は必要以上であり、環境内で必要以上の可能性があります。 ミラーリングを使用する場合、この割合が増加すると、プライマリ コンテンツ データベースよりもはるかに多くの IO が発生します。 ミラー化されたコンテンツ データベースは軽量になることはありません。

サービス アプリケーションの必要なストレージと IOPS を見積もる

コンテンツ ストレージと IOPS のニーズを見積もった後、実際の環境で使用するそれぞれのサービス アプリケーションに必要なストレージと IOPS を決定する必要があります。

SharePoint Server サービス アプリケーションに必要なストレージと IOPS

システム内のサービス アプリケーションに必要なストレージを見積もるためには、最初に各サービス アプリケーションとその使用方法を確認する必要があります。 次の表に、SharePoint Server 2016 で使用できるサービス アプリケーションのうち、データベースを持つものを示します。 SharePoint Server サブスクリプション エディション、2019、または 2016 のすべてのサービス アプリケーションのストレージと IOPS データは、SharePoint Server 2010 および 2013 と同じままです。

Search Service アプリケーションに必要なストレージと IOPS

Database	スケーリング	ディスク IOPS	ディスク サイズ	1,000 万アイテム	1 億アイテム
クロール	2,000 万アイテムあたり 1 DB SQL IOPS: 1 DPS あたり 10	中/高	中	15 GB 2 GB log	110 GB 50 GB log
リンク	6,000 万アイテムあたり 1 DB SQL IOPS: 100 万アイテムあたり 10	中	中	10 GB 0.1 GB log	80 GB 5 GB log
分析レポート	100 - 300 GB に達した場合の分割	中	中	用途による	用途による
Search Administration	1 DB	低	低	0.4 GB 1 GB log	1 GB データ 2 GB log

サービス アプリケーションに必要なストレージと推奨される IOPS

サービス アプリケーション	サイズ見積もりに関する推奨事項
ユーザー プロファイル	User Profile Service アプリケーションは、プロファイル、同期、ソーシャル タグという 3 つのデータベースと関係しています。 注: ユーザー プロファイル データベースのストレージ要件と IOPS に関する推奨事項のテストはまだ完了していません。 追加情報をご確認ください。 User Profile データベース情報については、「データベースの種類と説明 (SharePoint Server)」を参照してください。
Managed Metadata Service	Managed Metadata Service アプリケーションにはデータベースが 1 つ存在します。 このデータベースのサイズは、システム内で使用されるコンテンツ タイプとキーワードの個数に影響されます。 多くの環境には、Managed Metadata Service アプリケーションのインスタンスが複数存在します。
Secure Store Service	Secure Store Service アプリケーション データベースのサイズは、ストア内の資格情報の個数と監査テーブルのエントリ数で決まります。 1,000 個の資格情報ごとに 5 MB を割り当てることをお勧めします。 必要な IOPS はごくわずかです。
State Service	State Service アプリケーションにはデータベースが 1 つ存在します。 このデータベースには 1 GB を割り当てることをお勧めします。 必要な IOPS はごくわずかです。
Word Automation Service	Word Automation Service アプリケーションにはデータベースが 1 つ存在します。 このデータベースには 1 GB を割り当てることをお勧めします。 必要な IOPS はごくわずかです。
PerformancePoint Service	PerformancePoint Service アプリケーションにはデータベースが 1 つ存在します。 このデータベースには 1 GB を割り当てることをお勧めします。 必要な IOPS はごくわずかです。
Business Data Connectivity Service	Business Data Connectivity Service アプリケーションにはデータベースが 1 つ存在します。 このデータベースのサイズは小さく、大きく増大する可能性はほとんどありません。 必要な IOPS はごくわずかです。 PerformancePoint Servicesはサブスクリプション エディションには適用されません。
App Management	App Management Service アプリケーションにはデータベースが 1 つ存在します。 このデータベースのサイズは小さく、大きく増大する可能性はほとんどありません。 必要な IOPS はごくわずかです。
Power Pivot	Power Pivot Service アプリケーションにはデータベースが 1 つ存在します。 このデータベースのサイズは小さく、I/O に大きい影響はありません。 SharePoint コンテンツ データベースと同じ IOPS を使用することをお勧めします。 コンテンツ データベースの I/O 要件は、Power Pivot サービス アプリケーション データベースよりも大幅に高くなっています。

可用性のニーズを決定する

可用性とは、SharePoint Server 環境がユーザーが使用可能であると認識する量です。 使用可能なシステムは回復性のあるシステムです。つまり、サービスに影響を与えるインシデントは発生頻度が低く、発生した場合はタイムリーかつ効果的なアクションが実行されます。

可用性の要件により、ストレージのニーズが大幅に増加する可能性があります。 詳細については、「SharePoint Server の高可用性のアーキテクチャと戦略を作成する」を参照してください。 また、SQL Server 2012 ホワイト ペーパーの 「Always On アーキテクチャ ガイド: Always On 可用性グループを使用した高可用性とディザスター リカバリー ソリューションの構築」も参照してください。

SQL Server のバージョンとエディションを選択する

SharePointServer サブスクリプション エディション、2019、または 2016 については、環境を、以下の SQL Server の Enterprise Edition で実行して、これらのバージョンで提供されるその他のパフォーマンス、可用性、セキュリティ、および管理機能の利用を検討することをお勧めします。

• SQL Server 2019 (SharePoint サブスクリプション エディション、2019、および 2016)

• SQL Server 2017 RTM (SharePoint Server 2016 および 2019)

• SQL Server 2016 (SharePoint Server 2016 および 2019)

• Service Pack 1 (SP1) を適用した SQL Server 2014 (SharePoint Server 2016 のみ)

これらのバージョンの利点の詳細については、「SQL Server 2014 のエディションでサポートされる機能」、SQL Server 2016 のエディションとサポートされている機能、SQL Server 2017 のエディションとサポートされている機能、および SQL Server2019 (15.x) のサポートされる機能に関するページを参照してください。

SharePoint Server 2013 では、Service Pack 1 (SP1)、SQL Server 2012、または SQL Server 2014 の SQL Server 2008 R2 のEnterprise Editionで環境を実行して、これらのバージョンが提供するその他のパフォーマンス、可用性、セキュリティ、管理機能を利用することを検討することをお勧めします。 SQL Server 2008 R2 SP1、SQL Server 2012、および SQL Server 2014 Enterprise Edition の利点を使用するメリットの詳細については、「SQL Server 2016 の各エディションとサポートされている機能」、「SQL Server 2012 の各エディションがサポートする機能」、「SQL Server 2008 R2 の各エディションとサポートされている機能」を参照してください。

特に、以下の機能について必要性を検討してください。

• バックアップ圧縮バックアップの圧縮は SharePoint バックアップを高速化でき、SQL Server 2008 以降のすべてのエディションで利用できます。 バックアップ スクリプトで圧縮オプションを設定するか、SQL Serverを実行しているサーバーを既定で圧縮するように構成することで、データベース バックアップと配布されたログのサイズを大幅に削減できます。 詳細については、「バックアップの圧縮 (SQL Server)」を参照してください。

  注:

  SQL Server のデータ圧縮は、Search Service アプリケーション データベースを除き、SharePoint Server ではサポートされていません。

• 透過的なデータ暗号化 セキュリティ要件に透過的なデータ暗号化が含まれる場合は、SQL Server Enterprise Edition を使用する必要があります。

• コンテンツ展開 コンテンツ展開機能の使用を計画している場合は、システムでデータベース スナップショットを利用できるようにするために SQL Server Enterprise Edition を使用することを検討してください。

  注:

  データベース スナップショットをサポートしないリモート BLOB ストレージ プロバイダーを使用している場合は、コンテンツ展開とバックアップにスナップショットを使用することはできません。

• リモート BLOB ストレージ  コンテンツ データベースごとに関連付けられているファイルとは別に特定のデータベースまたは場所を指すリモート BLOB ストレージを利用する場合は、以下のサーバー製品の Enterprise Edition を使用する必要があります。

  SharePoint Server Subscription Edition:

  • SQL Server 2016

  • SQL Server 2017 RTM

  • SQL Server 2019

  SharePoint Server 2019:

  • SQL Server 2016

  • SQL Server 2017 RTM

  • SQL Server 2019

  SharePoint Server 2016:

  • SQL Server 2014 (SP1)

  • SQL Server 2016

  • SQL Server 2017 RTM

  • SQL Server 2019

  SharePoint 2013:

  • SQL Server 2008 R2 SP1

  • SQL Server 2012 Enterprise Edition

• リソース ガバナー Resource Governorは、SQL Server 2008 で導入されたテクノロジであり、受信要求によるリソース使用量の制限を指定することで、SQL Serverワークロードとリソースを管理できます。 リソース ガバナーを使用すると、ワークロードを区別し、要求された CPU やメモリを自分で決めた制限に基づいて割り当てることができます。 Resource Governorの使用方法の詳細については、「Resource Governor」を参照してください。

  SharePoint Server では、次の目的でリソース ガバナーを使用することをお勧めします。

  • 検索クロール コンポーネントの対象となる Web サーバーが消費する SQL Server リソースの量を制限する。 ベスト プラクティスとして、システムに負荷がかかっているときは、クロール コンポーネントの CPU 使用率を 10 パーセントに制限することをお勧めします。

  • システム内の各データベースで消費されるリソースの量を監視する。たとえば、リソース ガバナーを使用すると、SQL Server を実行している各コンピューターにデータベースをどう配置すればよいかを決めることができます。

• Microsoft Power Pivot for SharePointユーザーがExcel on the webでユーザー生成データ モデルと分析を共有および共同作業しながら、それらの分析を自動的に更新できるようにします。 Power Pivot for SharePoint および SharePoint Server 2016 でExcel on the webを使用するには、Office on the webが必要です。 SharePoint Server 2016 には、SQL Server 2014 (SP1) または SQL Server 2016 RTM Enterprise Edition およびビジネス インテリジェンス用 SQL Server Analysis Services も使用できます。 ただし、SQL Server 2016 RTM には Power Pivot for SharePoint のみが使用可能であり、SQL Server 2014 (SP1) は使用できません。

• Power Pivot for SharePoint 2013 この機能を使用すると、ユーザーはユーザーの生成したデータ モデルや分析を Excel またはブラウザーで共有して共同で作業しながら、それらの分析を自動的に更新できます。 この機能は、SQL Server 2008 R2 Analysis Services (SSAS) Datacenter および Enterprise Edition、SQL Server 2012 SP1 Analysis Services (SSAS) Enterprise Edition、SQL Server 2014 Analysis Services (SSAS) Enterprise および Business Intelligence Edition に含まれています。

容量および I/O の要件に基づいてストレージ アーキテクチャを設計する

実際の環境でどのストレージ アーキテクチャとディスクタイプを使用するかによって、システムのパフォーマンスが影響を受けることがあります。

このセクションの内容

• ストレージ アーキテクチャを選択する

• ディスク タイプを選択する

• RAID タイプを選択する

ストレージ アーキテクチャを選択する

SharePoint Server では Direct Attached Storage (DAS)、Storage Area Network (SAN)、Network Attached Storage (NAS) の各ストレージアーキテクチャがサポートされていますが、コンテンツ データベースがリモート BLOB ストレージを利用するように構成されている場合には NAS のみを使用できます。 どれを選択するかは、ビジネス ソリューションと現在のインフラストラクチャに含まれるさまざまな要因によって変化します。

どのストレージ アーキテクチャも必要な可用性を満たし、適切な IOPS と遅延で実行する必要があります。 この条件を満たすためにシステムは常にデータの 1 バイト目を 20 ミリ秒以内に返す必要があります。

直接接続ストレージ (DAS)

DASは、ストレージ ネットワークを介さないでサーバーまたはワークステーションに直に接続されるデジタル ストレージ システムです。 DAS の物理ディスク タイプには、SAS (Serial Attached SCSI) と SATA (Serial Attached ATA) があります。

一般的に、共有ストレージ プラットフォームが平均およびピーク時の IOPS で 20 ms の応答時間と十分な容量を保証できないときは、DAS アーキテクチャを選択することをお勧めします。

SAN (記憶域ネットワーク)

SAN は、リモート コンピューターの記憶装置 (ディスク アレイおよびテープ ライブラリなど) を、オペレーティング システムにローカルに接続されたデバイスとして表示されるように、サーバーに接続するアーキテクチャです (たとえば、ブロック ストレージ)。

一般的に、共有ストレージのメリットが組織にとって重要な場合は、SAN を選択することをお勧めします。

共有ストレージには次のメリットがあります。

• サーバー間のディスクストレージの再配置が簡単になる。

• 複数のサーバーに対応できる。

• アクセスできるディスクの数に制限がない。

ネットワーク接続ストレージ (NAS)

NAS ユニットは、ネットワークに接続された自己完結的なコンピューターです。 その唯一の目的は、ネットワーク上の他のデバイスにファイル ベースのデータ ストレージ サービスを提供することです。 NAS ユニット上のオペレーティング システムとソフトウェアによって、データ ストレージ、ファイル システム、ファイル アクセスなどの機能と、これらの機能の管理 (ファイル ストレージなど) の管理が実現されます。

注:

NAS は、リモート BLOB ストレージ (RBS) を使用するように構成されたコンテンツ データベースでのみサポートされています。 ネットワーク ストレージ アーキテクチャは、1 ミリ秒以内の ping に応答する必要があり、20 ミリ秒以内にデータの最初のバイトを返す必要があります。 この制限は、ローカル SQL Server FILESTREAM プロバイダーには適用されません。これは、データが同じサーバー上にローカルにのみ格納されるためです。

注:

iSCSI (Internet Small Computer System Interface) を使用する場合に iSCSI を NAS プロトコルとみなすかどうかについては、若干混同があります。 CFIS (Common Internet File System) を介してこの iSCSI ストレージにアクセスする場合、それは NAS プロトコルです。 つまり、RBS を使用するように構成されていないコンテンツ データベースにはこのストレージを使用できません。 しかし、ローカルに接続されたハードディスクを介してこの iSCSI ストレージにアクセスする場合、それは SAN アーキテクチャとみなされます。 つまり、このストレージを NAS に使用できます。

ディスク タイプを選択する

システム内で使用するディスク タイプが信頼性とパフォーマンスに影響することがあります。 他の条件がすべて同じなら、ドライブの容量が大きいほど平均シーク タイムは長くなります。 SharePoint Server は、以下のタイプのドライブをサポートしています。

• SCSI (Small Computer System Interface)

• SATA (Serial Advanced Technology Attachment)

• SAS (Serial-attached SCSI)

• ファイバー チャネル (FC)

• IDE (Integrated Device Electronics)

• ソリッド ステート ドライブ (SSD) またはフラッシュ ディスク

RAID タイプを選択する

RAID (Redundant Array of Independent Disks) は、個々のディスクによるパフォーマンス特性を改善すること (これは複数のディスクにデータをストライピングすることで実現される) と同時に個々のディスクの故障への耐性を高める目的でよく使用されます。

すべての RAID の種類は、SharePoint Server でサポートされています。 ただし、RAID 10 または同等のパフォーマンスを備えたベンダー固有の RAID ソリューションを使用することをお勧めします。

RAID アレイを構成するときは、ファイルシステムをベンダー提供のオフセットに必ず合わせてください。

SQL Server での RAID の準備の詳細については、「RAID」をご覧ください。

必要なメモリを見積もる

SharePoint Server に必要なメモリは、 SQL Server を実行するサーバー上でホストしているコンテンツ データベースのサイズと直接関係しています。

サービス アプリケーションや機能を追加すると、それに伴って要件も厳しくなるものです。 次の表に、推奨するメモリ量のガイドラインを示します。

コンテンツ データベースの合計サイズ	SQL Server を実行するコンピューターの推奨メモリ量
小規模の実稼働環境に展開する場合の最小値	8 GB
中規模の実稼働環境に展開する場合の最小値	16 GB
最大 2 テラバイトの場合の推奨値	32 GB
2 テラバイトから最大 5 テラバイトの範囲の推奨値	64 GB
5 テラバイトを超える場合の推奨値	64 GB 以上の余分なメモリによって SQL Server のキャッシュ速度が向上する

注:

これらの値が SQL Server の最小値として推奨されている値よりも大きいのは、SharePoint Server 環境で必要とされるデータ分布のためです。 SQL Serverシステム要件の詳細については、「SQL Server 2014 をインストールするためのハードウェアとソフトウェアの要件」および「SQL Server 2016 および 2017 のSQL Serverをインストールするためのハードウェアとソフトウェアの要件」を参照してください。

SQL Server の容量制限と仕様の詳細については、「SQL Server のエディション別の計算容量制限」および「SQL Server の最大容量仕様」を参照してください。

必要メモリ量に影響するその他の要因には次が含まれます。

• SQL Server ミラーリングを使用する。

• 15 MB を超えるファイルを頻繁に使用する。

ネットワーク トポロジの要件を把握する

ファーム内とファーム間のネットワーク接続について計画しする必要があります。 遅延の短いネットワークを使用することをお勧めします。

以下に、ベスト プラクティスと推奨方法を示します。

• ファーム内のすべてのサーバーに、SQL Server を実行しているサーバーに対する LAN 接続の帯域幅と遅延を設定します。 遅延が 1 ミリ秒を超えないようにしてください。

• SQL Server を実行しているサーバーがファーム内の他のコンポーネントから遠く離れて展開され、そのネットワーク接続の遅延が 1 ミリ秒を超えるようなワイド エリア ネットワーク (WAN) トポロジは、お勧めしません。このトポロジはまだテストされていません。

• SQL Server、Always On 実装スイート、ミラーリング、ログ配布、またはフェールオーバー クラスタリングを使用してリモート サイトを最新の状態に保つ場合は、適切な WAN ネットワークを計画してください。

• Web サーバーやアプリケーション サーバーに 2 つのネットワーク アダプターを設けることをお勧めします。1 つのネットワーク アダプターでエンド ユーザーのトラフィックを処理し、もう 1 つのアダプターで SQL Server を実行しているサーバーとの通信を処理します。

  注:

  iSCSI を使用する場合、各ネットワーク アダプターがネットワーク通信と iSCI の両方ではなく、どちらか一方の専用となるように設定してください。

SQL Server を構成する

以下のセクションでは、SharePoint Server の SQL Server についての構成計画を説明します。

このセクションの内容

• 必要なサーバーの数を見積もる

• ストレージとメモリを構成する

• SQL Server のオプションを設定する

• データベースを構成する

必要なサーバーの数を見積もる

一般的に、SharePoint Server は SQL Server のスケール アウトを利用するように設計されています。 たとえば、SharePoint Server は、少数の大規模サーバーが存在する環境よりも、SQL Server を実行している多数の中規模サーバーが存在する環境で高いパフォーマンスを発揮します。

SQL Server は、他のファーム ロールを実行しておらず、また他のアプリケーションのデータベースをホスティングしていない専用サーバー上に必ず配置してください。 ただし、開発用のスタンドアロン サーバーまたはパフォーマンスを目的としていないテスト環境にシステムを展開する場合に限り、この推奨事項は当てはまりません。 SQL Server は SharePoint と同じサーバーで実行できますが、より良いパフォーマンスを得るには、別のサーバーで SQL Server を実行することをお勧めします。

次の手順は、SQL Server インスタンスを実行する余分なサーバーを展開するときの一般的なガイダンスです。

• 最大限の能力で稼働する Web サーバーが 4 台を超えたとき、データベース サーバーをもう 1 台追加する。

• 現在のサーバーがメモリ、CPU、ディスク I/O スループット、ディスク容量、またはネットワーク スループットに関してその実効リソース限度に達したとき、データベース サーバーをもう 1 台追加する。

詳細については、「SQL Server のエディション別の計算容量制限」および「SQL Server の最大容量仕様」を参照してください。

Secure Store Service アプリケーションを実行しているときは、資格情報ストレージのセキュリティを高めるためにSecure Storeデータベースを独立したデータベース インスタンス上でホストして一人の管理者だけがそこにアクセスできるようにすることをお勧めします。

ストレージとメモリを構成する

SQL Server を実行しているサーバーでは、CPU ごとに 2 MB 以上の L2 キャッシュを割り当ててメモリのアクセス速度を上げることをお勧めします。

ベンダーの推奨するストレージ構成方法に従う

物理ストレージ アレイを構成するときは、最適なパフォーマンスを得るため、オペレーティング システムの既定の値に頼らず、ストレージ ベンダーの推奨するハードウェア構成方法に従ってください。

ベンダーからの指示がない場合は、Windows Server 2012 R2 に提供されている PowerShell ストレージのコマンドレットを使用することをお勧めします。 詳細については、「Windows PowerShell のストレージ コマンドレット」を参照してください。

可能な限り多くのリソースを提供する

ディスクへの SQL Server I/O チャネルが他のアプリケーション (ページング ファイルや インターネット インフォメーション サービス (IIS) ログなど) で共有されないようにしてください。

可能な限り多くのバス帯域幅を提供します。 バス帯域幅を大きくすると、信頼性とパフォーマンスが向上します。 たとえば、ディスクがバス帯域幅の唯一のユーザーではないことを考えてみましょう。たとえば、ネットワーク アクセスについても考慮する必要があります。

SQL Server のオプションを設定する

SharePoint Server を展開する前に、SQL Server の以下の設定値とオプションを構成する必要があります。

• SQL Serverをホストし、SharePoint Server をサポートするサーバーで統計の自動作成を有効にしないでください。 SharePoint Server では、準備とアップグレードで必要な設定値を構成します。 統計を自動作成すると、クエリの実行プランをSQL Serverの 1 つのインスタンスからSQL Serverの別のインスタンスに変更できます。 そのため、すべての顧客が一貫したサポートを得られるように、SharePoint Server では必要に応じてクエリに暗号化されたヒントを提供して、どのようなシナリオでも最適なパフォーマンスが得られるようにしています。

• 最適なパフォーマンスが得られるように、SharePoint Server データベースをホストする SQL Server インスタンスで、 並列処理の最大限度 (MAXDOP) を 1 に設定することを強くお勧めします。 並列処理の最大限度 を設定する方法の詳細については、「 max degree of parallelism サーバー構成オプションの構成」を参照してください。

データベースを構成する

次のガイダンスは、環境内の各データベースを構成するときのベスト プラクティスです。

データ別にディスクを分類して優先度を付ける

理想的には、tempdb データベース、コンテンツ データベース、データベース、検索データベース、SQL Server 2019、SQL Server 2017 RTM、SQL Server 2016、SQL Server 2014 (SP1)、SQL Server 2012、および SQL Server 2008 R2 SP1 のトランザクション ログを、それぞれ別の物理ハードディスクに配置することが望まれます。

以下に、データの優先度を決めるベスト プラクティスと推奨方法を示します。

• さらに高速のディスク間でデータの優先度を付けるときは、次のように順位を決めます。

  • tempdb データ ファイルとトランザクション ログ

  • データベースのトランザクション ログ ファイル

  • 検索データベース (検索管理データベースは除く)

  • データベースのデータ ファイル

    読み取りが非常に多いポータル サイトでは、ログよりもデータを優先します。

• テストと顧客データは、tempdb のディスク I/O が不足することで SharePoint Server ファームのパフォーマンスが低下する可能性があることを示しています。 この問題を避けるには、tempdb に専用のディスクを割り当ててください。 高いワークロードが予想されるか実際に観測されている場合は (具体的には、読み取りまたは書き込みに平均 20 ミリ秒以上かかっている場合)、ファイルをディスクに分けて配置するか、より高速なディスクに交換することによって、この障害を軽減する必要があります。

• 最適なパフォーマンスを得るには、raid 10 アレイに tempdb を配置します。 tempdb データ ファイルの数はコア CPU の数に等しく、tempdb データ ファイルは同じサイズに設定する必要があります。 この場合、デュアルコア プロセッサは 2 個の CPU と数えます。 ハイパースレッディングをサポートする各プロセッサは、1 個の CPU と数えます。 詳細については、「 tempdb パフォーマンスの最適化」を参照してください。

• データベースのデータ ファイルとトランザクション ログ ファイルを個別のディスクに配置します。 専用のディスクまたはストライプを割り当てるには小さすぎるために (またはディスク スペースが足りないために) ディスクを共用しなければならないファイルについては、利用パターンの異なるファイルを同じディスクに配置して、できるだけアクセス要求が同時に発生しないようにしてください。

• 特定のストレージ ソリューションですべてのログおよび検索データベースの書き込みを最適化するには、その構成方法をストレージ ハードウェアのベンダーに問い合わせてください。

コンテンツ データベースで複数のデータ ファイルを使用する

最適なパフォーマンスを得るためには、次の推奨方法に従ってください。

• データベースのプライマリ ファイル グループ内にのみファイルを作成する。

• ファイルを別のディスクに分散する。

• データ ファイルの数をコア CPU の個数以下にする。 この場合、デュアルコア プロセッサは 2 個の CPU と数えます。 ハイパースレッディングをサポートする各プロセッサは、1 個の CPU と数えます。

• データ ファイルを同じサイズで作成する。

重要

SharePoint Server に組み込まれているバックアップ/復元ツールを使用すれば、複数のデータ ファイルのバックアップと復元を行うことができますが、同じ場所に上書きした場合は、これらのツールで複数のデータ ファイルを異なる場所に復元することはできません。 そのため、コンテンツ データベースで複数のデータ ファイルを使用するときは、SQL Server のバックアップ/復元ツールを使用することを強くお勧めします。 SharePoint Server のバックアップおよび復元の詳細については、「SharePoint Server でのバックアップと回復を計画する」をご覧ください。

ファイル グループの作成と管理の詳細については、「ファイルとファイル グループのアーキテクチャ」をご覧ください。

コンテンツ データベースのサイズを制限して管理性を高める

実際の環境に合わせて管理性とパフォーマンスが向上するように、またアップグレードが容易になるように、データベースのサイズを計画してください。

システム パフォーマンスを確実に得るために、コンテンツ データベースのサイズは 200 GB に制限することを強くお勧めします (200 GB を超えるサイズをサポートする特定の使用シナリオや使用状況を除く)。 コンテンツ データベースのサイズ制限の詳細については、「 SharePoint Server 2016 および 2019 のソフトウェアの境界と制限」の「コンテンツ データベースの制限」セクションを参照してください。

そのサイト コレクションがデータベースの唯一のサイト コレクションでない限り、サイト コレクションは 100 GB を超えないようにすることをお勧めします。この制限を満たしているときは、必要に応じて SharePoint Server の詳細バックアップ ツールを使用してサイト コレクションを別のデータベースに移動できます。

事前にデータおよびログ ファイルの増加を管理する

以下の推奨方法に従い、データ ファイルやログ ファイルの拡大を見越して管理することをお勧めします。

• できるだけ、すべてのデータ ファイルとログ ファイルを、予想される最終サイズまであらかじめ拡大させておきます。

• 安全上の理由から、自動拡張を有効にすることをお勧めします。 既定の自動拡張設定に依存しないでください。 自動拡張を構成する場合は、次のガイドラインを考慮してください。

  • 推奨サイズ (200 GB) を超えるコンテンツ データベースを計画するときは、データベースの自動拡張値を比率ではなくメガバイト単位の固定値に設定します。 この設定により、ファイルのサイズを大きくSQL Server頻度が減ります。 ファイル サイズの拡張は、新たな領域を空のページで埋めるブロッキング操作です。

  • コンテンツ データベースの計算サイズが、次の 1 年以内に推奨される最大サイズ 200 GB に達することが予想されない場合は、 ALTER DATABASE MAXSIZE プロパティを使用して、データベースが 1 年間に到達すると予測される最大サイズに設定します。エラーの余分なマージンは 20% です。 この設定を定期的に見直し、過去の増大率と照らして値がまだ適切であることを確認するようにしてください。

• 拡大とピーク時の利用パターンに対応できるように、使用している各ディスクの全体で少なくとも 25 パーセント程度の空き領域を残すようにします。 RAID アレイにディスクを追加するかストレージの割り当てを増やす方法で増大を管理している場合は、ディスク サイズを念入りに監視して領域が足りなくならないようにしてください。

ストレージと SQL Server のパフォーマンスを検証し監視する

使用しているハードウェアのパフォーマンスとバックアップ ソリューションが、サービス レベル契約 (SLA) の要件を満たしているかをテストしてください。 特に、SQL Server を実行しているコンピューターの I/O サブシステムをテストして、十分なパフォーマンスが得られるか確認します。

使用しているバックアップ ソリューションをテストして、利用可能なメンテナンス期間の間にシステムのバックアップが可能か確認します。 バックアップ ソリューションがビジネス上の SLA の要件を満たせない場合は、Microsoft System Center Data Protection Manager などの増分バックアップ ソリューションの使用を検討してください。

SQL SERVERを実行しているサーバーのリソース コンポーネント (CPU、メモリ、キャッシュ/ヒット率、I/O サブシステム) を追跡することが重要です。 1 つ以上のコンポーネントが低速または過剰な負荷と思われる場合は、現在のワークロードと予測されるワークロードに基づいて適切な戦略を分析します。 詳細については、「パフォーマンスの監視とチューニング」を参照してください。

次のセクションでは、SharePoint Server 環境で稼働する SQL Server データベースのパフォーマンスを監視する手段としてお勧めするパフォーマンス カウンターを示します。 この他、各カウンターの望ましいおおよその値も示します。

パフォーマンスの監視方法とパフォーマンス カウンターの使用方法の詳細については、「Windows パフォーマンス モニター」と「パフォーマンスの監視」を参照してください。

監視する SQL Server カウンター

サーバーの調子を確認するために、SQL Server の以下のカウンターを監視します。

• General Statistics このオブジェクトは、サーバー全体の活動 (現在の接続数、SQL Server インスタンスを実行しているコンピューターに対する 1 秒あたりのユーザー接続数/切断数など) を監視するためのカウンターを提供します。 次のカウンターを監視することを検討してください。

  • User Connections このカウンターは、SQL Server を実行しているコンピューターのユーザー接続数を表します。 この値が基準値から 500 パーセント上昇する場合は、パフォーマンスの低下が見られることがあります。

• Databases このオブジェクトは、一括コピー操作、バックアップと復元のスループット、およびトランザクション ログ活動を監視するためのカウンターを提供します。 トランザクションとトランザクション ログを監視することによって、データベース内でのユーザー活動の量とトランザクション ログの消費状況を調べます。 ユーザー活動の量は、データベースのパフォーマンスのほか、ログ サイズ、ロック、およびレプリケーションに影響することがあります。 ログ活動を監視してユーザー活動およびリソースの利用状況が低レベルであれば、パフォーマンスのボトルネックを特定できます。 次のカウンターを監視することを検討してください。

  • Transactions/sec このカウンターは、特定のデータベースまたはサーバー全体における 1 秒あたりのトランザクション数を表します。 これは基準値としての意味合いが強く、問題の解決に利用されます。

• Locks このオブジェクトは、リソース タイプごとの SQL Server のロックに関する情報を提供します。 以下のカウンターを監視することを検討してください。

  • Average Wait Time (ms) このカウンターは、待ち状態となった各ロック要求の平均待機時間を表します。

  • Lock Wait Time (ms) このカウンターは、直近の 1 秒間に生じたロックの待ち時間を表します。

  • Lock waits/sec このカウンターは、直ちに解決されないためにリソース待ちとなる 1 秒あたりのロック数を表します。

  • Number of deadlocks/sec このカウンターは、SQL Server を実行しているコンピューター上の 1 秒あたりのデッドロック数を表します。 この数は 0 を超えてはなりません。

• Latches このオブジェクトは、SQL Server 内部のラッチと呼ばれるリソース ロックを監視するためのカウンターを提供します。 ラッチを監視してユーザー活動とリソースの利用状況を調べると、パフォーマンスのボトルネックを特定できます。 以下のカウンターを監視することを検討してください。

  • Average Latch Wait Time (ms) このカウンターは、待ち状態となったラッチ要求の平均ラッチ待機時間を表します。

  • Latch Waits/sec このカウンターは、直ちに許可できなかったラッチ要求の数を表します。

• SQL Statistics このオブジェクトは、コンパイルや特定の SQL Server インスタンスに対して送信された要求の種類を監視するためのカウンターを提供します。 クエリのコンパイルおよび再コンパイルの回数や特定の SQL Server インスタンスが受け取るバッチの数を監視すると、SQL Server におけるユーザー クエリの処理速度やクエリ オプティマイザーにおけるクエリの処理効率を示す指標を得ることができます。 以下のカウンターを監視することを検討してください。

  • SQL Compilations/sec このカウンターは、1 秒あたりにコンパイル コード パスが入力された回数を表します。

  • SQL Re-Compilations/sec このカウンターは、1 秒あたりのステートメントの再コンパイル数を表します。

• Buffer Manager このオブジェクトは、SQL Server がデータ ページ、内部データ構造、プロシージャ キャッシュなどを格納するためにメモリをどのように使用するかを監視するカウンターや、SQL Server がデータベース ページを読み書きする際の物理 I/O を監視するカウンターを提供しています。 次のカウンターを監視することを検討してください。

  • Buffer Cache Hit Ratio

  • このカウンターは、バッファー キャッシュ内で見つかったためにディスクから読み取らなくて済んだページの比率を表します。 この比率は、ここ数千回のページ アクセスで得られたキャッシュ ヒット総数をキャッシュ検索総数で割ったものです。 キャッシュからの読み取りはディスクからの読み取りよりも遙かに低負荷なので、この比率は大きいことが望まれます。 一般に、SQL Server の使用可能なメモリを増やすことでバッファー キャッシュのヒット率を高めることができます。

• Plan Cache このオブジェクトは、SQL Server のストアド プロシージャや、その場限りの (または事前に準備された) Transact-SQL ステートメント、トリガーといったオブジェクトを格納するメモリを監視するカウンターを提供しています。 次のカウンターを監視することを検討してください。

  • Cache Hit Ratio

  • このカウンターは、プランを検索したときキャッシュがヒットする比率を表します。

監視する物理サーバー カウンター

SQL Server を実行しているコンピューターの調子を確認するために、以下のカウンターを監視します。

• Processor: % Processor Time: _Total このカウンターは、プロセッサがアプリケーションや Idle 以外のオペレーティング システム プロセスを実行している時間の比率を表します。 SQL Server を実行しているコンピューターでは、このカウンターの値が 50 ～ 75 パーセントの範囲に入るようにしてください。 一定の過負荷が発生する場合は、異常なプロセス アクティビティがあるかどうか、またはサーバーにさらに CPU が必要かどうかを調べます。

• System: Processor Queue Length このカンターは、プロセッサ キュー内のスレッド数を表します。 このカウンターを監視して、値がコア CPU 数の 2 倍より小さくなるようにしてください。

• Memory: Available Mbytes このカウンターは、コンピューター上で実行されるプロセスで利用できる物理メモリ量 (MB) を表します。 このカウンターを監視して、値が利用可能な全物理メモリ量の少なくとも 20 パーセントになるようにしてください。

• Memory: Pages/sec このカウンターは、ハード ページ フォールトを解決するためのディスク ページの読み書きが行われる速度を表します。 このカウンターを監視して、値が 100 未満になるようにしてください。

詳細とメモリのトラブルシューティング方法については、次のリソースを参照してください。

• SQL Server 2014 (SP1) -メモリ使用率の監視

• ディスクの使用量の監視

• CPU 使用率の監視

• SQL Server 2017、SQL Server 2017、& SQL Server 2019 -メモリ使用率の監視

• ディスクの使用量の監視

• CPU 使用率の監視

メモリに関する問題の解決などの詳細については、「メモリ使用率の監視」(SQL Server 2008 R2 SP1 の場合)、「メモリ使用率の監視」(SQL Server 2012 の場合)、「メモリ使用率の監視」(SQL Server 2014 の場合) を参照してください。

監視するディスク カウンター

ディスクの調子を確認するために以下のカウンターを監視します。 次の値は、時間の経過に伴って測定される値を表します。急激なスパイク時に発生する値ではなく、単一の測定値に基づく値ではありません。

• 物理ディスク: % ディスク時間: DataDrive このカウンターは、選択したディスク ドライブが読み取りまたは書き込み要求のサービスをビジー状態にしている経過時間の割合を示します。これは、ディスクのビジー状態を示す一般的なインジケーターです。 PhysicalDisk: % Disk Time カウンターが高い (90% を超える) 場合は、PhysicalDisk: Current Disk Queue Length カウンターをチェックして、ディスクアクセスを待機しているシステム要求の数を確認します。 待機中の I/O 要求の数は、物理ディスクを構成するスピンドルの数の 1.5 から 2 倍以下で維持する必要があります。

• Logical Disk: Disk Transfers/sec このカウンターは、ディスク上の読み取りと書き込みの速度を表します。 このカウンターを使用して拡大傾向を監視し、適宜予測を行います。

• Logical Disk: Disk Read Bytes/sec と Logical Disk: Disk Write Bytes/sec これらのカウンターは、読み取り時または書き込み時におけるディスクからのバイト転送速度を表します。

• Logical Disk: Avg. Disk Bytes/Read このカウンターは、読み取り時にディスクから転送される平均バイト数を表します。 この値はディスクの遅延を反映し、読み取り操作が多いと遅延がいくらか大きくなることがあります。

• Logical Disk: Avg. Disk Bytes/Write このカウンターは、書き込み時にディスクへ転送される平均バイト数を表します。 この値はディスクの遅延を反映し、書き込み操作が多いと遅延がいくらか大きくなることがあります。

• Logical Disk: Current Disk Queue Length このカウンターは、パフォーマンス データの収集時にディスク上でまだ処理が行われていない要求の数を表します。 このカウンターは、値が小さいほど良いことになります。 1 ディスクあたりの値が 2 を超えた場合は、ボトルネックがあることを示唆するので調査が必要です。 そのため、4 つのディスクで構成される論理ユニット (LUN) には、最大 8 の値を使用できます。 これらのボトルネックはバックログを生じさせ、ディスクにアクセスしている現在のサーバーを越えてその影響が伝播し、結局、ユーザー レベルの待機時間が長くなります。 ボトルネックの解消策としては、RAID アレイにディスクを追加する、既存のディスクをより高速のものに取り替える、一部のデータを他のディスクに移動する、などの方法が考えられます。

• 論理ディスク: 平均ディスク キューの長さ このカウンターは、サンプル期間中に選択したディスクに対してキューに登録された読み取り要求と書き込み要求の平均数を示します。 ルールでは、スピンドルごとに未処理の読み取りおよび書き込み要求が 2 つ以下である必要があります。 ただし、この要求数は、ストレージの仮想化と構成間の RAID レベルの違いにより、測定が困難な場合があります。 平均ディスク 待ち時間よりも長いディスク キュー長を組み合わせて探します。 この組み合わせは、ストレージ アレイ キャッシュが過剰に使用されているか、他のアプリケーションとのスピンドル共有がパフォーマンスに影響を与えている可能性があります。

• Logical Disk: Avg. Disk sec/Read と Logical Disk: Avg. Disk sec/Write これらのカウンターは、ディスクの読み取りまたは書き込み操作の平均時間 (秒) を表します。 これらのカウンターを監視して、ディスク操作がディスク能力の 85 パーセント以下にとどまっていることを確認します。 読み取りまたは書き込み操作がディスク能力の 85 パーセントを超えると、ディスク アクセス時間は急激に増加します。 使用しているハードウェアの固有の能力を調べるには、ベンダーの提供するドキュメントを参照するか、Diskspd ユーティリティというストレージ テスト ツールを使用してそれを計算します。 詳細については、「 DISKSPD を使用してワークロード ストレージのパフォーマンスをテストする」を参照してください。

  • 論理ディスク: 平均ディスク秒/読み取り このカウンターは、ディスクからの読み取り操作の平均時間 (秒単位) を示します。 適切に調整されたシステムでは、ログの場合は 1 から 5 ミリ秒 (キャッシュされた配列では理想的には 1 ミリ秒)、データの場合は 4 から 20 ミリ秒 (理想的には 10 ミリ秒未満) の値が理想的です。 待機時間が長いほど、ピーク時に発生する可能性があります。 ただし、高い値が定期的に発生する場合は、原因を調査する必要があります。

  • 論理ディスク: 平均ディスク秒/書き込み このカウンターは、ディスクへの書き込み操作の平均時間 (秒単位) を示します。 適切に調整されたシステムでは、ログの場合は 1 から 5 ミリ秒 (キャッシュされた配列では理想的には 1 ミリ秒)、データの場合は 4 から 20 ミリ秒 (理想的には 10 ミリ秒未満) の値が理想的です。 待機時間が長いほど、ピーク時に発生する可能性があります。 ただし、高い値が定期的に発生する場合は、原因を調査する必要があります。

    RAID 構成を使用しているときの Logical Disk: Avg. Disk Bytes/Read または Logical Disk: Avg. Disk Bytes/Write カウンターについては、次の表に示す式でディスクの入力および出力速度を計算してください。

RAID レベル	式
RAID 0	1 ディスク当たりの I/O 数 = (読み取り数 + 書き込み数) / ディスク数
RAID 1	1 ディスク当たりの I/O 数 = [読み取り数 + (2 × 書き込み数)] / 2
RAID 5	1 ディスク当たりの I/O 数 = [読み取り数 + (4 × 書き込み数)] / ディスク数
RAID 10	1 ディスク当たりの I/O 数 = [読み取り数 + (2 × 書き込み数)] / ディスク数

たとえば、2 台の物理ディスクで構成される RAID 1 システムがあって、カウンターの値が次の表に示すとおりであるとします。

カウンター	Value
Avg. Disk sec/Read**	80
Logical Disk: Avg. Disk sec/Write**	70
Avg. Disk Queue Length**	5

• I/O value per disk は、次のように計算することができます。(80 + (2 × 70))/2 = 110

• disk queue length は、次のように計算することができます。5/2 = 2.5

• この状況は、I/O ボトルネックのボーダーラインにあります。

その他の監視ツール

SQL Server 2008 の sys.dm_io_virtual_file_stats 動的管理ビューでディスクの遅延を監視して傾向を分析することもできます。 詳細については、「sys.dm_io_virtual_file_stats (Transact-SQL)」を参照してください。

SQL Server 2012 for SharePoint Server 2013

Microsoft シニア プロダクト マーケティング マネージャーであり、MicroTechPoint の CEO 兼創設者である Brian Alderman の Bill Baer が、一連のオンライン SQL Server 2012 トレーニング モジュールを提供しています。 これらのオンライン トレーニング モジュールをホストするための Channel 9 Microsoft に感謝します。 次のトレーニング モジュールでは、SharePoint Server 2016 のパフォーマンス、可用性、およびセキュリティを向上させる方法を学習するのに役立つ、SQL Server 2012 データベース設定の詳細について説明します。

• SQL Server 2012 のチューニング (SharePoint 2013): (01) 重要な SQL Server および SharePoint Server の統合

• SQL Server 2012 のチューニング (SharePoint 2013): (02) SQL Server データベース設定のベストプラクティス

• SQL Server 2012 のチューニング (SharePoint 2013): (03) SQL Server のサーバー設定

• SQL Server 2012 のチューニング (SharePoint 2013): (04) SQL Server および SharePoint の可用性

関連項目

概念

SharePoint Server 2016 および 2019 環境内の SQL Server の概要

SharePoint Server 2013 のパフォーマンスを最適化する

SharePoint Server ファーム内の SQL Server のベスト プラクティス

SharePoint Server 2013 の計画、パフォーマンスを計画します。

SharePoint Server 2013 での容量管理と規模設定

SharePoint Server 2013 の容量計画

その他のリソース

SharePoint Server 2013 環境内の SQL Server の概要