本文為機器翻譯文章。如需檢視英文版,請選取 [原文] 核取方塊。您也可以將滑鼠指標移到文字上,即可在快顯視窗顯示英文原文。
譯文
原文

規劃升級到 SharePoint 2013 期間的效能

 

適用版本:SharePoint Foundation 2013, SharePoint Server 2013

上次修改主題的時間:2016-12-16

摘要:了解升級效能以及如何規劃升級到 SharePoint 2013 所需的空間與時間。

從 SharePoint 2010 產品升級至 SharePoint 2013 的升級規劃相當重要的一部分,就是決定升級程序所需的時間,以及所需的儲存空間。每一個環境都是唯一的,且包含不同的硬體功能及不同的資料庫和網站特性。執行升級所需的空間及時間長度,會隨環境而有極大的差異。評估這些因素的最佳方式是執行一或多次試驗升級,然後再檢閱升級所需的空間及時間。如需如何執行試驗升級的詳細資訊,請參閱<利用 SharePoint 2013 的試驗升級發掘潛在的問題>。

其中一個主要原因是資料庫升級與網站集合升級現在在 SharePoint 2013 中是個別的動作,讓您對升級效能擁有更多的控制權。

  • SharePoint 2010 產品升級的運作方式

    升級至 SharePoint 2010 產品期間,在升級資料庫的時候,該資料庫內的所有網站集合也會一併升級。這表示在特定步驟中,例如啟動產品或更新「快速啟動」控制權時,升級程序需要為資料庫中每個網站集合重複執行這些步驟,之後升級資料升級才能完成。

    SharePoint 2010 產品的升級程序

    SharePoint 2010 產品的升級程序

  • SharePoint 2013 升級的運作方式

    升級到 SharePoint 2013 的時候,資料庫升級不再開始這些網站特定步驟。因此,資料庫升級階段變得更快。有些測試已發現資料庫升級至 SharePoint 2013 的時間,是升級相同資料至 SharePoint 2010 產品的時間的三分之二。這些網站特定步驟仍然必須執行。不過,只有在升級網站集合時才需要執行它們,而且只需要為該網站執行。因為每個網站集合是個別升級的,所以您可以管理您環境中這些升級的效能要求。

    SharePoint 2013 產品的升級程序

    SharePoint 2013 產品的升級程序

對於 SharePoint 2013,一次控制可以升級幾個網站,即可控制網站集合升級的效能要求。有一個網站集合佇列中保留了目前要求被升級的網站集合清單。另外在內容資料庫及 Web 應用程式層級上還有節流閥,來控制一次可以升級幾個網站集合。如需這些控制的詳細資訊,請參閱<在 SharePoint 2013 中規劃網站集合升級>和<管理升級到 SharePoint 2013 的網站集合升級>。

除了規劃升級期間的效能,也可以規劃升級後生產環境的效能。使用所規劃的硬來測試規劃的環境,確認它們可以支援這個環境。

資料庫升級時,它們可能會暫時擴充。此外,執行升級程序時會產生多項異動,因此您必須確定記錄檔有足夠的空間可擴充以容納發生的變更。所以,您必須同時為資料庫與記錄檔的成長進行規劃。

由於新版的資料表結構有所變更,因此資料庫在重新組織資料時會暫時擴充。雖然此空間在升級後即可復原,但是您應確定有足夠的空間,讓資料庫於升級期間,可擴充為目前大小的 1.5 倍 (請注意,您可以於升級後,再次縮小資料庫以復原幾乎同樣的空間)。

您也應確保資料庫伺服器上具有足夠的空間,可讓資料庫在一般使用情況下隨時間擴充。若要了解目前的資料庫大小,請使用 SQL Server 中的 Enterprise Manager。

除了資料庫的空間以外,您必須也要為資料庫的交易記錄檔預留空間。這些記錄檔為容納資料庫的諸多變更,一定會快速成長。

