資料庫守護精靈DBAssistant
「小陳啊，快來幫我看一下。怎麼ERP這個開窗快5分鐘了還沒有反應。我有一堆單子等著要印，貨車司機等著要出貨。到底可不可以快一點啊！」業務部的小玲在電話那一頭喊著。

小陳是桃園某電子零件廠的MIS，公司導入ERP系統已經六年的時間。拼過了當初ERP上線時的黑暗期，想說可以安穩地維護著ERP，再利用空檔try try新技術。結果想不到現在是這樣子的光景。一到月底結帳的這個禮拜，整個資訊室像是在打仗一般，電話聲此起彼落，小陳就這樣在機房與各辦公室間忙進忙出，不斷地忍受著來自同事與主管的壓力。而這樣的狀況已經持續了快半年，讓小陳的身心都受到很大的影響。

不過小陳也不是輕易被擊倒！看過了一些效能調教相關的網頁跟書籍。小陳嘗試著做了一些效能的調教。有些使用者開窗慢的問題真的得到了改善。但是好景不長！經過了一些時日，小陳發現ERP的批次作業的處理時間越來越久，而且資料庫備份檔空間大幅度的成長。後來這個問題經過了鼎新的協助檢查，發現原來是小陳建了很多使用機率不是很高的索引，而且索引欄位數也太多。這樣的狀況讓批次作業更新資料表的效率受到了影響。大家想想，小陳的下一步該做甚麼呢？

資料庫調校的重要性
SQL Server這個產品線在微軟與Sybase停止合作關係後，微軟自行開發的SQL Server 6.0版，到現在的SQL Server 2008 R2，已經超過15年的時間。經過了不斷的改版與功能增強後，現在已經是足以與資料庫大廠Oracle抗衡的企業級產品。尤其SQL Server 2005的發行，大幅度的拉高產品的高度與深度。資料庫鏡像、資料庫快照、線上索引維護、資料表與索引分割等的功能，讓SQL Server可以支撐企業面對各種資訊化的各種挑戰。

在同樣的功能之下，Oracle的售價可能是SQL Server的10倍甚至更多。因此平易近人的價格與容易駕馭的設定介面，讓SQL Server快速席捲整個中小型企業甚至中大型資料庫市場。這一點，從書局架上，類似快快樂樂學SQL等書名就可以略知一二。加上微軟全中文化的SQL線上叢書與使用介面，(註：SQL Server的使用手冊)讓大部分的資訊人員都可以快速入門上手。

不過也因為上述的原因，讓SQL Server的異常維護或效能調教，變得看起來似乎並不是那麼有價值。如果沒有瞭解真正價值所在，甚至可能會認為一套二萬多的產品，誰願意花超過本身價值的費用去維護、調教它呢？

但是，試想一下。SQL Server所存放的資料為何？SQL Server所提供的服務為何？如果有一天企業的SQL Server突然停擺甚至是資料遺失了。有多少人會因此而失業？多少企業會因為系統停擺而無法繼續營運？有多少的人力是浪費在資料庫效能不佳所產生的無謂等待？又或有多少資源浪費在應該可以自動化完成的工作上？

事前處理的重要
過去經手幾個資料庫救援的經驗，資料庫發生有疑問(suspect)或是某些資料無法讀取的狀況。在剛接案時，問題描述都不是資料庫有問題。好一點的是反應ERP系統某些作業不能正常執行。狀況嚴重的是反應ERP系統不能登入，系統已經停擺了。而最後確認造成系統停擺的問題點經常是資料表或資料庫已經毀損。毀損的原因通常是硬碟子系統出現問題，例如壞軌、分割區異常、硬碟控制卡異常等所造成。

而另一個令人稱奇的現象，這樣的企業，通常備份排程可能早在一個月前就已經停擺，或是資料庫備份檔也是壞的，根本無法還原出資料。而到了這樣的地步，可能只能救援出部分的資料，不太可能還原完整的資料。只有非常非常少數的企業可以全身而退。大部分這樣狀況的企業，可能要找一批的工讀生來補打資料了。

