我正在与一位客户合作,该客户从其 SharePoint 数据库之一的日志备份中收到以下错误:
Backup detected log corruption in database FOOPORTAL_SP2010_Config. Context is FirstSector.
LogFile: 2 'D:\MSSQL2K8\MSSQL10_50.MSSQLSERVER\MSSQL\DATA\FOOPORTAL_SP2010_Config_log.LDF'
VLF SeqNo: x864 VLFBase: x172d0000 LogBlockOffset: x176b1800
SectorStatus: 2 LogBlock.StartLsn.SeqNo: x771 LogBlock.StartLsn.Blk: x1f0c
Size: x400 PrevSize: x200
我知道这表明磁盘硬件和/或 IO 子系统存在问题,我们一直在与 Hosting Provider 一起努力。具体来说,这似乎是 /a 磁盘上的一个“坏点”,因为此 DB 的日志文件一直报告它,但过去几周其他 6 个 DB 日志备份没有报告其他错误,也不用于任何 20 多个其他数据库的完整数据备份。
我的直接问题是客户已经以这种方式运行了几个星期,因为这是一项强制性的 24x7 服务,直到今晚(突然)2 小时,他们才能给我一个停机服务窗口来解决这个问题. 不幸的是,数据库损坏和这种管理工作不是我在 SQL Server 中的专长,我不确定最好/最安全/最可靠的方法是什么。
我现在的初步计划是:
- 停机时间窗口开始后立即对数据库进行完整备份(在此期间完整备份一直在正常工作)
- 分离旧数据库
- 删除空间的数据文件
- 重命名日志文件(仍然保留它)
- 从步骤 1 中的新备份还原数据库的新副本。
我对此的担忧/焦虑是:
- 这应该工作吗?还是更安全/更可靠的方法?
- 我只有 2 小时,有没有更省时的方法?
欢迎任何其他建议。
如果您的日志文件损坏,我担心备份/恢复会保留损坏。我的方法(可能会更快完成)是:
要附加数据库并重建日志文件,它只是CREATE DATABASE语句中的附加语法:
这将强制 SQL Server 在附加数据库时重建日志文件。
这样做的风险是丢失完成完整备份和分离数据库之间发生的任何事务,但听起来这将是一个最小的风险。如果您可以在停机时间窗口开始时“冻结”Sharepoint,这将有助于降低该风险。