SharePoint Server 2010 のデータベース メンテナンス
トピックの最終更新日: 2016-11-30
概要: Microsoft SharePoint 2010 製品のデータと構成設定をホストするデータベースを管理する方法について説明します。ガイドラインを確認し、推奨のデータベース メンテナンス戦略およびタスクの例について学習します。
適用対象: Microsoft SharePoint Server 2010、Microsoft SharePoint Foundation 2010
著者: Bill Baer、Bryan Porter
技術校閲者: Paul S. Randal (SQLskills.com (英語))
内容
概要
データベース コンソール コマンド (DBCC) CHECKDB を使用して整合性エラーの有無を確認する
DBCC CHECKDB について
DBCC CHECKDB とパフォーマンス
インデックスの断片化を測定して抑制する
オンラインとオフラインでのインデックスの再構築
SQL Server 2008 または 2005 データベース内の断片化を測定する (sys.dm_db_index_physical_stats)
データベースの断片化を抑制する
特定のテーブルとそのインデックスの断片化を抑制する
FILL FACTOR を設定することでインデックスのパフォーマンスを微調整する
データ ファイルを圧縮する
SQL Server 2008 のメンテナンス プランを作成する
まとめ
注意
データベース メンテナンス タスクを実施したり、SharePoint 2010 データベースを変更したりする前に、「Office サーバー製品と Windows SharePoint Services によって使用されるデータベースへの変更のサポート」を参照してください。
概要
Microsoft SharePoint 2010 データベースの円滑な操作には、データベースの日常的なメンテナンスが不可欠です。
SharePoint 2010 データベースの推奨メンテナンス タスクは、以下のとおりです。
データベースの整合性を確認します。
インデックスの再構成または再構築によって、インデックスを最適化します。
サーバーの FILL FACTOR を設定します。
注意
この記事では、データベース メンテナンスについて説明します。容量計画やパフォーマンスについては説明しません。容量または容量計画の詳細については、「ストレージおよび SQL Server の容量計画と構成 (SharePoint Server 2010)」を参照してください。
SharePoint 製品とテクノロジの以前のバージョンでは、インデックスの最適化と統計情報メンテナンスを行うために手動の作業が必要でしたが、SharePoint 2010 では、いくつかの SharePoint Health Analyzer ルールによってこの処理が自動化されます。これらのルールは、データベースのインデックスと統計情報の状態を毎日評価し、以下のデータベースのそれらの項目に自動的に対処します。
構成データベース
コンテンツ データベース
User Profile Service アプリケーションのプロファイル データベース
User Profile Service アプリケーションのソーシャル データベース
Web Analytics Service アプリケーションのレポート データベース
Web Analytics Service アプリケーションのステージング データベース
Word Automation Services データベース
データベース メンテナンス タスクを行うには、Transact-SQL コマンドを実行するか、データベースのメンテナンス ウィザードを実行します。この記事では、使用可能な Transact-SQL コマンドについて説明した後に、Microsoft SQL Server データベース メンテナンス ウィザードを使用してメンテナンス プランを作成する方法について説明します (Microsoft SQL Server 2008 R2 と Microsoft SQL Server 2005 の詳細な例も含まれます)。
データベース コンソール コマンド (DBCC) CHECKDB を使用して整合性エラーの有無を確認する
日常的なメンテナンス操作は、データとインデックスが破損していないことを確認する整合性チェックから始めます。データベース コンソール コマンド (DBCC) CHECKDB ステートメントを使用して、データおよびインデックス ページの内部整合性チェックを実行できます。
ほとんどの場合、データベースの整合性の問題は、I/O サブシステムのエラーによって発生します。ただし、他の要因やイベントもデータベースの整合性に影響する可能性があります。たとえば、データベース サーバーの不適切なシャットダウンやドライブの障害です。顕著なパフォーマンスの問題や可用性の問題は、場合によって、基盤となるデータベースの一貫性の問題を表している可能性があります。データベースの整合性チェックは、SharePoint 2010 データベースに対して週に 1 回以上実行します。また、データベース サーバーまたは I/O サブシステムの障害のようなイベントが発生したときに実行します。
DBCC CHECKDB について
DBCC CHECKDB では、以下の操作が実行され、指定されたデータベース内のすべてのオブジェクトの論理的および物理的な整合性が確認されます。
DBCC CHECKALLOC に相当する操作を実行し、データベース内の割り当て構造を確認します。
データベース内のすべてのテーブルおよびビューに対して DBCC CHECKTABLE に相当する操作を実行し、それらの論理的および物理的な整合性を確認します。
データベースに対して DBCC CHECKCATALOG に相当する操作を実行し、データベース内のメタデータの整合性を確認します。
DBCC CHECKDB では、可能性のある最大範囲のエラーが特定されるため、このコマンドを運用環境で安全に実行できます。したがって、個々の操作 (DBCC CHECKALLOC、DBCC CHECKTABLE、および DBCC CHECKCATALOG コマンド) を実行するのではなく、DBCC CHECKDB を実行することをお勧めします。
DBCC CHECKDB では、多くのメモリ、I/O、および CPU リソースが使用されます。DBCC CHECKDB を運用システムで実行する代わりに、異なるサーバーに復元した SharePoint データベースのバックアップ上で実行できます。これにより、整合性チェックのワークロードが運用システムから移されます。
まず DBCC CHECKDB を実行し、次にエラーが発生した場合は最新のバックアップを使用して、影響を受けたデータベースを復元することをお勧めします。
重要
DBCC CHECKDB WITH REPAIR_ALLOW_DATA_LOSS は実行できません。ただし、DBCC_CHECKDB WITH REPAIR_FAST および REPAIR_REBUILD は実行できます。これらのコマンドは、関連付けられたデータベースのインデックスのみを更新するためです。
次に、DBCC CHECKDB のサンプル出力を示します。
DBCC results for 'Contoso_Content_1'.
Service Broker Msg 9675, State 1: Message Types analyzed: 14.
Service Broker Msg 9676, State 1: Service Contracts analyzed: 6.
Service Broker Msg 9667, State 1: Services analyzed: 3.
Service Broker Msg 9668, State 1: Service Queues analyzed: 3.
Service Broker Msg 9669, State 1: Conversation Endpoints analyzed: 0.
Service Broker Msg 9674, State 1: Conversation Groups analyzed: 0.
Service Broker Msg 9670, State 1: Remote Service Bindings analyzed: 0.
DBCC results for 'sys.sysrowsetcolumns'.
There are 2663 rows in 21 pages for object "sys.sysrowsetcolumns".
DBCC results for 'sys.sysrowsets'.
There are 309 rows in 4 pages for object "sys.sysrowsets".
...more
CHECKDB found 0 allocation errors and 0 consistency errors in database 'Contoso_Content_1'.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.
SQL Server 2008 で DBCC CHECKDB を使用する方法の詳細については、「DBCC CHECKDB (Transact-SQL)」を参照してください。
DBCC CHECKDB とパフォーマンス
DBCC CHECKDB はリソース (I/O、CPU、メモリ、および tempdb 領域) を大量に消費するため、運用が行われていない時間に整合性チェックを実行することをお勧めします。一般に、DBCC CHECKDB はブロッキング ロックを取得すると誤解されていますが、SQL Server 2000 以前からこれは事実ではなくなりました。詳細については、「A SQL Server DBA myth a day: (2/30) DBCC CHECKDB causes blocking (英語)」を参照してください。
DBCC CHECKDB を実行すると、運用システムの大量のリソースが使用される場合があります。この場合、テーブルごとに整合性チェックを実行しないでください。運用システムでの整合性チェックのオーバーヘッドを軽減する最適な方法は、以下のオプションの 1 つを使用することです。
WITH PHYSICAL_ONLY オプションを使用して、CPU およびメモリの使用率を下げます。
別の SQL Server にデータベース バックアップを復元し、復元したデータベースのコピーに対して整合性チェックを実行します。
これらのオプションの詳細については、Paul S. Randal のブログ記事「CHECKDB From Every Angle: Consistency Checking Options for a VLDB (英語)」を参照してください。
インデックスの断片化を測定して抑制する
インデックスの断片化が発生するのは、テーブルまたはインデックス (インデックス キーによって定義される) 内のページの論理的な順序がデータ ファイル内のページの物理的な順序と異なる場合です。また、インデックスの断片化は、データ ファイル ページのデータ密度が低いことを意味する可能性があるため、結果的にディスク領域、メモリ、および I/O が浪費されます。インデックスの断片化は、テーブルに対して大量の挿入、更新、または削除が行われた結果として発生する可能性があります。以下の図に、新しく構築された断片化されていないインデックスと、大量の挿入、更新、および削除が行われた後の断片化されたインデックスとの比較を示します。赤い矢印はインデックスの物理的な順序を示し、黒い矢印はインデックス ページの論理的な順序を示します。
図 1. 断片化されていないインデックス (画像ソース: Paul S. Randal)
.jpg "非断片化インデックス")
図 2. 断片化されたインデックス (画像ソース: Paul S. Randal)
.jpg "断片化インデックス")
挿入、更新、および削除は、テーブルおよびインデックスの行全体にわたって均等に分散されないため、各ページのフルネス (データ密度) は時間と共に変化する可能性があります。テーブルのインデックスの一部またはすべてをスキャンするクエリの場合、断片化によって追加のページ読み取りが発生し、データの並行スキャンが妨げられたり、検索のパフォーマンスが大きな影響を受けたりする可能性があります。
インデックスの断片化によって、パフォーマンスが低下したり、領域が非効率的に使用されたりする可能性があります。インデックスは、中程度の使用量のみのデータベースですぐに断片化する場合があります。
インデックスの断片化のメンテナンス プランを実施する前に、最も断片化されたテーブルおよびインデックスを確認します。次に、それらのインデックスを再構築または再構成するためのメンテナンス プランを作成します。
たとえば、SharePoint 2010 でよく断片化が発生するテーブルは AllDocs です。このテーブルには、ドキュメント ライブラリ、ドキュメント ライブラリに関連付けられたドキュメントとリストおよびリスト アイテム、およびそれらの各メタデータが含まれます。
インデックスの断片化レベルは、論理的な順序と物理的な順序が異なるインデックス ページの割合 (パーセンテージ) で示されます。
オンラインとオフラインでのインデックスの再構築
オンラインでのインデックス再構築は、SQL Server Enterprise、Developer、および Evaluation エディションでのみ使用できます。この記事で説明する方法については、この制限を考慮しています。特定のデータベースをホストする SQL Server のエディションがオンラインでのインデックス再構築をサポートしていない場合、または再構築するインデックスがオンラインでのインデックス再構築の対象でない場合は、この記事の手順はオフラインでのインデックス再構築に戻ります。データ型が NVARCHAR(MAX)、IMAGE の列など、ラージ オブジェクト (LOB) 列が存在すると、インデックスはオンラインでの再構築の対象とならない場合があります。
オンラインでのインデックス再構築の詳細については、「オンライン インデックス操作の動作原理」を参照してください。オフラインでのインデックス再構築を行うと、再構築処理中にテーブル レベルのロックが取得されるため、テーブルへの書き込みやテーブルへのアクセスもできなくなります。SharePoint データベースの多くのインデックスは、LOB 列があるため、常に、オフラインでのインデックス再構築を使用して再構築されます。
オンラインでのインデックス再構築を使用する場合も、操作中の 2 つの時点でテーブル ロックが一瞬保持されるため、ブロックが発生する可能性があります。したがって、常に、活動が少ない期間にインデックス再構築作業をスケジュールすることをお勧めします。
SQL Server 2008 または 2005 データベース内の断片化を測定する (sys.dm_db_index_physical_stats)
SQL Server 2008 または 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 の結果の例です。1 つの行の avg_fragmentation_in_percent の値が 9.375 を示しています。
|
|
|
|
10 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
sys.dm_db_index_physical_stats 動的管理ビューを使用するには
タスクバーで、[スタート] ボタンをクリックし、[すべてのプログラム]、[Microsoft SQL Server 2008] の順にポイントして、[SQL Server Management Studio] をクリックします。
データベース オブジェクトで
sys.dm_db_index_physical_statsを使用するには、データベース ID とオブジェクト ID を把握する必要があります。オブジェクト エクスプローラーでコンテンツ データベースを選択し、[新しいクエリ] をクリックします。次のスクリプトを実行します。
SELECT DB_ID() AS [Database ID];注意
データベース名を指定しないで
DB_IDを使用する場合、現在のデータベースの互換性レベルが 100 (a SQL Server 2008 データベース) または 90 (SQL Server 2005 データベース) である必要があります。以前のバージョンの SQL Server からアップグレードしている場合、データベース名をDB_IDステートメントに指定する必要があります。互換性レベルの詳細については、「sp_dbcmptlevel (Transact-SQL)」を参照してください。選択したデータベースまたはオブジェクトに対して
sys.dm_db_index_physical_statsを実行します。データベースのほかにテーブルやインデックスも指定できます。sys.dm_db_index_physical_statsを実行する場合は次の構文を使用します。sys.dm_db_index_physical_stats ( { database_id | NULL | 0 | DEFAULT } , { object_id | NULL | 0 | DEFAULT } , { index_id | NULL | 0 | -1 | DEFAULT } , { partition_number | NULL | 0 | DEFAULT } , { mode | NULL | DEFAULT } )sys.dm_db_index_physical_statsDMV は大量のリソースを消費する可能性があるため、これを使用する場合は注意する必要があります。このさまざまな使用方法を説明する包括的なガイドについては、「Inside sys.dm_db_index_physical_stats (英語)」を参照してください。
データベースの断片化を抑制する
次のガイダンスを使用して、インデックスの断片化のレベルを下げます。
データベース メンテナンスの Health Analyzer ルールを実行する
SharePoint 2010 には、Health Analyzer ルールのフレームワークが含まれます。このフレームワークには、SharePoint 環境の状態を監視したり、場合によって、アクションを実行して特定の種類の問題を解決したりする多くのルールが含まれます。
SharePoint 2010 には、コンテンツ データベースのメンテナンスに関するいくつかのルールが含まれます。これらのルールには、いくつかの SharePoint データベースのインデックスの断片化を自動的に抑制するルールや、古い統計情報がないかどうかを確認し、必要に応じて更新するルールがあります。これらの Health Analyzer ルールは、SharePoint 製品とテクノロジの Service Pack 2 で導入された、更新された "データベースの統計情報" タイマー ジョブを置き換えます。既定では、このルールは、スケジュールに基づいて実行されるように構成されています。スケジュールは、毎日、毎週実行されるものから、オンデマンド、ルールのターゲットに応じて実行されるものまでさまざまです。
毎日実行されるように構成されたすべての Health Analyzer ルールのうち、特定の SharePoint サービスに関連付けられたルールは、同じタイマー ジョブによって実行されます。このタイマー ジョブのスケジュールを調整すると、毎日実行されるように構成された Health Analyzer ルールのうちそのサービスに関連付けられたルールの実行時刻が調整されます。この記事で説明されているすべてのルールは SharePoint Timer Service に関連付けられます。
別の間隔 (毎週など) に基づいて実行されるように構成されたか、別のサービスに関連付けられた Health Analyzer ルールには、それぞれ別のタイマー ジョブがあります。毎週実行するように Health Analyzer ルールを構成した場合、その Health Analyzer ルールに関連付けられた特定のサービスに対して毎週実行されるように構成されたタイマー ジョブを使用してそのルールが実行されます。つまり、ルールは、そのタイマー ジョブに対して定義されたスケジュールに基づいて実行されます。
サーバーの全体管理の Health Analyzer ルール ページで、リボンの [今すぐ実行] をクリックすることで、Health Analyzer ルールを手動で実行できます。このルールを実行すると、インデックスと統計情報の状態が評価されます。また、必要に応じて、インデックスの再構築と再計算が実行されます。
SharePoint で使用されているデータベースのインデックスが断片化されています。このルールを実行すると、以下のタスクが実行されます。
このルールは、インデックスが断片化されているとして報告しています。インデックスの状態を評価する操作には高い負荷がかかります。したがって、Health Analyzer ルールが実行された後、このルールは、常に、インデックスが断片化されているとして報告し、修正処理を起動します。
SharePoint データベースごとに、このルール操作によって、
proc_DefragmentIndicesストアド プロシージャが検索され、見つかった場合はそのストアド プロシージャが実行されます。これにより、データベース内のすべてのインデックスのリストが構築されます。各インデックスで、現在の断片化レベルが評価されます。断片化が 30% を超えるインデックスは再構築が考慮されます。SQL Server のエディションがオンラインでのインデックス再構築をサポートする場合、インデックスごとにオンラインでのインデックス再構築が試行されます。これが失敗した場合 (LOB 列のために、基盤となるインデックスがオンラインでの再構築をサポートしていない場合など)、オフラインでのインデックス再構築が実行されます。
前述のとおり、このルールは、SharePoint 環境内のすべてのデータベースで機能するとは限りません。特定のデータベースでは、別のルールを使用して、同様のメンテナンス作業が実行されます。
検索 - インデックスが断片化されているプロパティ データベースがあります。 このルールは、SharePoint 2010 エンタープライズ検索のプロパティ データベース内のインデックスを保守します。既定では、このルールは、ファーム内のすべてのサーバーに対して毎週実行されるように構成されています。このルールのすべての処理 (修正処理を含む) は、ルールの Check フェーズ中に実行されます。つまり、エンタープライズ検索のプロパティ データベースのインデックスの再構築を管理する場合、インデックスの再構築を自動的に実行しないようにこのルールを構成するだけでは不十分です。SharePoint 2010 でインデックスのメンテナンス操作を自動的に実行しないようにする場合、ルールを完全に無効にする必要があります。
"Search - One or more property databases have fragmented indices" を実行すると、以下のタスクが実行されます。
このルールは、環境が、インデックスの再構築を安全に実行できる状態であることを確認します。
ローカル ファーム内の検索アプリケーション用に構成されたプロパティ データベースごとに、ルールは、
proc_MSS_DefragSearchIndexesストアド プロシージャを実行します。これにより、断片化の平均が 10% を超えるすべてのインデックスのリストが構築されます。プロパティ データベースのパフォーマンスに影響する、リスト内の各インデックスが再構築されます。SQL Server のエディションがオンラインでのインデックス再構築をサポートする場合、オンラインでのインデックス再構築が実行されます。オンラインでのインデックス再構築が試行され、それが失敗した場合、インデックスはオフラインで再構築されます。
検索 - 1 つ以上のプロパティ データベースに断片化されたインデックスがあります。このルールは、SharePoint 2010 エンタープライズ検索のプロパティ データベース内のインデックスを保守します。既定では、このルールは、ファーム内のすべてのサーバーに対して毎週実行されるように構成されています。このルールのすべての処理 (修正処理を含む) は、ルールの Check フェーズ中に実行されます。つまり、エンタープライズ検索のプロパティ データベースのインデックスの再構築を管理する場合、インデックスの再構築を自動的に実行しないようにこのルールを構成するだけでは不十分です。SharePoint 2010 でインデックスのメンテナンス操作を自動的に実行しないようにする場合、ルールを完全に無効にする必要があります。
"Search - One or more property databases have fragmented indices" を実行すると、以下のタスクが実行されます。
このルールは、環境が、インデックスの再構築を安全に実行できる状態であることを確認します。
ローカル ファーム内の検索アプリケーション用に構成されたプロパティ データベースごとに、ルールは、
proc_MSS_DefragSearchIndexesストアド プロシージャを実行します。これにより、断片化の平均が 10% を超えるすべてのインデックスのリストが構築されます。プロパティ データベースのパフォーマンスに影響する、リスト内の各インデックスが再構築されます。SQL Server のエディションがオンラインでのインデックス再構築をサポートする場合、オンラインでのインデックス再構築が実行されます。オンラインでのインデックス再構築が試行され、それが失敗した場合、インデックスはオフラインで再構築されます。
検索 - 1 つ以上のクロール データベースに断片化されたインデックスがあります。このルールは、SharePoint 2010 エンタープライズ検索のクロール データベース内のインデックスを保守します。既定では、このルールは、オンデマンドのみで実行されるように構成されています。実行する場合、ファーム内のあらゆるサーバーからこのルールを実行できます。
データベースの断片化の有無をチェックする操作には負荷がかかるため、このルールはクロール データベース内のインデックスが断片化されているとして報告しています。このルールの "修復" 作業を単に無効にすると、クロール データベースのインデックスの再構築が最近行われた場合でも、すべてのクロール データベースが正常でないという報告が出力されます。
クロール データベース内のインデックスを手動で保守するには、"Search - One or more crawl databases may have fragmented indices" ルールを完全に無効にします。
"Search - One or more crawl databases may have fragmented indices" を実行すると、以下のタスクが実行されます。
このルールは、環境が、インデックスの再構築を安全に実行できる状態であることを確認します。
ローカル ファーム内の検索アプリケーション用に構成されたクロール データベースごとに、このルールは、
proc_MSS_DefragGathererIndexesストアド プロシージャを実行します。リスト内のクロール データベースの各インデックスが再構築されます。SQL Server のエディションがオンラインでのインデックス再構築をサポートする場合、オンラインでのインデックス再構築が実行されます。オンラインでのインデックス再構築が試行され、それが失敗した場合、インデックスはオフラインで再構築されます。
重要
"Search - One or more crawl databases may have fragmented indices" ルールは、断片化レベルに関係なく、すべてのクロール データベース内のすべてのインデックスを再構築します。また、クロール データベースをホストする SQL Server のエディションでページ レベルのデータ圧縮がサポートされている場合は、このルールによってページ レベルのデータ圧縮も実行できます。
クロール データベースの性質上、通常は、このデータベースの最適化を頻繁に実行する必要はありません。コンテンツに対してフル クロールを最初に実行した後にこのルールを実行します。その後は、クロール データベース内のインデックスを監視して断片化の有無を確認し、インデックスの断片化が増大した場合にこのルールを実行します。インデックスの断片化は、クロールされた大量のコンテンツの突然の追加または削除によって発生する場合があります。たとえば、環境のクリーンアップによるコンテンツの排除時、または新しいコンテンツ ソース (ファイル共有、大規模の SharePoint Web アプリケーションなど) の搭載後に発生する場合があります。
以下のデータベースには、自動メンテナンス メカニズムが用意されていません。通常、これらのデータベースはあまり断片化されません。これらのデータベースの断片化を監視して、断片化が 30% を超えた場合にこれらのデータベースのインデックスを再構築します。
検索管理データベース
Secure Store データベース
State Service データベース
Profile Sync データベース
利用状況データベース
Managed Metadata データベース
Business Connectivity Services データベース
PerformancePoint Services データベース
SharePoint 2010 データベースでサポートされる変更点の詳細については、Microsoft サポート技術情報の「Office サーバー製品と Windows SharePoint Services によって使用されるデータベースへの変更のサポート」を参照してください。
大量に断片化されたデータベースまたはテーブルを頻繁に最適化しても、そのパフォーマンスが目に見えて向上しない場合、I/O サブシステムのパフォーマンスを確認する必要があります。
特定のテーブルとそのインデックスの断片化を抑制する
データベース全体ではなく、特定のテーブルに関連付けられたインデックスを最適化するには、インデックスを再構成または再構築できます。
インデックスの再構成とは、インデックスのリーフ レベルを再構成することです。インデックスを再構成すると、テーブルとビューのクラスター化インデックスおよび非クラスター化インデックスが最適化されて圧縮されるため、インデックスのスキャン パフォーマンスが大きく向上する可能性があります。インデックスの再構成では、インデックスに割り当てられた既存の領域が使用されます。再構成は常にオンラインで実行されるため、ユーザーは基盤となるテーブルを使用できます。
インデックスの再構築とは、インデックスのまったく新しいコピーが構築されることです。したがって、再構築操作では、断片化された古いインデックスを削除する前に、インデックスの新しいコピーを構築するための十分な特別領域が必要です。再構築により、インデックスのスキャンとシークのパフォーマンスが向上します。インデックスとテーブルの再構築は、オンラインとオフラインで実行できます。
インデックスの断片化のレベルによって、インデックスの最適化に使用する必要がある方法が決まるとともに、インデックスをオンラインのままにできるか、またはインデックスをオフラインにする必要があるかが決まります。以下の表で、各断片化レベルでの推奨断片化の方法について説明します。
| 断片化のレベル | 最適化の方法 |
|---|---|
10% 以下 |
再編成 (オンライン) |
10 ～ 75% |
再構築 (オンライン) |
75% |
再構築 (オフライン) |
注意
SharePoint 2010 データベースでは、DROP INDEX および CREATE INDEX コマンドの使用はサポートされません。
インデックスの再構成および再構築を行うには、SQL Server 2008 または SQL Server 2005 の ALTER INDEX ステートメント、あるいは SQL Server 2008 または SQL Server 2005 のメンテナンス プラン ウィザードを使用できます。この記事では、SQL Server 2008 または SQL Server 2005 のオプションのみを詳細に説明します。
ALTER INDEX を使用する
ALTER INDEX を使用すると、データベース管理者は、テーブルまたはビューのインデックスに対してメンテナンス操作を実行できます。これを使用して、インデックスの無効化、再構築、および再構成ができます。また、これを使用して、インデックスにオプションを設定できます。ほとんどの場合、データベースがオンライン状態の間にインデックスを再構築できるため、オフラインでのインデックス再構築よりもユーザーに対するデータの可用性が向上します。
重要
SQL Server 2000 では、インデックスのメンテナンスに対して DBCC DBREINDEX および DBCC INDEXDEFRAG がサポートされました。これらのコマンドは、SQL Server 2005 以降から使用できなくなり、SQL Server の今後のバージョンでは削除されます。SharePoint 2010 データベースのインデックス メンテナンスを実行するのに、これらのコマンドを使用しないでください。
注意
インデックスをオフラインで再構築する場合、テーブルに共有テーブル ロックが設定されるため、SELECT 以外のすべての操作が実行できなくなります。SharePoint 2010 データベースでは、特に、クラスター化インデックスが使用されています。クラスター化インデックスをオフラインで再構築する場合、テーブルに排他テーブル ロックが設定されるため、ユーザーはテーブルにアクセスできなくなります。
次のサンプル スクリプトをカスタマイズして、テーブルのすべてのインデックスを再構築できます。
USE Contoso_Content_1
GO
ALTER INDEX ALL ON [database_name. [ schema_name ] . | schema_name. ]table_or_view_name
REBUILD WITH (FILLFACTOR = 80, SORT_IN_TEMPDB = ON,
STATISTICS_NORECOMPUTE = ON)
GO
FILL FACTOR を設定することでインデックスのパフォーマンスを微調整する
インデックス データの保存とパフォーマンスをさらに向上するには、FILL FACTOR を使用します。インデックスを作成または再構築するときに、FILL FACTOR の値 (1 ～ 100) によって、各リーフ レベル ページでデータを入力できる領域の割合が決まります。残りの領域は、将来の拡大に備えて予約されます。サーバー全体に適用される既定の FILL FACTOR レベル 0 (各ページで 100% まで入力する) は、ほとんどの状況で最適です。ただし、SharePoint 2010 の場合は、拡大に対応し、断片化を最小限に抑えるために、サーバー全体に適用される設定を 80 にすることをお勧めします。
注意
個々のテーブルやインデックスに対して FILL FACTOR を設定することはお勧めしません。SharePoint SQL Server データベース以外のデータベースでは、この方法が推奨されますが、テストでは、SharePoint データベースは 80% の FILL FACTOR で最適に動作することが示されています。
1 つ以上のインデックスの FILL FACTOR 値を表示するには、sys.indexes カタログ ビューに対してクエリを実行します。ビューの詳細については、「sys.indexes (Transact-SQL)」を参照してください。
サーバー全体の FILL FACTOR 値を構成するには、sp_configure システム ストアド プロシージャを使用します。詳細については、「spconfigure (Transact-SQL)」を参照してください。
データ ファイルの圧縮
SQL Server 2008 および SQL Server 2005 では、データベース内の各ファイル (ファイル名拡張子が .mdf, .ldf、および .ndf) を圧縮して、未使用のページを削除し、ディスク領域を回復できます。SharePoint 2010 データベースでは、多くのアクティビティによってデータベース内に未使用領域が作成されますが、データ ファイルは自動的に圧縮されません。未使用領域を作成する可能性があるアクティビティには、Move-SPSite Windows PowerShell コマンドの実行や、ドキュメント、ドキュメント ライブラリ、リスト、リスト アイテム、およびサイトの削除があります。
図 3. データベースの割り当て
.jpg "データベースの割り当て")
空き領域は、ファイルの終端からのみ解放されます。たとえば、60 GB のコンテンツ データベース ファイルがあり、目標のサイズとして 40 GB が指定されている場合、データベース ファイルの終端 (概念的には "右側の" 終端) の 20 GB から可能な限りの領域が解放されます。使用されているページが終端の 20 GB に含まれる場合、そのページは、保持されるファイルの先頭の 40 GB に後で再割り当てされます。データベース ファイルは、個別またはグループ単位で圧縮できます。
圧縮操作はあまり行わないようにしてください。この操作を行うのは、データベースから大量のデータを削除した後、その空き領域を再利用する予定がない場合だけにします。データ ファイルの圧縮操作によりインデックスの断片化がかなり進み、リソースの消費が極端に多くなります。データベース ファイルを圧縮しなければならない例としては、コンテンツ データベース間で多数のサイト コレクションを移動した場合、大きなリストを削除した場合などがあり、どちらの場合も未使用の領域が大量に生成される可能性があります。データベース ファイルを圧縮しても、空き領域がまったく残っていない状態までにしかそのサイズを減らすことはできません。したがって、コンテンツがほとんど削除されないコンテンツ データベースについては、圧縮してもあまりメリットはありません。また、拡張することで調整なしでデータの追加に対応する必要がある場合は、パフォーマンスが低下する可能性があります。詳細については、「データベース ファイルの初期化」を参照してください。
圧縮操作によりインデックスが断片化するので、データベース ファイルは定期的には圧縮しないでください。このデータベース ファイルの圧縮操作は、データベース内の大量の使用領域に大きく影響する操作を行ったことで、大量の未使用領域が発生した場合にのみ行うようにします。可能な限り、データベースを圧縮することは避けてください。
それでも、データベースを圧縮する必要がある場合は、以下のガイドラインに従ってください。
データベースは自動圧縮しないでください。また、プログラムを使用してデータベースを圧縮するメンテナンス プランを構成するのもおやめください。
データベースの圧縮は、ユーザーまたは管理者が 50% 以上のコンテンツを削除し、未使用領域を再利用する予定がない場合にのみ行います。
コンテンツ データベースのみを圧縮します。ユーザーおよび管理者が構成データベース、サーバーの全体管理コンテンツ データベース、およびさまざまなサービス アプリケーション データベースからデータを削除しても、大量の空き領域を得ることはできません。
データベースの圧縮は、非常に多くのリソースを使用する操作です。したがって、データベースを絶対に圧縮しなければならない場合は、その圧縮操作の実施時期を慎重に検討します。
データベースを圧縮したら、そのデータベースのインデックスが断片化されます。この断片化には、ALTER INDEX… REORGANIZE を使用して対処します。迅速なファイル初期化が行えるように構成されていない場合は、当面の拡張に必要なサイズに対応できるようにデータベースを圧縮します。詳細については、「データベース ファイルの初期化」を参照してください。
データベースおよびデータベース ファイルを手動で圧縮して領域を回復するには、SQL Server 2008 または SQL Server 2005 Management Studio で DBCC SHRINKFILE and DBCC SHRINKDATABASE ステートメントを.実行します。
データベース圧縮によりパフォーマンスが低下する理由、また、やむを得ない場合を除きデータベース圧縮を行うべきではない理由の詳細については、「Why you should not shrink your data files (英語)」を参照してください。
Transact-SQL コマンドを使用してデータベースを圧縮する
DBCC SHRINKDATABASE により特定のデータベースのデータ ファイルおよびログ ファイルが圧縮されます。個別のファイルを圧縮するには、DBCC SHRINKFILE を使用します。
DBCC SHRINKDATABASE
DBCC SHRINKDATABASE では、次の構文を使用します。
DBCC SHRINKDATABASE
( 'database_name' | database_id | 0
[ ,target_percent ]
[ , { NOTRUNCATE | TRUNCATEONLY } ]
)
[ WITH NO_INFOMSGS ]
database_name | database_id | 0 では、データベース名またデータベース ID を指定します。現在のデータベースを選択するには、0 を使用します。
target_percent は、データベースの圧縮後に維持したい空き領域です。これはパーセンテージで表されます。
NOTRUNCATE は、データ ファイル末尾の割り当て済みページをファイル先頭の未割り当てページに移動することで、ファイル内のデータを圧縮します。
TRUNCATEONLY は、ファイル末尾のすべての空き領域をオペレーティング システムに解放しますが、ファイル内ではページを移動しません。
注意
TRUNCATEONLY オプションは、SharePoint 2010 コンテンツ データベースでは使用できません。
詳細については、「DBCC SHRINKDATABASE (Transact-SQL)」を参照してください。
DBCC SHRINKFILE
DBCC SHRINKFILE では、次の構文を使用します。
DBCC SHRINKFILE
(
{ 'file_name' | file_id }
{ [ , EMPTYFILE ]
| [ [ , target_size ] [ , { NOTRUNCATE | TRUNCATEONLY } ] ]
}
)
[ WITH NO_INFOMSGS ]
file_name | file_id では、ファイル名またはファイル ID を指定します。
EMPTYFILE は、指定したファイルから同じファイルグループの他のファイルにすべてのデータを移行します。
重要
EMPTYFILE オプションは SharePoint 2010 データベース ファイルでは使用できません。
target_size は、ファイルの目標サイズ (MB 単位) で、整数として表されます。
NOTRUNCATE は、データ ファイル末尾の割り当て済みページをファイル先頭の未割り当てページに移動することで、ファイル内のデータを圧縮します。
TRUNCATEONLY は、ファイル末尾のすべての空き領域をオペレーティング システムに解放しますが、ファイル内ではページを移動しません。
重要
TRUNCATEONLY オプションは、SharePoint 2010 コンテンツ データベースでは使用できません。
詳細については、「DBCC SHRINKFILE (Transact-SQL)」を参照してください。
SQL Server 2008 Management Studio を使用してデータベースを圧縮する
次の手順を使用します。
SQL Server 2008 Management Studio を使用してデータベースを圧縮するには
タスクバーで、[スタート] ボタン、[すべてのプログラム]、[Microsoft SQL Server 2008]、[SQL Server Management Studio] の順に選択します。
オブジェクト エクスプローラーで、SQL Server 2008 データベース エンジンのインスタンスに接続し、そのインスタンスを展開します。
[データベース] を展開し、圧縮するデータベースを右クリックして、[タスク]、[圧縮]、[ファイル] の順に選択します。
ファイルの種類とファイル名を選択します。
[未使用領域の解放前にファイルを再構成する] を選択します。[ファイルの圧縮] の値を設定する必要もあります。このオプションを選択し、ファイル内の未使用領域をオペレーティング システムに解放して、未割り当てページに行を移動します。
[OK] をクリックします。
SQL Server 2008 メンテナンス プランを作成する
この記事で説明するデータベース メンテナンス操作の多くをプログラムを使用して適用するには、SQL Server メンテナンス プランを実装します。メンテナンス プランでは、データの保護に不可欠なタスクを自動化およびスケジュールできます。SQL Server 2008 または SQL Server 2005 でメンテナンス プランを使用することで、管理者が、データベースの整合性チェック、インデックスの再構成、インデックスの再構築などの操作をスケジュールできます。詳細については、以下を参照してください。
SQL Server 2008 用のメンテナンス プラン ウィザード。
SQL Server 2005 用のデータベース メンテナンス プラン ウィザード。
SQL Server 2008 データベース メンテナンス プランを構成するには
タスクバーで、[スタート] ボタン、[すべてのプログラム]、[Microsoft SQL Server 2008]、[SQL Server Management Studio] の順に選択します。
オブジェクト エクスプローラーで、SQL Server 2008 データベース エンジンのインスタンスに接続し、そのインスタンスを展開します。
[管理] を選択し、[メンテナンス プラン] を右クリックして、[ メンテナンス プラン ウィザード] を選択します。
[プランのプロパティを選択] ページが表示されるまで [次へ] を選択します。
図 4. [プランのプロパティを選択] ページ
![[プランのプロパティを選択] ページ](images/cc262731.3343a34e-9289-4dc4-8a22-b64224f3c8cb(office.14).jpg "[プランのプロパティを選択] ページ")
[名前] フィールドと [説明] フィールドで、名前と説明を指定します。
1 つのメンテナンス プランを構成するか、複数のプランを構成するかを決めます。
1 つのメンテナンス プランを構成するには、[プラン全体で単一のスケジュールを使用するか、スケジュールを使用しない] を選択します。
特定のタスクについて複数のメンテナンス プランを構成するには、[タスクごとに個別のスケジュールを使用する] を選択します。
10 以上のコンテンツ データベースがある環境や 200 GB を超えるコンテンツがある環境では、個別に適切に対処し、メンテナンス時間を最大化するために、個別のメンテナンス プランを構成することをお勧めします。
データベースに対して複数のメンテナンス プランを構成する場合は、プランとその目的を区別できるように、プランの名前または説明、およびそのスケジュールを指定します。
[変更] をクリックし、1 つ以上のプランのスケジュールを設定します。
[ジョブ スケジュールのプロパティ] ダイアログ ボックスが表示されます。
図 5. [ジョブ スケジュールのプロパティ] ダイアログ ボックス
![[ジョブ スケジュールのプロパティ] ダイアログ ボックス](images/cc262731.d73e04e9-71bb-4a31-9e54-e9511bfb6b77(office.14).jpg "[ジョブ スケジュールのプロパティ] ダイアログ ボックス")
スケジュールを完成させ、[OK]、[次へ] の順にクリックします。
[メンテナンス タスクの選択] ページで、プランに含めるメンテナンス タスクを選択し、[次へ] をクリックします。
図 6. [メンテナンス タスクの選択] ページ
![[メンテナンス タスクの選択] ページ](images/cc262731.0ff890b4-b429-4dc8-be3a-b1ed5cf3a903(office.14).jpg "[メンテナンス タスクの選択] ページ")
以下の点に注意してください。
メンテナンス プランに組み込むのはインデックスの再構成またはインデックスの再構築のどちらかにして、両方は組み込まないようにします。
メンテナンス プランにはデータベースの圧縮を組み込まないようにします。
各タスクの所要時間を判断するには、各タスクを個別にテストしてから 1 つのプランに結合します。ユーザーに悪影響が及ばない時間にタスクを完了できるように、複数のメンテナンス プランを個別のスケジュールで定義しなければならない場合があります。
[メンテナンス クリーンアップ タスク] により、スケジュールされたメンテナンス後に残ったファイルが削除されます。
[メンテナンス タスクの順序を選択] ページで、必要に応じて、メンテナンス プランのタスクの順序を変更します。タスクを選択し、[上へ移動] または [下へ移動] をクリックしてタスクを並べ替えたら、[次へ] をクリックします。
注意
非常に大きなデータベースの場合は、インデックスのメンテナンスよりも少ない頻度でデータベースの整合性を確認するメンテナンス プランを個別に作成することをお勧めします。
図 7. [メンテナンス タスクの順序を選択] ページ
![[メンテナンス タスクの順序を選択] ページ](images/cc262731.8fe7910c-89b5-49c8-8429-30956cbf91a0(office.14).jpg "[メンテナンス タスクの順序を選択] ページ")
次に、ウィザードの手順に従って各タスクの詳細を設定します。[データベースの整合性確認タスクの定義] ページで、整合性を確認するデータベースを選択し、[次へ] をクリックします。
注意
すべての SharePoint 2010 データベースの整合性を安全に確認することができます。
図 8. [データベースの整合性確認タスクの定義] ページ
![[データベースの整合性確認タスクの定義] ページ](images/cc262731.f79eaf9d-4684-4ef2-85b2-0f2c8ae8cc65(office.14).jpg "[データベースの整合性確認タスクの定義] ページ")
[インデックスの再構成タスクの定義] ページの [データベース] ボックスの一覧で、インデックスを再構成するデータベースを指定し、[ラージ オブジェクトを圧縮する] チェック ボックスをオンにして、[次へ] をクリックします。
図 9. [インデックスの再構成タスクの定義] ページ
![[インデックスの再構成タスクの定義] ページ](images/cc262731.ed686e41-0a19-450b-b6d0-cd5588fc6d58(office.14).jpg "[インデックスの再構成タスクの定義] ページ")
[インデックスの再構成タスクの定義] ページで、インデックスを再構成するのではなく再構築するように選択した場合は、[データベース] ボックスの一覧でデータベースを指定します。
[ページごとの空き領域の比率を変更する] を選択し、「80」と入力して、[次へ] をクリックします。
[ページごとの空き容量の比率を変更する] により FILL FACTOR が設定されます。
図 10. [インデックスの再構築タスクの定義] ページ
![[インデックスの再構築タスクの定義] ページ](images/cc262731.d6db7b22-fd81-47c5-9860-d5d403a746a9(office.14).jpg "[インデックスの再構築タスクの定義] ページ")
[メンテナンス クリーンアップ タスクの定義] ページで、要求された値を指定し、[次へ] をクリックします。
ヒント
メンテナンス プラン テキスト レポートを削除することをお勧めします。
図 11. [メンテナンス クリーンアップ タスクの定義] ページ
![[メンテナンス クリーンアップ タスクの定義] ページ](images/cc262731.8ced2b44-665f-4558-8358-c1c2ad28da31(office.14).jpg "[メンテナンス クリーンアップ タスクの定義] ページ")
[レポート オプションの選択] ページで、[レポートをテキスト ファイルに書き込む] を選択し、ファイルの場所を選択して、ウィザードが完了するまで [次へ] をクリックします。
図 12. レポート オプションの選択
.jpg "レポート オプションの選択")
まとめ
SharePoint 2010 をホストするデータベースを常時維持することで、システムの正常性とパフォーマンスを大幅に向上させることができます。
メンテナンス操作およびメンテナンス計画を実装する前に、すべてのデータベースを確実にバックアップします。
メンテナンス プランまたは常時実行される特定のメンテナンス操作を実装する前に、システムへの操作の影響と、その操作の実行にかかる時間をテストします。
ユーザーに及ぼすパフォーマンスの影響を最小限に抑えるために、メンテナンス操作またはメンテナンス計画は、可能な限りオフピーク時に実行するように設定します。