壓縮技術給SQL Server備份檔案瘦身_MsSql

可是，其體積仍然很龐大。所以，在日常工作中，如何給SQL Server的備份檔案瘦身，就是很多資料庫管理員所關心的問題了。

　　也許微軟的資料庫產品設計專家聽到了眾多資料庫管理員的呼聲了吧。在最新的2008版本的SQLServer資料庫中，提出了備份壓縮的概念。其基本原理跟利用RAR等壓縮公用程式壓縮檔一樣，可以讓原有的備份檔案體積更小。這直接帶來的好處，就是可以節省伺服器的備份空間。另外，若SQLServer資料庫配置了異地備份的話，那麼也可以節省網路頻寬，縮短異地備份的時間，等等。

　　筆者前不久剛把資料庫升級到了2008，並重新更改了備份配置，讓資料庫支援備份壓縮。下面筆者就把備份壓縮的管理心得跟大家分享一下。希望筆者這些經驗能夠協助大家做好SQL ServerDatabase Backup壓縮的管理。簡單的來說，如果要採用備份壓縮技術，那麼資料庫管理員要弄明白幾個問題。

　　問題一：備份壓縮技術的限制條件。

　　由於備份壓縮技術是2008版本中才提出來的，所以其相容性可能就會收到一些限制。根據官方的說法是，從2008以後的資料庫版本，都會支援這個備份壓縮技術。故向後相容應該問題不大。資料庫管理員關心的應該是，從低版本升級到高版本的資料庫時的一些限制條件。掌握這些限制條件，可能會讓資料庫升級少遇到一些問題。根據筆者的瞭解，這裡至少有二個限制條件。

　　一是壓縮的備份和未壓縮的備份不能夠共存於一個媒體集中。在SQL Server資料庫中，如果要對資料集進行備份，則首先需要建立一個媒體集。筆者升級完成之後，先對資料庫進行了一個完全備份，這個備份沒有採用壓縮技術。後來筆者在測試壓縮備份的時候，卻發現怎麼都不成功。後來根據錯誤提示查詢了相關資料並進行親自測試，才發現壓縮的備份和未壓縮的備份不能夠共存於一個媒體集中。筆者後來重建立立了一個媒體集後，備份壓縮技術就可以起作用了。

　　二是早期版本的SQL Server資料庫無法讀取壓縮的備份。為了測試備份壓縮技術的向前相容性，筆者特意利用備份壓縮後的資料庫檔案，去恢複2005版本的資料庫。注意，這個資料庫檔案是升級到2008後馬上備份的，也就是說，除了這個壓縮技術外，沒有採用2008的新技術與新對象。但是，卻發現2005版本的資料庫根本不認賬，不認識這個壓縮後的備份檔案。可見，早期版本的SQL Server資料根本無法讀取壓縮後的備份檔案。

　　這是筆者測試後發現的兩個限制條件。不過筆者查詢了一些官方資料後發現，還有一個重要的限制。如NTBACKUP工具無法共用含壓縮的Database Backup磁帶。不過由於筆者用不到這方面的內容，所以也沒有測試是否如此。

　　問題二：壓縮的效果到底如何?

　　如果採用了壓縮備份技術，那麼備份檔案到底可以瘦下來多少呢?這主要跟資料庫有關。根據筆者的瞭解，如下一些因素會直接影響到最終的壓縮效果。

　　首先是跟資料類型有關。如果資料庫中大部分是字元型的資料，則其壓縮效果會比較好。而如果數字類型比較多的話，那麼採用壓縮備份技術後，備份檔案並不能夠小多少。這也給資料庫管理元是否要採用壓縮備份技術提供了一個判斷的標準。

　　其次是資料是否加密。正常情況下，如果資料庫中的資料未加密，則其壓縮的效果會比較明顯。相反如果資料庫的資料加密了，則其壓縮的程度就會小很多。如資料庫管理員利用透明資料加密方法來加密整個資料庫，則採用壓縮備份技術之後，壓縮備份並不會將資料庫減小多少，甚至根本不會減小。

　　再者，跟資料表設計也有關係。一般情況下，如果表設計比較合理，則其壓縮的效果就會好許多。如某頁中包含多個行，而其中的某個欄位包含相同的值，則該值就可以獲得比較大的壓縮率。與之相反，如果欄位中的資料大部分是隨機資料(即使只有稍微的差別)，則其壓縮備份的大小几乎與未壓縮的備份相同。這也就是說，要想取得比較好的壓縮效果，則在資料庫設計時，就需要考慮。如可以採用一些列表欄位供使用者選擇，就可以提高最終備份檔案的壓縮效果。

