SQL Server如何提升数据库备份的速度

对于一个数据库完整备份来讲，备份的速度很大程度上取决于下面两个因素：读磁盘数据、日志文件的吞吐量，写磁盘数据文件的吞吐量。

下图是备份过程当中磁盘的变化状况：

读吞吐量

读吞吐量的大小取决于磁盘读取数据的速度，而磁盘读取的速度又取决于数据文件在磁盘中的位置。所以，位于不一样盘符上不一样数据库文件的读取速度都不相同。

测量读吞吐量的一个方法就是进行一次数据库完整备份，而后使用Windows性能监控器(perfmon)来监控数据库文件所在磁盘的Read bytes/sec 性能计数器。保存备份文件的磁盘应该在物理上区别于数据库文件所在的磁盘，不然测量精度会不许确。固然备份同时也应该会有另一些来自系统或是其余应用程序对磁盘的读取操做。

注意：若是你使用完整备份来监测磁盘读写吞吐量的话，那么这个测试用的备份文件应该和其余常规备份放在一块儿，以便恢复时使用。也就是说，若是你在测试备份文件以后又进行了常规差别备份，那么这些差别备份就会以这个测试备份为还原的起始点。

假设数据库全部文件的大小都是相等的，那么你获取的最小测量值就是你指定数据库在系统中最大的备份吞吐量了。

另外一个测量读吞吐量的方法是在NUL设备上执行备份，以下：

BACKUP DATABASE AdventureWorks TO DISK = 'NUL' WITH COPY_ONLY

注意咱们使用了COPY_ONLY选项，这个选项仅仅在SQL Server 2005及以上版本中才提供。你能够在SQL Server2000上执行相同的备份，只是要忽略这个选项，可是必定要当心。由于备份到NUL设备也会被认为是一个有效备份，这就意味着当你执行备份到NUL设备后，你后续的全部差别备份都将不可用，除非你在执行备份到NUL设备后，再执行一次常规的数据库完整备份。假如你执行事务日志备份到NUL设备，那么你将破坏日志恢复链，致使后续事务日志备份不可用。

若是你必须在SQL Server 2000上执行备份到NUL设备的话，必定要作好备灾恢复的准备。

假设我如今已经测量出个人AdventureWorks读吞吐量为46MB/sec。这就是说，46MB/sec是最大的备份吞吐量了，也是个人磁盘能提供给SQL Server备份读线程最快的速度了。那咱们如何提升这个速度呢？使用更快的磁盘确定是一种方法。另外的方法就是把数据库文件分散到多个物理磁盘上，以便于在读数据时能够同步建立多个读线程。减少数据库文件的碎片级别也能够提升吞吐量，特别是当数据库文件有大量碎片存在时。

写吞吐量

如今开始说说写吞吐量。执行一个文件备份，在个人系统中，我获得了以下的结果：

BACKUP DATABASE successfully processed 7529 pages in 3.300 seconds (18.688 MB/sec).

上面的结果代表写吞吐量在这里成为了瓶颈。个人磁盘能够提供46MB/sec的数据，可是写速度仅为18.688MB/sec。实际上，我把备份文件放在了同数据文件相同的磁盘上，当我把备份文件放在不一样的物理磁盘上时，我获得以下的结果：

BACKUP DATABASE successfully processed 7529 pages in 1.421 seconds (43.399 MB/sec).

上面的结果已经好不少了。如今读写速度都取决于磁盘了，总体的吞吐量已经明显提升了。因此把备份文件放到不一样的物理磁盘上就是一种提升写吞吐量的方法。另外一个方法就是把备份分散成不一样的文件。若是磁盘能够控制它的话，那么文件能够位于相同的物理磁盘上。若是不能，你最好把文件分散到不一样的物理磁盘上。使用更快的磁盘存储备份文件是另外一个好的选择。

然而，让咱们回到第一步，再看看那个总体图。想想备份吞吐量的第一步是读吞吐量。也就是说即便你的写吞吐量达到150MB/sec，可是若是读吞吐量只有46MB/sec的话，也无济于事，你能得到的最大备份吞吐量仍是46MB/sec。

总结

首先咱们总结一下咱们都作了什么：

咱们测量了读吞吐量为46MB/sec，咱们讨论了以下方法来提升这个数值：

• 使用更快的磁盘。
• 把多个数据库文件存储在不一样的物理磁盘上
• 减小数据库文件碎片级别

咱们在数据库文件所在磁盘执行了备份执行，备份吞吐务为18MB/sec。很糟的速度，咱们知道读吞吐量为46MB/sec，因此咱们把目标放到了写吞吐量上。而后，咱们把备份文件放到了与数据库文件不一样的物理磁盘上。备份吞吐量为43MB/sec。速度不错。我也还能够提升这一数值吗？看起来好像是不行了。可是若是咱们的写吞吐量仅仅为25MB/sec的话，咱们还能够从如下几方面来考虑：

• 使用更快的磁盘进行备份
• 把备份文件分割成多个文件（在相同或不一样的物理磁盘上，这取决于磁盘的吞吐量）
• 使用备份压缩工具。假如压缩速度很是好的话，那么就会减小写到磁盘上的数据量，从而加大写吞吐量。通常状况执行这种压缩程序都会消耗大量的CPU资源

补充说明

为了得到最好的备份吞吐量，下面这几点在最开始建立数据库时就应该考虑到。实际上，下面这几点也一样适用于提升你数据库的应用性能。

• 磁盘速度：使用最快的磁盘或是在预算容许的前提下进行磁盘配置来提升备份吞吐量。
• 数据库文件：把数据库文件分散到多个物理磁盘上，以便于SQL Server使用多个读线程去每一个磁盘上读取数据。对比单数据文件的数据库存储来说，多数据文件能够在很短期内完成数据的读取。
• 使用不一样的物理磁盘：SQL Server的读线程数量是基于你数据库文件所在的盘符数量的。然而，假如你的盘符是相同物理磁盘上的分区，并且你的磁盘不能知足读线程的读取要求时，你的备份吞吐量将会不好。
• 文件碎片：建立数据时指定的数据库的初始大小就至关于指定的数据库减小文件碎片的指望最大值。假如数据库文件被设置为自动增加，且设置了一个最大增加值的话，这样也要有助于减少碎片。
• 有计划的存储你的事务日志到独立的磁盘中：把你的事务日志文件存储在独立于数据库文件的磁盘中，甚至独立于操做系统或是其余常用I/O的应用程序，有助于在执行事务日志备份时提升读写吞吐量。事务日志的磁盘的I/O操做是天然相连的，而不是数据文件I/O那种随机的操做。把事务日志文件同数据文件放在同一个盘上的话，当数据库忙碌时，会使事务日志备份变慢。
• 有计划的存储你的备份到独立的磁盘中：把你的备份文件存储在独立于数据库文件的磁盘中，甚至独立于操做系统或是其余常用I/O的应用程序，有助于提升写吞吐量。

获取备份速度数据

你能够从msdb..backupset表中获取备份速度数据。backup_start_date,backup_finish_date和backup_size列提供了计算备份速度所需的全部数据细节信息。注意备份大小不是定义数据库大小所必需的，由于SQL Server 2005不备份包括已被删除数据的数据页。具体细节请参见article。

下面的脚本能够显示出你全部数据库的备份时间：

SELECT database_name, backup_start_date, CAST(CAST((backup_size / (DATEDIFF(ss, backup_start_date, backup_finish_date))) / (1024 * 1024) AS NUMERIC(8, 3)) AS VARCHAR(16)) + ' MB/sec' speed FROM msdb..backupset ORDER BY database_name, backup_start_date