我們一般做 SQL Server 維護都會設定一套維護計畫，並且使用 Management Studio 工具幫我們建立，且建立完成後會在 SQL Server Agent 建立起對應的作業與排程，前陣子我公司負責管理資料庫的同仁因為設定 SQL 記錄傳送 (Log Shipping) 的關係將原本維護計畫中的交易記錄備份停用，但是他並不是在維護計畫中設定停用，而是直接到 SQL Server Agent 的作業中停用，導致今天發生的一場資料庫災難。
這個故事是這樣的：
- 原本維護計畫設定的交易記錄備份都是正常運作的
- 設定了 SQL 記錄傳送 (Log Shipping) 之後，就改由 SQL 記錄傳送 來負責做交易記錄備份
- 前陣子因為 SQL 記錄傳送 (Log Shipping) 次要伺服器的主機硬碟空間不夠，所以停用了
- 當時就再次重新啟用 維護計畫 設定的 交易記錄備份
- 因為從那時開始交易記錄備份都沒有正常執行，導致今天交易記錄檔把我正式機的硬碟塞爆了！
這段過程我都沒有經手，資料庫的維護計畫的執行作業也都沒有報錯，所以也覺得不疑有誤，但詭異的地方就是為什麼維護計畫的交易記錄備份作業不再備份了呢？
底下是一個維護計畫與 SQL Server Agent 作業的畫面，這會讓你感覺好像每一個在維護計畫建立的子計畫都建立一個SQL Server Agent 作業，另外一個重點是如下圖的紅線，代表如果交易記錄備份失敗會自動發信通知操作員：
首先，所有我們在維護計畫所定義的作業內容，並不是一個單純的 T-SQL 執行或是許多步驟結合在一起的複雜作業，而是 SSIS 的封裝，如下圖是其中一個作業的屬性，點擊「步驟」頁面可以看到每個透過維護計畫建立的作業都只會有一個步驟，且類型皆為 SQL Server Integration Services 封裝 ( SSIS Package )：
接下來，我就要說明這次災難發生的原因了。
經過調查之後發現，之前同事因為設定 SQL 記錄傳送 (Log Shipping) 的關係，直接到 SQL Server Agent 直接將作業設為「停用」，這樣做基本上是沒錯，作業真的會停用，交易記錄備份也不會再繼續運作，而之後就由 SQL 記錄傳送 來做交易記錄備份的工作：
但前陣子 SQL記錄傳送 因故停用了，所以必須復原原本維護計畫中的交易記錄備份作業，但這段時間該同事離職了，也沒交代到一些細節，所以我也就依照他的方式重新再將作業啟用，但你知道為何作業就算啟用了為何還不會執行呢？原因就在於，前同事除了將作業停用外，還額外停用了該作業的排程，這是我萬萬沒想到的事，而且從上圖的外觀上並不會直覺的想到「排程」被關閉這件事：
所以這次學到的教訓就是『千萬不要手動修改透過維護計畫設定的 SQL Server Agent 作業，請一律使用維護計畫中的 SSIS 設計工具來停用特定工作』。
鄉親阿~~ (台語口音)，老話一句 魔鬼總在細節裡 不是說假的，在我的部落格裡搜尋「魔鬼」已經可以搜出不少篇了，可見我經常在跟魔鬼打交道，呵呵～ XD
心得分享
今天也跟 SQL 界的資深前輩聊了一下，我問他：「請問你深厚的 SQL 功力都是從這些日常的災難中鍛鍊出來的嗎？」，他沒說些什麼，就點了點頭然後笑了一下。如果去外面上課，這些日常的災難通常老師不會教太深入，學生也不會練習的很透徹，唯有真的上戰場遇到的狀況才能深刻體會，這時這些災難復原的經驗才是你的，不容易阿～～～～
人家常說，夜路走多了總會遇到鬼，我怎麼覺得跟鬼打交道多了總是不怕鬼，這代表著些什麼呢？從事技術行業，還是要培養追根究底的精神，不管你學歷多低或多高，這是一種習慣，養成習慣就好，遇到問題無論如何要找到發生問題的主因，並且釐清問題背後的問題，這樣才有可能不斷進步，下次再遇到同一個類型的鬼，就再也不怕了。