　　問題三：壓縮備份對於效能的影響如何?

　　資料庫採用壓縮備份之後，對於資料庫的影響是雙方面的，即有利也有害。

　　利是直接跟上面所說的資料庫壓縮效果相關。因為同一個資料庫的壓縮備份檔案要比原來的備份檔案要小，所以壓縮備份所需要的裝置輸入輸出通常比較少，所以可以大大提高備份速度。而且，資料庫進行異地備份的話，還可以大大縮短網路傳輸的時間。所以，當資料庫的壓縮效果越好，則對於資料庫的效能，也會有很大的改善。

不利之處就在於資源的消耗方面。如果採用了壓縮備份技術，則壓縮會顯著增加CPU的使用率。而壓縮排程所佔用的額外CPU可能會對兵法操作產生消極的影響。為了盡量減少這個不利影響，可以採取的措施就是調整SQL Server資料庫的備份策略。如把備份時間放在午夜時分。那時候，基本上沒有使用者使用資料庫，或者資料庫的使用幾率會大大降低。此時，就是多一些額外的CPU消耗，使用者也很難察覺到。

　　另外在資料庫中，也可以通過降低優先順序的方式，來降低壓縮備份對資料庫的不利影響。如當發生CPU爭用時，此備份的CPU使用就會受到資源控制其的限制。通過將特定的使用者會話映射到限制CPU使用的資源管理員工作負載來實現。不過這個實現起來比較複雜，以後若有機會，筆者將會專題講述。對於大部分企業來說，資料庫的使用都有很明顯的高發期與低潮期。只需要稍微調整一下備份策略，在資料庫使用低潮期進行壓縮備份，就可以很輕鬆的避免壓縮備份所帶來的負面影響。而完全不需要吃力不討好，採用這麼複雜的解決方案。即使像銀行類這些金融機構，在晚上12點之後使用者也會大量的減少。此時他們釋放出來的CPU給壓縮備份使用已經足夠了。

　　還好筆者以前採取的備份策略，就是在晚上12點之後讓資料庫進行自動備份。所以這次採用了壓縮備份之後，對於效能的影響可以忽略。

　　問題四：如何啟用壓縮備份?

　　預設情況下，資料庫在執行備份的時候，是不採用壓縮備份的。如果資料庫管理員出於特定的需要要啟用壓縮備份的話，就需要管理員去手工啟動。壓縮備份的預設行為是資料庫系統中的備份壓縮預設選項伺服器級配置來決定的。

　　如需要啟用壓縮備份策略，只需要經過簡單的三個步驟即可。

　　第一步：開啟資料庫物件資源管理員，按右鍵需要啟用壓縮備份策略的那個伺服器，然後開啟屬性對話方塊。

　　第二步：單擊資料庫設定節點。找到備份與還原選項卡。在壓縮備份頁簽中顯示了備份壓縮預設設定的當前配置。這個“壓縮備份”選項決定了資料庫在備份的時候是否要才用壓縮備份策略。如果選中的話，預設情況下資料庫將啟用壓縮備份。

　　第三步：建立新備份媒體。筆者在上面提到過，壓縮備份與未壓縮備份不能夠儲存在同一個媒體集中。如果資料庫管理員是中途啟用這個壓縮備份策略的。即在原先的備份媒體中已經有未壓縮的備份檔案，那麼資料庫管理員要麼需要刪除原有的備份檔案，要麼就是重建立一個備份媒體。筆者的意見是重建立立別分媒體，而保留原有的備份檔案。這主要是出於安全的考慮。萬一壓縮備份因為某些原因不成功，則仍然可以有補救措施。

　　壓縮備份是SQLServer資料庫推出的一個新技術。筆者以為，如果企業資料庫容量比較小的話，沒有必要採用這個壓縮備份。只有資料庫容量比較大，或者要進行異地備份的情況下，採用壓縮備份的效果才會顯現出來。由於壓縮備份有比較大的限制條件和管理痛點，資料庫管理員還是需要在效能、壓縮效果等方面評估壓縮備份可能會給企業帶來的效果。評估之後再進行取捨，是否要採用壓縮備份。