none
请教数据库服务器断电之后如何修复 RRS feed

  • 问题

  • 我尝试附加报如下错误:

    无法在数据库“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)

    2014年10月9日 2:52

全部回复

  • Do you have good backup? Or tried fix it with dbcc?
    2014年10月9日 3:19
  • 如果有备份,则直接还原备份吧
    对于数据库恢复模型非 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'
    

    2014年10月9日 3:45
  • 如果无法通过备份还原,则尝试硬修

    -- 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 模式下把能够读取的数据弄出来放到一个新建的库里面吧
    
    

    2014年10月9日 3:52
  • 如果无法通过备份还原,则尝试硬修

    -- 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(拒绝访问。)"。
    2014年10月9日 4:58
  • 如果无法通过备份还原,则尝试硬修

    -- 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 行
    紧急模式修复失败。您必须从备份中还原。

    2014年10月9日 5:04
  • 文件激活失败。物理文件名称'C:\DB2008R2\UFDATA.LOG'可能不正确。
     无法重新生成日志,原因是数据库关闭时存在打开的事务/用户,该数据库没有检查点或者该数据库是只读的。如果事务日志文件被手动删除或者由于硬件或环境问题而丢失,则可能出现此错误。
     消息 5123,级别 16,状态 1,第 1 行
     尝试打开或创建物理文件 'D:\U8SOFT\ADMIN\PC2014\ZT003\2014\UFDATA.LDF' 时,CREATE FILE 遇到操作系统错误 21(设备未就绪。)。

    --------------- 这个是做那步操作的时候出的错呢? 这里面提示两个文件名称, 你是有两个日志文件?

    2014年10月9日 5:22
  • 如果确定不是权限问题,而是日志文件损坏, 你可以把 mdf 文件复制到一个目录,然后试试用 rebuild log 的方法附加 mdf 文件

    CREATE DATABASE xx_rebuild
     ON (FILENAME = 'x:\xx.mdf')
     FOR ATTACH_REBUILD_LOG

    2014年10月9日 5:26
  • 文件激活失败。物理文件名称'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这个时候会去找原来的日志路径.  服务器断电的瞬间有事务正在执行。


    2014年10月9日 5:44
  • Do you have good backup? Or tried fix it with dbcc?
    没有的
    2014年10月9日 6:16
  • 我昨天也遇到这个问题,由于数据库几TB,没有做备份

    用周建大侠的硬修方法

    一般就两种情况

    日志没有损坏:1 、还原备份  2、紧急模式下的DBCC CHECKDB(xx, REPAIR_ALLOW_DATA_LOSS)

    日志损坏:删除ldf文件,然后ATTACH_REBUILD_LOG 

    但是保险做法还是要备份数据库,或者在删除ldf文件之前备份一下

    数据库太大的话,特别要注意做好备份

    2014年10月9日 7:03
  • You copied that db from other server? Shouldn't point to old file path if copied properly.
    2014年10月9日 13:23
  • 我昨天也遇到这个问题,由于数据库几TB,没有做备份

    用周建大侠的硬修方法

    一般就两种情况

    日志没有损坏:1 、还原备份  2、紧急模式下的DBCC CHECKDB(xx, REPAIR_ALLOW_DATA_LOSS)

    日志损坏:删除ldf文件,然后ATTACH_REBUILD_LOG 

    但是保险做法还是要备份数据库,或者在删除ldf文件之前备份一下

    数据库太大的话,特别要注意做好备份

    没有备份,紧急模式修复失败,日志文件损坏了,重建日志文件会提示“无法重新生成日志,原因是数据库关闭时存在打开的事务/用户,该数据库没有检查点或者该数据库是只读的”。

    尝试在紧急模式下读取数据,发现部分表有问题。

    2014年10月10日 1:00
  • 尝试在紧急模式下读取数据,发现部分表有问题。

    ---------------------------- 这样的情况估计没什么办法,如果数据非常重要,可以试试联机微软,如果不是太重要,那么就放弃吧,建新库,把紧急模式下可导出的数据导出到新库中

    2014年10月10日 2:40
  • 你的比我还严重
    2014年10月10日 5:39
  • 我数据库前两天也突然连接不上了,由于是用的虚拟主机,那边只有自动两三天备份一次,现在数据库文件,他们给我弄出来了,用之前的自动备份的,给恢复了,弄出来的数据库文件无法附加,提示如下:

    标题: 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

    2014年10月17日 5:18
  • You can't rely on OS backup, have to do db/log backups in sql.
    2014年10月17日 13:26