昨天在教授 MCM 時與 SharePoint 專家交談時提出的另一個問題。 SharePoint 準則是不支援超過 100GB 的內容資料庫。在不深入了解這些準則背後的原因的情況下，我有興趣了解內容資料庫更大超過 100GB 以及您的使用體驗（主要圍繞效能、災難復原和 HA 配置）。
您已成功將 SharePoint 安裝推進到什麼程度？我聽過 > 1TB 內容資料庫的二手故事，但我想聽聽 SharePoint 管理員自己的聲音。
感謝您提供的任何資訊。
答案1
我們的資料庫分別為 111 GB 和 102 GB，可在 GigE 網路上在 30 分鐘內完成備份。我聽說較大的資料庫可能會出現長時間運行的預存程序的問題，但沒有看到任何演示。
「擴充 SharePoint 2007：儲存架構」白皮書中的一段精彩引用：
「...這通常被稱為『100GB 內容資料庫大小限制』。事實上，這並不是一個真正的限制，而是建議。多年來，SQL Server 資料庫的擴展規模已遠遠超過100GB。實際上，推薦主要基於兩個重要因素：
給定組織的服務等級協定 (SLA) 要求可能規定 SharePoint 資料庫的備份作業必須在有限的時間內執行。內容資料庫的大小將直接影響執行備份所需的時間。
儲存子系統必須足夠強大，能夠滿足其所服務的 SharePoint 解決方案的磁碟 I/O 要求。
只要給定的組織能夠減輕這兩個考慮因素，那麼就可以允許內容資料庫成長。現實世界中已經成功進行了 SharePoint 部署，資料庫大小為 100GB、150GB、200GB、250GB、300GB、350GB 和 400GB。
答案2
對於日常使用，資料庫大小並不那麼重要 - 大多數查詢會傳回一個清單中的項目，資料庫中還有什麼並不重要。然而，對整個資料庫進行操作將變得更加困難。備份是最明顯的例子 - 對於大型資料庫，備份將花費更長的時間。但是，只要資料庫不超過夜間備份的範圍，就可以了 - 備份被設計為可以長期運行，並且只要您不耗盡磁碟空間，備份就相當可靠。
您會遇到真正問題的地方是不太頻繁的事情，例如移動或升級內容資料庫- 這些可能需要大約5 倍的資料庫大小的可用空間，並且使用可以執行諸如觸發失控自動增長之類的操作的查詢來實現。
答案3
我們有一個大小為 300 GB 的內容資料庫。切換到 Lite Speed 後備份沒有問題。在切換之前，我們會看到網站效能嚴重下降。
根據記錄，我們不想擁有這麼大的內容資料庫。我們對內容共享有特定的業務要求，如果我們將內容放在單獨的網站集中，這些要求將很難實現。
當我們第一次上線時，我們在高峰使用期間遇到了資料庫的主要鎖定問題。我們將此追溯到 SharePoint 中 CrossListQueryCache 物件的使用。我們不再使用該 API，它修復了我們的許多效能。
我寫了一篇部落格文章，其中包含更多信息這裡。
我們仍然看到某些類型的更新（刪除> 20 MB 的blob）、重新命名Web（這可能會導致AllUserData 表中的大量記錄更新）的鎖定問題。從回收站中刪除大型項目） ），這些都可以追溯到SharePoint中特定預存程序刪除資料的方式，但我們還沒有解決方案。
就我個人而言，我認為在 AllUserData 表中獲得如此多的記錄後就會出現問題，而 MS 向人們傳達這一點的最簡單方法是保持在 100 GB 以下。
我建議 ping MS IT 的人員...我私下聽說他們有一個 > 800 GB 的 SharePoint 內容資料庫。
答案4
那是假的。尺寸沒有限制。他們建議不要使用大型資料庫，而只是為了使資料庫管理更容易並最大限度地減少備份/還原時間。我們可以說大小限制僅取決於您的 SQL 基礎架構。