microsoft sharepoint 2010 製品のデータベース...

Microsoft® SharePoint

® 2010 製品のデータ

ベースメンテナンス

著者:

Bill Baer

Bryan Porter

テクニカルレビューアー:

Paul S. Randal (SQLskills.com)

発行:

2011 年 7 月

概要:

このホワイトペーパーでは、SharePoint 2010 製品のコンテンツおよび構成の設定をホストする

データベースの推奨メンテナンス戦略について説明します。

Microsoft SharePoint 2010 2011 年 7 月

© 2011 Microsoft Corporation.All rights reserved. ページ | 2

このホワイトペーパーまたは機能に関するご意見、ご要望については、SharePoint IT ドキュメントチーム

([email protected]) までお送りください。

このドキュメントは「現状のまま」提供されます。このドキュメントで説明されている情報お

よびビューは、URL および他のインターネット Web サイトの参照を含めて、予告なく変更され

ることがあります。そのようなリスクがあることを承知の上でお読みください。

このドキュメントに記載されている事例の一部は、説明のみを目的とした架空のものです。実在

する事例とは一切関係ありません。

このドキュメントは、マイクロソフト製品の知的所有権に対する法的な権利をお客様に提供する

ものではありません。このドキュメントの複製と利用は、お客様が社内でこれを参照する目的の

場合に限って許可されます。

© 2011 Microsoft Corporation.All rights reserved.





要約このホワイトペーパーでは、Microsoft

® SharePoint

® 2010 のデータおよび構成をホストするデ

ータベースのメンテナンスに関する情報とガイドラインを提供します。また、SharePoint 2010

を使用するときの推奨データベースメンテナンスタスクについて、例を挙げながら説明します。

データベースメンテナンスタスクを実装する場合、または SharePoint 2010 データベースを変

更する場合は、事前にサポート記事「Office サーバー製品と Windows SharePoint Services によ

って使用されるデータベースへの変更のサポート」