非常大環境中有交易記錄檔 (10%) 預設成長率不足以應付進行升級程序的可能性。這會導致逾時。同樣地,試用版升級是判斷交易記錄檔是否能夠應付進行升級程序的最佳方式。如果您的環境是非常大或者在試用版升級期間逾時的程序,請考慮展開SQL Server交易記錄檔事先以確定您有可供必須已處理交易數。如需如何依序展開 [ SQL Server交易記錄檔的詳細資訊,請參閱展開資料庫 (SQL Server 2008 R2)

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

下列清單說明影響升級效能的因素。

  • 環境因素  下列因素可以影響資料庫與網站集合兩者的升級效能:

    • 同時升級

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

    • SQL Server 資料庫至磁碟配置

    • SQL Server 暫存資料庫最佳化

    • SQL Server CPU 與記憶體特性

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

    • 網路頻寬與延遲

  • 資料庫因素  下列因素可以影響資料庫的升級效能。數目:

    • 網站集合

    • 子網站

    • 清單

    • 清單內的 Rowspan

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

    • 文件

    • 連結

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

  • 網站集合因素  下列因素可以影響網站集合的升級效能。數目:

    • 子網站

    • 清單

    • 已啟用的升級功能

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

    • 文件

    • 連結

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

硬體的結構也對效能有很大的影響。一般而言,資料庫伺服器效能比網頁伺服器效能更加重要,但各層若有能力不佳的硬體或連線問題,都將大幅影響升級效能。網頁伺服器對於資料庫升級效能佔了很重要的部分,主要是因為它發出命令來變更資料庫中的資料及結構。資料庫伺服器必須處理這些變更,並操作每個命令的龐大資料集。在網站集合升級期間,網頁伺服器效能會是更大的問題,當升級程序為每個網站集合反覆執行數個動作 (可能一次數個網站集合一起發生)。網站集合升級也會影響資料庫伺服器,因為 SQL Server 中必須發生每個動作。

評估整體時間的最好方法,是執行資料的試驗升級,然後檢閱升級記錄檔。記錄檔包含升級的持續時間 (請尋找升級記錄檔底部的 [總共經歷時間])。此時間可用以預估整組內容的持續時間。您也可以使用記錄檔在升級程序期間檢查進度。升級記錄檔位於 %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\15\LOGS。

若要從記錄檔判斷持續時間,請檢查下列各項:

  • 各個記錄檔每個升級序列所花的時間。

  • 各個記錄檔每個升級動作執行個體所花的時間。

  • 最小、最大以及平均時間。

請確定區隔資料升級時間與升級網站集合升級時間,以便制定精確的規劃。執行多次試驗升級,確保得到更正確的數據。接著核對多個測試的數據,判斷各序列、各動作及各資料庫可能的效能。您可以使用 Windows PowerShell 中的 Get-SPUpgradeActions Cmdlet 檢視伺服器陣列上發生多少個動作。如需詳細資訊,請參閱<Get-SPUpgradeActions>。

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

請考慮下列因素:

  • 建立自訂元素   升級網頁組件,或是重新執行自訂範本以利用新功能,都需要較多的時間。建立自訂元素的程序應早點開始,最好在專案評估階段就開始。

  • 備份資料庫   對於資料庫附加升級,您必須對資料庫執行完整備份,而不是差異備份。此步驟在大型環境中會需要很長的時間。特別是要備份到網站位置時,網路延遲問題會拖慢此程序。

  • 建立服務應用程式以及設定服務   建立服務應用程式以及設定服務不需要太長的時間,但若必須聯絡資料庫管理員在您建立服務應用程式之前預先為您建立資料庫,可能需要一至兩天的前置時間。

  • 對所有內容執行搜尋編目   此步驟在大型網站約需 24 小時以上。除非執行編目,否則搜尋不可能傳回結果,因為索引沒有升級。

  • 升級環境後進行驗證   在大型環境中,驗證環境並檢查網站集合,以確保它們是良好狀態才允許使用者存取,可能需要一些時間。如需詳細資訊,請參閱<在 SharePoint 2013 中驗證資料庫的升級>。

若是網站集合升級,請考量下列因素:

環境中的其他因素也會拉長升級時間。這些因素包括下列項目:

  • 極大型的文件庫   文件超過 250,000 份且全在文件庫根目錄而不在資料夾中的文件庫,升級非常耗時,也可能無法成功。請依據指導原則使用資料夾分割大型文件庫,有助於管理文件庫大小。例如,若重新排列相同的文件庫,讓 250,000 份文件分為在 125 個資料夾中,則升級會容易得多。

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

    若內容資料庫大於 100 GB 而且包括混合的網站類型 (例如「我的網站」和小組網站以及發佈的網站),則建議您先將其分成數個內含資料類型一致的較小型資料庫,再執行升級。

    注意事項 附註:
    「我的網站」在 SharePoint Server 中才有提供,SharePoint Foundation 不提供。

    您可以使用 Move-SPSiteWindows PowerShell Cmdlet 在資料庫之間移動網站。如需詳細資訊,請參閱<Move-SPSite>。

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

  • 寬幅清單 (含有許多欄的清單)

    寬幅清單列示的欄數超過內容資料庫中單一 Rowspan 可以容納的數。升級期間,這些清單需要更長的時間進行處理,或者它根本無法升級。如需詳細資訊,請參閱<升級到 SharePoint 2013 之前清理環境>。.

  • 包含許多子網站的網站

    在網站集合升級期間,包含了數百或數千個子網站的網站集合需要很長的處理時間。例如,包含了數千個子網站的網站集合需要花費許多個小時 (而不只是幾分鐘) 或更長的時間來升級。

  • 溝通需求

    您必須通知使用者及小組有關升級的排程時間,並讓他們有時間執行工作。如需詳細資訊,請參閱<建立升級到 SharePoint 2013 的通訊計畫>。

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

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

  • 開啟/關閉 SQL Server 鏡像及記錄傳送 (或 AlwaysOn Availability Groups)

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

    這同樣適用於 SQL Server 2012 中的 AlwaysOn Availability Groups。

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

完成升級之後,環境的效能可能會有一些延遲,因為它正在歷經改變。請確定升級後與預期的效能比對來確認實際的效能,以確保新的伺服器陣列的運行在可接受的範圍內。請檢查 SQL Server 回應性:磁碟佇列長度太長了嗎?CPU 與記憶體的使用率太高了嗎?另外也請檢查網頁伺服器與應用程式伺服器的回應性:每秒要求 (RPS) 數是可接受的嗎?頁面載入時間 (初始及後續頁面要求) 如何?請檢閱整體環境效能,並依需要進行調整。

https://technet.microsoft.com/zh-tw/library/cc303429.aspx
顯示: