对于上下文- SQL 2014 EE,我们正在从主生产框进行tran日志备份,并恢复到R/O实例。日志通常在50 is左右。
因此,我熟悉Server恢复的结构,并且知道完整估计的百分比仅指数据复制阶段。对于我们来说,这通常运行得非常快,但是重做阶段是花费时间的地方。
通过sp_whoisactive,我可以轻松地让日志恢复读取/编写页面。我想知道的是,如果我知道日志的大小(我知道),我能从这些数字中估计恢复的进度吗?
我打算给是一个快速,但如果有人已经尝试过,这是一个愚蠢的差事,我会跳过它!
发布于 2015-04-02 14:17:31
看看percent_complete和estimated_completion_time在sys.dm_exec_requests。如果它实际上是为还原日志而填充的(我只测试过完整的数据库恢复),那么它将基于您想要手工计算的相同的数学。
SELECT percent_complete, estimated_completion_time
FROM sys.dm_exec_requests
WHERE session_id = <SPID running the backup>;显然,这两种方法都不能预测挂起的并发/ I/O中断,因此它根本无法保证--只是粗略的猜测。也不可能预测任何撤销/重做操作需要多少I/O,因为这些操作与日志大小没有直接关系。
https://dba.stackexchange.com/questions/96901
复制相似问题