• [アーティクル]

Project Server 2010 データベースのインデックスを最適化する

 

適用先: Project Server 2010

トピックの最終更新日: 2016-11-30

データベースのメンテナンス タスクは、Transact-SQL コマンドまたはデータベース メンテナンス ウィザードを実行して行うことができます。この記事では、両方の方法について説明します。

Microsoft Project Server 2010 データベースでは、以下のデータベース メンテナンス タスクを行うことをお勧めします。

  • データベースの整合性の確認

  • インデックスの再構成または再構築による最適化

  • サーバーの FILL FACTOR の設定

  • データベースの事前拡張または圧縮に備えてのデータベース サイズの監視

  • 履歴のクリーンアップ

  • 統計情報の更新

再構成または再構築によるインデックスの最適化

データベースの論理および物理記憶域の割り当てに、不十分であったり、物理的に連続していなかったり、効果的に使用できないほど断片化している多数の分散した記憶域領域が含まれる場合に、断片化が発生します。断片化は、テーブルに対して多くの挿入、更新、または削除が行われた場合に発生することがあります。テーブルが断片化すると、そのテーブルで定義されているインデックスも断片化します。

Project Server 2010 では、クラスター キーとして GUID タイプを使用して、同じデータ ページへの競合する同時挿入を回避していますが (ホット スポットの挿入)、これが、テーブルとインデックスの断片化の原因になる可能性があります。新しいレコードは B ツリーの末端ではなくどこにでも挿入でき、ページ (インデックスおよびデータ) の分断が大きくなって断片化が生じる可能性があります。これは、プロジェクト UID を使用する複合キーでクラスター化して、データ ページに関連データが含まれるようにすることで低減されますが、大きいテーブルを定期的に最適化すると、特に Project Server 2010 の大規模な展開では、パフォーマンスが向上します。

時間が経過すると、データベースの断片化によってパフォーマンスが低下し (不要なディスク アクティビティ)、領域の使用状況が非効率になる場合があります。断片化を抑制し、断片化の発生率を最小限に抑えるには、ビジネス要件とデータベース アーキテクチャに基づいて、コンテンツ データベースのサイズを手動で最大限に設定します。たとえば、コンテンツ データベースを 100 GB に制限する必要がある場合は、コンテンツ データベースを作成した後、SQL Server Management Studio でそのサイズを 100 GB に設定します。

テーブルを最適化することもできますが、データベースのパフォーマンスにとってはインデックスを最適化する方が効果的であり、時間もかかりません。この記事では、インデックスを最適化する方法についてのみ説明します。

データベース断片化メンテナンス計画を実装する前に、最も断片化しているテーブルとインデックスを判断し、そのインデックスを再構築または再編成するメンテナンス計画を作成します。

sys.dm_db_index_physical_stats で断片化を測定する

sys.dm_db_index_physical_stats 動的管理ビューを使用して、指定されたテーブルまたはビューのインデックスの断片化を判断します。

断片化を測定するには、[avg_fragmentation_in_percent] の列を監視することをお勧めします。最大限のパフォーマンスを得るには、[avg_fragmentation_in_percent] の値が可能な限りゼロに近くになる必要があります。ただし、値が 0 ~ 10% であれば許容範囲です。

