可是，其體積仍然很龐大。所以，在日常工作中，如何給SQL Server的備份文件瘦身，就是很多數據庫管理員所關心的問題了。
也許微軟的數據庫產品設計專家聽到了眾多數據庫管理員的呼聲了吧。在最新的2008版本的SQLServer數據庫中，提出了備份壓縮的概念。其基本原理跟利用RAR等壓縮工具壓縮文件一樣，可以讓原有的備份文件體積更小。這直接帶來的好處，就是可以節省服務器的備份空間。另外，若SQLServer數據庫配置了異地備份的話，那麼也可以節省網絡帶寬，縮短異地備份的時間，等等。
筆者前不久剛把數據庫升級到了2008，並重新更改了備份配置，讓數據庫支持備份壓縮。下面筆者就把備份壓縮的管理心得跟大家分享一下。希望筆者這些經驗能夠幫助大家做好SQL Server數據庫備份壓縮的管理。簡單的來說，如果要采用備份壓縮技術，那麼數據庫管理員要弄明白幾個問題。
問題一：備份壓縮技術的限制條件。
由於備份壓縮技術是2008版本中才提出來的，所以其兼容性可能就會收到一些限制。根據官方的說法是，從2008以後的數據庫版本，都會支持這個備份壓縮技術。故向後兼容應該問題不大。數據庫管理員關心的應該是，從低版本升級到高版本的數據庫時的一些限制條件。掌握這些限制條件，可能會讓數據庫升級少遇到一些問題。根據筆者的了解，這裡至少有二個限制條件。
一是壓縮的備份和未壓縮的備份不能夠共存於一個媒體集中。在SQL Server數據庫中，如果要對數據集進行備份，則首先需要建立一個媒體集。筆者升級完成之後，先對數據庫進行了一個完全備份，這個備份沒有采用壓縮技術。後來筆者在測試壓縮備份的時候，卻發現怎麼都不成功。後來根據錯誤提示查詢了相關資料並進行親自測試，才發現壓縮的備份和未壓縮的備份不能夠共存於一個媒體集中。筆者後來重新建立了一個媒體集後，備份壓縮技術就可以起作用了。
二是早期版本的SQL Server數據庫無法讀取壓縮的備份。為了測試備份壓縮技術的向前兼容性，筆者特意利用備份壓縮後的數據庫文件，去恢復2005版本的數據庫。注意，這個數據庫文件是升級到2008後馬上備份的，也就是說，除了這個壓縮技術外，沒有采用2008的新技術與新對象。但是，卻發現2005版本的數據庫根本不認賬，不認識這個壓縮後的備份文件。可見，早期版本的SQL Server數據根本無法讀取壓縮後的備份文件。
這是筆者測試後發現的兩個限制條件。不過筆者查詢了一些官方資料後發現，還有一個重要的限制。如NTBACKUP工具無法共享含壓縮的數據庫備份磁帶。不過由於筆者用不到這方面的內容，所以也沒有測試是否如此。
問題二：壓縮的效果到底如何?
如果采用了壓縮備份技術，那麼備份文件到底可以瘦下來多少呢?這主要跟數據庫有關。根據筆者的了解，如下一些因素會直接影響到最終的壓縮效果。
首先是跟數據類型有關。如果數據庫中大部分是字符型的數據，則其壓縮效果會比較好。而如果數字類型比較多的話，那麼采用壓縮備份技術後，備份文件並不能夠小多少。這也給數據庫管理元是否要采用壓縮備份技術提供了一個判斷的標准。
其次是數據是否加密。正常情況下，如果數據庫中的數據未加密，則其壓縮的效果會比較明顯。相反如果數據庫的數據加密了，則其壓縮的程度就會小很多。如數據庫管理員利用透明數據加密方法來加密整個數據庫，則采用壓縮備份技術之後，壓縮備份並不會將數據庫減小多少，甚至根本不會減小。
再者，跟數據表設計也有關系。一般情況下，如果表設計比較合理，則其壓縮的效果就會好許多。如某頁中包含多個行，而其中的某個字段包含相同的值，則該值就可以獲得比較大的壓縮率。與之相反，如果字段中的數據大部分是隨機數據(即使只有稍微的差別)，則其壓縮備份的大小幾乎與未壓縮的備份相同。這也就是說，要想取得比較好的壓縮效果，則在數據庫設計時，就需要考慮。如可以采用一些列表字段供用戶選擇，就可以提高最終備份文件的壓縮效果。
問題三：壓縮備份對於性能的影響如何?
數據庫采用壓縮備份之後，對於數據庫的影響是雙方面的，即有利也有害。
利是直接跟上面所說的數據庫壓縮效果相關。因為同一個數據庫的壓縮備份文件要比原來的備份文件要小，所以壓縮備份所需要的設備輸入輸出通常比較少，所以可以大大提高備份速度。而且，數據庫進行異地備份的話，還可以大大縮短網路傳輸的時間。所以，當數據庫的壓縮效果越好，則對於數據庫的性能，也會有很大的改善。
不利之處就在於資源的消耗方面。如果采用了壓縮備份技術，則壓縮會顯著增加CPU的使用率。而壓縮進程所占用的額外CPU可能會對兵法操作產生消極的影響。為了盡量減少這個不利影響，可以采取的措施就是調整SQL Server數據庫的備份策略。如把備份時間放在午夜時分。那時候，基本上沒有用戶使用數據庫，或者數據庫的使用幾率會大大降低。此時，就是多一些額外的CPU消耗，用戶也很難察覺到。
另外在數據庫中，也可以通過降低優先級的方式，來降低壓縮備份對數據庫的不利影響。如當發生CPU爭用時，此備份的CPU使用就會受到資源控制其的限制。通過將特定的用戶會話映射到限制CPU使用的資源調控器工作負荷來實現。不過這個實現起來比較復雜，以後若有機會，筆者將會專題講述。對於大部分企業來說，數據庫的使用都有很明顯的高發期與低潮期。只需要稍微調整一下備份策略，在數據庫使用低潮期進行壓縮備份，就可以很輕松的避免壓縮備份所帶來的負面影響。而完全不需要吃力不討好，采用這麼復雜的解決方案。即使像銀行類這些金融機構，在晚上12點之後用戶也會大量的減少。此時他們釋放出來的CPU給壓縮備份使用已經足夠了。
還好筆者以前采取的備份策略，就是在晚上12點之後讓數據庫進行自動備份。所以這次采用了壓縮備份之後，對於性能的影響可以忽略。
問題四：如何啟用壓縮備份?
默認情況下，數據庫在執行備份的時候，是不采用壓縮備份的。如果數據庫管理員出於特定的需要要啟用壓縮備份的話，就需要管理員去手工啟動。壓縮備份的默認行為是數據庫系統中的備份壓縮默認選項服務器級配置來決定的。
如需要啟用壓縮備份策略，只需要經過簡單的三個步驟即可。
第一步：打開數據庫對象資源管理器，右鍵單擊需要啟用壓縮備份策略的那個服務器，然後打開屬性對話框。
第二步：單擊數據庫設置節點。找到備份和還原選項卡。在壓縮備份頁簽中顯示了備份壓縮默認設置的當前配置。這個“壓縮備份”選項決定了數據庫在備份的時候是否要才用壓縮備份策略。如果選中的話，默認情況下數據庫將啟用壓縮備份。
第三步：建立新備份媒體。筆者在上面提到過，壓縮備份與未壓縮備份不能夠存儲在同一個媒體集中。如果數據庫管理員是中途啟用這個壓縮備份策略的。即在原先的備份媒體中已經有未壓縮的備份文件，那麼數據庫管理員要麼需要刪除原有的備份文件，要麼就是重新建一個備份媒體。筆者的意見是重新建立別分媒體，而保留原有的備份文件。這主要是出於安全的考慮。萬一壓縮備份因為某些原因不成功，則仍然可以有補救措施。
壓縮備份是SQLServer數據庫推出的一個新技術。筆者以為，如果企業數據庫容量比較小的話，沒有必要采用這個壓縮備份。只有數據庫容量比較大，或者要進行異地備份的情況下，采用壓縮備份的效果才會顯現出來。由於壓縮備份有比較大的限制條件和管理難點，數據庫管理員還是需要在性能、壓縮效果等方面評估壓縮備份可能會給企業帶來的效果。評估之後再進行取捨，是否要采用壓縮備份。
