询问者
请教数据库服务器断电之后如何修复

问题
-
我尝试附加报如下错误:
无法在数据库“UFDATA_003_2014”(数据库 ID 为 12)的分配单元 392698844479488,页 (1:933) 上重做事务 ID (0:995391) 的日志记录 (4133:486:5)。页: LSN = (4132:24010:5),分配单元 = 392698844479488,类型 = 1。日志: OpCode = 2,上下文 2,PrevPageLSN: (4132:24714:5)。请从数据库备份还原该数据库,或者修复它。
在重做数据库 'UFDATA_003_2014' 的日志中记录的操作时,日志记录 ID (4133:486:5) 出错。通常,特定故障以前会在 Windows 事件日志服务中记录为错误。请利用完整备份还原数据库,或者修复该数据库。
无法打开新数据库 'UFDATA_003_2014'。CREATE DATABASE 中止。 (.Net SqlClient Data Provider)
全部回复
-
如果有备份,则直接还原备份吧
对于数据库恢复模型非 simple 的情况,可以尝试日志还原来恢复到未损坏的最后一刻-- 1. 备份损坏数据库的尾部日志 BACKUP LOG XX TO DISK = 'x:\xx.log.bak' WITH NO_TRUNCATE -- 如果无法成功,尝试使用 CONTINUE_AFTER_ERROR 选项 GO -- 2. 从备份还原数据库(通常建议先改名还原,而不是直接覆盖损坏的数据库) -- 这里面需要通过 MOVE 选项将数据文件移到正确的位置 RESTORE DATABASE XX_RESTORE FROM DISK = 'x:\xx.最后一个完全备份.bak' WITH NO_RECOVERY RESTORE DATABASE XX_RESTORE FROM DISK = 'x:\xx.最后一个差异备份(如果有的话).bak' WITH NO_RECOVERY RESTORE DATABASE XX_RESTORE FROM DISK = 'x:\xx.顺序还原前一个差异(或者完全)备份之后的所有日志备份.bak' WITH NO_RECOVERY GO -- 3. 还原第一步备份的损坏数据库的尾部日志 RESTORE DATABASE XX_RESTORE FROM DISK = DISK = 'x:\xx.log.bak' WITH NO_RECOVERY GO -- 4. 如果步骤3是成功的,那么你的数据库已经恢复到最后未丢失时间的点,再执行下面的语句使数据库可用即可 RESTORE DATABASE XX_RESTORE WITH RECOVERY; GO -- 5. 验证数据没有问题之后,删除损坏的数据库,并用还原的数据库取代 DROP DATABASE XX EXEC sp_renamedb 'XX_RESTORE', 'XX'
-
如果无法通过备份还原,则尝试硬修
-- 1. 将数据库设置为 EMERGENCY 模式 ALTER DATABASE XX SET EMERGENCY GO -- 2. 使用 DBCC CHECKDB 检查损坏情况 DBCC CHECKDB(xx) GO -- 3. 执行输出中建议的 DBCC 修复语句做数据修复 ALTER DATABASE XX SET SINGLE_USER DBCC CHECKDB(xx, REPAIR_ALLOW_DATA_LOSS) GO -- 4. 如果成功修复,则将数据库改回正式模式 ALTER DATABASE XX SET ONLINE ALTER DATABASE XX SET MULTI_USER GO -- 5. 如果无法,那么在 EMERGENCY 模式下把能够读取的数据弄出来放到一个新建的库里面吧
-
如果无法通过备份还原,则尝试硬修
-- 1. 将数据库设置为 EMERGENCY 模式 ALTER DATABASE XX SET EMERGENCY GO -- 2. 使用 DBCC CHECKDB 检查损坏情况 DBCC CHECKDB(xx) GO -- 3. 执行输出中建议的 DBCC 修复语句做数据修复 ALTER DATABASE XX SET SINGLE_USER DBCC CHECKDB(xx, REPAIR_ALLOW_DATA_LOSS) GO -- 4. 如果成功修复,则将数据库改回正式模式 ALTER DATABASE XX SET ONLINE ALTER DATABASE XX SET MULTI_USER GO -- 5. 如果无法,那么在 EMERGENCY 模式下把能够读取的数据弄出来放到一个新建的库里面吧
-
如果无法通过备份还原,则尝试硬修
-- 1. 将数据库设置为 EMERGENCY 模式 ALTER DATABASE XX SET EMERGENCY GO -- 2. 使用 DBCC CHECKDB 检查损坏情况 DBCC CHECKDB(xx) GO -- 3. 执行输出中建议的 DBCC 修复语句做数据修复 ALTER DATABASE XX SET SINGLE_USER DBCC CHECKDB(xx, REPAIR_ALLOW_DATA_LOSS) GO -- 4. 如果成功修复,则将数据库改回正式模式 ALTER DATABASE XX SET ONLINE ALTER DATABASE XX SET MULTI_USER GO -- 5. 如果无法,那么在 EMERGENCY 模式下把能够读取的数据弄出来放到一个新建的库里面吧
DBCC CHECKDB(xx, REPAIR_ALLOW_DATA_LOSS) 这里提示 无法打开物理文件 "C:\DB2008R2\UFDATA.mdf"。操作系统错误 5:"5(拒绝访问。)"。
权限问题解决了。
再次执行:
文件激活失败。物理文件名称'C:\DB2008R2\UFDATA.LOG'可能不正确。
无法重新生成日志,原因是数据库关闭时存在打开的事务/用户,该数据库没有检查点或者该数据库是只读的。如果事务日志文件被手动删除或者由于硬件或环境问题而丢失,则可能出现此错误。
消息 5123,级别 16,状态 1,第 1 行
尝试打开或创建物理文件 'D:\U8SOFT\ADMIN\PC2014\ZT003\2014\UFDATA.LDF' 时,CREATE FILE 遇到操作系统错误 21(设备未就绪。)。
消息 5024,级别 16,状态 2,第 1 行
在 sysfiles1 中找不到主日志文件所对应的条目。无法重建日志。
消息 5028,级别 16,状态 2,第 1 行
系统无法激活足够的数据库来重建日志。
UFDATA的 DBCC 结果。
CHECKDB 在数据库 'UFDATA' 中发现 0 个分配错误和 0 个一致性错误。
消息 7909,级别 20,状态 1,第 1 行
紧急模式修复失败。您必须从备份中还原。 -
文件激活失败。物理文件名称'C:\DB2008R2\UFDATA.LOG'可能不正确。
无法重新生成日志,原因是数据库关闭时存在打开的事务/用户,该数据库没有检查点或者该数据库是只读的。如果事务日志文件被手动删除或者由于硬件或环境问题而丢失,则可能出现此错误。
消息 5123,级别 16,状态 1,第 1 行
尝试打开或创建物理文件 'D:\U8SOFT\ADMIN\PC2014\ZT003\2014\UFDATA.LDF' 时,CREATE FILE 遇到操作系统错误 21(设备未就绪。)。--------------- 这个是做那步操作的时候出的错呢? 这里面提示两个文件名称, 你是有两个日志文件?
-
文件激活失败。物理文件名称'C:\DB2008R2\UFDATA.LOG'可能不正确。
无法重新生成日志,原因是数据库关闭时存在打开的事务/用户,该数据库没有检查点或者该数据库是只读的。如果事务日志文件被手动删除或者由于硬件或环境问题而丢失,则可能出现此错误。
消息 5123,级别 16,状态 1,第 1 行
尝试打开或创建物理文件 'D:\U8SOFT\ADMIN\PC2014\ZT003\2014\UFDATA.LDF' 时,CREATE FILE 遇到操作系统错误 21(设备未就绪。)。--------------- 这个是做那步操作的时候出的错呢? 这里面提示两个文件名称, 你是有两个日志文件?
D:这个路径是mdf里面的,原来服务器上的路径,
ATTACH_REBUILD_LOG 一样的错误信息
文件激活失败。物理文件名称'D:\U8SOFT\ADMIN\PC2014\ZT003\2014\UFDATA.LDF'可能不正确。
无法重新生成日志,原因是数据库关闭时存在打开的事务/用户,该数据库没有检查点或者该数据库是只读的。如果事务日志文件被手动删除或者由于硬件或环境问题而丢失,则可能出现此错误。
消息 1813,级别 16,状态 2,第 1 行
无法打开新数据库 'UFDATA_rebuild'。CREATE DATABASE 中止。D:\U8SOFT\ADMIN\PC2014\ZT003\2014\UFDATA.LDF这个时候会去找原来的日志路径. 服务器断电的瞬间有事务正在执行。
- 已编辑 Daniel Chow 2014年10月9日 5:46
-
我昨天也遇到这个问题,由于数据库几TB,没有做备份
用周建大侠的硬修方法
一般就两种情况
日志没有损坏:1 、还原备份 2、紧急模式下的DBCC CHECKDB(xx, REPAIR_ALLOW_DATA_LOSS)
日志损坏:删除ldf文件,然后ATTACH_REBUILD_LOG
但是保险做法还是要备份数据库,或者在删除ldf文件之前备份一下
数据库太大的话,特别要注意做好备份
没有备份,紧急模式修复失败,日志文件损坏了,重建日志文件会提示“无法重新生成日志,原因是数据库关闭时存在打开的事务/用户,该数据库没有检查点或者该数据库是只读的”。
尝试在紧急模式下读取数据,发现部分表有问题。
-
我数据库前两天也突然连接不上了,由于是用的虚拟主机,那边只有自动两三天备份一次,现在数据库文件,他们给我弄出来了,用之前的自动备份的,给恢复了,弄出来的数据库文件无法附加,提示如下:
标题: Microsoft SQL Server Management Studio ------------------------------ 附加数据库 对于 服务器“BAUER”失败。 (Microsoft.SqlServer.Smo) 有关帮助信息,请单击: http://go.microsoft.com/fwlink?ProdName=Microsoft+SQL+Server&ProdVer=11.0.3000.0+((SQL11_PCU_Main).121019-1322+)&EvtSrc=Microsoft.SqlServer.Management.Smo.ExceptionTemplates.FailedOperationExceptionText&EvtID=附加数据库+Server&LinkId=20476 ------------------------------ 其他信息: 执行 Transact-SQL 语句或批处理时发生了异常。 (Microsoft.SqlServer.ConnectionInfo) ------------------------------ 无法在数据库“sq_mikrotiknet”(数据库 ID 为 7)的分配单元 72057594042449920,页 (1:204) 上重做事务 ID (0:10603) 的日志记录 (82:739:2)。页: LSN = (82:342:2),分配单元 = 72057594042449920,类型 = 1。日志: OpCode = 6,上下文 2,PrevPageLSN: (82:360:2)。请从数据库备份还原该数据库,或者修复它。 在重做数据库 'sq_mikrotiknet' 的日志中记录的操作时,日志记录 ID (82:739:2) 出错。通常,特定故障以前会在 Windows 事件日志服务中记录为错误。请利用完整备份还原数据库,或者修复该数据库。 无法打开新数据库 'sq_mikrotiknet'。CREATE DATABASE 中止。 (Microsoft SQL Server,错误: 3456) 有关帮助信息,请单击: http://go.microsoft.com/fwlink?ProdName=Microsoft%20SQL%20Server&EvtSrc=MSSQLServer&EvtID=3456&LinkId=20476