要約 - download.microsoft.comdownload.microsoft.com/.../databasemaintenancesharepoint201… ·...

Microsoft® SharePoint® 2010 製品のデータベースメンテナンス

著者: Bill Baer

Bryan Porter

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

Paul S. Randal (SQLskills.com)

発行: 2011 年 7 月

概要:このホワイトペーパーでは、SharePoint 2010 製品のコンテンツおよび構成の設定をホストするデータベースの推奨メンテナンス戦略について説明します。

Microsoft SharePoint 2010 2011 年 7 月

このドキュメントは「現状のまま」提供されます。このドキュメントで説明されている情報およびビューは、URL および他のインターネット Web サイトの参照を含めて、予告なく変更されることがあります。そのようなリスクがあることを承知の上でお読みください。このドキュメントに記載されている事例の一部は、説明のみを目的とした架空のものです。実在する事例とは一切関係ありません。このドキュメントは、マイクロソフト製品の知的所有権に対する法的な権利をお客様に提供するものではありません。このドキュメントの複製と利用は、お客様が社内でこれを参照する目的の場合に限って許可されます。

© 2011 Microsoft Corporation.All rights reserved.

© 2011 Microsoft Corporation.All rights reserved. ページ | 2このホワイトペーパーまたは機能に関するご意見、ご要望については、SharePoint IT ドキュメントチーム ([email protected]) までお送りください。

mailto:[email protected]?subject=Customer%20feedback


要約このホワイトペーパーでは、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はじめに......................................................................................................................................... 5DBCC CHECKDB による整合性エラーのチェック.......................................................................5DBCC CHECKDB について...........................................................................................................6DBCC CHECKDB とパフォーマンス............................................................................................7インデックスの断片化の測定および削減......................................................................................7オンラインおよびオフラインでのインデックスの再構築.............................................................8SQL Server 2008 または 2005 データベースの断片化の測定 (sys.dm_db_index_physical_stats).............................................................................................9

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

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

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

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

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

SQL Server 2008 メンテナンスプランの作成............................................................................17SQL 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 に無駄が生じます。テーブルで挿入、更新、または削除を繰り返すと、インデックスが断片化します。次の図は、新しく作成された断片化されていないインデックスと、挿入、更新、削除を繰り返したことで断片化したインデックスを示しています。赤の矢印はインデックスの物理的な順序、黒の矢印はインデックスページの論理的な順序を表します。



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

http://www.sqlskills.com/BLOGS/PAUL/post/A-SQL-Server-DBA-myth-a-day-(230)-DBCC-CHECKDB-causes-blocking.aspx%20(%E8%8B%B1%E8%AA%9E)

http://www.sqlskills.com/BLOGS/PAUL/post/A-SQL-Server-DBA-myth-a-day-(230)-DBCC-CHECKDB-causes-blocking.aspx%20(%E8%8B%B1%E8%AA%9E)




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

