SharePointコンテンツデータベースの最大サイズ

昨日MCMを教えている間にSharePointの達人と話すことからのもう1つの質問。SharePointのガイドラインでは、100GBを超えるコンテンツデータベースはサポートされていません。これらのガイドラインの背後にある理由になってなければ、私は、コンテンツデータベースを聞いて興味が大きくなる 100ギガバイトよりも、それらとあなたの経験（主に周りのパフォーマンス、災害復旧、およびHAはプロビジョニング）。

SharePointのインストールをどこまでプッシュできましたか？1TBを超えるコンテンツデータベースの古本の話を聞いたことがありますが、SharePoint管理者からの連絡をお待ちしています。

あなたが持っている情報をありがとう。

GigEネットワークでは、それぞれ111 GBと102 GBのDBがあり、30分未満でバックアップされます。大きなデータベースでは、長時間実行されるストアドプロシージャで問題が発生する可能性があると聞いていますが、そのデモはありません。

「Scaling SharePoint 2007：Storage Architecture」ホワイトペーパーからの素晴らしい引用：

「...これは一般に「100 GBのコンテンツデータベースのサイズ制限」と呼ばれます。実際、これは本当の制限ではなく、推奨事項です。SQLServerデータベースは、何年もの間100 GBをはるかに超えてスケ​​ーリングしています。実際には、推奨は主に2つの重要な要素に基づいています。

1. 特定の組織のサービスレベルアグリーメント（SLA）要件により、SharePointデータベースのバックアップ操作は限られた時間内で実行可能でなければならない場合があります。コンテンツデータベースのサイズは、そのバックアップの実行にかかる時間に直接影響します。

2. ストレージサブシステムは、サービスを提供するSharePointソリューションのディスクI / O要件を処理するのに十分な堅牢性が必要です。

特定の組織がこれら2つの考慮事項を軽減できる限り、コンテンツデータベースの拡大を許可できます。実際の実装では、100 GB、150 GB、200 GB、250 GB、300 GB、350 GB、400 GBのデータベースサイズを実装したSharePointの導入が成功しています。」

日常的な使用では、データベースのサイズはそれほど重要ではありません。ほとんどのクエリは1つのリストでアイテムを返し、データベース内の他のアイテムは関係ありません。ただし、データベース全体を操作する操作はより困難になります。バックアップは最も明らかな例です。大規模なデータベースでは、バックアップに時間がかかります。ただし、データベースが一晩でバックアップできるものを超えない限り、問題はありません。バックアップは長時間実行するように設計されており、ディスク領域が不足しない限り、かなり信頼できます。

実際の問題が発生するのは、コンテンツデータベースの移動やアップグレードなどの頻度が少ない場合です。これらは、空き領域でデータベースサイズの約5倍を必要とし、制御不能な自動拡張などのトリガーを実行できるクエリを使用して実装されます。

サイズが300 GBのコンテンツデータベースがあります。Lite Speedに切り替えた後のバックアップに問題はありません。切り替え前は、Webサイトのパフォーマンスが大幅に低下していました。

ちなみに、コンテンツデータベースをこれほど大きくしたくありませんでした。コンテンツを個別のサイトコレクションに配置した場合、実装が非常に困難であったコンテンツ共有に関する特定のビジネス要件がありました。

最初に稼働したとき、使用量のピーク時にデータベースに大きなロックの問題がありました。これは、SharePointでのCrossListQueryCacheオブジェクトの使用まで遡ります。そのAPIの使用から変更し、それにより多くのパフォーマンスが修正されました。

詳細については、こちらのブログ記事にまとめました。

特定のタイプの更新（BLOBを削除する> 20 MB）、Webの名前を変更すると、ロックの問題が引き続き発生します（これにより、AllUserDataテーブルの多数のレコードが更新される可能性があります。特定のケース（つまり、ごみ箱から大きなアイテムを削除する）についてMSサポートと協力しています）これらは、SharePointの特定のストアドプロシージャがデータを削除する方法までさかのぼりますが、まだ解決策はありません。

個人的には、AllUserDataテーブルに非常に多くのレコードを取得した後に問題が発生すると思います。MSがこれを人々に伝達する最も簡単な方法は、100 GB未満を維持することでした。

MS ITの人々にpingを実行することをお勧めします... 800 GBを超えるSharePointコンテンツDBを持っているというオフレコを聞いたことがあります。

当社のデータベースは現在140Mbです。複数のバージョンの添付ファイルを含む添付ファイルを含む1.5Gbまで拡大することが許可されている特定のリストでパフォーマンスが低下しています。（ちなみに私はたった2ヶ月しか行っていません）。現在、移行を計画しており、Metalogixツールを使用してSP 2010に移行すると、テストに基づいて完了するまでに数日かかる場合があります。私たちのものは、設計が不十分なデータベースであり、設計が不十分であり、実際の問題でそれを管理しなければならない人々がいます。

私たちが使用するバックアップサイトは、実稼働環境の正確なコピーです。ただし、ハードウェアは、前回のハードウェアアップデート後の古いハードウェアです。開発用の古いハードウェア、本番用の新しいハードウェアです。ただし、パフォーマンスの問題のため、開発環境の一部の領域は使用できません。大規模なリストでの一部の開発は、本番環境で実行する必要があります。痛い、痛い、痛い...

それは誤りです。サイズに制限はありません。彼らは、大きなデータベースを持たないことをお勧めしますが、データベース管理をより簡単にし、バックアップ/復元時間を最小化するためだけです。サイズの制限は、SQLインフラストラクチャのみに依存すると言えます。