共用方式為


評估升級程序所需的時間與空間 (SharePoint Foundation 2010)

 

適用版本: SharePoint Foundation 2010

上次修改主題的時間: 2016-11-30

從 Windows SharePoint Services 3.0 升級至 Microsoft SharePoint Foundation 2010 的升級規劃中,佔有舉足輕重的一個環節就是決定升級程序所需的時間,以及所需的儲存空間。每一個環境都是唯一的,且包含不同的硬體功能及不同的網站特性。執行升級所需的空間及時間,會因環境而有極大差異。評估這些因素的最佳方式是執行升級試驗,然後審視升級所需的空間及時間。如需如何執行升級試驗的詳細資訊,請參閱<利用試驗升級發掘潛在的問題 (SharePoint Foundation 2010)>。

本文內容:

  • 評估升級所需的空間

  • 評估升級所需的時間

評估升級所需的空間

不論是就地升級或資料庫附加升級方法,都可能在升級期間擴充資料庫。此外,執行升級程序時會產生多項異動,因此您必須確定記錄檔有足夠的空間可擴充以容納發生的變更。您必須同時為資料庫與記錄檔的擴充進行規劃。

規劃升級時,請確定目前的環境遵循 Windows SharePoint Services 3.0 儲存裝置最佳作法,使升級期間獲得最佳經驗與效能。如需詳細資訊,請參閱實體儲存裝置建議 (Office SharePoint Server);也可檢閱 SharePoint Foundation 2010 的最佳作法,並對升級後環境進行必要調整。