(http://go.microsoft.com/fwlink/?LinkId=110812&clcid=0x409) をお読みください。

http://go.microsoft.com/fwlink/?linkid=110812&clcid=0x411






目次

要約 .................................................................................................................................................. 3

はじめに .......................................................................................................................................... 5

DBCC CHECKDB による整合性エラーのチェック ....................................................................... 5

DBCC CHECKDB について ............................................................................................................ 6

DBCC CHECKDB とパフォーマンス ............................................................................................. 7

インデックスの断片化の測定および削減 ....................................................................................... 7

オンラインおよびオフラインでのインデックスの再構築 .............................................................. 8

SQL Server 2008 または 2005 データベースの断片化の測定

(sys.dm_db_index_physical_stats) ............................................................................................. 9 sys.dm_db_index_physical_stats 動的管理ビューを使用するには ....................................... 9

データベースの断片化の削減 ........................................................................................................ 10 データベースメンテナンス Health Analyzer ルールの実行 ..................................................... 10

特定のテーブルおよびそのインデックスの断片化の削減 ............................................................ 12 ALTER INDEX の使用 ............................................................................................................... 13

FILL FACTOR の設定によるインデックスパフォーマンスの微調整 ......................................... 14

データファイルの圧縮.................................................................................................................. 14 Transact-SQL コマンドでのデータベースの圧縮 ..................................................................... 15 SQL Server 2008 Management Studio を使用してデータベースを圧縮するには ................... 16

SQL Server 2008 メンテナンスプランの作成 ............................................................................ 17 SQL Server 2008 データベースのメンテナンスプランを構成するには ................................. 17

まとめ ............................................................................................................................................ 24





はじめに

Microsoft® SharePoint

® 2010 データベースを円滑に操作するには、定期的なデータベースメン

テナンスが欠かせません。このホワイトペーパーでは、SharePoint 2010 でサポートされている

データベースメンテナンスタスクについて説明します。

SharePoint 2010 データベースの推奨メンテナンスタスクは次のとおりです。

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

インデックスの再構成または再構築によるデフラグ。

サーバーの FILL FACTOR の設定。

メモ: この記事では、容量またはパフォーマンスの計画ではなくデータベースのメンテナンスに

ついて説明します。容量または容量計画については、「ストレージおよび SQL Server の容量計

画と構成 (SharePoint Server 2010)」(http://go.microsoft.com/fwlink/?LinkId=217482) を参照して

ください。

前のバージョンの 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® のデータベースのメンテナンスウィ

ザードを使用してデータベースメンテナンスプランを作成する方法について説明します。

メモ: このホワイトペーパーでは、SQL Server 2008 R2 および SQL Server 2005 の例について

のみ詳しく説明します。

DBCC CHECKDB による整合性エラーのチェック

整合性チェックによって定期的なメンテナンス作業を開始し、データとインデックスが破損して

いないことを確認します。DBCC (データベースコンソールコマンド) CHECKDB ステートメン

トを使用すると、データおよびインデックスページの内部整合性をチェックできます。

データベースの整合性に関する問題の大部分が I/O サブシステムエラーによって発生します。た

だし、データベースの整合性に何らかの影響を与える可能性があるのは、データベースサーバ

ーが不適切にシャットダウンしたか、ドライブでエラーが発生したときです。パフォーマンスお

よび可用性の問題が明確に表れた場合、それは基本データベースの整合性に問題が発生している

可能性があることを示すことがあります。SharePoint 2010 データベースでは、少なくとも週に

1 回、またデータベースサーバーまたは I/O サブシステムエラーが発生した場合は必ずデータ

ベースの整合性チェックを行う必要があります。







DBCC CHECKDB について

DBCC CHECKDB は、次の処理を実行することで、指定されたデータベースのすべてのオブジ

ェクトの論理および物理整合性をチェックします。

DBCC CHECKALLOC (http://go.microsoft.com/fwlink/?LinkId=110815&clcid=0x409) と同

等のコマンドを実行し、データベース内の割り当て構造を確認します。

DBCC CHECKTABLE (http://go.microsoft.com/fwlink/?LinkId=162093) と同等のコマンド

をデータベース内のすべてのテーブルとビューで実行し、論理および物理整合性を確認

します。

DBCC CHECKCATALOG (http://go.microsoft.com/fwlink/?LinkId=110834&clcid=0x409)

と同等のコマンドをデータベースで実行し、そのメターデータの整合性を確認します。

つまり、DBCC CHECKALLOC、DBCC CHECKTABLE、DBCC CHECKCATALOG の各コマン

ドは、DBCC CHECKDB とは別に実行する必要はありません。個別のコマンドで処理を別々に

実行するのではなく、DBCC CHECKDB を実行することをお勧めします。このコマンドは、発

生した可能性のあるエラーを幅広く特定するので、運用環境でより安全に実行できるからです。

メモリ、I/O、および CPU の観点から言うと、DBCC CHECKDB はリソースを集中的に使用し

ます。運用システムの代わりに、他のサーバーで復元された SharePoint データベースのバック

アップで DBCC CHECKDB を実行すると、運用システムへの整合性チェックの負荷が軽減され

ます。

まず、DBCC CHECKDB を実行し、エラーが見つかったら、影響を受けるデータベースを最新

のバックアップを使用して復元することをお勧めします。

重要 - DBCC CHECKDB WITH REPAIR_ALLOW_DATA_LOSS はサポートされていないので実

行できません。ただし、DBCC_CHECKDB WITH REPAIR_FAST および REPAIR_REBUILD は

サポートされています。これらのコマンドは、関連するデータベースのインデックスを更新する

のみのためです。

DBCC CHECKDB の出力例を次の表に示します。

'Contoso_Content_1' の DBCC 結果。

Service Broker メッセージ 9675、状態 1:分析されるメッセージ型: 14.

Service Broker メッセージ 9676、状態 1:分析されるサービスコントラクト: 6.

Service Broker メッセージ 9667、状態 1:分析されるサービス: 3.

Service Broker メッセージ 9668、状態 1:分析されるサービスキュー: 3.

Service Broker メッセージ 9669、状態 1:分析されたメッセージ交換のエンドポイント:

0.

Service Broker メッセージ 9674、状態 1:分析されたメッセージ交換グループ: 0.

Service Broker メッセージ 9670、状態 1:分析されるリモートサービスバインド: 0.

'sys.sysrowsetcolumns' の DBCC 結果。

オブジェクト "sys.sysrowsetcolumns" の 21 ページには 2663 行あります。

'sys.sysrowsets' の DBCC 結果。

オブジェクト "sys.sysrowsets" の 4 ページには 309 行あります。

…more

CHECKDB により、データベース 'Contoso_Content_1' に 0 個のアロケーションエラ









ーと 0 個の一貫性エラーが見つかりました。

DBCC の実行が完了しました。DBCC がエラーメッセージを出力した場合は、システム管理者

に相談してください。

表 1DBCC CHECKDB の出力例

SQL Server 2008 での DBCC CHECKDB の使用の詳細については、「DBCC CHECKDB

(Transact-SQL)」(http://go.microsoft.com/fwlink/?LinkId=217483) を参照してください。

DBCC CHECKDB とパフォーマンス

I/O、CPU、メモリ、および tempdb スペースの観点から言うと、DBCC CHECKDB はリソース

を集中的に使用します。したがって、整合性チェックは運用時間外に行うことをお勧めします。

DBCC CHECKDB がブロッキングロックを取得するというのはよくある誤解で、これは SQL

Server 2000 以前からずっと事実とは異なっています。ブロッキングロックを取得しない DBCC

CHECKDB の詳細については、「A SQL Server DBA myth a day: (2/30) DBCC CHECKDB

causes blocking」(http://www.sqlskills.com/BLOGS/PAUL/post/A-SQL-Server-DBA-myth-a-day-

(230)-DBCC-CHECKDB-causes-blocking.aspx (英語)) を参照してください。

DBCC CHECKDB のリソースオーバーヘッドが、運用システムには高すぎることがあります。

この場合、テーブルの整合性チェックは一度に 1 つずつ行わないでください。問題が大きくなり

全体に広がります。運用システムでの整合性チェックのオーバーヘッドを軽減するには、次のど

ちらかの操作を行います。

WITH PHYSICAL_ONLY オプションを使用して、CPU およびメモリの使用量を少なく

する。

個別の SQL Server にデータベースバックアップを復元し、復元されたデータベースコ

ピーで整合性チェックを実行する。

このオプションの詳細については、Paul S. Randal のこちらのブログの投稿 (英語) を参照して

ください。

インデックスの断片化の測定および削減

インデックスの断片化は、テーブルまたはインデックス内のページの論理的な順序 (インデック

スキーで定義) が、データファイルのページの物理的な順序と一致しない場合に発生します。こ

れはデータファイルページのデータ密度が低いことを意味する場合もあり、これによりディス

ク領域、メモリ、および I/O に無駄が生じます。テーブルで挿入、更新、または削除を繰り返す

と、インデックスが断片化します。次の図は、新しく作成された断片化されていないインデック

スと、挿入、更新、削除を繰り返したことで断片化したインデックスを示しています。赤の矢印

はインデックスの物理的な順序、黒の矢印はインデックスページの論理的な順序を表します。

図 1. 断片化されていないインデックス (画像提供元: Paul S. Randal)



http://www.sqlskills.com/BLOGS/PAUL/post/A-SQL-Server-DBA-myth-a-day-(230)-DBCC-CHECKDB-causes-blocking.aspx%20(英語)

http://www.sqlskills.com/BLOGS/PAUL/post/A-SQL-Server-DBA-myth-a-day-(230)-DBCC-CHECKDB-causes-blocking.aspx%20(英語)

http://www.sqlskills.com/BLOGS/PAUL/post/CHECKDB-From-Every-Angle-Consistency-Checking-Options-for-a-VLDB.aspx





図 2. 断片化されたインデックス (画像提供元: Paul S. Randal)

挿入、更新、および削除がテーブルおよびインデックスの行に均等に分散されることはないので、

各ページのフルネス (データ密度) は時間が経つと変わっていきます。テーブルのインデックス

の一部またはすべてをスキャンするクエリの場合、断片化によって追加のページ読み取りが発生

し、これによりデータの並行スキャンが妨げられ、検索パフォーマンスに大きな影響を与えます。

インデックスが断片化すると、パフォーマンスと領域の使用効率が低下します。インデックスの

断片化は、データベースの利用頻度がそれほど高くない場合でも急速に進むことがあります。

インデックスの断片化のメンテナンスプランを実装する前に、どのテーブルおよびインデック

スが最も断片化しているかを把握し、そのインデックスを再構築または再構成するメンテナンス

プランを作成する必要があります。

SharePoint 2010 では、よく断片化するテーブルの例として AllDocs が挙げられます。このテー

ブルには、ドキュメントのライブラリ、そのライブラリに関連するドキュメントおよびリストと

リストアイテム、およびその個別のメタデータが含まれます。

インデックスの断片化のレベルは、論理的な順序と物理的な順序が異なるインデックスページ

の割合で表されます。

オンラインおよびオフラインでのインデックスの再構築

オンラインでのインデックスの再構築は、SQL Server Enterprise Edition、Developer Edition、

および Evaluation Edition でのみ利用できます。このホワイトペーパーに記載されている方法で

はこの点が考慮されています。特定のデータベースをホストしている SQL Server のエディショ

ンがオンラインでのインデックスの再構築をサポートしていない場合、または、再構築中のイン

デックスがオンラインでのインデックス再構築の対象となっていない場合、記載されている手順

はオフラインでのインデックスの再構築にフォールバックされます。たとえば、LOB (大きなオ

ブジェクト) 列 (データ型 NVARCHAR(MAX)、IMAGELOB が含まれる列など) が存在すると、イ

ンデックスがオンラインでの再構築の対象とならない場合があります。

オンラインでのインデックスの再構築については、「オンラインインデックス操作の動作原理」

(http://go.microsoft.com/fwlink/?LinkId=217492) を参照してください。オフラインでのインデッ

クス再構築が実行されるとき、テーブルレベルのロックが再構築プロセス中に取得されます。

これによりテーブルへの書き込みを行えなくなる可能性があります。また、テーブルに一切アク

セスできなくなることもあります。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」

(http://go.microsoft.com/fwlink/?LinkId=110839&clcid=0x409) を参照してください。

表 2 は、sys.dm_db_index_physical_stats の結果例を示しています。この例では、1 つの行の

avg_fragmentation_in_percent に 9.375 が示されています。

database_id index_type_desc

alloc_unit_type_

desc

avg_fragmentation_

in_percent

10 CLUSTERED INDEX IN_ROW_DATA 0

10 NONCLUSTERED INDEX IN_ROW_DATA 0


10 CLUSTERED INDEX IN_ROW_DATA 0


10 CLUSTERED INDEX IN_ROW_DATA 9.375

表 2. sys.dm_db_index_physical_stats の結果例

sys.dm_db_index_physical_stats 動的管理ビューを使用するには

1. タスクバーで [スタート] ボタンをクリックし、[すべてのプログラム]、[Microsoft SQL

Server 2008] の順にポイントして、[SQL Server Management Studio] をクリックします。

データベースオブジェクトが含まれる sys.dm_db_index_physical_stats を使用するには、

データベース ID とオブジェクト ID を把握しておく必要があります。

2. オブジェクトエクスプローラーでコンテンツデータベースを選択し、[新しいクエリ] を

クリックします。次のスクリプトを実行します。

SELECT DB_ID() AS [Database ID];

メモ: データベース名を指定せずに DB_ID を使用する場合、現在のデータベースの互換性レ

ベルは 100 (SQL Server 2008 データベースの場合) または 90 (SQL Server 2005 データベー

スの場合) である必要があります。前のバージョンの SQL Server からアップグレードした場

合は、DB_ID ステートメントでデータベース名を指定しなければなりません。互換性レベル

の詳細については、「sp_dbcmptlevel (Transact-SQL)」









3. 選択したデータベースまたはオブジェクトで 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_stats DMV はリソースを集中的に使用することがあるので、慎重に

使用してください。このビューをさまざまな方法で使用するための包括的なガイドについては、

「Inside sys.dm_db_index_physical_stats」(http://www.sqlskills.com/BLOGS/PAUL/post/Inside-

sysdm_db_index_physical_stats.aspx) を参照してください。

データベースの断片化の削減

インデックスの断片化レベルを削減するには、以下のガイダンスに従います。

データベースメンテナンス Health Analyzer ルールの実行

SharePoint 2010 には、Health Analyzer ルールのフレームワークが付属しています。このルール

のフレームワークは複数のルールで構成され、SharePoint 環境の正常性と状態を監視し、場合

によっては、特定の種類の問題を解決するためのアクションを実行します。

SharePoint 2010 には、コンテンツデータベースメンテナンスに関連する複数のルールが付属

しています。たとえば、一部の SharePoint データベースのインデックスの断片化を自動的に削

減するルール、古くなった統計がないかどうかをチェックし、必要に応じてその統計を更新する

ルールなどがあります。SharePoint 製品およびテクノロジ用に Service Pack 2 製品で導入され

た更新済みのデータベース統計タイマージョブはこうした Health Analyzer ルールに置き換えら

れます。既定では、これらのルールは、ルールの対象に応じてさまざまなスケジュール (毎日、

毎週、オンデマンドなど) で実行されるように構成されます。

毎日実行されるように構成され、特定の SharePoint サービスに関連付けられた Health Analyzer

ルールはすべて、同じタイマージョブによって実行されます。このタイマージョブのスケジュ

ールを調整すると、そのサービスに関連付けられた Health Analyzer ルールで、毎日実行される

ように構成されたものが、一日のどの時間に実行されるかが調整されます。このホワイトペー

パーで説明するルールはすべて、SharePoint Timer サービスに関連付けられています。

異なる間隔 (毎週など) で実行するように構成されている Health Analyzer ルールまたは異なるサ

ービスに関連付けられている Health Analyzer ルールには、別のタイマージョブがあります。毎

週実行されるように Health Analyzer ルールを構成するということは、その Health Analyzer ル

ールは、自身が関連付けられている特定のサービスに対して毎週実行されるように構成されたタ

イマージョブで実行されることを意味します。この実行処理は、そのタイマージョブに定義さ

れているすべてのスケジュールで発生します。

Health Analyzer ルールを手動で実行するには、サーバーの全体管理の [Health Analyzer ルール]

ページ内のリボンから [今すぐ実行] を選択します。これらのルールを実行すると、インデックス

および統計の正常性が評価され、必要に応じてインデックスの再構築および再計算が行われます。

http://www.sqlskills.com/BLOGS/PAUL/post/Inside-sysdm_db_index_physical_stats.aspx





SharePoint で使用されているデータベースのインデックスは断片化されています - このルール

を実行すると、次のタスクが実行されます。

インデックスが断片化されていることがレポートされます。これは、インデックスの正

常性を評価する作業はコストがかかるからです。Health Analyzer ルールの詳細を実行す

ると必ず、インデックスが断片化されていることがこのルールによりレポートされ、修

正処理が実行されます。

SharePoint データベースごとに、ルールの動作によって proc_DefragmentIndices スト

アドプロシージャが検索され、見つかった場合は実行されます。このストアドプロシー

ジャの実行中、データベース内でインデックスの一覧が構築されます。断片化の現在の

レベルに関して、各インデックスが評価されます。いずれかのインデックスの断片化が

30 パーセントを超える場合は、再構築が検討されます。

SQL Server のエディションがオンラインでのインデックスの再構築をサポートしている

場合、オンラインでのインデックスの再構築はインデックスごとに試行されます。この

再構築が失敗すると (LOB 列が使用されていることが原因で基本となるインデックスが

オンラインでの再構築をサポートしていない場合は失敗します)、オフラインでのインデ

ックスの再構築が行われます。

上記で説明したように、SharePoint 環境のデータベースへのサービスの提供は、すべてがこの

ルールに従って行われるわけではありません。一部のデータベースについては、別のルールを使

用して同じようなメンテナンスアクティビティを実行します。

検索 - インデックスが断片化されているプロパティデータベースがあります - このルールでは、

SharePoint 2010 エンタープライズ検索プロパティデータベース内のインデックスのメンテナン

スを行います。このルールは、ファーム内の任意のサーバーで毎週実行されるように既定で構成

されています。このルールのすべての処理が、修正処理を含め、ルール実行の "チェック" フェ

ーズで発生します。つまり、エンタープライズ検索プロパティデータベースのインデックスの

再構築を管理する場合は、インデックスが自動的に再構築されないようにこのルールを構成する

だけでは不十分です。インデックスメンテナンス作業が SharePoint 2010 によって自動的に実

行されないように、ルール全体を無効にする必要があります。

"検索 - インデックスが断片化されているプロパティデータベースがあります" を実行すると、次

のタスクが実行されます。

環境でインデックスの再構築を安全に行えることが確認されます。

ローカルファーム内の検索アプリケーションに対して構成されたプロパティデータベー

スごとに、proc_MSS_DefragSearchIndexes ストアドプロシージャが実行されます。こ

のストアドプロシージャの実行中、断片化の平均値が 10% を超えているインデックス

の一覧が構築されます。

プロパティデータベースのパフォーマンスに影響するリスト内の各インデックスが再構

築されます。SQL Server のエディションがオンラインでのインデックスの再構築をサポ

ートしている場合は、オンラインでインデックスが再構築されます。オンラインでイン

デックスを再構築できなかった場合は、オフラインで再構築されます。

検索 - 1 つ以上のクロールデータベースに断片化されたインデックスがあります - このルールで

は、SharePoint 2010 エンタープライズ検索クロールデータベース内のインデックスのメンテナ

ンスを行います。このルールは、オンデマンドでのみ実行されるように既定で構成されています。

また、ファーム内の任意のサーバーから実行されます。

このルールを実行すると必ず、クロールデータベース内のインデックスが断片化されているこ

とがレポートされます。これは、データベース内で断片化を確認するにはコストがかかるからで

す。この結果、このルールの "修復" アクティビティを無効にしただけでは、クロールデータベ





ースに含まれるインデックスが最近構築されたものでも、すべてのクロールデータベースが "異

常" としてレポートされます。

クロールデータベース内のインデックスのメンテナンスを手動で管理するには、"検索 - 1 つ以

上のクロールデータベースに断片化されたインデックスがあります" ルール全体を無効にします。

"検索 - 1 つ以上のクロールデータベースに断片化されたインデックスがあります" を実行すると、

次のタスクが実行されます。

環境でインデックスの再構築を安全に行えることが確認されます。

ローカルファーム内の検索アプリケーションに対して構成されたクロールデータベース

ごとに、proc_MSS_DefragGathererIndexes ストアドプロシージャが実行されます。

リストのクロールデータベースのパフォーマンス内で各インデックスが再構築されます。

SQL Server のエディションがオンラインでのインデックスの再構築をサポートしている

場合は、オンラインでインデックスが再構築されます。オンラインでインデックスを再

構築できなかった場合は、オフラインで再構築されます。

"検索 - 1 つ以上のクロールデータベースに断片化されたインデックスがあります" ルールでは、

断片化のレベルにかかわらず、すべてのクロールデータベース内ですべてのインデックスが再

構築される点に注意してください。クロールデータベースをホストしている 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 によって使用されるデータ

ベースへの変更のサポート」(http://go.microsoft.com/fwlink/?LinkId=110844&clcid=0x409) を参

照してください。

過度に断片化されたデータベースまたはテーブルのパフォーマンスが、頻繁にデフラグを行って

もそれほど向上しない場合は、I/O サブシステムのパフォーマンスを確認してください。

特定のテーブルおよびそのインデックスの断片化の削減データベース全体ではなく特定のテーブルに関連付けられているインデックスをデフラグするに

は、インデックスを再構成または再構築します。







インデックスの再構成では、インデックスのリーフレベルが再構成されるように指定します。

インデックスを再構成すると、テーブルおよびビューのクラスター化インデックスおよび非

クラスター化インデックスがデフラグおよび圧縮され、インデックススキャンのパフォーマ

ンスが大幅に向上します。再構成するときは、インデックスに割り当てられている既存の領

域が使用されます。また、必ずオンラインで実行されるので、基本となるテーブルをユーザ

ーが利用できます。

インデックスの再構築では、まったく新しいインデックスコピーが再構築されるように指定

します。つまり、再構築を行うには、断片化された古いインデックスを削除する前に新しい

インデックスコピーを構築するための追加領域が必要です。再構築するとインデックスス

キャンおよび検索のパフォーマンスが向上します。テーブルのインデックスは、オンライン

またはオフラインのどちらかで再構築できます。

インデックスをデフラグする方法、およびオンラインのままデフラグを実行するか、オフライン

にして実行するかは、断片化のレベルによって決まります。次の表は、推奨デフラグ方法を断片

化のレベルごとに説明しています。

断片化のレベルデフラグ方法

10% 未満再構成 (オンライン)

10-75% 再構築 (オンライン)

75% 再構築 (オフライン)

メモ: DROP INDEX コマンドと CREATE INDEX コマンドは、SharePoint 2010 データベースで

はサポートされていません。

インデックスを再構成および再構築するには、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 データ

ベースでは、この 2 つのコマンドを使用してインデックスのメンテナンスを行わないでください。

メモ: オフラインでのインデックスの再構築中は、共有テーブルロックがテーブルに設定され、

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 (http://technet.microsoft.com/en-us/library/ff607915.aspx) Windows PowerShell コマンド

の実行、ドキュメント、ドキュメントライブラリ、リスト、リストアイテム、サイトの削除な

どのアクティビティによって、未使用領域が発生します。

ディスク上のサイズ

120GB

ディスク上のサイズ100GB

使用領域

空き領域

図 3. データベースの割り当て

空き領域はファイルの最後からのみ解放されます。たとえば、60 GB のコンテンツデータベー

スファイルでターゲットサイズとして 40 GB が指定されている場合、データベースファイル

の末尾 (概念的には "右端") の 20 GB からできるだけ多くの領域が解放されます。この末尾 20

GB に使用済みページが含まれている場合、そのページは、保持されているファイルの先頭の 40

GB に再配置されます。データベースファイルの圧縮は個別に行うことも、まとめて行うことも

できます。

圧縮操作を行う必要があるのはまれで、大量のデータをデータベースから削除した後と、空き領

域が二度と利用されることがないと予想される場合にのみ実行します。データファイルを圧縮

するとインデックスが過度に断片化されます。また、この処理はリソースを集中的に使用します。

データベースデータファイルの圧縮が許容されるのは、コンテンツデータベース間で大量のサ

イトコレクションの再配置または大きなリストの削除のどちらかによって、大量の未使用領域

が発生した場合などです。データベースファイルは、空き領域の分しか小さくなりません。し

たがって、コンテンツの削除があまり行われないコンテンツデータベースの場合は、圧縮して

もあまり効果がありません。また、データ追加に対応するためにデータベースを拡張する必要が

あるとき、特別な領域がないと、パフォーマンスが低下することがあります。詳細については、

「データベースファイルの初期化」(http://msdn.microsoft.com/en-us/library/ms175935.aspx) を

参照してください。



http://technet.microsoft.com/ja-jp/library/ff607915.aspx

http://technet.microsoft.com/ja-jp/library/ff607915.aspx

http://msdn.microsoft.com/ja-jp/library/ms175935.aspx

http://msdn.microsoft.com/zh-tw/library/ms175935.aspx





圧縮によってインデックスが断片化するので、データベースファイルの圧縮は定期的には行わ

ないでください。この圧縮処理は、大量の未使用領域があり、この領域が、データベース内の使

用済み領域に大きな影響を及ぼす操作の結果として発生したと思われる場合にのみ実行します。

可能な限り、データベースの圧縮は避けてください。

データベース圧縮のガイドラインを次に示します。

データベースを自動的に圧縮しないでください。また、プログラムによってデータベースを

圧縮するメンテナンスプランを構成しないでください。

ユーザーまたは管理者の削除によってデータベース内のコンテンツの 50% 以上が削除され、

他のデータによって未使用の領域が再利用されないと思われる場合にのみ、データベースを

圧縮します。

コンテンツデータベースのみを圧縮することをお勧めします。構成データベース、サーバー

の全体管理のコンテンツデータベース、およびさまざまなサービスアプリケーションのデ

ータベースについては、通常、大量の空き領域が発生する削除は行われません。

データベースの圧縮は、リソースを集中的に使用します。したがって、データベースをやむ

を得ず圧縮しなければならない場合は、圧縮スケジュールについて慎重に検討してください。

データベースを圧縮すると、データベース内のインデックスが断片化されます。この断片化

に対処するには、ALTER INDEX… REORGANIZE を使用します。インスタントファイル初

期化を許可するように構成されていない場合は、当面の拡大に必要な領域を確保できるサイ

ズまでデータベースを圧縮します。詳細については、「データベースファイルの初期化」

(http://msdn.microsoft.com/en-us/library/ms175935.aspx) を参照してください。インデック

スの再構築によって断片化を削減すると、未使用領域が残り、データベースが再度大きくな

ります。

データベースおよびデータベースファイルを手動で圧縮して領域を回復するには、SQL Server

2008 または SQL Server 2005 Management Studio を使用して、DBCC SHRINKFILE および

DBCC SHRINKDATABASE ステートメントを実行します。

データベースの圧縮によりパフォーマンスが低下する理由、およびやむを得ない場合を除き圧縮

を行うべきではない理由の詳細については、「Why you should not shrink your data files (英語)」

(http://www.sqlskills.com/BLOGS/PAUL/post/Why-you-should-not-shrink-your-data-files.aspx) を

参照してください。

Transact-SQL コマンドでのデータベースの圧縮 DBCC SHRINKDATABASE を実行すると、特定のデータベースのデータとログファイルが圧縮

されます。個別のファイルを圧縮するには、DBCC SHRINKFILE を使用します。

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 は、データベースの圧縮後に保持する空き領域の割合です。

http://msdn.microsoft.com/ja-jp/library/ms175935.aspx

http://msdn.microsoft.com/zh-tw/library/ms175935.aspx

http://www.sqlskills.com/BLOGS/PAUL/post/Why-you-should-not-shrink-your-data-files.aspx





NOTRUNCATE は、ファイル末尾の割り当て済みのページをファイル先頭の未割り当てのペー

ジに移動することで、データファイルのデータを圧縮します。

TRUNCATEONLY は、ファイル末尾のすべての空き領域をオペレーティングシステムに解放し

ます。ただし、ファイル内でページは移動されません。

メモ: TRUNCATEONLY オプションは、SharePoint 2010 コンテンツデータベースではサポート

されていません。

詳細については、「DBCC SHRINKDATABASE (Transact-SQL)」


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 は、ファイルのターゲットサイズ (メガバイト単位) です。整数として表されます。

NOTRUNCATE は、ファイル末尾の割り当て済みのページをファイル先頭の未割り当てのペー

ジに移動することで、データファイルのデータを圧縮します。

TRUNCATEONLY は、ファイル末尾のすべての空き領域をオペレーティングシステムに解放し

ます。ただし、ファイル内でページは移動されません。

メモ: TRUNCATEONLY オプションは、SharePoint 2010 コンテンツデータベースではサポート

されていません。

詳細については、「DBCC SHRINKFILE (Transact-SQL)」


SQL Server 2008 Management Studio を使用してデータベースを圧縮するには



2. オブジェクトエクスプローラーで、SQL Server 2008 データベースエンジンのインスタ

ンスに接続し、そのインスタンスを展開します。

3. [データベース] を展開し、圧縮するデータベースを右クリックして、[タスク]、[圧縮] の順

にポイントし、[ファイル] をクリックします。

4. ファイルの種類と名前を選択します。








5. [未使用領域の解放前にファイルを再構成する] を選択します。[圧縮先のファイル] の値を

設定する必要もあります。このオプションを選択すると、ファイル内の未使用領域がオペ

レーティングシステムに解放され、未割り当てのページへの行の再配置が試行されます。

6. [OK] をクリックします。

SQL Server 2008 メンテナンスプランの作成このホワイトペーパーで説明するデータベースメンテナンス作業の多くが、SQL Server メンテ

ナンスプランを実装することでプログラムによって適用されます。メンテナンスプランでは、

重要なデータ保護タスクを自動化することもスケジュールすることもできます。SQL Server

2008 または SQL Server 2005 のメンテナンスプランを使用すると、管理者が、データベースの

整合性チェックの実行、インデックスの再構成または再構築などの操作をスケジュールできます。

詳細については、次のリソースを参照してください。

メンテナンスプランウィザード

(http://go.microsoft.com/fwlink/?LinkId=110855&clcid=0x409)

メンテナンスプランウィザード(http://go.microsoft.com/fwlink/?LinkId=217494)

SQL Server 2008 データベースのメンテナンスプランを構成するには



2. オブジェクトエクスプローラーで、SQL Server 2008 データベースエンジンのインスタ

ンスに接続し、そのインスタンスを展開します。

3. [管理] をクリックし、[メンテナンスプラン] を右クリックして、[メンテナンスプランウ

ィザード] をクリックします。

4. [プランのプロパティを選択] ページが表示されるまで [次へ] をクリックします。

5. [名前] および [説明] の各フィールドに名前と説明を入力します。

6. 1 つのメンテナンスプランを構成するか、複数のプランを構成するかを指定します。








1 つのメンテナンスプランを構成するには、[プラン全体で単一のスケジュールを使用す

るか、スケジュールを使用しない] を選択します。

特定のタスクに複数のメンテナンスプランを構成するには、[タスクごとに個別のスケ

ジュールを使用する] を選択します。

環境内に 10 以上のコンテンツデータベースがある場合、または環境内のコンテンツのサイ

ズが 200 GB を超える場合は、個別のメンテナンスプランを構成して適切な特殊性を指定し、

さらにメンテナンスウィンドウを最大化することをお勧めします。

複数のメンテナンスプランを構成する場合は、プランとその目的 (スケジュールを含む) を

区別できるように名前と説明を指定します。

7. [変更] をクリックして、1 つ以上のプランのスケジュールを設定します。

[ジョブスケジュールのプロパティ] ダイアログボックスが表示されます。

8. スケジュールを完成させ、[OK]、[次へ] の順にクリックします。

9. [メンテナンスタスクの選択] ページで、プランに含めるメンテナンスタスクを選択し、

[次へ] をクリックします。





メモ:

メンテナンスプランには、インデックスの再構成またはインデックスの再構築のどちら

かを含めます。両方を含めることはできません。

メンテナンスプランには、データベースの圧縮は含めないでください。

各タスクの期間を決めるには、各タスクを個別にテストしてから、タスクを 1 つのプラ

ンにまとめます。エンドユーザーの操作に悪影響を及ぼさない時間帯にタスクを実行で

きるように、個別のスケジュールで複数のメンテナンスプランを定義しなければならな

い場合があります。

メンテナンスクリーンアップタスクは、メンテナンスプランを実行して、残っている

ファイルを削除します。

10. [メンテナンスタスクの順序を選択] ページで、必要に応じてメンテナンスプランタスク

の順序を変更します。タスクを選択し、[上へ移動] または [下へ移動] をクリックします。

タスクが正しい順序で並べられたら、[次へ] をクリックします。

メモ: データベースのサイズが非常に大きい場合は、個別のメンテナンスプランを作成し、

インデックスのメンテナンスよりも少ない頻度でデータベースの整合性チェックを行います。





次に、ウィザードの指示に従って、各タスクの詳細を設定します。

11. [データベースの整合性確認タスクの定義] ページで、整合性をチェックするデータベース

を選択し、[次へ] をクリックします。

メモ: すべての SharePoint 2010 データベースの整合性を安全にチェックすることができま

す。





12. [インデックスの再構成タスクの定義] ページの [データベース] ボックスの一覧で、インデ

ックスを再構成するデータベースを指定し、[ラージオブジェクトを圧縮する] チェック

ボックスをオンにして、[次へ] をクリックします。

13. インデックスの再構成ではなくインデックスの再構築を選択した場合は、[インデックスの

再構築タスクの定義] ページの [データベース] ボックスの一覧で、インデックスを再構築

するデータベースを指定します。





14. [ページごとの空き領域の比率を変更する] を選択し、「80」と入力して、[次へ] をクリッ

クします。

[ページごとの空き領域の比率を変更する] によりデータベースの FILL FACTOR が設定さ

れます。

15. [メンテナンスクリーンアップタスクの定義] ページで、ニーズに合った値を設定し、[次

へ] をクリックします。

メンテナンスプランテキストレポートは削除することをお勧めします。





16. [レポートオプションの選択] ページで [レポートをテキストファイルに書き込む] を選択

し、ファイルの場所を選択して、ウィザードが完了するまで [次へ] をクリックします。

まとめ SharePoint 2010 をホストするデータベースのメンテナンスを常に行っていれば、どの方法を使

用しても、システムの状態とパフォーマンスは大幅に向上します。

メンテナンス作業およびメンテナンスプランを実装する場合は、必ず事前にすべてのデータベ

ースの信頼できるバックアップを取ってください。

継続的に実行されるメンテナンス作業またはメンテナンスプランを実装する前に、システムへ

のメンテナンス実装の影響と実行に必要な時間をテストしてください。

メンテナンス作業またはメンテナンスプランはできる限り稼働時間外に実行し、ユーザーパフ

ォーマンスへの影響を最小限に抑えます。

microsoft sharepoint 2010 製品のデータ ベース...

Documents

microsoft sharepoint 2010 製品のデータベース...