SharePointコンテンツデータベースの最大サイズ
昨日MCMを教えている間にSharePointの達人と話すことからのもう1つの質問。 SharePointのガイドラインでは、100GBを超えるコンテンツデータベースはサポートされていません。これらのガイドラインの背後にある理由に触れずに、コンテンツデータベース大きい 100GBとそれについての経験（主にパフォーマンス、災害復旧、HAプロビジョニングについて）について聞きたいです。
SharePointのインストールをどこまでプッシュできましたか？ 1 TBを超えるコンテンツデータベースの中古の話を聞いたことがありますが、SharePoint管理者自身から聞きたいです。
あなたが持っている情報をありがとう。
GigEネットワークでは、それぞれ111 GBと102 GBのDBがあり、30分未満でバックアップされます。大きなデータベースでは、実行時間の長いストアドプロシージャで問題が発生する可能性があると聞いたことがありますが、デモはありません。
「SharePoint 2007のスケーリング：ストレージアーキテクチャ」ホワイトペーパーからの素晴らしい引用：
「...これは一般に「100GBコンテンツデータベースのサイズ制限」と呼ばれます。実際、これは本当の制限ではなく、推奨事項です。SQLServerデータベースは何年もの間100GBをはるかに超えて拡張されています。実際には、推奨事項は、主に2つの重要な要素に基づいています。
特定の組織のサービスレベルアグリーメント（SLA）要件により、SharePointデータベースのバックアップ操作を限られた時間内に実行可能にする必要がある場合があります。コンテンツデータベースのサイズは、そのバックアップの実行にかかる時間に直接影響します。
ストレージサブシステムは、サービスを提供するSharePointソリューションのディスクI/O要件を処理するのに十分な堅牢性が必要です。
特定の組織がこれら2つの考慮事項を軽減できる限り、コンテンツデータベースの拡張を許可できます。実際の実装では、100 GB、150 GB、200 GB、250 GB、300 GB、350 GB、400GBのデータベースサイズを実装したSharePointの導入が成功しています。」
サイズが300GBのコンテンツデータベースがあります。 LiteSpeedに切り替えた後のバックアップに問題はありません。切り替え前は、Webサイトのパフォーマンスが大幅に低下していました。
ちなみに、これほど大きなコンテンツDBは必要ありませんでした。コンテンツを個別のサイトコレクションに配置した場合、実装が非常に困難であったコンテンツ共有に関する特定のビジネス要件がありました。
私たちが最初に稼働したとき、ピーク使用時にデータベースで大きなロックの問題が発生しました。これは、SharePointでのCrossListQueryCacheオブジェクトの使用にまでさかのぼります。そのAPIの使用から変更し、パフォーマンスの多くを修正しました。
私はより多くの情報を含む小さなブログ記事を書きました ここ 。
特定の種類の更新（20 MBを超えるblobの削除）、Webの名前変更（これにより、AllUserDataテーブルの多くのレコードが更新される可能性があります。特定の場合（つまり、ごみ箱から大きなアイテムを削除する）でMSサポートと協力してロックの問題が発生します。 ）これらは、SharePointの特定のストアドプロシージャがデータを削除する方法までさかのぼりますが、まだ解決策はありません。
個人的には、AllUserDataテーブルに非常に多くのレコードを取得した後に問題が発生すると思います。MSがこれを人々に伝える最も簡単な方法は、100GB未満にとどまると言うことでした。
MSITの担当者にpingを送信することをお勧めします...彼らが800GBを超えるSharePointコンテンツDBを持っているとオフレコで聞いたことがあります。
日常の使用では、データベースのサイズはそれほど重要ではありません。ほとんどのクエリは1つのリスト内のアイテムを返し、データベース内の他の内容は関係ありません。ただし、データベース全体で機能する操作はより困難になります。バックアップは最も明らかな例です。大規模なデータベースでは、バックアップに時間がかかります。ただし、データベースが一晩でバックアップできるものを超えない限り、問題はありません。バックアップは長時間実行するように設計されており、ディスク領域が不足しない限り、かなり信頼性が高くなります。
実際の問題が発生するのは、コンテンツデータベースの移動やアップグレードなど、頻度の低いものです。これらは、空き領域にデータベースサイズの約5倍を必要とし、制御不能な自動拡張のトリガーなどを実行できるクエリを使用して実装されます。
当社のデータベースは現在140Mbです。複数のバージョンの添付ファイルを含む添付ファイルを含む1.5Gbまで拡大することが許可されている特定のリストでパフォーマンスが低下しています。 （ちなみに私は約2ヶ月しかそこにいませんでした）。現在移行を計画しており、Metalogixツールを使用してSP 2010に移行する場合、テストに基づいて完了するまでに数日かかる可能性があります。私たちのデータベースは設計が不十分で、設計が不十分なポータルです。私たちの人々は実際の問題でそれを管理しなければなりません。
実稼働環境の正確なコピーであるバックアップサイトを使用しています。ただし、ハードウェアは、最後のハードウェアアップデート後の古いハードウェアです。開発用の古いハードウェア、本番用の新しいハードウェアです。ただし、パフォーマンスの問題により、開発環境の一部の領域は使用できず、大規模なリストの一部の開発は本番環境で実行する必要があります。痛い、痛い、痛い…。
それは誤りです。サイズに制限はありません。彼らは大きなデータベースを持たないことをお勧めしますが、データベース管理をより簡単にし、バックアップ/復元時間を最小化するためだけです。サイズ制限はSQLインフラストラクチャのみに依存すると言えます。