一、SQL-Server附加数据库时失败。 异常情况：服务器在正常运行的情况下突然断电，导致数据库文件损坏，具体表现是：数据库名后面有“（置疑）”字样。 ================================错误 823 严重级别 24 消息正文 在文件 "%4!" 的偏移量 %3! 处的 %2! 过程中，检测到 I/O 错误 %1!。解释 Microsoft SQL Server 在对某设备进行读或写请求时遇到 I/O 错误。该错误通常表明磁盘问题。但是，错误日志中在错误 823 之前记录的其它核心消息应指出涉及了哪个设备。 3、解决办法： 在SQL-Server企业管理器中，新建同名数据库（这里假设为Test）后，停止数据库，把损坏的数据库文件Data.mdf和Test_log.LDF覆盖刚才新建数据库目录下的Data.mdf和Test_log.LDF，同时删除Test_log.LDF文件；启动数据库服务，发现数据库名Test后面有“置疑”字样。不要紧，打开SQL自带查询分析器，分别执行如下SQL语句： 第一、 exec sp_configure 'allow updates',1 RECONFIGURE WITH OVERRIDE /* 打开修改系统表的开关 */ 第二、 update sysdatabases set status=32768 where name='数据库名' /* 设置数据库状态 */ 第三、 DBCC REBUILD_LOG ('数据库名','D:\database\Test_Log.LDF') /* 重建LDF文件 */ 第四、 update sysdatabases set status=0 where name='数据库名' /* 重置数据库状态 */ 第五、 restore database 数据库名 WITH RECOVERY /* 恢复数据库 */ 第六、 exec sp_configure 'allow updates',0 RECONFIGURE WITH OVERRIDE /* 关闭打开修改系统表的开关 */ 按照此方法操作，应该能修复数据库正常访问了。如果问题依然存在，最笨的一个方法就是新建另一个数据库，把原数据库（Test）各个表的数据导出到新建数据库表中。 ============================================================ 补充说明：用上面的六步把数据库置疑的问题解决了，但是数据库表里还有损坏的表(inf_gdscode)，把坏表导出的时候也不成功。最后在查询分析器里运行：USE nmgbt_hcxuexipos (数据库名) GO DBCC CHECKTABLE ('inf_gdscode',REPAIR_ALLOW_DATA_LOSS) GO
-- 解决方法： -- 假设数据库名为：Test -- 先创建一个同样的数据库Test -- 停掉server服务，用旧的数据文件覆盖新创建的文件（只要mdf就可以）。 -- 启动server服务 -- 运行以下命令 sp_configure 'allow',1 go reconfigure with override go update sysdatabases set status=32768 where name='Test' go dbcc rebuild_log('Test','D:\database\Test_Log.ldf') go update sysdatabases set status=0 where name='Test' go sp_configure 'allow',0 go reconfigure with override go dbcc checkdb('Test') go --若发现有错误，还要进一步找出出错的地方，可以先检查 -- DBCC CHECKTABLE (sysobjects) -- DBCC CHECKTABLE (sysindexes) -- DBCC CHECKTABLE (syscolumns ) -- DBCC CHECKTABLE (systypes)
删除这个库,找到最开始的LDF,MDF,然后附加.
异常情况：服务器在正常运行的情况下突然断电，导致数据库文件损坏，具体表现是：数据库名后面有“（置疑）”字样。
================================错误 823
严重级别 24
消息正文
在文件 "%4!" 的偏移量 %3! 处的 %2! 过程中，检测到 I/O 错误 %1!。解释
Microsoft SQL Server 在对某设备进行读或写请求时遇到 I/O 错误。该错误通常表明磁盘问题。但是，错误日志中在错误 823 之前记录的其它核心消息应指出涉及了哪个设备。
3、解决办法：
在SQL-Server企业管理器中，新建同名数据库（这里假设为Test）后，停止数据库，把损坏的数据库文件Data.mdf和Test_log.LDF覆盖刚才新建数据库目录下的Data.mdf和Test_log.LDF，同时删除Test_log.LDF文件；启动数据库服务，发现数据库名Test后面有“置疑”字样。不要紧，打开SQL自带查询分析器，分别执行如下SQL语句：
第一、
exec sp_configure 'allow updates',1 RECONFIGURE WITH OVERRIDE /* 打开修改系统表的开关 */
第二、
update sysdatabases set status=32768 where name='数据库名' /* 设置数据库状态 */
第三、
DBCC REBUILD_LOG ('数据库名','D:\database\Test_Log.LDF') /* 重建LDF文件 */
第四、
update sysdatabases set status=0 where name='数据库名' /* 重置数据库状态 */
第五、
restore database 数据库名 WITH RECOVERY /* 恢复数据库 */
第六、
exec sp_configure 'allow updates',0 RECONFIGURE WITH OVERRIDE /* 关闭打开修改系统表的开关 */
按照此方法操作，应该能修复数据库正常访问了。如果问题依然存在，最笨的一个方法就是新建另一个数据库，把原数据库（Test）各个表的数据导出到新建数据库表中。
============================================================
补充说明：用上面的六步把数据库置疑的问题解决了，但是数据库表里还有损坏的表(inf_gdscode)，把坏表导出的时候也不成功。最后在查询分析器里运行：USE nmgbt_hcxuexipos (数据库名)
GO
DBCC CHECKTABLE ('inf_gdscode',REPAIR_ALLOW_DATA_LOSS)
GO
-- 假设数据库名为：Test
-- 先创建一个同样的数据库Test
-- 停掉server服务，用旧的数据文件覆盖新创建的文件（只要mdf就可以）。
-- 启动server服务
-- 运行以下命令
sp_configure 'allow',1
go
reconfigure with override
go
update sysdatabases set status=32768 where name='Test'
go
dbcc rebuild_log('Test','D:\database\Test_Log.ldf')
go
update sysdatabases set status=0 where name='Test'
go
sp_configure 'allow',0
go
reconfigure with override
go
dbcc checkdb('Test')
go
--若发现有错误，还要进一步找出出错的地方，可以先检查
-- DBCC CHECKTABLE (sysobjects)
-- DBCC CHECKTABLE (sysindexes)
-- DBCC CHECKTABLE (syscolumns )
-- DBCC CHECKTABLE (systypes)
用这个方法解决了质疑问题,在查询分析器里可以看到表,但是打不开表,想导出数据也不成功:用DTS导出1.从源数据库复制表和视图提示:上下文,在提供程序上调用openrowset使出错.2.在sqlserver数据库对象直接复制对象和数据提示:由于数据移动,未能继续以NOLOUCK方式扫描.
checkdb 的时候提示:未能读取并闩锁页 (1:156)（用闩锁类型 SH）。sysindexes 失败。DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
已将配置选项 'allow updates' 从 0 改为 1。请运行 RECONFIGURE 语句以安装。（所影响的行数为 1 行）警告: 数据库 'mhyk' 的日志已重建。已失去事务的一致性。应运行 DBCC CHECKDB 以验证物理一致性。将必须重置数据库选项，并且可能需要删除多余的日志文件。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。（所影响的行数为 1 行）DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
已将配置选项 'allow updates' 从 1 改为 0。请运行 RECONFIGURE 语句以安装。
服务器: 消息 8966，级别 16，状态 1，行 1
未能读取并闩锁页 (1:156)（用闩锁类型 SH）。sysindexes 失败。
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。