我必须对所有数据库进行备份（所有.BAK文件组合的3.25 GB数据）。
如果我configuration脚本将数据库设置为只读，然后再备份，会更快吗？
我正在使用RESTORE VERIFYONLY选项来检查备份的完整性。 我也想知道是否有什么可以加速这个过程？ 我发现需要比实际备份更长的时间！
把它设置为READ ONLY可以帮助你，只要你从海中移出一滴水。
在备份期间， 备份会考虑活动事务 。
这意味着，是的，当你把你的数据库READ ONLY你正在消除一点点的开销。
技术上有什么帮助，但是这不值得。
提高备份性能是众所周知的领域 。
有大量的博客文章 ，甚至是关于如何提高备份性能的技术网文章。 没有一个提到只是因为老实说，你不会注意到任何区别。
为了改善您的备份性能：
所以回顾一下：
是的，它是有帮助的，但还不足以被一个理智的人所衡量。
有办法提高备份性能，试着看看这些。
将其设置为只读不会帮助你。 您还可以为任何需要写入权限的应用程序创build停机时间。
看看你的瓶颈现在在哪里。 大多数情况下，这是2件事中的1件。
CPU是瓶颈：不要压缩备份。
磁盘是瓶颈：压缩备份。
如果您想深入研究，请在备份运行时运行此TSQL脚本：
SELECT command, sh.text, start_time, percent_complete, CAST(((DATEDIFF(s,start_time,GetDate()))/3600) as varchar) + ' hour(s), ' + CAST((DATEDIFF(s,start_time,GetDate())%3600)/60 as varchar) + 'min, ' + CAST((DATEDIFF(s,start_time,GetDate())%60) as varchar) + ' sec' as running_time, CAST((estimated_completion_time/3600000) as varchar) + ' hour(s), ' + CAST((estimated_completion_time %3600000)/60000 as varchar) + 'min, ' + CAST((estimated_completion_time %60000)/1000 as varchar) + ' sec' as est_time_to_go, dateadd(second,estimated_completion_time/1000, getdate()) as est_completion_time, status, blocking_session_id, wait_type, wait_time, last_wait_type, wait_resource, reads, writes, cpu_time FROM sys.dm_exec_requests re CROSS APPLY sys.dm_exec_sql_text(re.sql_handle) sh WHERE re.command in ('RESTORE DATABASE', 'BACKUP DATABASE', 'RESTORE LOG', 'BACKUP LOG')
（ percent_complete完成在2014 percent_complete不了，仍然需要find一个解决scheme）。
在wait_type列中，您将看到什么导致备份等待。 你可以在这个列表中查找它。 如果必须等待另一个进程，它将显示在blocking_session_id 。 您可以使用sp_who2 xxx获取有关该进程的更多详细信息。
如果您的服务器（磁盘/ cpu）可以处理它，则可以安排备份同时运行。 如果你真的想要性能，备份到多个文件，跨越多个磁盘。
@BartDeVos说得对，这取决于你的瓶颈是什么，但是他错过了一个重要的观点，那就是IF竞争性写入锁是你的瓶颈，那么是的，只有数据库读取才能提供帮助。 （如果没有，那么不要担心）。
我的数据库专业知识不在Microsoft产品中，所以我不能评论您使用的特定引擎，并且在数据库引擎和备份系统之间的实施细节方面存在很大差异。
编辑。 阅读评论。 如果正在使用的备份系统是其他受访者所假定的备份系统，那么备份速度不会受到影响，我猜测OP对.bak文件的引用往往会支持这一点。