要设置允许对系统表的更新:  
sp_configure   'allow   updates',1   
  GO   
  RECONFIGURE   WITH   OVERRIDE   
  GO

解决方案 »

  1.   


     
       
    你可以使用只有mdf的数据文件进行恢复操作,然后再进行dbcc检查。(假设数据库为test,路径为'C:\Program Files\Microsoft SQL Server\MSSQL\data下)
    @@只有mdf文件的恢复技术
    sp_attach_single_file_db可以恢复数据库,但是会出现类似下面的提示信息
    设备激活错误。物理文件名 'C:\Program Files\Microsoft SQL Server\MSSQL\data\test_Log.LDF' 可能有误。
    已创建名为 'C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.LDF' 的新日志文件。
    也许会得到类似下面的错误信息
    服务器: 消息 1813,级别 16,状态 2,行 1
    未能打开新数据库 'test'。CREATE DATABASE 将终止。
    设备激活错误。物理文件名 'd:\test_log.LDF' 可能有误。
    别着急,下面我们举例说明恢复办法。
    A.我们使用默认方式建立一个供恢复使用的数据库(如test)。可以在SQL Server Enterprise Manager里面建立。
    B.停掉数据库服务器。
    C.将刚才生成的数据库的日志文件test_log.ldf删除,用要恢复的数据库mdf文件覆盖刚才生成的数据库数据文件test_data.mdf。
    D.启动数据库服务器。此时会看到数据库test的状态为“置疑”。这时候不能对此数据库进行任何操作。
    E.设置数据库允许直接操作系统表。此操作可以在SQL Server Enterprise Manager里面选择数据库服务器,按右键,选择“属性”,在“服务器设置”页面中将“允许对系统目录直接修改”一项选中。也可以使用如下语句来实现。
    use master
    go
    sp_configure 'allow updates',1
    go 
    reconfigure with override
    go
    F.设置test为紧急修复模式
    update sysdatabases set status=-32768 where dbid=DB_ID('test')
    此时可以在SQL Server Enterprise Manager里面看到该数据库处于“只读\置疑\脱机\紧急模式”可以看到数据库里面的表,但是仅仅有系统表
    G.下面执行真正的恢复操作,重建数据库日志文件
    dbcc rebuild_log('test','C:\Program Files\Microsoft SQL Server\MSSQL\Data\test_log.ldf')
    执行过程中,如果遇到下列提示信息:
    服务器: 消息 5030,级别 16,状态 1,行 1
    未能排它地锁定数据库以执行该操作。
    DBCC 执行完毕。如果 DBCC 输出了错误信息,请与系统管理员联系。
    说明您的其他程序正在使用该数据库,如果刚才您在F步骤中使用SQL Server Enterprise Manager打开了test库的系统表,那么退出SQL Server Enterprise Manager就可以了。
    正确执行完成的提示应该类似于:
    警告: 数据库 'test' 的日志已重建。已失去事务的一致性。应运行 DBCC CHECKDB 以验证物理一致性。将必须重置数据库选项,并且可能需要删除多余的日志文件。
    DBCC 执行完毕。如果 DBCC 输出了错误信息,请与系统管理员联系。
    此时打开在SQL Server Enterprise Manager里面会看到数据库的状态为“只供DBO使用”。此时可以访问数据库里面的用户表了。
    H.验证数据库一致性(可省略)
    dbcc checkdb('test')
    一般执行结果如下:
    CHECKDB 发现了 0 个分配错误和 0 个一致性错误(在数据库 'test' 中)。
    DBCC 执行完毕。如果 DBCC 输出了错误信息,请与系统管理员联系。
    I.设置数据库为正常状态
    sp_dboption 'test','dbo use only','false'
    如果没有出错,那么恭喜,现在就可以正常的使用恢复后的数据库啦。
    J.最后一步,我们要将步骤E中设置的“允许对系统目录直接修改”一项恢复。因为平时直接操作系统表是一件比较危险的事情。当然,我们可以在SQL Server Enterprise Manager里面恢复,也可以使用如下语句完成
    sp_configure 'allow updates',0
    go 
    reconfigure with override
    go
      

  2.   

    USE MASTER
    GO
    SP_CONFIGURE 'ALLOW UPDATES',1 RECONFIGURE WITH OVERRIDE
    GO
    sp_dboption databasename, 'single user', 'true'
    Go
    DBCC CHECKDB(databasename) 
    Go
    sp_configure 'allow updates', 0 reconfigure with override
    Go 
    sp_dboption databasename, 'single user', 'false'
    Go
    试试
      

  3.   

    用了大家的方法,还是不行啊,这2005还真是难搞,我有备份啊,只是10几天前的完整备份!
    配置选项 'allow updates' 已从 0 更改为 1。请运行 RECONFIGURE 语句进行安装。
    消息 926,级别 14,状态 1,第 1 行
    无法打开数据库 'zxfb'。恢复操作已将该数据库标记为 SUSPECT。有关详细信息,请参阅 SQL Server 错误日志。
    消息 5069,级别 16,状态 1,第 1 行
    ALTER DATABASE 语句失败。
    sp_dboption 命令失败。
    消息 824,级别 24,状态 2,第 1 行
    SQL Server 检测到基于一致性的逻辑 I/O 错误 pageid 不正确(应为 1:1988,但实际为 1:2172)。在文件 'F:\zxdata\wsl2\zxfb_Data.MDF' 中、偏移量为 0x00000000f88000 的位置对数据库 ID 5 中的页 (1:1988) 执行 读取 期间,发生了该错误。SQL Server 错误日志或系统事件日志中的其他消息可能提供了更详细信息。这是一个威胁数据库完整性的严重错误条件,必须立即纠正。请执行完整的数据库一致性检查(DBCC CHECKDB)。此错误可以由许多因素导致;有关详细信息,请参阅 SQL Server 联机丛书。
    消息 3414,级别 21,状态 1,第 1 行
    恢复期间出错,导致数据库 'zxfb' (数据库 ID 5)无法重新启动。请诊断并纠正这些恢复错误,或者从已知的正确备份中还原。如果无法更正错误,或者为意外错误,请与技术支持人员联系。
      

  4.   

    -MyDB为修复的数据名
    USE MASTER
    GO
    SP_CONFIGURE 'ALLOW UPDATES',1 RECONFIGURE WITH OVERRIDE
    GO
    ALTER DATABASE MyDB SET EMERGENCY
    GO
    sp_dboption 'MyDB', 'single user', 'true'
    GO
    DBCC CHECKDB('MyDB','REPAIR_ALLOW_DATA_LOSS')
    GO
    ALTER DATABASE MyDB SET ONLINE
    GO
    sp_configure 'allow updates', 0 reconfigure with override
    GO
    sp_dboption 'MyDB', 'single user', 'false'
    GO