共用方式為

實體儲存裝置建議 (Office SharePoint Server)

  • 發行項

您所選擇的磁碟與陣列，以及在這些磁碟與陣列中存放資料的方式，對系統效能有很大的影響。若您對獨立磁碟容錯陣列 (RAID) 不熟悉，請參閱下列資源：

本主題主要說明 SQL Server 2008，但是也支援 Microsoft SQL Server 2005 與 Microsoft SQL Server 2000。

使用適當的磁碟與 RAID 陣列

下列清單提供一些用以選擇最佳 RAID 層級與硬碟的最佳作法與建議：

  • 較多與較快的磁碟或陣列可改善效能。關鍵在於維持所有磁碟的低延遲性與佇列功能。

  • 若要取得較高的可用性與效能 (隨機讀取/寫入)，請將陣列設定為 RAID 10。

  • 設定 RAID 陣列前，請先洽詢儲存裝置硬體廠商或參閱相關文件。請考量較快的隨機讀取回應時間對資料庫是否有所助益；以靜態網站內容為例，RAID 5 與 RAID 10 所提供的效能幾近相同。另一方面，隨機寫入回應時間是否夠快則可能較為重要；以讀取-寫入混合使用的共同作業網站為例，RAID 10 較具有優勢。

  • 設定 RAID 陣列時，請務必根據廠商所提供的位移進行檔案系統對齊。如果廠商未提供相關指導，請參閱 SQL Server 預先部署 I/O 最佳作法 (英文) (https://go.microsoft.com/fwlink/?linkid=105583&clcid=0x404)。

如需佈建 RAID 與 SQL Server I/O 子系統的詳細資訊，請參閱 SQL Server 最佳作法文章 (英文) (https://go.microsoft.com/fwlink/?linkid=168612&clcid=0x404)。

部署新的伺服器陣列之前，建議您使用 SQLIO Disk Subsystem Benchmark Tool 評定 I/O 子系統的效能。如需詳細資訊，請參閱 SQLIO Disk Subsystem Benchmark Tool (英文) (https://go.microsoft.com/fwlink/?linkid=105586&clcid=0x404)。

主動管理持續成長的資料與記錄檔

  • 預估資料與記錄檔的大小。

  • 不要只是仰賴自動成長功能，而應以手動方式管理持續成長的資料與記錄檔。您可以基於安全考量啟用自動成長，但同時也應主動管理持續成長的資料與記錄檔。

  • 設定自動成長設定，以符合部署的需求。

    • 如果規劃的內容資料庫超出建議的大小 (100 GB)，請將資料庫自動成長值設為固定的 MB 數目，而非百分比。如此可減少 SQL Server 增加檔案大小的頻率。增加檔案大小是一種封鎖作業，包括使用空白頁填入新的空間。

      注意

      在 Windows Server 2003 上執行的 SQL Server 2008 支援即時檔案初始化。即時檔案初始化可以大幅降低檔案成長作業對效能的影響。如需詳細資訊，請參閱資料庫檔案初始化 (https://go.microsoft.com/fwlink/?linkid=132063&clcid=0x404)。

    • 如果規劃的內容資料庫小於建議的大小 (100 GB)，請在使用 ALTER DATABASE MAXSIZE 屬性建立此類內容資料庫時，將資料庫設為 100 GB。

    • 如果磁碟空間有限，或無法調整資料庫的大小，則應將自動成長值設為固定百分比。例如，如果資料庫小於 500 GB，請將自動成長值設定為 10%，而如果資料庫超出 500 GB，則請將自動成長值設定為固定的 MB 數目。

  • 維持至少 25% 左右的可用磁碟空間以因應成長與尖峰使用模式。若是以在 RAID 陣列中新增磁碟的方式或配置更多儲存空間之方式因應成長，請嚴密監視磁碟大小，以避免發生空間不足的情況。

限制內容資料庫的大小以改善管理

規劃資料庫大小的調整，以改善管理與環境的效能。

注意

此處建議的限制只適用於執行 SQL Server 2008 且主控 Microsoft Office SharePoint Server 2007 的伺服器，且並非 SQL Server 2008 的一般指導。

  • 在大部分的情況下，若要增強 Office SharePoint Server 2007 的效能，建議不要使用大於 100 GB 的內容資料庫。若您的設計需要大於 100 GB 的資料庫，請遵循以下的指導：

    • 如有多個網站集合，請勿使用大於 100 GB 的資料庫。

    • 使用差異備份解決方案，例如 SQL Server 2008 或 Microsoft System Center Data Protection Manager 2007，而不要使用內建的備份與復原工具。

    • 在移至依賴 100 GB 內容資料庫的解決方案前，請先測試執行 SQL Server 2008 的伺服器及 I/O 子系統。

  • 將包含多個網站集合的內容資料庫限制在大約 100 GB。

區分磁碟中的資料，並為其定出優先順序

tempdb 資料庫、內容資料庫及 SQL Server 2008 交易記錄最好存放在不同的實體硬碟中。

下列清單提供某些排定資料優先順序的最佳作法與建議：

  • 在速度較快的磁碟間排定資料的優先順序時，請使用下列分級方式：

    1. Tempdb 資料檔與交易記錄

    2. 資料庫交易記錄檔

    3. 搜尋資料庫

    4. 資料庫資料檔

    在絕大部分以讀取為主的入口網站中，資料的優先順序應高於記錄檔。

  • 根據測試與客戶資料顯示，Office SharePoint Server 2007 伺服器陣列的效能可能會因為 tempdb 的磁碟 I/O 不足而大幅降低。為避免此問題，請為 tempdb 配置專用的磁碟。若預計或監視到很高的工作量 (亦即平均讀取作業或平均寫入作業需要 20 毫秒以上)，您可能必須分隔磁碟間的檔案，或以速度較快的磁碟取代原有磁碟，以緩解瓶頸。

  • 為發揮最佳效能，請將 tempdb 放置於 RAID 10 陣列上。tempdb 資料檔數目應等於核心 CPU 的數目，且 tempdb 資料檔應設定為相同的大小。為此目的，請將雙核心處理器計為兩個 CPU。另請將每個支援超執行緒的處理器計為單一 CPU。如需詳細資訊，請參閱最佳化 tempdb 效能 (https://go.microsoft.com/fwlink/?linkid=148537&clcid=0x404)。

  • 將不同磁碟的資料庫資料與交易記錄檔分開。如果因為檔案太小而無法使用整個磁碟或等量磁碟區，或您的磁碟空間不足，而使檔案必須共用磁碟，請將使用模式不同的檔案存放在相同的磁碟上，以儘可能減少同時執行的存取要求。

  • 請洽詢儲存裝置硬體廠商，以瞭解應如何設定所有記錄檔與搜尋資料庫，才能在您特定的存儲解決方案中發揮最佳的寫入效能。

  • 為搜尋資料庫配置專用磁針。

為大型內容資料庫和 SSP 搜尋資料庫使用多個資料檔

若要改善大型內容資料庫和 SSP 搜尋資料庫的效能，請考慮使用多個資料檔。

注意

  • 內容資料庫和 SSP 搜尋資料庫以外的資料庫無法使用多個資料檔。

  • SharePoint 產品及技術資料庫無法使用 SQL Server 磁碟分割。請僅使用簡單的資料檔。

為內容資料庫使用多個資料檔

請遵循下列建議以獲取最佳效能：

  • 在資料庫中，僅建立主要檔案群組中的檔案。

  • 將檔案分配到不同的磁碟。

  • 資料檔數目應小於或等於核心 CPU 的數目。為此目的，請將雙核心處理器計為兩個 CPU。另請將每個支援超執行緒的處理器計為單一 CPU。

  • 建立大小相同的資料檔。

重要

雖然 SharePoint 產品及技術內建的備份與復原工具，可用以備份及復原多個資料檔，但是若您在相同的位置進行覆寫，則這些工具無法將多個資料檔還原至不同的位置。有鑑於此，強烈建議您在對單一內容資料庫使用多重資料檔時，應使用 SQL Server 備份與復原工具。如需備份及復原 Office SharePoint Server 2007 的詳細資訊，請參閱＜選擇備份和復原工具 (Office SharePoint Server)＞。

如需建立及管理檔案群組的詳細資訊，請參閱實體資料庫檔案與檔案群組 (https://go.microsoft.com/fwlink/?linkid=117909&clcid=0x404)。

為 SSP 搜尋資料庫使用多個資料檔

針對搜尋資料庫，建議使用檔案群組分隔主要用於編目與查詢處理的資料表。而主控主要受到編目影響之資料表的檔案群組，應該從主要檔案群組移至另一組磁針，以將對 I/O 子系統的影響降到最低。

下表列出主要與編目相關的資料庫資料表。

MSSAnchorChangeLog

MSSCrawlDeletedErrorList

MSSAnchorPendingChangeLog

MSSCrawlDeletedURL

MSSAnchorText

MSSCrawlErrorList

MSSAnchorTransactions

MSSCrawlHostList

MSSCrawlChangedSourceDocs

MSSCrawlQueue

MSSCrawlChangedTargetDocs

MSSCrawlURL

MSSCrawlContent

MSSCrawlURLLog

MSSTranTempTable0

重要

Transact-SQL 指令碼可用於將這些資料表移至檔案群組。這些指令碼是移動與編目相關之資料表唯一支援的機制。張貼於 Microsoft Enterprise Search 部落格的部落格文章 SQL 檔案群組和搜尋 (英文) (https://go.microsoft.com/fwlink/?linkid=132066&clcid=0x404) 中包含有這些指令碼。

請遵循下列建議以獲取搜尋資料庫的最佳效能：

  • 將資料表移出資料庫的主要檔案群組。

  • 將檔案分配到不同的磁碟。

重要

將資料表移至新的檔案群組之程序，包含捨棄與重新建立許多叢集索引，因此非常昂貴且需要數小時才可完成。假設您的資料庫在移動期間會離線。

已知問題

下列各節說明將檔案群組用於搜尋資料庫的已知問題。

備份與還原

SharePoint 產品及技術中的備份與還原無法感知檔案群組。沒有任何方法可以指出新檔案群組的目標還原位置。還原程序會嘗試將編目檔案群組置於建立備份時，其所在的相同磁碟機上。若要進行還原，則用於編目與主要檔案群組的磁碟機，必須與初始備份磁碟機的磁碟機代號相同。

未來的更新、Service Pack 和 Hotfix

套用至伺服器的每項更新、Service Pack 與 Hotfix，都可能會修改已移至編目檔案群組的索引，或將新的索引新增至其中一個已移至檔案群組的資料表。若發生上述任一情況，會將索引移回主要檔案群組，或在主要檔案群組中重新建立索引。

因為可能會發生修改索引的風險，所以在套用任何更新之後，應執行 Enterprise Search 部落格上所提供的指令碼，以重複將資料表移至檔案群組的程序。

至少需要 SQL Server 2005，而最好使用 SQL Server 2008

用以移動索引的產品小組指令碼，使用 SQL Server 2005 發行且在 SQL Server 2008 中續用的功能。只有當您執行 SQL Server 2005 或更新版本時，才可執行此最佳化。 .

遵循廠商的設定建議

設定實體儲存裝置陣列時若要具有最佳效能，請依照儲存裝置廠商所提供的硬體設定建議作業，而不要使用作業系統的預設值。

若廠商未提供相關指導，建議您使用 DiskPart.exe 磁碟設定公用程式，為 SQL Server 2008 設定儲存裝置。如需詳細資訊，請參閱預先部署 I/O 的最佳作法 (英文) (https://go.microsoft.com/fwlink/?linkid=105583&clcid=0x404)。

下載本書

本主題隨附於下列可下載的叢書中，以便於閱讀與列印：

請參閱 Office SharePoint Server 2007 的可下載內容 (https://go.microsoft.com/fwlink/?linkid=89172&clcid=0x404) 上提供的完整叢書清單。