DBA五大浪費時間的工作

恢復完整備份到日誌傳送目標

這件事希望你不是每天都在做。日誌傳送被某個沒有完全理解事務日誌怎樣工作的人設定的第一徵兆就是，日誌傳送配置被設定為每日或者每週恢復完整備份到日誌傳送目標伺服器。

當你備份事務日誌時，自上次日誌備份以來的所有資料庫操作都包括在內了。這包括了新增欄位和表，索引重建等待。通過恢復完整備份來更新在此期間缺少的操作，相當於你只是簡單地把目標資料庫刪掉，然後把它恢復到相同的狀態，然後向前應用在全備份恢復時備份的所有日誌。

所做的這些都增加了日誌備份遺失的概率。

2、刪減事務日誌

我在聯機環境中見過的最普遍的設定之一就是下面的資料庫維護計畫表：

日誌備份

索引重建

全備份刪減日誌

每三十分鐘做日誌備份

在這裡實際完成的是索引重建，而且執行了全備份。到目前為止，一切還算正常，不是嗎?實際上，日誌被刪減會打斷日誌鏈，這會使所有日誌備份變得無用，直到下次執行全備份。

這是因為日誌序列號（log sequence number，簡稱lsn）鏈被刪減日誌操作中斷了。

無論什麼時候事務出現時，事務日誌中就會寫進去乙個日誌序列號。在執行備份時，第乙個日誌序列號和最後乙個日誌序列號都包含在備份中，被寫到了日誌備份的頭位置。在日誌被恢復時，日誌備份中的日誌序列號必須是連續的。

如果他們不連續，那麼sql server就認為日誌記錄丟失了，日誌備份不能恢復了。

在這種情況下，全備份可以恢復到資料庫。不幸的是，所做的日誌備份沒用了。，因為刪減日誌命令改變了日誌的序列號。

我所見到的另一種十分常見的場景是刪減日誌，然後執行全備份。這中做法會好一點，但是也強不到**去。如果全備份被破壞的話，任何在刪減（truncate）語句和下一次全備份之間的事務都不能被恢復。

這是為什麼呢?因為既然刪減日誌步驟會重置日誌序列號，你就不能從兩天前恢復全備份，然後向前滾動所有事務日誌。是的，把日誌轉換為簡單恢復模式做的實際也是一樣的事。

如果你打算刪減你的事務日誌，以便你可以進行收縮，那麼請將螢幕向上滾動，把上面的內容再讀一遍。

現在，如果你不需要完整的事務日誌記錄，而是讓資料庫完全恢復，那麼你應該把資料庫改為簡單恢復模式。這種方式的事務日誌不會增長，因為日誌條目將被覆蓋，而不是儲存到下一次日誌備份。

dba以常規方式執行的一些任務，不僅對sql server資料庫幾乎沒有益處，而且實際上可能對他們的生產環境造成不利影響。在本文中，我會闡述幾類這樣的工作。如果你正在執行其中的一些工作，我希望你能盡快停下來。

1、收縮資料庫

每天執行收縮（shrink）資料庫是一種不好的做法，有如下幾個原因。從技術角度考慮，你看到的最大影響會是，每次資料庫收縮之後會產生大量的索引碎片。另外，收縮資料庫檔案既增加了磁碟子系統的物理檔案碎片，也增加了伺服器的i/o負載，在執行收縮操作期間，會降低其他功能的效能。

現在，收縮資料庫並不是一定會引起碎片。但是，因為檔案本身是持續增長的，而你又一直在對它進行收縮，那麼隨著資料庫自身的增長，資料庫碎片將會變得越來越多。

如果你收縮日誌檔案，也有必然會再增長的壞影響，所有資料庫操作在事務日誌增長時都會處於暫停狀態。在非常繁忙的系統中，這會花上一兩秒的時間，會引起所有型別的鎖定和阻塞，因為程序在等待事務日誌增長。

另乙個缺點是當資料庫維護開始再次執行時，檔案需要增長，這會占用cpu和磁碟資源才能完成。那麼，這就會使得資料庫維護時間花的更長，在sql server 2000和更早的版本中，或者在沒有啟用即時檔案初始化設定的sql server 2005系統中尤其如此。

從管理的角度來看，這可能會給你造成一種安全錯覺，因為你不知道你的資料庫實際上需要多少占用空間。換句話說，如果每次你執行資料庫維護程序時，你的資料庫從一百gb增長到了一百三十gb，然後你把它再收縮到一百gb，你就不知道資料庫實際上需要多少空間了。它需要一百gb還是一百三十gb?

答案是它需要一百三十gb空間，以便它可以執行需要的資料庫維護。如果你做了收縮，然後在磁碟上放了其他資料，你不可能有足夠的空間執行你的資料庫維護，這項任務就會失敗的。