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

適用対象:yes-img-13 2013yes-img-162016 yes-img-192019 yes-img-seSubscription Edition no-img-sopSharePoint in Microsoft 365

Service Pack 1 (SP1)、SQL Server 2016、または SQL Server 2017 RTM を使用して、SQL Server 2014 の SharePoint Server 2016 および 2019 リレーショナル データベースを構成して管理する場合は、パフォーマンスとセキュリティを向上させるオプションを選択する必要があります。 同様に、SQL Server 2008 R2 Service Pack 1 (SP1)、SQL Server 2012、および SQL Server 2014 で SharePoint Server 2013 リレーショナル データベースを構成および管理するときも、パフォーマンスとセキュリティを促進するためのオプションを選択する必要があります。

この記事のベスト プラクティスは、SQL Server のインストールと構成から、SharePoint Server を展開し、その後のファームの管理にいたるまで、適用される一連の手順に基づいて並べられています。 大半のプラクティスはすべてのバージョンの SQL Server に適用されます。 SQL Server バージョンに固有のプラクティスは、別のセクションに示されます。

注:

SharePoint Server 2016 ファームでSQL Server ビジネス インテリジェンス コンポーネントの使用を計画している場合は、SQL Server 2016 CTP 3.1 以降を使用する必要があります。 今すぐ SQL Server 2016 CTP 3.1 以降をダウンロードして、SQL Server Power Pivot for SharePoint アドインを使用することができます。 SharePoint 統合モードの SQL Server Reporting Services (SSRS) と SSRS フロント エンド アドインを SQL Server のインストール メディアからインストールすると、Power View も使用できます。

詳細については、新しいホワイトペーパー「SharePoint 2016 での SQL Server 2016 PowerPivot および Power View の展開」をダウンロードしてください。 複数のサーバー SharePoint Server 2016 ファームでのビジネス インテリジェンスの構成と展開の詳細については、「多層 SharePoint 2016 ファームでの SQL Server 2016 PowerPivot および Power View の展開」をダウンロードしてください。

注:

SharePoint Server 2013 ファームで SQL Server ビジネス インテリジェンス コンポーネントの使用を計画する場合、SQL Server 2012 Service Pack 1 (SP1) または SQL Server 2014 を使用する必要があります。 SQL Server 2012 SP1 BI および SharePoint Server 2013 の詳細については、「SharePoint 2013 を使用した SQL Server BI 機能のインストール (SQL Server 2012 SP1)」を参照してください。 SQL Server 2014 と SharePoint Server 2013 について詳しくは、「SQL Server のビジネス インテリジェンス機能のインストール」を参照してください。

重要

この記事のベスト プラクティスは、SQL ServerSharePoint Server のリレーショナル データベース管理システム (RDBMS) に適用されます。

SQL Server の専用サーバーを使用する

ファーム操作に最適なパフォーマンスを確保するために、他のファーム ロールを実行せず、他のアプリケーションのデータベースをホストしない専用サーバーにSQL Serverをインストールすることをお勧めします。 唯一の例外は、Single-Server ファームロールでの SharePoint Server 2016 または 2019 の展開、またはスタンドアロン サーバーでの SharePoint 2013 の展開です。これは開発またはテストを目的としており、運用環境での使用にはお勧めしません。 詳細については、「 SharePoint Server 2016 および 2019 の MinRole および関連サービスの説明」および「SharePointServer 2016 または 2019 を 1 つのサーバーにインストールする」を参照してください。

注:

リレーショナル データベースに専用サーバーを使用するという推奨事項は、仮想環境での SQL Server の展開にも適用されます。

SharePoint Server を展開する前に特定の SQL Server 設定を構成する

