为何要对数据库的还原过程进行“长篇大论”？
如果一个数据库还原的时间远超日常均值，眼看时间一分分过去，但还未结束，更严重的是，你不知道什么时候能结束，出了焦急等待，你可能会这么做：
- 还原假死了，我要停止这次还原，重新还原一次；
- 备份文件有问题，换个备份文件再试一次（尽管会有数据丢失）；
然而你以为的解决方法并没有出现预期的效果，而浪费在这些方法上的时间让业务系统恢复变得更加遥不可及。
如果你熟知还原的过程，你就能跟踪还原的进度，而当你看到进度在变化时，让你至少能看到业务恢复的时间在一步步靠近。
数据库还原有3个阶段
阶段1：复制文件的阶段
在阶段1中，SQL Server将备份文件中的所有的数据、日志、索引拷贝到还原后的数据库文件中。
此时，你在数据库的日志文件里，可以看到数据库start的记录，同时该数据库会被标记为restoring。
如下视图可以帮助你查看复制的进度：
select percent_complete,last_wait_type,* from sys.dm_exec_requests
阶段2：redo 阶段2是还原的redo阶段，
SQL Server根据日志文件对已提交的事务进行redo，将数据库恢复到recovery point，但此时，日志文件中因存在未提交的事务需回滚，因此，此时数据库还处于不可用状态。
进入此阶段时，你会在数据库的日志中看到数据库会再次starting一次，且能看到百分比显示的redo进度，注意，此时如果你查看
sys.dm_exec_requests视图中percent_complete字段，你会发现一直显示100%，这是正常的，因为redo的进度并不会在
sys.dm_exec_requests中显示。所以切记不要以为还原卡死了而结束还原。
阶段3：回滚
阶段3是还原的回滚阶段，
SQL Server对日志文件中未提交的事务进行回滚，从而保证数据的一致性。数据库只有在回滚完成后，才会变得可用。
如果备份文件的事务日志中存在大量未提交的事务，那回滚的过程就会很长，还原的时间可能远超日常的均值。
笔者曾经遇到这样的场景：数据库的备份文件中包含了一个执行了10天没有完的事务（死循环）的日志，当我在进行还原时，整整还原了2天，客户的业务系统也停了2天。
这个阶段的还原进度也只能在SQL Server的错误日志中才能看到，当你看到进度为100%日志时，SQL Server会执行一个checkpoint操作，它会将内存中的脏数据固化到磁盘。
checkpoint执行时间的长短取决于内存中脏数据的大小，保守的估算方法是：假设内存的大小就是脏数据的大小，
checkpoint执行时间= 内存大小/数据文件（mdf）的写入速率
其中写入的速率可以在资源监视器（win2012及以上的系统）中可以详细看到。
当checkpint完成是时，在SQL Server的错误日志中可以看到还原完成的记录。此时数据库就可以正常使用了。
总结
看完了上述的还原的完整过程，当你再次碰到数据库还原的时间远超日常均值你就不会心慌了，起码你知道这是正常的还原过程，甚至你还能通过这个现象来判断该数据库很可能运行了非正常的SQL在序，需要进行治理。
