sql server 日志传送还原慢

最新推荐文章于 2023-04-14 17:34:44 发布

alex_198208

最新推荐文章于 2023-04-14 17:34:44 发布

阅读量811

点赞数

CC 4.0 BY-SA版权

分类专栏： MS Sql Server 文章标签： sql server delay database buffer less 数据库

本文链接：https://blog.youkuaiyun.com/alex_198208/article/details/5907323

MS Sql Server 专栏收录该内容

33 篇文章

订阅专栏

本文探讨了SQL Server 2005 SP2在进行日志还原时遇到的问题，特别是当面对大量日志文件（每日约20GB）时，还原过程变得异常缓慢。文章提到了一个可能的bug，即在某些情况下，系统时间导致了负数的延迟设置，进而影响了还原进程。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

SQL SERVER为 2005 SP2，数据库每天大概有20G的日志，基本都是默认配置。

在备库RESTORE的时候，一次执行数个小时也无法还原，JOB中有如下信息，当然还无法判断是否就和此有关，

2010-09-26 13:10:16.11 Retrieved database restore settings. Secondary Database: 'Bk5173', Restore Delay: -2000000000, Restore All: True, Restore Mode: Standby, Disconnect Users: False, Last Restored File: //ip/Logshipping/dbname_20100925214215.trn, Block Size: Not Specified, Buffer Count: Not Specified, Max Transfer Size: Not Specified
查了一些资料，在备库上修改了log_shipping_secondary_databases表的一个值，不过像需要重启服务才起作用（保留）

use [msdb];

update dbo.log_shipping_secondary_databases
set [restore_delay] = -2000000000;

In short, there's a bug in the SQLLogShip application. Sometimes depending on the machine time it gets a negative number and checks if it's less than tha value of the msdb.dbo.log_shipping_secondary_databases.restore_delay column.