故事要從4月底說起! 難得有機會和北虎(前Microsoft MVP: Enterprise Security) 林柏甫 TigerLin 一起做專案，而這個專案目標是要建置一組SQL Server Cluster，而客戶端的硬體設備是相當的高階，不管是Server或是Storage都是一等一的，而在建置的過程中，包含應該優化的磁碟對映，無論是系統資料庫或是索引也都做了最佳的選擇，而客戶端也有數名ASP.NET MVP加持…
故事要從4月底說起! 難得有機會和北虎(前Microsoft MVP: Enterprise Security) 林柏甫 TigerLin 一起做專案，而這個專案目標是要建置一組SQL Server Cluster，而客戶端的硬體設備是相當的高階，不管是Server或是Storage都是一等一的，而在建置的過程中，包含應該優化的磁碟對映，無論是系統資料庫或是索引也都做了最佳的選擇，而客戶端也有數名ASP.NET MVP加持，在建置過程也非常的順利，在我建置完成後，完成了系統的壓力測試後，而客戶完成基本的測試後，也開始移動服務到這組新的設備上。
往往悲劇就這麼發生了! 經過兩周後，客戶反應，怎麼硬體設備升級了，程式沒有任何改變，資料庫的結構一模一樣，怎麼會效益不升反降呢?! 當然，這個過程中也調整了SQL各種不改Code為前提的調校，能改進的都做的差不多了，而各位MVP們也都紛紛的投入到這個專案開始發功，在經過連續一周賣肝油的半夜工作，能調整的都調整完了，但是無論做任何動作都回復到和舊設備持平的狀態，但是客戶的CIO也必須站在商務考量上，提出了一個必然的問題，投入了這麼多的錢提升設備，效益只能持平，那麼花這麼多錢買這組設備，是不是符合效益呢?
當然，站在專案執行的角度上，若效益不能提升到原本承諾的水準，那麼這個專案還是失敗，雖然說Jason的專案目標是完成SQL Server Cluster的建置，在我的專案目標來說我已經達成了，但是，如果因為整個專案驗收不過，造成退貨，我還是收不到錢，在小孩還這麼小，公司又剛起步，投入一些經驗和兄弟們一起射茶包，當作自我能力的提升，沒問題的!!
而客戶的最大載量是產生在晚上7:00~10:00，光是客服人員按下個查詢資料，就等個三四分鐘，這個在客服人員應對客戶時，很容易打槍的! 後來在Tiger的協助之下，把SQL查詢資料最久的查詢式分段檢查，找到了一問題，把這個欄位加上索引後，得到了相當的改善!
但是!根本問題還是沒有解決!程式已經修改了，但只是到持平，還是沒有得到效益呀，而且唯一得到資訊就是在資料庫的資源監視下，在SQL 活動監視器中Latch和Buffer Latch分別佔了一二名，但是，奇怪的就是，明明什麼設備都是這麼優的狀況下，Server是上有四顆8核的CPU，插了128G的RAM，資料庫所在的磁碟陣列是用4G Fiber Channel連結，最差的磁碟群組是用8顆300G 15k PRM所組成的RAID10，怎麼可能怎麼調整都是這樣呢! 可是，在磁碟的壓力測試和磁碟櫃上跑出來的數據都是美到不像話!
在Tiger協助處理監看效能，我則是進行效能記錄的分析，發現即使沒有什麼人，在磁碟的Disk Queue Length 還是持續在100以上，代表磁碟真的是一個關鍵因素了，但是磁碟陣列的廠商表示沒有問題。
在這個時侯突然靈光一閃的，天邊飛來一筆，資料庫也是在Windows 之上，也是運作在檔案為基礎的架構之上，並不是獨立運作的服務，而這個狀況在和Tiger還有朱神的討論之下，問題直指I/O效能，但是我們的方向都錯了，都忘了一個問題沒有被處理『I/O的優先權』，預設的環境之下，僅有Administrators有權。
這個時侯，我把問題拉到最底層，I/O的優先權設定是在『執行磁碟區維護工作』中指定，這個權限指派的說明如下：”此安全性設定決定哪些使用者及群組能在磁碟區上執行維護工作，例如遠端磁碟重組。指派此使用者權限時要特別小心。具有此使用者權限的使用者可以瀏覽磁碟和將檔案延伸到包含其他資料的記憶體中。當延伸檔案開啟時，使用者能夠讀取和修改取得的資料。”
本項在本機安全性原則的使用者權利指派。
上面的說明已經點出了問題，我們在SQL Server Cluster的服務啟動是指派網域使用者來啟動，所以在要求磁碟I/O的優先權等於是放在Administrators後面了，但是服務已經啟動了，又要不中斷怎麼辦呢?
請大家跟著下面的步驟做一次：
一、將服務移轉到Node2。
二、在Node1上將本機安全性原則->使用者權利指派->執行磁碟區維護工作(perform volume maintenance tasks)將啟動SQL Server的網域使用者加入。
三、重開Node1，並在啟動好了之後，將服務轉移回Node1。
四、一樣的在Node2上將網域使用者加入執行磁碟區維護工作。
五、再把Node2重新啟動。
接下來，只要服務失效移轉時，服務切到Node2就不因為沒有指派而造成效能又掉下深淵中。
總結
這個問題其實在早期Windows XP時代就存在著，當初只是要讓使用者可以重組磁碟，而Server則是在資料庫建立或更改時有權限，而且這個設定也有應用在檔案伺服器上面，而因為我們將WindowsUser也加入這個指派中，但是在這個Case中所有的帳戶和環境都是由客戶端準備，因此我們在環境的掌握度上確實不是100%，而以安全的角度來看這個狀況，也是對的，因為服務可以正常的啟動，容錯移轉也是正常運作，當然不會考量到問題會出在磁碟IO的優先權，這個問題一口氣打死了好幾位MVP，雖說術業有專攻，像Jason、Tiger這些純種IT人，不寫Code為最大原則的改善服務效能才是我們的價值，也因為這樣，才讓我們想到有這個千年沒出現過的問題，也因為所有的設備都是相當的高級，照理來說，應該是效能要大增啊!結果CPU快、Storage效能高、RAM大! 竟然會跑輸舊機器，被Tiger笑稱是公主病，原來這個公主病是因為效能太好，所以才凸顯了這個問題，而在調整之前，Disk Queue Length高達600以上，將權利指派完成之後…馬上降到60以下，效能大幅度的增加了十倍! 比起開Trubo還快!以上經驗分享，和大家一起共享這個關鍵黃金點。
Anything keeps Availability.
Anywhere keeps Integrity.
Anytime keeps Confidentiality.
keep A.I.C. = Information Security