如何找出数据库备份慢的原因

[Sylaro0]

一个数据文件大小10G左右，log文件也是10G左右的数据库，
每周都会有停机维护，维护时会有维护计划对数据库进行一次完整备份。
正常情况下维护计划1分钟就能完成，但偶尔会出现维护计划需要20分钟左右的执行时间
请问下如何能够找出数据库备份慢的原因。

[發糞塗牆]

还可以用这些计数器来监控一下备份相关的值

[Sylaro0]

引用 4 楼 DBA_Huangzj 的回复:

可能原因： 1、磁盘碎片，碎片多，同样的数据分布范围就光，备份是按区来做单位的。可以监控一下，备份过程中备份扫描了多少个区。如果区的差异很大，可能就是碎片问题。 2、10G日志，要看日志的内容有多少，完整备份时，除了数据文件，还会包含可用于恢复的那部分日志，如果“那部分日志”很多，那备份也多。 3、对比一下两次备份的备份文件大小。会不会相差很大。 4、I/O性能是否有降低，不过如果你的时间不是越来越久而是时而高时而低，那这个问题的发生机会应该没那么大。 5、有其他进程（包括windows和sqlserver）在同时运行，备份不仅要考虑IOPS，还要考虑IO带宽。带宽被占了，也一样不会快。 6、看看CPU的使用率是否很高，这个其实和5有点关系，如果有其他操作在做，占用了CPU，也会影响备份，备份除了高IO开销之外CPU开销也很重要。 我觉得你可以用backup语句，看看每次的区数是否合理增长，这个是最重要的

因为LOG文件长的比较快，所以在每次完整备份之后，会把数据库恢复模式临时改为简单，然后收缩数据库，收缩完再改回完整恢复模式。 现在暂时不知道是备份数据库，还是收缩数据库占用了20分钟，因为这些都是写在维护计划的一个步骤里，只能等下次备份时，把语句拿出来一步步执行才能知道是备份还是收缩数据库占用了比较多的时间。 两次备份文件大小差距不大，备份时cpu使用率是1%，且没有其他应用在使用数据库 是否是磁盘碎片的原因还没去查，谢谢你提供的计数器参数，今天备份的时候使用计数器去看，却不知道要看那些参数~ 另外你说的用backup语句，看看每次的区数是否合理增长，这个能再讲的细一些么？ 蛋疼的是备份久这情况只是偶尔出现~

[發糞塗牆]

不能这要经常改恢复模式的，特别是从简单改到完整后，必须马上做一次日志备份，不然lsn就断掉，而且不做日志备份，当前的数据库还是自动截断模式

[發糞塗牆]

如果你把收缩的作业也放到一起，那当然容易变得不稳定了。计数器那个，有BACKUP那些都选上，不过最好监控一段时间，看看带宽之类的值会不会增长很大。SQL的话，直接BACKUP DATABAES xxx to disk这些语句，你可以执行一下，会有显示整个备份过程扫描了多少个区

[唐诗三百首]

系统表msdb.dbo.backupset里有backup_start_date字段(备份开始时间)和backup_finish_date字段(备份结束时间),查看一下是否差20分钟.

select top 1 name,
             database_name,
case when TYPE='D' then 'Database' 
     when TYPE='I' then 'Diff Database' 
     when TYPE='L' then 'Log'
     when TYPE='F' then 'File(Group)' 
     when TYPE='G' then 'Diff File'
     when TYPE='P' then 'Partial'
     when TYPE='Q' then 'Diff Partial' end as BACKUPTYPE,
     backup_size/1024/1024 'BACKUPSIZE(MB)',
     backup_start_date '备份开始时间',
     backup_finish_date '备份结束时间'
from msdb.dbo.backupset
order by backup_set_id desc

[Sylaro0]

我这边的数据库是没有日志备份策略的，因为业务决定不能把数据库还原到时间点。

[唐诗三百首]

其实做备份可以不需要停机的. 备份速度取决于: 1.磁盘的繁忙程度及写入速度. 2.若是异机备份,取决于网络速度与目标机器繁忙程度. 3.备份期间新产生的日志情况. 4.是否有启用压缩备份选项(with compression).

[Sylaro0]

