いまさらながらコンテンツデータベースを計画する

SharePoint でポータルを構築する場合、どうしてもサイトコレクション、サイト、サブサイトの構成にばかり注目してしまいがちですが、実はコンテンツデータベースの設計も重要です。

SharePoint は、すべてのコンテンツを SQL データベースのテーブルに格納します。
標準では wss_contents という単一データベースで、いちデータベースの推奨値は最大 100GB です。
それなりの容量に思えますが、少し本気で活用しだすと、案外すぐ越えてしまいます。

推奨値を超過しても、即座に問題が発生するわけではありませんが、しかし、じわりじわりと障害の「種」が増えます。

例えば、データベースのロックが発生した場合、その影響はコンテンツデータベース全体に及びます。
つまり単一コンテンツデータベースの場合、全てのコンテンツにアクセスできなくなります。
しかし、予め分割しておけば、こうした事態を避けることができます。
ポータルサイトのレスポンスにも影響がありますので、基本は 100GB 以下に抑えます。

コンテンツデータベースの新規作成は簡単で、サーバの全体管理画面 > アプリケーション構成の管理 からGUIで行うことができます。

しかし、簡単でないのが既存コンテンツの移行です。
権限やメタデータを維持したままコンテンツデータベースを跨ぐのはかなり大変…と言うか、無理です。
Metalogix の SiteMigrationManager や AvePoint の DocAve 等のサードベンダーツールが必要になります。

従って、あらかじめ、ある程度サイト容量を勘案してコンテンツデータベースを分割し、かつその中でもサイトコレクションを分割してクォータをかける、などの事前計画が重要になります。
まあ、逆に割り切って最初から上のようなツール購入前提で、スモールスタートする（単一データベース、単一コレクション）方法もありますが。

ちなみに、コンテンツデータベースの容量 = SharePointに登録されたファイルのサイズではありません。
メタデータもありますし、ファイルも SQL のテーブルに登録されるため、実サイズより大きくなります。
Microsof の資料では、実体データの 1.2～1.5倍が想定値とされています。
つまり「100GB」のコンテンツデータベースも、実データでは70GB 程度だと認識しておく必要があります。

また、少し趣旨とずれますが、インデックスサーバの容量にも注意が必要です。
もし十分な容量のデータベース領域を確保したとしても、それを検索する側にもそれに見合った領域が必要になります。
Microsoft の推奨値によると、総容量に対して 5～12％とのこと。
仮に 500GB を検索対象とした場合、最低でも 50GB くらいは必要になることになります（経験上、実際にはこの半分くらいかと思いますが）

さて、複数のコンテンツデータベースを作成した場合、どのコンテンツデータベースにどのコンテンツ（サイトコレクション）が配置されているのかを把握しておくことも重要です。
障害時にどのコンテンツが影響をうけるかを知っておく必要がありますし、バックアップのサービスレベルにも関係します。
しかし、実は、SharePoint 2007 は、サイトコレクション作成時に「どのコンテンツデータベースにサイトコレクションを作成するか」を明示的に支持することができません。
SharePoint が勝手に判断して適切な（適当な？）データベースにサイトコレクションを作成する仕様です。

しかし、それでは運用が困ります。
次の方法で、管理者が明示的にコンテンツデータベースを指定することができます。

方法1：サイト最大値を変更する

SharePoint は、サイトコレクションが作成されるとき、既存コンテンツデータベースの中で、最も「最大サイト数－現在のサイト数」が大きいコンテンツデータベースを選択します。
そこで、意図的にこの数値（最大値）を変更すれば、どのコンテンツデータベースが選ばれるかを制御できます。

方法2：コンテンツデータベースを「オフライン」にする

オフライン、という言葉がやや怖いですが、SharePoint の GUI からコンテンツデータベースを「オフライン」にした場合、ユーザはなんの制限もなくそのデータにアクセスできますが、唯一、サイトコレクションを作成できなくなります。
そこで、狙ったコンテンツデータベース以外はすべて「オフライン」にしてしまうことで、結果的にどのデータベースにサイトコレクションが作成されるかを制御することができます。

あと、コンテンツデータベースで注意が必要なのが「監査ログ」でしょうか。
監査ログは IIS のそれと異なり、データベース内に格納されるのですが、環境次第では、このログが肥大化してデータベースを圧迫します。

監査ログ機能は利用していないから大丈夫…とは限りません。
じつは、SharePoint の監査ログは、同時に「情報管理ポリシー」のログでもあるのです。
この機能を利用している場合、毎晩相当な数のログが蓄積されます。
具体的には、データベース内の AuditData テーブルが肥大化します。

これを削除するコマンドは次のとおりです。
Trimauditlog : Stsadm 操作 (Office SharePoint Server)　
stsadm -o trimauditlog
-url
-date
-databasename <データベース名>
[-databaseserver] <データベース サーバー名>

例えば、コンテンツ データベース WSSContent から2010年8月30日のログを削除するには：
stsadm -o trimauditlog –date 201008030 –databasename WSSContent