一個企業的SQL Server會因為許多因素會考量如何搬上雲端？在不同的時機點，這個議題說複雜也複雜，說單純也單純，所以本篇將因應2019年7月9日的SQL 2008(含R2)EOS的時間點來進行討論，介紹微軟的解決方案與工具軟體。
- 為何要遷移至雲端(包含大數據時代的資料發展趨勢、可能會遇到的風險…)
首先可以先從微軟的官方部落格來開始，例如影響的版本與相關的時間點
其次是雲端正在改變應用程式的設計方式。不同於(Monolithic)龐大且集中的單一體系，應用程式會分解成較小型的非集中式微服務(Microservices)。然後這些微服務會透過 API或使用非同步傳訊進行通訊。讓應用程式可以依據商務需求，以新增或減少執行個體的方式進行水平式的調整。細節可以參考微軟官網的文件說明
第三是企業可能會遇到的風險，在下圖中，由左至右，包含了資料中心(機房)的汰舊換新或搬家、因為商務需求，整合異質平台、不同的廠商的產品、監控所有的資訊系統、預警機制、通知機制…或是因應客戶端的需求增加、旺季、尖峰時間所造成的緊急性的硬體容量擴充、因應軟/硬體的升級所衍生的資料風險、因應安全上的威脅(中毒、惡意程式、零時差攻擊…)所衍生的資料風險、各種產業的合規需求(例如醫療業的HIPAA、金融業的PCI-DSS、歐盟個資法GDPR…等)、因應先進的科技在商務模式的創新或是想應用先進的科技來提升佈署的時效性、最後是各家軟體廠商(database/dev/monitoring/backup/middleware...)的EOS
第四是SQL2008(含R2)即將功成身退，任何產品的誕生都是基礎於當前的客戶需求以及當前的主流技術所發展的，就好比你幫小孩子買衣服，現在穿剛剛好但2年後穿不下是很正常。又比如說，當初2008年就沒有Hadoop，你又怎麼能期望SQL 2008會推出可以讀取Hadoop的Polybase企業版功能？
第五是人工智慧，SQL Server從SQL2000(要上Service pack)開始支援Data mining資料探斟，陸陸續續推出了近10種的演算法(關聯/群集/決策樹/線性迴歸/羅吉斯迴歸/貝氏機率分類/類神經網路/時序群集/時間序列)，縱使客戶可以交叉使用這些演算法，但是發展至SQL2008已達極至。換句話說，在有限的排列組合，或者說特定的演算法僅能配合特定類型(時間連續、線性/非線性、文字、數值…)的資料去解決特定的問題，所以難以誕生嶄新的商務應用。雖然SQL Server在後續的版本還可以允許客戶使用ISV開發的外掛程式演算法，所以其發展是有限，直至微軟買下了Revolution Analytics這家擁有R語言的公司。結合開源的力量，超過七千個Package套件，又再度燃起了這個領域的發展。
第六是雲端的科技，先講我個人對雲端的體認，再談這項科技對於企業的影響。我主張，再怎麼高效彈性的資料庫，如果沒有安全的前端，只是白白地浪費運算力，在陪駭客虛耗能源而已。眾所皆知公有雲的誕生，可以解決中小企業無法投入太多的預算在機房(尤其是在颱風地震天然災害不少的台灣要能維護7*24的伺服器運算環境)、軟體授權(在雲端的VM虛擬機器的費用也有包含Windows/SQL Server/Exchange...的軟體授權，而且是以小時計價，用多少付多少)、伺服器(運算力)叢集與HA/DR(高可用性/異地災難備援)、DNS網域名稱轉址服務、Public IP address、DDos網路安全的防護…等；以及解決大型企業單點內部私有雲擴充至跨洲際(多點)時，可以用國際海纜取代國際專線，應用近乎無限的網路頻寬在DDos或是其他資訊安全的防護，應用O365這類的Saas服務來取代買不完的垃圾郵件的box moving 的compliance，應用Application proxy service這種雲端的轉址服務來降低在網際網路上被攻擊的可能性…
第七是雲端資料庫，基礎於資料庫是一個動態環境，發生效能問題是必然的現象。就像Windows作業系統，隨著使用的時間拉長，資料碎片的問題會愈來愈嚴重，就必需進行磁碟重組或是重灌作業系統一樣。在上一點(第六點)的SQL Server on Azure指的是Iaas(Infrastrure as a service)，所以除了機房環境是微軟代管，從底層的作業系統、SQL server的安全性或新功能的 patch都要自己來。另外，一但發生效能低下、頻寬不足、備份空間不足、HADR、資安威脅、加密、資料遮罩…各方面的需求，系統管理者可能要分析問題、將標準版升級至企業版、處理因為硬體資源增加所衍生的管理(就地擴充、建好新的環境再移過去)，在Paas(Platform as a service)的Azure SQL database，只需要把拉Bar由左向右拉(當級別由Standard來到Premium就等同級升級至企業版)就能在不需重啟SQL Server的條件下動態調整資源或是賦與企業版功能，或是把Auto tuning、Dynamic masking、威脅偵測…等選項打勾
- 你有什麼選擇？
第一是資料庫的配置規劃，你可以選擇on Premises/VM on Azure/Paas DB(Single/Elastic pool/Managed Instance)，基礎於SQL 2008即將EOS，選擇第一個(地端)只有升級一條路；選擇第二個(單指搬遷至微軟的Azure)可以享受免費得到三年的Security patch，當然在這三年內還是要想辦法重新規劃(前台與後台同時改寫來符合現代化的技術架構)，第一與第二你可以參考Azure官網的比較表；選擇第三個以後，因為是Paas隨時都是最新的版本，不需再升級了
第二，若你需要更簡單的懶人包，這邊提供二個簡易選項：
選項一
選項二
第三，某些企業還是選擇留在地端，並且打算以老舊的技術挑戰駭客，請注意，連台灣的高科技龍頭都曾經在2018發生了WannaCrypt事件，損失十幾億。給我的啟示是，不管是小矮人還是大巨人，只要身體上有任何一點的傷口，都有可以帶來生命危險的威脅。端看企業的反應速度與回應的態度，你可以消極地等到生病再找醫生，但是你至少應該要買 Extended Security Update 這個微軟不主推的SKU，當成預防針來強化你先天虛弱的身體
第四，Paas SQL database，由於這不是本篇的重點，建議你可以延伸閱讀Azure官網去了解一下，將來我會再找時間來寫
第五，綜合以上，你的選擇地圖應該會是~~
- 應對的工具與其技術
首先是談到適合的方法論來做為專案的 framework框架，大致上步驟為選定目標(上雲或是在端地做版本升級)、評估差異(舊版本與新環境的差異)、移轉(可停機或不可停機的移轉)、優化(適度的架構調整與相關的參數調整)
第一步選定目標，微軟提供了MAP(Microsoft Assessment Planning Toolkit)來協助企業做軟硬體資源的盤點。除此之外，就要看企業的短中長期的資訊策略發展方向。
MAP經過多年的發展已經很成熟，它應用了WMI(DCOM/RPC)、VMWare webservice，可以在不種Agent 的情況下透過AD/ IP range/Hostname…等設定去掃描企業內的軟硬體資源
可以分門別類的進行掃描，也包含雲端的資源喔！
除了傳統的Excel，透過PowerBI高度視覺化的工具，它可以接受MAP匯出的Excel或是直接介接MAP的資料庫(安裝時自帶的SQL express)，來分析企業內的軟硬體資產
第二步評估差異，微軟提供了DMA(Data Migration Assistant)來協助企業進行二個資料庫從地到雲(呵…萬一你要問從雲到地，這是微軟不希望的，所以沒有提供)的差異評估，以及停機的移轉Schema與Data(底層可能是以bcp指令bulk copy的方式，效能普通，若資料庫建議只移轉Schema就好，不然會等很久)。以地端來看能支援SQL2005~SQL2017，以雲端來看從SQL VM on Azure、Azure SQL Database(Single單一資料庫)、Azure managed instance。細節請參考官網的說明，若你想要用PowerBI來呈現評估的結果，也可以參考官網的說明
第三步移轉，微軟提供了SSMA(SQL Server Migration Assistant)在異質資料庫的移轉，包含了Access/DB2/SAP(前Sybase)ASE/Oracle，細節可以參考官網。以及剛才介紹的DMA(Data Migration Assistant)與DMS(Azure Data Migration Service)。前者僅適合停機的移轉，後者是應用不同的技術在進行停機/不停機的移轉。至於費用，只要是停機的移轉微軟是不收費的，若是有重要的資料庫，可以選擇付費的DMS來處理。比較特別的是，DMS只負責移轉，並不負責評估差異，所以在官網中，它會建議客戶先用DMA選好目標，再開始移轉。
若我們選擇停機，跟DMA很像可能也是用bcp指令，而且設定完只能執行一次，若後續還有異動資料要追加至目標資料庫是沒有支援的，建議選擇付費的不停機移轉
若我們選擇不停機，將會採用交易式複寫(Transactional replication)機制，來進行資料的移轉。不需驚訝，我記得好像SQL Server 2012開始就可以進行單向的交易式複寫(雲端的Azure SQL database僅能是訂閱者不能擔任發行者)，若要做到雙向的交易式複寫，需要使用2018/10剛GA的Azure Managed Instance
第四步優化，雖然微軟有提供DEA(Database Experimentation Assistant)這個AB test的工具，它能收集效能數據，在二個資料庫(通常是不同版本比較多)進行PK比賽，但我個人覺得，這一段需要較多DBA經驗，比較可行。
大方向談完了，若有興趣，可以再參考以下的分項工具的介紹文章：
- 使用DMA分析與移轉至雲端 或是官網文章
- 使用SSMS移轉至雲端
- 使用DMS移轉至雲端
李秉錡 Christian Lee
Once worked at Microsoft Taiwan