sys.dm_db_index_physical_stats の使用方法の詳細については、「sys.dm_db_index_physical_stats (Transact-SQL)」(https://technet.microsoft.com/ja-jp/library/ms188917.aspx) を参照してください。

データベースの断片化を抑制する

データベースの断片化の抑制の詳細については、ホワイト ペーパー「Database Maintenance for Microsoft SharePoint 2010 Products」の「Measure and reduce fragmentation」を参照してください。ホワイト ペーパーは、「SharePoint Server 2010 のデータベース メンテナンス」からダウンロードできます。

特定のテーブルとそのインデックスの断片化を抑制する

データベース全体ではなく、特定のテーブルに関連付けられたインデックスを最適化するには、インデックスを再編成またはまたは再構築します。詳細については、「クラスタ化インデックスの構造」(https://technet.microsoft.com/ja-jp/library/ms177443.aspx) を参照してください。

インデックスの再編成とは、インデックスのリーフ レベルを再編成することです。インデックスを再編成すると、テーブルとビューのクラスター化インデックスおよび非クラスター化インデックスが最適化され、圧縮されて、インデックスのスキャン パフォーマンスが大きく向上します。再編成は常にオンラインで実行され、ユーザーは基のテーブルを使用できます。

インデックスの再構築とは、同じ列、インデックスの種類、一意性属性、および並べ替え順を使用して、インデックスを再構築することです。再構築により、インデックスのスキャンとシークのパフォーマンスが向上します。インデックスとテーブルの再構築は、オンラインとオフラインで実行できます。

インデックスの断片化のレベルによって、最適化に使用する方法と、オンラインのままにするか、またはオフラインにする必要があるかが決まります。

断片化のレベル 最適化の方法

10% 以下

再編成 (オンライン)

10 ～ 75%

再構築 (オンライン)

75% 以上

再構築 (オフライン)

DROP INDEX コマンドと CREATE INDEX コマンドの使用は、Microsoft SharePoint Server 2010 データベースではサポートされないことに注意してください。

ALTER INDEX を使用する

ALTER INDEX を使用すると、データベース管理者は、既存のテーブルまたはビューのインデックスに対してメンテナンス操作を実行できます。このコマンドを使用すると、インデックスを無効化、再構築、および再編成でき、必要に応じてインデックスのオプションも設定できます。

インデックスをオフラインで再構築しても大きなメリットはないため、ほとんどの場合、インデックスの再構築はデータベースをオンラインにしたままで実行できます。ただし、インデックスを再構築している間、テーブルには共有テーブル ロックが設定され、SELECT 操作以外のすべての操作を実行できなくなるので注意してください。特に、SharePoint Server 2010 データベースでは、クラスター化インデックスが使用されています。クラスター化インデックスの再構築が行われている間、テーブルには排他テーブル ロックが設定され、エンド ユーザーはテーブルにアクセスできません。

次のサンプル スクリプトをカスタマイズして、テーブルのすべてのインデックスを再構築できます。

USE Contoso_Content_1
GO
ALTER INDEX ALL ON [database_name. [ schema_name ] . | schema_name. ]table_or_view_name
REBUILD WITH (FILLFACTOR = 70, SORT_IN_TEMPDB = ON, ONLINE = ON,
STATISTICS_NORECOMPUTE = ON)
GO

レポート データベースに関する特別な考慮事項

ユーザーはレポート データベースで使用できるユーザー設定フィールドとデータに基づいてカスタム レポートを実装すると考えられるので、T-SQL の記述とインデックス作成に関するベスト プラクティスに従って、スケーラブルでパフォーマンスに優れたレポート ソリューションを実現することをお勧めします。Project Server 2010 では、主キーの外部にあるこれらの (動的に生成される) テーブルについてはインデックスが作成されません。

Microsoft カスタマー サポートを利用すると、サポート エンジニアから、作成した追加インデックスの削除や、既存のインデックスに追加した列の削除を求められることがあります。これは、インデックスを追加するとデータ アクセス パスが変化し、場合によっては予期しないパフォーマンスとロック/デッドロックの問題が発生する可能性があるためです。

サーバーの FILL FACTOR の設定

FILL FACTOR を使用すると、インデックス データの保存とパフォーマンスをさらに改善できます。インデックスを作成または再構築するとき、FILL FACTOR の値 (1 ～ 100) によって、各リーフ レベル ページでデータを入力できる領域の割合が決まります。残りの領域は、将来の拡大に備えて予約されます。サーバー全体に適用される 0 という既定の FILL FACTOR レベルは、ほとんどの状況で最適です。ただし、SharePoint Server 2010 の場合は、拡大に対応し、断片化を最小限に抑えるために、サーバー全体の設定を 70 にするのが最適です。

個々のテーブルやインデックスに FILL FACTOR を設定できますが、このような設定はお勧めしません。

インデックスの FILL FACTOR 値を表示するには、sys.indexes カタログ ビューに対してクエリを実行します。ビューの詳細については、「sys.indexes (Transact-SQL)」(https://technet.microsoft.com/ja-jp/library/ms173760.aspx) を参照してください。

サーバー全体の FILL FACTOR 値を構成するには、sp_configure ストアド プロシージャを使用します。詳細については、「sp_configure (Transact-SQL)」(https://technet.microsoft.com/ja-jp/library/ms188787.aspx) を参照してください。