當然，我們也不用太悲觀，在歷史上最令人震撼的恐怖分子事件－911恐怖攻擊，位於紐約的雙子星大樓兩棟大樓全毀，位於大樓內的德意志銀行在紐約的業務也跟著垮台。但是位於愛爾蘭的備援系統，卻讓德意志銀行可以當天就繼續處理超過3000億美金的交易。所以只要有完整的備援計畫，任何狀況都是可以因應的。

另外一個特殊的案例是，某企業的ERP系統到了某些時段效能會非常非常的差，甚至狀況嚴重到連管理工具都沒辦法進行資料庫管理，此時CPU與磁碟I/O的耗用狀況都非常的低，但是系統就是幾乎無法使用。經過查看後，才發現原來資訊室人員不小心把資料庫主機的TCP 1433埠(註：SQL Server服務的端口)開放網際網路外部IP可以存取，造成外部未知的來源，透過駭客程式以暴力的方式嘗試破解密碼，因此TCP 可以用連線數已經被用完了，主機完全無法接受新的連線。

以上這些問題，可能書上會跟您說一些大方向，您應該要每天備份；您應該設定一些警示預防錯誤的發生；您應該善用索引來提升效率；您應該透過分散磁碟I/O來減緩資源競爭的狀況。但是當您真正要制定或執行公司的災難復原演練計畫或是效能遇到瓶頸時，完全派上用場的機會可能不多。因為面對真實的環境時，任何一個不當的設定或調整都可能變成災難。所以最後的狀況可能都是推給應用程式寫得不好、系統上線人數太多、資料庫太大機器又太老舊、系統架構太複雜很難維護等等因素。其實這些問題都可以透過效能資訊的收集與分析後，給予最佳的解決方案！

五項例行工作大簡化
預防勝於治療！我想這個除了適用身體的保健外，也非常適合資料庫的維護工作。資料庫使用的時間一久，除了資料本身的大幅成長外，資料的離散與缺乏維護的索引、前端不當資料的查詢方式、缺乏索引的查詢工作等等，都會讓資料庫效率每況愈下。所以一定需要專業的DBA資料庫管理師來進行維護。不過並不是所有企業都會配置這樣的角色！一方面是資料庫管理師的進入門檻不低，另一方面並不是所有企業的資訊化規模都可以滿足該職務的工作量。雖然SQL Server也提供了一些效能工具，您可能也會拿來試看看！但是面對SQL Profiler(註：SQL Server提供的效能工具)每秒收集到超過2,000個SQL指令，沒有扎實的資料庫底子加上豐富的經驗，事實上要能分析出效能的瓶頸點在哪裡，難度是很高的。

所以，為了解決廣大企業資料庫上的營運問題，我們透過以往管理與服務的經驗，把經常需要人工的收集分析工作，透過自動化的工具來協助我們完成。資料庫守護精靈DBAssistant這個工具就因應而生了！DBAssistant這個工具名稱是DBA加上Assistant，字義就是資料庫的助手。透過這個助手，我們可以簡化下列的工作：

1. 磁碟系統狀態的監控。
2. 資料庫重大錯誤訊息的監控。
3. 資料庫異常登入的監控。
4. 資料庫稽核。
5. 效能資訊的收集與分析。

前三項工作，透過作業系統的排程定期收集系統的事件日誌。當發現有警告或錯誤則立刻透過EMAIL通知管理人員，並且可以選項設定同步通知鼎新窗口。



▲ 圖 透過主動通知的報表，讓管理人員快速掌握資料庫主機的運作狀況。


第四項資料庫稽核的部分，可以透過自定義稽核特定的事件。例如資料表結構的建立、改變、卸除；SQL使用者帳號的建立與刪除；用戶端登入失敗事件。使用者密碼變更事件。透過稽核的功能，可以清楚的追蹤何人何時對資料庫做了何事。(筆者註：這裡指的是針對資料庫物件稽核，不是資料本身的稽核喔！)


