brent ozar的sqlserver dba訓練課程翻譯——第二章：手動恢複資料庫

標籤：style   http   使用   io   strong   檔案   資料   for   

備份的唯一原因備份的唯一原因是我們可以還原 當我第一次成為sqlserver資料庫管理員，只要備份工作都能成功運行，我就會覺得一切都很好。我會查看sqlserver代理，保證那些作業都在運行，然後就這樣了。我想只要發生災難了，我只需要做一個恢複。這能有多難？ 理論上，我們使用凱德拉的5個簡單問題來測試我們的備份策略，並且我們要記住會導致dba被解僱的9個注意事項。 在實踐中，有一些小問題會困擾我們。當出現問題的時候，我們是否要還原整個資料庫——即只恢複幾個表還是一個完整的資料庫。有些人把生產環境的資料庫當做開發環境從而不小心刪除了資料庫，接下來的事情當然是大家都瘋掉了。提前思考我們的備份計劃可以使危機處理地更加容易。   在那裡做恢複?當你恢複代碼（預存程序、視圖、觸發器等）或者表時，不要恢複到生產伺服器上。 我並不喜歡去動生產資料庫，當我們面對這些事故時——你就已經有了糟糕的一天。這就是你為什麼做還原，還記得嗎？讓我們在不同的環境（開發或者測試）做不同的事情，遠離生產環境。我也會寫如何在開發、測試和生產環境中還原。 當我們安全的恢複一個資料庫後，可以很容易的把資料複製到其他的伺服器上面。你可以在生產環境上通過串連伺服器安全而簡單的訪問唯讀恢複伺服器上的資料庫。並且，從生產資料庫可以通過串連伺服器把資料導到恢複資料庫上。 然後，如果要恢複的資料超過10G，那麼你可能必須在生產資料庫上恢複以加快速度。我們必須非常小心，並且確保你的指令碼和資料庫名稱正確——我們不想覆蓋正在工作中的資料庫。這可能需要生產伺服器增加額外的空間，在一個緊急情況下，我不得不把tempdb和log檔案縮小到1M來釋放可用空間。tempdb在一個非常快的磁碟上，並且恢複過程中沒出現例如斷電等其它問題，因此這次恢複完美的完成了。我們並不會總是這麼好運，但這有利於我們想出更多這樣的情形。 一個警告：如果存在依賴性關係，比如一個表和其他表存在依賴關係，而你恢複了這個表，而沒有恢複這個表依賴的那個表，那麼這會造成傷害。我們不能說到所有的情境——真的，每種情況都是不同的。  執行恢複 使用no recovery選項來恢複最近一次完整備份——這是非常重要的。這使得資料庫處於恢複狀態，並且可以恢複其他的備份。如果你忘記了這兩點，那麼可能你就需要再一次的從頭恢複了，所以在你恢複之前，請務必仔細檢查。 如果我恢複的代碼或者配置表在上一次完成備份後並沒有更改，那麼我不會還原之後的差異備份和交易記錄備份，我們的目標是儘可能快的完成還原。 接下來，在還原差異備份後還原交易記錄備份（如果你在上一次完整備份後沒有差異備份），同樣，不要忘了no recovery。 用圖形介面執行這一切實在是糟透了。備份越多，你還原的時間就越長，並且更加容易出錯。相反，你需要指令碼來管理備份檔案夾，找到對應的檔案並進行自動回複。在接下來的培訓裡我們會討論自動還原模組。 學習備份與還原知識，我們推薦下列這些文章： 

• Grant Fritchey‘s SQL Server Backup and Restore for the Accidental DBA
• Brent‘s DBA Nightmare: SQL Down, No Plans
• Jes‘s 3 Things You Need to Start Doing to Your Database Server

感謝！我們下周再見！?