図 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_descalloc_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)」(http://go.microsoft.com/fwlink/?LinkId=110840&clcid=0x409) を参照してください。

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 ルールに置き換



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




えられます。既定では、これらのルールは、ルールの対象に応じてさまざまなスケジュール (毎日、毎週、オンデマンドなど) で実行されるように構成されます。

毎日実行されるように構成され、特定の SharePoint サービスに関連付けられた Health Analyzer ルールはすべて、同じタイマージョブによって実行されます。このタイマージョブのスケジュールを調整すると、そのサービスに関連付けられた Health Analyzer ルールで、毎日実行されるように構成されたものが、一日のどの時間に実行されるかが調整されます。このホワイトペーパーで説明するルールはすべて、SharePoint Timer サービスに関連付けられています。

異なる間隔 (毎週など) で実行するように構成されている Health Analyzer ルールまたは異なるサービスに関連付けられている Health Analyzer ルールには、別のタイマージョブがあります。毎週実行されるように Health Analyzer ルールを構成するということは、その Health Analyzer ルールは、自身が関連付けられている特定のサービスに対して毎週実行されるように構成されたタイマージョブで実行されることを意味します。この実行処理は、そのタイマージョブに定義されているすべてのスケジュールで発生します。

Health Analyzer ルールを手動で実行するには、サーバーの全体管理の [Health Analyzer ルール] ページ内のリボンから [今すぐ実行] を選択します。これらのルールを実行すると、インデックスおよび統計の正常性が評価され、必要に応じてインデックスの再構築および再計算が行われます。

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_1GO




ALTER INDEX ALL ON [database_name.[ schema_name ] .| schema_name.]table_or_view_nameREBUILD 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)」(http://go.microsoft.com/fwlink/?LinkId=110850&clcid=0x409) を参照してください。サーバー全体の FILL FACTOR 値を構成するには、sp_configure システムストアドプロシージャを使用します。詳細については、「spconfigure (Transact-SQL)」(http://go.microsoft.com/fwlink/?LinkId=110851&clcid=0x409) を参照してください。

データファイルの圧縮SQL Server 2008 および SQL Server 2005 では、データベース内の各ファイル (拡張子は .mdf、.ldf、および .ndf) を圧縮して未使用のページを削除し、ディスク領域を回復することができます。SharePoint 2010 データベースのデータファイルは自動的には圧縮されませんが、多くのアクティビティによってデータベース内に未使用領域が発生します。たとえば、Move-SPSite (http://technet.microsoft.com/en-us/library/ff607915.aspx) Windows PowerShell コマンドの実行、ドキュメント、ドキュメントライブラリ、リスト、リストアイテム、サイトの削除などのアクティビティによって、未使用領域が発生します。

図 3. データベースの割り当て空き領域はファイルの最後からのみ解放されます。たとえば、60 GB のコンテンツデータベースファイルでターゲットサイズとして 40 GB が指定されている場合、データベースファイルの末尾 (概念的には "右端") の 20 GB からできるだけ多くの領域が解放されます。この末尾 20 GB に使用済みページが含まれている場合、そのページは、保持されているファイルの先頭の 40 GB に再配置されます。データベースファイルの圧縮は個別に行うことも、まとめて行うこともできます。圧縮操作を行う必要があるのはまれで、大量のデータをデータベースから削除した後と、空き領域が二度と利用されることがないと予想される場合にのみ実行します。データファイルを圧縮するとインデックスが過度に断片化されます。また、この処理はリソースを集中的に使用します。データベースデータファイルの圧縮が許容されるのは、コンテンツデータベース間で大量のサイトコレクションの再配置または大きなリストの削除のどちらかによって、大量の未使用領域が発生した場合などです。データベースファイルは、空き領域の分しか小さくなりま© 2011 Microsoft Corporation.All rights reserved. ページ | 15このホワイトペーパーまたは機能に関するご意見、ご要望については、SharePoint IT ドキュメントチーム ([email protected]) までお送りください。


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

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






せん。したがって、コンテンツの削除があまり行われないコンテンツデータベースの場合は、圧縮してもあまり効果がありません。また、データ追加に対応するためにデータベースを拡張する必要があるとき、特別な領域がないと、パフォーマンスが低下することがあります。詳細については、「データベースファイルの初期化」(http://msdn.microsoft.com/en-us/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 ]



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

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

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




[ , { NOTRUNCATE | TRUNCATEONLY } ] )[ WITH NO_INFOMSGS ]

database_name | database_id | 0 には、データベースの名前または ID を指定します。現在のデータベースを選択するには、0 を使用します。

target_percent は、データベースの圧縮後に保持する空き領域の割合です。

NOTRUNCATE は、ファイル末尾の割り当て済みのページをファイル先頭の未割り当てのページに移動することで、データファイルのデータを圧縮します。

TRUNCATEONLY は、ファイル末尾のすべての空き領域をオペレーティングシステムに解放します。ただし、ファイル内でページは移動されません。

メモ: TRUNCATEONLY オプションは、SharePoint 2010 コンテンツデータベースではサポートされていません。

詳細については、「DBCC SHRINKDATABASE (Transact-SQL) 」 (http://go.microsoft.com/fwlink/?LinkId=110852&clcid=0x409) を参照してください。

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)」(http://go.microsoft.com/fwlink/?LinkId=110853&clcid=0x409) を参照してください。







SQL Server 2008 Management Studio を使用してデータベースを圧縮するには1. タスクバーで [スタート] ボタンをクリックし、[すべてのプログラム]、[Microsoft SQL


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 データベースのメンテナンスプランを構成するには1. タスクバーで [スタート] ボタンをクリックし、[すべてのプログラム]、[Microsoft SQL


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 をホストするデータベースのメンテナンスを常に行っていれば、どの方法を使用しても、システムの状態とパフォーマンスは大幅に向上します。

メンテナンス作業およびメンテナンスプランを実装する場合は、必ず事前にすべてのデータベースの信頼できるバックアップを取ってください。

継続的に実行されるメンテナンス作業またはメンテナンスプランを実装する前に、システムへのメンテナンス実装の影響と実行に必要な時間をテストしてください。

メンテナンス作業またはメンテナンスプランはできる限り稼働時間外に実行し、ユーザーパフォーマンスへの影響を最小限に抑えます。



要約 - download.microsoft.comdownload.microsoft.com/.../databasemaintenancesharepoint201… ·...

Documents