▲ 圖 收集到的稽核事件，工具本身也提供了查詢的功能，可以快速過濾大量的稽核事件，追蹤事件發生的始末。


第五項效能資訊的收集與分析，工具提供了硬體效能資訊收集(CPU、硬碟、記憶體)、SQL效能指標收集、耗時SQL指令與分析工具等三項。透過作業系統內建的Performance Log and Alert服務，將收集的效能資訊儲存於資料庫中。再透過工具將效能資訊以線圖的方式呈現。當然您可以依照選定的日期區間、取樣的單位與平均值，將效能的瓶頸點呈現出來，並且透過圖表下方的計數器中文說明，可以簡易判斷該項目是否有瓶頸。


▲ 圖 透過圖表下方的計數器中文說明，可以簡易判斷該項目是否有瓶頸。


耗時SQL指令的部分，區分為「CPU」與「磁碟讀取超過指標」二個面向，工具會將這二類的SQL指令執行的時間點、資源耗用的狀況等資訊記錄下來。透過效能圖表的瓶頸時間點搭配查詢，可以快速得知哪些SQL指令佔用的大部分的資源。例如我們從效能的線圖發現某個時點磁碟讀取量特別高，再參照這個時點有哪些SQL指令被執行過。（如下圖所示）


▲ 圖 8/29 上午1點30有一個SQL指令被執行了2689秒，耗用了大量的磁碟讀取。


另外工具也提供了SQL指令彙總分析的功能，分析工具將SQL指令先進行一般化。例如：
第一個指令：
SELECT TA001 FROM ACRTA WHERE TA001='A01' AND TA002='990101001'。
第二個指令：
SELECT TA001 FROM ACRTA WHERE TA001='C01' AND TA002='970101001'。
兩者以字串內容來看，是二個不同的文字字串。但是其實只有值的部分有所不同。因此工具將'A01'、'990101001'、'C01'、'970101001'都置換為{S}，則指令轉換成：
SELECT TA001 FROM ACRTA WHERE TA001={S} AND TA002={S}。
那我們就可以統計相同的指令執行的次數與耗用的資源，進而針對這些SQL指令進行效能的調教。


當然有了工具可以快速且有效的收集與分析效能瓶頸，不過要判斷出合理的快與慢，還是需要一些相關經驗與專業的判斷來併行輔助。隨著處理經驗的逐步累積，再針對不同的使用者習慣來進行優化。例如使用者可能用單據日期加上結案碼來查詢資料，而這個方式預設系統是可能沒有適當的索引可以加速查詢。所以我們要依照使用的量，來決定是否建立這個索引。當然也可能因為使用者不當的查詢方式造成系統的過度負載，例如使用%條件值%，肯定是會造成全資料表掃描的行為，因此透過工具發掘這種狀況並教育使用者正確適當的查詢方法。

規劃與演練
資訊化越深入的企業，仰賴資料庫服務越密切。透過資訊化也讓營運的決策可以快而有效！但是隨手可得的資訊必須是建立在一個可靠且穩定的資料庫系統之上。因此，如果資訊化只專注在流程面與系統功能的強化，而忽略同樣重要的基礎建設。當面對龐大的歷史資料與災難復原時，將很難可以全身而退。因此我們應該在現在就開始進行了解企業內部資料庫主機的運作狀況，資料庫備份還原計畫、主機災難復原計畫、索引維護計畫，甚至是整個資訊系統的備援計畫！如果沒有的做過，我們應該立即開始著手規劃。已經做過的，是否安排個時間進行演練？驗證計劃是否可行！最後，相信在有了萬全的準備之下，我們就可以胸有成足面對資訊化一切的挑戰！



-----作者簡介-----
洪智遠現服務於鼎新科技規劃部