由於新版的資料表結構有所變更,因此資料庫在重新組織資料時會暫時擴充。雖然此空間在升級後即可復原,但是您應確定有足夠的空間,讓資料庫於就地升級或資料庫附加升級期間,可擴充為目前大小的 1.5 倍 (請注意,您可以於升級後,再次縮小資料庫以復原幾乎同樣的空間)。您也應確保資料庫伺服器上具有足夠的空間,可讓資料庫在一般使用情況下隨時間擴充。若要了解目前的資料庫大小,請使用 Microsoft SQL Server 中的 Enterprise Manager。除了資料庫空間外,您還必須為下列項目保留空間:

  • 暫存資料庫。請確認資料庫空間足以容納快速擴充的暫存資料庫。如果沒有足夠的空間,升級程序可能會逾時,而導致升級失敗。

  • 升級記錄檔。

  • 資料庫的交易記錄檔。這些記錄檔為容納資料庫諸多變更,一定會快速擴充。

    注意

    在極大型環境中,交易記錄檔預設擴充率 (10%) 可能不敷升級程序需求;如此即會造成逾時。要判斷交易記錄檔能否跟上升級程序需求的最好方法,還是要透過升級試驗。若為非常大型的環境,或是在升級試驗期間發生程序逾時,請考慮事先擴充 SQL Server 交易記錄檔,以確保有足夠空間供必須處理的交易量使用。如需如何擴充 SQL Server 交易記錄檔的詳細資訊,請參閱展開資料庫 (SQL Server 2005) (https://go.microsoft.com/fwlink/?linkid=182619&clcid=0x404) 或展開資料庫 (SQL Server 2008) (https://go.microsoft.com/fwlink/?linkid=182620&clcid=0x404)。

評估升級所需的時間

在掌握了磁碟空間評估數據並完成一些測試之後,現在您就可以粗略估算出實際升級程序所需時間。升級時間會隨環境大為不同。升級的效能則多取決於所使用的硬體、網站複雜性及實作的特定特性。例如,若有許多大型文件庫,升級所花費的時間會比簡單的網站長。

下表說明影響效能的因素。

內容因素 硬體因素

數目:

  • 網站集合

  • 子網站

  • 清單

  • 文件版本 (數目與大小)

  • 文件

  • 連結

加上資料庫本身的整體大小。

  • 每秒的 SQL Server 磁碟輸入/輸出

  • SQL Server 資料庫至磁碟配置

  • SQL Server 暫存資料庫最佳化

  • SQL Server CPU 與記憶體特性

  • 網頁伺服器 CPU 與記憶體特性

  • 網路頻寬與延遲

資料的結構方式會影響升級資料的時間長短。例如,升級各含 10 個項目的 10,000 個清單所需的時間,會比升級各含 10,000 個項目的 10 個清單更久。不論項目數為何,都必須先針對每個清單執行升級清單基礎結構所需的動作;因此,清單愈多等於動作愈多。此適用於上表之「內容因素」欄中大部分的項目。

硬體的結構也對效能有很大的影響。一般而言,資料庫伺服器效能比網頁伺服器效能更加重要,但不管在哪一層若有運作能力不足的硬體或連線問題,都將大幅影響升級效能。

您所選擇的升級方法也會對程序所耗時間造成極大的差異。執行資料庫附加升級是最快的方法 (但是,此方法的升級前及升級後步驟所需時間較就地升級長)。由於就地升級除了升級網站之外還要升級環境,因此需要較多時間,但是在使用此方法時的升級前及升級後步驟會比較少。

評估整體時間的最好方法,是以小部分或全部資料進行升級試驗,然後審視升級記錄檔。記錄檔包含升級的持續時間 (請查看升級記錄檔底部的 [總經過時間])。此時間可用以預估整組內容將花費多長時間。您也可以透過記錄檔在升級程序期間檢查進度。升級記錄檔位於 %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\14\LOGS。

根據升級試驗所獲得的評估數據,是針對資料實際升級程序,並不包括在此步驟前後所必須執行的所有步驟,這些步驟會比資料升級本身還花時間。評估升級所需時間時,除了資料處理所需的時間之外,還必須評估升級前及升級後各階段活動所花費的時間。

以升級前步驟而言,請考量下列因素:

  • 建立自訂元素   為使用新功能而升級網頁組件或重新設定自訂範本,需花費一點時間。建立自訂元素的程序應提早在專案評估階段就開始。

  • 備份資料庫   若是就地升級,您必須執行整個環境的完整備份 (而非差異備份),如此才能確保在升級失敗而必須重建伺服器陣列時,可從遠端加以復原。此步驟在大型環境中會需要很長時間。特別是要備份到網站位置時,網路延遲問題會拖延此程序。

以升級後步驟而言,請考量下列因素:

環境中的其他因素也會拉長升級時間,包括:

  • 極大型的文件庫   文件庫文件超過 250,000 份,且全在文件庫根目錄而不在資料夾中,會使升級非常耗時,且可能無法成功。請依據 Windows SharePoint Services 3.0 原則,利用資料夾分割大型文件庫,這將有助於管理文件庫大小。例如,若重新排列同一個文件庫,讓 250,000 份文件分散在 125 個資料夾中,應可使升級變得更容易。

  • 極大型的資料庫   大於 100 GB 的資料庫升級很耗時。

    注意

    若內容資料庫大於 100 GB,可能需要先分割成較小的資料庫再執行升級。大型資料庫不僅升級較耗時,且一旦升級未成功完成,也較難復原。
    您可以使用 Stsadm.exe 中的 mergecontentdbsbackup 加上 restore 作業,在資料庫之間移動網站。如需詳細資訊,請參閱 Mergecontentdbs:Stsadm 作業 (Windows SharePoint Services)備份與還原:Stsadm 作業 (Windows SharePoint Services)

    如果您有極大的資料庫 (超過 100 GB),且因為大部分的內容在單一網站集合中而無法分割,您可能會想要重新考慮升級方法。資料庫附加升級方法較難處理極大的資料庫,因為備份及還原如此大型的資料庫很麻煩。

    警告

    嘗試升級之前,請確定已遵循舊版及新版的容量規劃原則。若超過最佳效能的原則,升級程序可能會很耗時,或可能不成功 (例如,升級程序可能會在同一個大型文件庫上重複發生逾時)。若部署不符合建議的容量原則,請考慮是否必須執行某些作業以符合這些原則,再嘗試升級。同樣地,您還是可以透過升級試驗來幫助您下決定。

  • 溝通需求

    您必須通知使用者及小組有關升級時間表,並讓他們有時間完成工作。如需詳細資訊,請參閱<建立溝通計劃 (SharePoint Foundation 2010)>。

  • 管理系統中心提醒與警示

    您必須監視升級期間的系統效能,但不需要監視特定功能。請從 Microsoft Systems Center Operations Manager 或 Microsoft Operations Manager 暫停任何不必要的警示與提醒,然後於升級後重新啟動。

  • 開啟/關閉 SQL 鏡像及記錄傳送

    升級之前,請務必關閉鏡像及記錄傳送,然後於升級完成並確定環境運作正常之後,再重新開啟。建議您不要在升級期間執行鏡像或記錄傳送,因為如此做會造成執行 SQL Server 的伺服器上額外的負載,也會浪費資源用於鏡像或傳送暫存資料。

測試升級程序以了解升級所需的時間,然後建立升級作業的排程,並測試該排程以決定時間表。您應在作業時間表中包含執行升級前後步驟所需的時間:若開始前需要 5 小時備份環境,則需要將該時間納入作業中斷時程。另請包含緩衝時間,以防需要進行還原或復原 (您應決定預計的中斷 (實際情況) 及緊急中斷 (最糟情況) 時間表)。