有人说是数据库表坏了，没动过，哎，不懂，求大神帮助

SQL Server 检测到基于一致性的逻辑 I/O 错误 校验和不正确

ALTER DATABASE CDBW_DDH_TMP/*数据库名称*/ SET SINGLE_USER   --设置为单用户

DBCC CHECKDB ('CDBW_DDH_TMP', repair_allow_data_loss) with NO_INFOMSGS   --允许丢失错误

go

ALTER DATABASE CDBW_DDH_TMP SET MULTI_USER   --设置为多用户

go

如果执行失败，把上面的SQL语句放到temp数据库运行，修复成功后，接着再把temp中的produce表导入CDBW_DDH_TMP中。

网页链接

简单情况下：进入原来mysql安装路径下的data文件夹下，找到相应的库和ibdata1，进行copy，就可回复原来的数据。

复杂情况下：

从另一台机上把MySQL数据库的mysql文件夹拷贝到本地机上，目的是恢复本地机对数据的访问和 *** 作。经过如下几种情况的 *** 作。

1. 在本地重装MySQL（安装目录D:\Program Files\MySQL\MySQL Server 5.0），直接把mysql文件夹拷贝至D:\Program Files\MySQL\MySQL Server 5.0\。结果，失败：数据库连接错误。

2. 卸载后重装MySQL，将D:\Program Files\MySQL\MySQL Server 5.0\下的数据备份，只把mysql\data文件夹全部内容拷贝到D:\Program Files\MySQL\MySQL Server 5.0\data下。结果，失败：数据库连接错误。将备份的数据还完覆盖。结果，失败，还是连接不上数据库。

3. 卸载后重装MySQL，将mysql\data文件夹里的cf1,last文件夹（这两个是原来MySQL里的数据库）拷贝进D:\Program Files\MySQL\MySQL Server 5.0\data。连接成功，在Navicat for MySQL里看到数据库cf1和last，但是不能访问，因为数据全为零。明白了原来data里以数据库命名的文件存储的是数据库的表结构，不是元数据。下一步，把data文件夹里的ibdata1文件（3.4G大，明显存储了元数据）拷贝到D:\Program Files\MySQL\MySQL Server 5.0\data里，代替原来的ibdata1文件。重启电脑，打开Navicat for MySQL，连接成功，数据可以访问 *** 作。

至此， *** 作终于成功。其实当初在那台机上把数据导出来，而不是现在直接把文件夹mysql复制过来会更容易恢复。但那台机已经重装了系统，也就是说MySQL失效了。

sqlserver附加数据库错误823的解决方案

一、SQL-Server附加数据库时失败。

1、异常情况：服务器在正常运行的情况下突然断电，导致数据库文件损坏，具体表现是：数据库名后面有“（置疑）”字样。

2、异常分析：关于823错误的 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

---