一貫性のある動作とパフォーマンスを実現するには、SharePoint Server を展開する前に以下のオプションおよび設定を構成します。

  • 複数の SQL インスタンスの保守に関するパフォーマンスの問題が発生する可能性があるため、デプロイされたデータベース サーバーごとに、SQL Serverの単一インスタンスを使用することをお勧めします。

  • SharePoint コンテンツ データベースで統計の自動作成を有効にしないでください。 統計の自動作成の有効化は SharePoint Server でサポートされていません。 SharePoint Server ではプロビジョニングおよびアップグレード中に必要な設定を構成します。 SharePoint データベースで統計の自動作成を手動で有効化すると、クエリの実行計画が大幅に変更される場合があります。 SharePoint データベースは、統計 (proc_UpdateStatistics) を管理するストアド プロシージャを使用するか、これを実行するために SQL Server を使用します。

  • SharePoint Server 2013 の場合、メンテナンス プランは SharePoint によって管理されます。

    • SQL 統計は、proc_updatestaticsを呼び出す正常性ルール "SharePoint で使用されるデータベースに古いインデックス統計がある" によって管理されます。
    • コンテンツ データベースの [統計の自動更新] プロパティが False に設定されている
  • SharePoint Server 2016 および 2019 の場合、SQL 管理者は SharePoint コンテンツ データベースの メンテナンス プラン を作成する必要があります。

    • SQL 統計は、正常性ルール "SharePoint で使用されるデータベースに古いインデックス統計がある" によって管理されません
    • コンテンツ データベースの統計の自動更新プロパティが True に設定されている `
  • SharePoint データベースをホストする SQL Server のインスタンスに対する並列処理の最大限度 (MAXDOP) を 1 に設定し、単一の SQL Server プロセスがそれぞれの要求を処理するようにします。

    重要

    並列処理の最大限度にその他の数字を設定すると、使用されるクエリ計画が最適でなくなり、SharePoint Server のパフォーマンスを低下させる場合があります。

  • データベースを別のサーバーに簡単に移動できるようにするなど、メンテナンスを簡略化するには、SQL Server のすべてのインスタンスの IP アドレスをポイントする DNS エイリアスを作成します。 DNS またはホスト名のエイリアスの詳細については、SQL Server インスタンスのホスト名エイリアスを追加する方法 を参照してください。

これらの SQL Server 設定およびオプションの詳細については、「SQL Server のオプションを設定する」をご覧ください。

SharePoint Server を展開する前にデータベース サーバーを堅牢にする

SharePoint Server を展開する前にデータベース サーバーを堅牢にする計画をお勧めします。 詳細については、以下をご覧ください。

パフォーマンスと可用性の確保のためにデータベース サーバーを構成する

フロントエンド サーバーおよびアプリケーション サーバーと同様に、データベース サーバーの構成は SharePoint Server の良好な実行に影響します。 他のデータベースと同じサーバー上に存在する必要のあるデータベースもあります。 反対に、他のデータベースと同じサーバー上に配置できないデータベースもあります。 詳細については、「SharePoint Server 2016 および 2019 の MinRole および関連サービスの説明」および「記憶域とSQL Server容量の計画と構成 (SharePoint Server)」を参照してください。

ミラーリングを使用する可用性の高いデータベースのガイダンスについては、「データベース ミラーリング (SQL Server)」を参照してください。

SQL Server フェールオーバー クラスタリングと AlwaysOn 可用性グループ

SQL Server 2012 では、Always On可用性グループ機能が導入されました。 この機能は、高可用性と、データベース ミラーリングやログ配布ソリューションに代わる災害復旧ソリューションです。 Always On可用性グループでは、最大 9 つの可用性レプリカがサポートされるようになりました。

注:

データベース ミラーリングは、SQL Server の将来のバージョンで非推奨になります。 Always On 可用性グループの使用をお勧めします。

可用性グループAlways On Windows Server フェールオーバー クラスタリング (WSFC) クラスターが必要です。 WSFC リソース グループは作成されるすべての可用性グループに作成されます。 詳細については、次のリソースを参照してください。

最適なスループットと管理性のためにストレージをデザインする

データベース サーバーの複数のドライブにデータを分割し、それに優先順位を付けることをお勧めします。 tempdb データベース、コンテンツ データベース、利用状況データベース、検索データベース、およびトランザクション ログを別々の物理ハード ディスクに配置するのが理想的です。 以下のリストではガイダンスを示します。 詳細については、「データベースを構成する」をご覧ください。

  • グループ作業サイトまたは更新を多用するサイトの場合、ストレージ配布に以下のランク付けを使用します。

    最も高くランク付けされたアイテムを最速のドライブに配置する必要があります。

    Rank アイテム
    1 tempdb データ ファイルとトランザクション ログ
    2 コンテンツ データベース トランザクション ログ ファイル
    3 検索データベース (検索管理データベースは除く)
    4 コンテンツ データベース データ ファイル
  • 読み取り指向の高いポータル サイトでは、以下のとおりデータに優先順位を付けて、トランザクション ログを検索します。

    最も高くランク付けされたアイテムを最速のドライブに配置する必要があります。

    Rank アイテム
    1 tempdb データ ファイルとトランザクション ログ
    2 コンテンツ データベース データ ファイル
    3 検索データベース (検索管理データベースは除く)
    4 コンテンツ データベース トランザクション ログ ファイル
  • テストとユーザー データにより、不十分な tempdb のディスク I/O はファーム全体のパフォーマンスを著しく妨げる可能性があることが示されています。 この問題を回避するために、tempdb データ ファイルを格納するドライブに専用ディスクを割り当てます。

  • 最適なパフォーマンスが得られるように、tempdb データ ファイルを格納するドライブに RAID 10 配列を使用します。 tempdb データ ファイルの数は CPU コアの数と同じである必要があり、各 tempdb データ ファイルは同じサイズで設定する必要があります。

  • データベース データおよびトランザクション ログ ファイルを個別のディスクに分割します。 ディスク領域に制限があるためデータおよびログ ファイルがディスクを共有する必要がある場合、別の使用状況パターンを含むファイルを同じディスク上に配置し、同時アクセス要求を最小限に抑えます。

  • 多用されるコンテンツ データベースに複数のデータ ファイルを使用し、それぞれのファイルをそれ自体のディスクに置きます。

  • 管理性を向上させるには、データベース サイズを制限するのではなく、200 GB 以下に保たれるようにコンテンツ データベースを監視および調整します。

    注:

    SQL Server のデータベース サイズを手動で制限する場合、容量を超えたときに予期しないシステムのダウンタイムが発生することがあります。

I/O サブシステムを正しく構成することは、SQL Server システムの最適なパフォーマンスおよび操作にとって非常に重要です。 詳しくは、「ディスク使用量の監視」をご覧ください。

ヒント

データ ファイルとログ ファイルの間で変化するディスク スピードを測定する方法を考慮します。 データベース データにとって最速のドライブが、ログ ファイルにとって最速であるとは限りません。 使用パターン、I/O、およびファイル サイズを考慮してください。

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

事前にデータおよびログ ファイルの増加を管理するための推奨事項を以下に示します。

  • 可能な場合は、すべてのデータ ファイルおよびログ ファイルを予想される最終サイズまで増やすか、定期的に設定された期間 (例: 毎月または 6 カ月ごと、またはファイルの移行中などに新しいストレージが大量に消費されるロールアウト前) に増加させます。

  • 予防的な措置としてデータベースの自動拡張を有効にし、データおよびログ ファイルのディスク領域が不足しないようにします。 次の状況について検討しましょう。

    重要

    自動拡張の使用に関連するパフォーマンスおよび運用の問題を詳細に検討する必要があります。 詳細については、「SQL Server における自動拡張および自動圧縮の構成に関する注意事項」を参照してください。

    • 新規データベース用の既定の設定では 1 MB ずつ増加します。 この既定の自動拡張の設定はデータベースのサイズを増加させるため、既定の設定は使用しないでください。 代わりに、「SQL Server のオプションを設定する」で示されるガイダンスを使用します。

    • 自動拡張の値にパーセンテージではなく、固定の MB 数を設定します。 データベースが大きいほど、拡張増分も大きくする必要があります。

      注:

      SharePoint データベースに自動拡張機能を設定する際は注意が必要です。 データベースの自動拡張をパーセンテージで設定する場合 (例: 10% の増加率)、5 GB のデータベースはデータ ファイルを拡張する必要があるたびに 500 MB ずつ増やされます。 このシナリオではディスク領域が不足する可能性があります。

      たとえば、増分が 100 MB でコンテンツが段階的に増やされ、自動拡大が 10 MB に設定されたシナリオについて検討してみます。 その後突然、新しいドキュメント管理サイトで、非常に大容量のデータ ストレージ (おそらく初期サイズが 50 GB) が必要となったとします。 このような大型の追加がある場合には、10 MB の増分よりも 500 MB の拡張増分の方が適しています。

    • 管理運用システムの場合、自動拡張は予期しない増加に対する単なる緊急対応として考えてください。 日常的にデータおよびログの増加を管理するために、自動拡張オプションを使用しないでください。 その代わり、1 年間の概算サイズに対応できるように自動拡張を設定し、障害に備えて 20% のマージンを追加します。 また、データベースの空き領域が不足してきたり、最大サイズに近づいた場合に受け取る通知を設定します。

  • 増加率とピーク時の使用状況パターンに合わせて、ドライブ間で使用できる領域を少なくとも 25% のレベルに維持します。 RAID 配列にドライブを追加、または管理するストレージをさらに割り当てる場合、ディスク領域が不足しないように厳重に容量を監視します。

SQL Server のストレージおよびパフォーマンスを継続的に監視する

SQL Server のストレージおよびパフォーマンスを継続的に監視し、それぞれの運用データベース サーバーが受ける負荷を十分に処理できるようにすることをお勧めします。 さらに、継続的に監視することで、リソース計画に使用できるベンチマークを確立できます。

リソース監視の包括的なビューを取得します。 SQL Server に固有のリソースに対する監視を制限しないでください。 SQL Server を実行しているコンピューター上のリソース (CPU、メモリー、キャッシュ/ヒット率、および I/O サブシステム) を追跡することも同じくらい重要です。

1 つ以上のサーバー リソースが遅い、または負荷が大きいようであれば、現在および計画されたワークロードに基づいて以下のパフォーマンス ガイダンスを検討してください。

バックアップの圧縮を使用して、バックアップを高速化してファイル サイズを抑制する

バックアップ圧縮は SharePoint のバックアップ操作を高速化します。 これは、SQL Server Standard Edition と Enterprise Edition で使用できます。 使用するバックアップ スクリプトに圧縮オプションを設定するか、SQL Server を既定で圧縮するように設定すると、データベース バックアップと配布ログのサイズを大幅に削減できます。 詳細については、「バックアップの圧縮 (SQL Server)」および「データの圧縮」、または「テーブルまたはインデックスの圧縮の有効化」を参照してください。

謝辞

SharePoint Server Content Publishing チームは、この記事の作成に協力していただいた以下の皆様に感謝の意を表します。

  • SQL Server シニア プログラム マネージャーの Kay Unkroth

  • SQL Server シニア プログラム マネージャーの Chuck Heinzelman

関連項目

概念

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

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

その他のリソース

SharePoint の保護: SharePoint 環境での SQL Server の強化