云計算行業專家指出，未使用的數據(在內部部署的數據數量可以忽略不計)可能會嚴重影響企業采用云平臺的預算。

[[329282]]

數字化轉型正在導致很多企業面臨前所未有的海量數據。許多人認為，面對不斷增長的數據量和更復雜的分析要求，從Microsoft Azure或AWS云平臺運行SQL Server數據庫是確保IT性能的優秀方法。但是，對于某些人而言，最初的希望是通過切換到云平臺能夠以更高的成本效益進行工作。一個重要的原因可能是尚未針對新的云計算環境預先優化數據資產。因此，只有在充分準備之后才能完成遷移。

遷移到云端就像搬入新家：當在家中查看所有物品時，很可能出現自己都不知道擁有的東西。不可避免地出現的問題是：家中的每一件物品都與新房子相關嗎?或者是時候徹底清理一下雜物了?

這種方法也可以應用于將SQL Server數據庫遷移到云平臺中。由于云計算環境的規則與內部部署環境不同，因此在順利進行遷移之前，應先對數據庫進行適當的清理工作。為此，數據庫管理員(DBA)首先必須獲得所有數據庫如何與連接的應用程序進行交互的概述。這使他們可以清除數據集中不必要的混亂數據，并在必要時修改代碼。因此在遷移之前，應先進行包含評估和審查階段的兩步過程。

評估階段：遷移的數據選擇

云遷移失敗的比較常見的原因之一是成本過高。在許多情況下，這可以歸因于以下事實：尚未充分考慮新的云計算收費模式。未使用的數據量(在內部部署運營中可忽略不計)會給云平臺中的預算帶來極大壓力，因為云計算服務的價格由CPU、存儲和IOPs決定。與其相反，提前完成全面評估有助于確保盡可能高效地使用新環境。為此，需要確定所有庫存數據記錄，并將它們依次分配到三個類別：清理、存檔、遷移。

清理

大量不再有用的垃圾數據或數據集適合在云遷移之前進行清理。這種類別的數據包括過去創建的數據，但數據質量可能很差，只是出于法律原因才需要進行存儲。如果超過法律要求的時限，則可以將其刪除。如果是個人數據，則還應根據GDPR法規和其他數據保護法規來考慮數據庫存。

存檔

在調查過程中，數據庫可能還會遇到相反的情況：某些數據集雖然過時了，但其質量適合當前和未來的趨勢分析。在此建議繼續以只讀模式使用數據。例如，如果計劃遷移到Microsoft Azure，則可以使用SQL Stretch數據庫將數據簡單地移動到成本相對較低的存儲級別。在那里，數據仍然以只讀模式可用，并且可以根據需要進行檢索，以用于商業智能操作，用于人工智能或機器學習功能的應用以及用于創建預測分析。

遷移

確定了需要清除和存檔的數據后，便自動形成了適合遷移的數據量。盡管這些數據來自內部部署生產系統，但這并不意味著可以將其直接傳輸到基于云計算的生產系統。為了防止用戶可能抱怨他們的報告自從遷移以來不再有意義，下一步是對這些數據進行徹底的質量檢查。

檢查階段：數據庫質量檢查

由于在遷移過程中不應對應用程序和數據庫進行任何更改，因此必須消除任何妨礙可靠性能的功能。必須進行額外的質量檢查，以確保應用程序和數據庫級別之間的平滑交互。因此，應該確保以下幾點：

• 諸如表格、視圖、觸發器、存儲過程和用戶​​定義的函數(UDF)之類的對象的一致命名標準。
• 如果所包含的值均不超過32個字符，則不要使用超大的列，例如CHAR(500)。
• GUID(全局唯一標識符)不用作聚集索引。這僅適用于未擴展的小型表格。還必須檢查是否將GUID用作集群主鍵，因為這會導致許多性能問題。
• 沒有定義為最大大小的數據類型，例如NVARCHAR(MAX)。
• 沒有隱式轉換，因為它們會導致嚴重的代碼問題。特別是，當使用對象關系映射(ORM)工具時，更容易發生轉換問題，因為對象關系映射(ORM)通常默認情況下使用GUID作為集群索引。

此外，應再次檢查查詢超時的編碼。如果某些查詢在內部部署環境中已經發生服務器超時，則這些超時將在云中增加。為避免這種情況，應修改代碼，以便與查詢超時相比，它在云平臺中更具彈性，并且相應地優化了關聯的查詢。

另一個必要但在某些情況下可能很痛苦的任務是對流行功能的評估和測試，例如創建臨時表。盡管通常使用這些功能來改進編碼的邏輯，但是只有少數幾個功能會對性能產生積極的影響。為了避免在云平臺中出現任何意外情況，最好安排對最常用的數據庫功能進行測試。

可靠的文檔有助于切換到云平臺

總體而言，進入云平臺只需要根據數據目錄創建全面的文檔即可。為了避免在遷移后發現應用程序和用戶已經遷移進來，必須進行下一個步驟：記錄哪些應用程序訪問目錄中記錄的數據。

對于數據庫來說，這似乎有些不愉快，就像搬家時必須處理長期遺忘的物品一樣。為了簡化文檔編制過程，需要使用適當的管理工具，這些工具可以自動創建數據源的詳細概述。通過這種方式，可以創建合適的條件以實現平穩遷移并有效使用云計算服務。