• [アーティクル]

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

更新日: 2008年9月

 

トピックの最終更新日: 2015-03-09

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

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

  • データベースの整合性のチェック

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

  • サーバーに対する FILL FACTOR の設定

  • データベースが拡大する前の対処またはデータベースの縮小を行うためのデータベース サイズの監視

  • 履歴のクリーンアップ

  • 統計情報の更新

再編成または再構築によりインデックスを最適化する

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

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

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

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

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

断片化は、次の方法で測定できます。

  • SQL Server 2005 で、sys.dm_db_index_physical_stats 動的管理ビューを使用する

  • SQL Server 2000 で、DBCC SHOWCONTIG を使用する

断片化を計算するアルゴリズムは、sys.dm_db_index_physical_stats の方が DBCC SHOWCONTIG より正確であることに注意してください。そのため、sys.dm_db_index_physical_stats で計算された断片化の値の方が高くなります。

sys.dm_db_index_physical_stats で断片化を測定する (SQL Server 2005)

SQL Server 2005 で、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」(https://go.microsoft.com/fwlink/?linkid=128479\&clcid=0x411) を参照してください。

DBCC SHOWCONTIG を使用して断片化を測定する (SQL Server 2000)

データベース テーブルの断片化を測定するには、DBCC SHOWCONTIG 関数を使用して断片化の論理およびエクステント スキャンについてのレポートを取得できます。DBCC SHOWCONTIG の結果の詳細については、「DBCC SHOWCONTIG」(https://go.microsoft.com/fwlink/?linkid=110841\&clcid=0x411) を参照してください。

断片化を測定するには、DBCC SHOWCONTIG によって返されるスキャン密度の値を監視することをお勧めします。完全に連続しているテーブルでは、スキャン密度は 100 になります。

データベースの断片化を緩和する

インデックスの断片化のレベルを下げるには、マイクロソフト サポート技術情報の記事「Windows SharePoint Services 3.0 のデータベースおよび SharePoint Server 2007 データベースを最適化する方法」(https://go.microsoft.com/fwlink/?linkid=110843\&clcid=0x411) で解説されているストアド プロシージャを実行します。

データベースの断片化のレベルを特定した後は、必要性および環境での全体的な変更の割合に基づいて、毎日、毎週、または毎月の頻度でストアド プロシージャを実行するようにスケジュールします。一般的には、少なくとも毎週最適化を実行するようにスケジュールを設定することをお勧めします。また、DBCC CHECKDB REPAIR 操作を実行した後で最適化操作を実行するようにスケジュールすることもお勧めします。

このストアド プロシージャは、コンテンツ データベースのインデックスを変更します。このストアド プロシージャの変更はサポートされていません。SharePoint 製品とテクノロジのコンテンツ データベースに対してサポートされている変更に関する追加情報については、マイクロソフト サポート技術情報の記事「Office サーバー製品によってや Windows SharePoint Services で使用されるデータベースへの変更のサポート」(https://go.microsoft.com/fwlink/?linkid=110844\&clcid=0x411) を参照してください。

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

データベース全体ではなく、特定のテーブルに関連付けられたインデックスを最適化する場合は、インデックスを再編成または再構築できます。詳細については、「クラスタ化インデックスの構造」(https://go.microsoft.com/fwlink/?linkid=128480\&clcid=0x411) を参照してください。

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

インデックスの再構築とは、同じ列、インデックス タイプ、一意性属性、および並べ替え順を使用して、インデックスを構築し直すことを意味します。再構築を行うと、インデックスのスキャンとシークのパフォーマンスが向上します。インデックスの再構築は、オンラインまたはオフラインで実行できます。再構築は、SQL Server 2000 の DBCC DBREINDEX ステートメントと同等の機能です。

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

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

10% 以下

再編成 (オンライン)

10 ～ 75%

再構築 (オンライン)

75% 以上

再構築 (オフライン)

DROP INDEX および CREATE INDEX コマンドの使用は、SharePoint 製品とテクノロジのデータベースではサポートされていないことに注意してください。

再編成および再構築は、SQL Server 2005 の ALTER INDEX ステートメント、SQL Server 2005 の保守ウィザード、SQL Server 2000 の DBCC INDEXDEFRAG および DBCC DBREINDEX ステートメント、または SQL Server 2000 の保守ウィザードを使用して実行できます。ここでは、SQL Server 2005 の方法のみについて詳細に説明します。SQL Server 2000 での方法の詳細については、以下の資料を参照してください。

ALTER INDEX を使用する

ALTER INDEX を使用すると、既存のテーブルまたはビューのインデックスに対して、メンテナンス操作を実行できます。インデックスの無効化、再構築、および再編成に使用でき、必要に応じてインデックスのオプションも設定できます。ALTER INDEX は、DBCC DBREINDEX および DBCC INDEXDEFRAG ステートメントに代わる機能です。

通常、インデックスの再構築は、データベースをオンラインにしたままで行うことができます。これは、オフラインにしてインデックスを再構築しても大きなメリットはないためです。ただし、重要なこととして、インデックスを再構築しているときは、テーブルに共有テーブル ロックが設定され、SELECT 操作を除くすべての操作を実行できなくなることに注意してください。特に、SharePoint 製品とテクノロジのデータベースでは、クラスタ化インデックスが使用されています。クラスタ化インデックスの再構築が行われている間、テーブルには排他テーブル ロックが設定され、エンド ユーザーによるすべてのテーブル アクセスが禁止されます。

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

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 の記述とインデックス作成に関する以下のベスト プラクティスを適用して、拡張性とパフォーマンスのよいレポート ソリューションにすることをお勧めします。Office Project Server 2007 では、主キーの外部にあるこれらの (動的に生成される) テーブルについてはインデックスが作成されません。Microsoft Office サーバー製品インフラストラクチャ更新プログラム では追加機能が提供されています。詳細については、ダウンロード可能な記事「Project 2007 Infrastructure Update Release for Server and Client (英語)」(https://go.microsoft.com/fwlink/?linkid=121912\&clcid=0x411) の「RDS Optimizations for Custom Fields (英語)」の項を参照してください。

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

サーバーに対する FILL FACTOR の設定

FILL FACTOR を使用すると、インデックス データの保存とパフォーマンスをさらに改善できます。インデックスを作成または構築するとき、FILL FACTOR の値 (1 ～ 100) は、各リーフ レベル ページでデータを充填できる領域の割合を示します。残りの領域は、将来の拡大に備えて予約されています。通常は、サーバー全体に適用される既定の FILL FACTOR レベルである 0 が最適な値です。ただし、Microsoft Office SharePoint Server 2007 の場合は、拡大に対応し、断片化を最小にするため、サーバー全体の設定を 70 にするのが最適です。

テーブルまたはインデックスに、個別に FILL FACTOR を設定できますが、その設定は推奨されていません。

インデックスの FILL FACTOR の値を確認するには、sys.indexes カタログ ビューを照会します。ビューの詳細については、「sys.indexes (Transact-SQL)」(https://go.microsoft.com/fwlink/?linkid=128510\&clcid=0x411) を参照してください。

サーバー全体の FILL FACTOR 値を構成するには、sp_configure システム ストアド プロシージャを使用します。詳細については、「sp_configure (Transact-SQL)」(https://go.microsoft.com/fwlink/?linkid=128512\&clcid=0x411) を参照してください。