引用 9 楼 ap0405140 的回复:

系统表msdb.dbo.backupset里有backup_start_date字段(备份开始时间)和backup_finish_date字段(备份结束时间),查看一下是否差20分钟.

select top 1 name,
             database_name,
case when TYPE='D' then 'Database' 
     when TYPE='I' then 'Diff Database' 
     when TYPE='L' then 'Log'
     when TYPE='F' then 'File(Group)' 
     when TYPE='G' then 'Diff File'
     when TYPE='P' then 'Partial'
     when TYPE='Q' then 'Diff Partial' end as BACKUPTYPE,
     backup_size/1024/1024 'BACKUPSIZE(MB)',
     backup_start_date '备份开始时间',
     backup_finish_date '备份结束时间'
from msdb.dbo.backupset
order by backup_set_id desc

看到了 是10分钟，那还有10分钟就是收缩数据库用掉了

[發糞塗牆]

引用 10 楼 Sylaro0 的回复:

我这边的数据库是没有日志备份策略的，因为业务决定不能把数据库还原到时间点。

不做日志备份ldf会越来越大，

[唐诗三百首]

引用 12 楼 Sylaro0 的回复:

看到了 是10分钟，那还有10分钟就是收缩数据库用掉了

备份时启用压缩选项(with compression),应可提高备份速度.

[Sylaro0]

引用 13 楼 DBA_Huangzj 的回复:

引用 10 楼 Sylaro0 的回复:

我这边的数据库是没有日志备份策略的，因为业务决定不能把数据库还原到时间点。

不做日志备份ldf会越来越大，

所以每次都会备份完都会收缩数据库，清空log

[發糞塗牆]

不做备份收缩不了什么的，你用DBCC SQLPERF(LOGSPACE)就可以看到

[Sylaro0]

因为LOG文件长的比较快，所以在每次完整备份之后，会把数据库恢复模式临时改为简单，然后收缩数据库，收缩完再改回完整恢复模式。 我看到的是每次收缩完，log文件就恢复到初始大小了，比如本来有10个G 收缩完只有500MB了。

[發糞塗牆]

转换恢复模式是会清理日志，那个叫自动提交事务。但是这样不符合数据库管理的正规理念，有点类似于看到ldf大就停机删掉再附加，只是你的没有那么暴力而已。我还是建议你定期做日志备份，备份文件可以不要，但是要做，这个是维护数据一致性的重要东西，不能随便乱搞

[Sylaro0]

引用 18 楼 DBA_Huangzj 的回复:

转换恢复模式是会清理日志，那个叫自动提交事务。但是这样不符合数据库管理的正规理念，有点类似于看到ldf大就停机删掉再附加，只是你的没有那么暴力而已。我还是建议你定期做日志备份，备份文件可以不要，但是要做，这个是维护数据一致性的重要东西，不能随便乱搞

OK 谢谢你的建议

[發糞塗牆]

根据你这样说，原因就再多了一个，如果某天的业务量剧增，那么那天的ldf就很大，在你切换恢复模式时，要写入的东西就很多，需要收缩的内容也很多，自然时间就多

[KevinLiu]

引用 19 楼 Sylaro0 的回复:

[quote=引用 18 楼 DBA_Huangzj 的回复:] 转换恢复模式是会清理日志，那个叫自动提交事务。但是这样不符合数据库管理的正规理念，有点类似于看到ldf大就停机删掉再附加，只是你的没有那么暴力而已。我还是建议你定期做日志备份，备份文件可以不要，但是要做，这个是维护数据一致性的重要东西，不能随便乱搞

OK 谢谢你的建议[/quote] 如果你不用日志干脆用Simple恢复模式啊。

[小魚人]

Profiler？

[LongRui888]

可能是下面的原因： 1、可能硬盘碎片太多，整理一下，或备份在其他硬盘； 2、确保没有其他应用在使用数据库； 3、数据库收缩一下； 4、查杀病毒等； 5、重启后备份；

[LongRui888]

另外， 加快备份速度：

backup database 数据库
to disk ='路径.bak'
with BUFFERCOUNT = 30,          --使用30个buffer，每个buffer 是4MB，也就是一共120MB
     MAXTRANSFERSIZE = 4194304  --4MB