作者：傅潔瑩 / 臺灣大學計算機及資訊網路中心程式設計組 / 幹事
網路上有許多資源解說SQL Server Always on 如何設定及使用，但鮮少分析Always on的特性及優缺點。今年適逢SQL Server 2008支援到期，必須升級資料庫伺服器，把這段時間跟同仁合作的過程摘要記錄下來，也供日後想選擇此解決方案的使用者一點參考。
先來看升級這件事
在談Alwawys on機制之前，先來說一下資料庫升級。早先SQL server2017發布之前，一直以為SQL Server按照慣例只能支援上下2個版本，因此同仁就非常認真積極尋求各種資料庫轉移方法，大家非常辛苦的多次進行轉移、測試、檢查各種資料一致性…等。
最後某次不經意在網路「巡田水」查資料發現，SQL Server 2008的資料可以「直升」到SQL Server 2017!經我們多次實驗，在此告訴大家結論：
1.SQL Server 2008的mdf檔、備份檔，都可以直接升到SQL Server 2017。
2.將SQL Server 2017的相容性調至2008即可。
3.上述升級不是用master資料庫。
Master資料還是需要辛苦轉移，還有必須另外把使用者帳號與uid完整複製到新資 料庫伺服器。
關於對Always on的心得
接下來就進入主題了，我用結論來說明比較快。如果你的資料庫具有下列特性，可以將Always on納入候選名單：
1. 資料庫伺服器的使用者不會經常異動：
a. Always on不會同步Master DB，如果在系統有異動，全部必須人工進行資料同步。
b.如果你的資料庫伺服器隔一段時間就會有其他單位來申請權限讀取，只要帳號有刪減，都要人工同步。
2. 不會有自動產生資料庫的系統：
因為Master DB不會同步，所以如果有系統會自動長出資料庫的，都不適合(例如：表單系統，流程引擎…具有較複雜功能的模組)，記得要確認。
3. 沒有大量資料的異動程序：
Always on 靠log來同步資料，每個行為都會產生log。所以如果你有那種，定期刪掉原有資料，再去 同步其他資料庫資料的預存程序，每執行一次就會產生相當可觀的log紀錄檔，硬碟使用量會超乎想像。
4. 有餘裕的儲存空間：
承3，Always產生log速度非常驚人，壓縮手續繁複耗時，較適合有大容量儲存空間的伺服器使用。
如果你的資料伺服器不具上述狀況，請多慎重考慮，再決定是否採用Always on機制。
小結
其實Always on同步完整度與即時性令人欣賞，但這陣子試用下來，發現要進行log檔的壓縮，調整log的大小限制…等工作時，都必須將資料庫移出Always on可用性群組，進行完所有設定(或備份)才能再將資料庫加回。
移出期間若有資料寫入就無法同步，需負擔一定程度的風險，或是有較短周期的檢修機制搭配才較適合(例如：每天固定可以有一到兩小時停止服務，此時就可以進行上述調整)。
另外Always on權限控管，微軟建議綁在AD上，因此若像我們不是以AD帳號在管理資料庫的DBA，就無法直接進行相關管理工作，需要另外給予AD帳號，以往的管理方式都需配合調整。
以上簡單整理使用的心得，希望大家都能尋得最適合自己的解決方案。