SQL Server 維護計畫與 SQL Server Agent 作業之間的關係

  分享到噗浪!

我們一般做 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 功力都是從這些日常的災難中鍛鍊出來的嗎?」,他沒說些什麼,就點了點頭然後笑了一下。如果去外面上課,這些日常的災難通常老師不會教太深入,學生也不會練習的很透徹,唯有真的上戰場遇到的狀況才能深刻體會,這時這些災難復原的經驗才是你的,不容易阿~~~~

人家常說,夜路走多了總會遇到鬼,我怎麼覺得跟鬼打交道多了總是不怕鬼,這代表著些什麼呢?從事技術行業,還是要培養追根究底的精神,不管你學歷多低或多高,這是一種習慣,養成習慣就好,遇到問題無論如何要找到發生問題的主因,並且釐清問題背後的問題,這樣才有可能不斷進步,下次再遇到同一個類型的鬼,就再也不怕了。


此文章由 will 發表於 2010/5/26 下午 10:42:00

永久連結 | 評論 (1) | 此文章的RSSRSS comment feed |

分類: SQL Server | 心得分享

標籤: , , , ,

評論

五月 27. 2010 16:39

chuck

這些都是很好的經驗,要好好記住,不過大公司的DBA都是專職DBA,像我自己,又要寫程式,又當DBA,還得管firewall,大概也沒辦法花那麼多時間來研究,唉~
只能從保哥這裏來吸取別人的經驗了

chuck Taiwan

新增評論


( 您輸入的Email不會顯示於網站上 )

  Country flag

biuquote
  • 評論
  • 線上預覽
Loading