压缩技术给SQL Server备份文件瘦身

　　众所周知，随着数据库体积的日益庞大，其备份文件的大小也水涨船高。虽然说通过差异备份与完全备份配套策略，可以大大的减小SQL Server数据库备份文件的容量。可是，其体积仍然很庞大。所以，在日常工作中，如何给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数据库推出的一个新技术。笔者以为，如果企业数据库容量比较小的话，没有必要采用这个压缩备份。只有数据库容量比较大，或者要进行异地备份的情况下，采用压缩备份的效果才会显现出来。由于压缩备份有比较大的限制条件和管理难点，数据库管理员还是需要在性能、压缩效果等方面评估压缩备份可能会给企业带来的效果。评估之后再进行取舍，是否要采用压缩备份。