第8章 数据库质疑处理.doc

数据库损坏和置疑修复方案 数据库置疑和损坏产生原因 Sql Server数据库本身依赖于操作系统、文件读写存储等环境，数据库经常因为操作系统、异常关机、异常终止退出或者SQL Server数据库本身的机制问题均会导致数据库无故损坏，其中数据库的主要原因如下：FDbMis_Data.MDF和FDbMis_Log.LDF，现在，先将两个文件移除D：\DATA文件夹，当前情况下启动网络服务程序报错如下 启动软件报错 进行正确设置后，还是重复这个错误。这时进入企业管理器发现fdbmis显示置疑状态，然后用数据库分离和附加数据库。去数据库目录下查找发现没有FDbMis_Data.MDF和FDbMis_Log.LDF。或者更改为其他名称了。 这时的解决办法是：找到被移除的物理文件，拷贝到正确的目录下，或者将更改了的名称改回来，放到正确的目录下之后，然后将sql server服务管理器停止，重新启动一下就可以了。 事务日志问题，日志文件误删除，或者日志文件过大，磁盘空间不足，导致数据库置疑 （1）磁盘空间不足，可通过释放磁盘空间暂时解决。日志文件过大，可以先将sql server服务管理器停止，然后将日志文件删除，启动sql server服务管理器。这时fdbmis数据库显示置疑状态。下面设置数据库允许直接操作系统表。用以下语句实现： use master go sp_configure allow updates,1 go reconfigure with override go （2）设置fdbmis为紧急修复模式update sysdatabases set status =-32768 where dbid=db_id(fdbmis)此时，可以在企业管理器中看到数据库为“紧急模式”。 （3）然后，利用以下语句，重建数据库日志文件dbcc rebuild_log(fdbmis,D:\Data\Fdbmis_log.ldf) （4）验证数据库的一致性，dbcc checkdb(‘fdbmis’) 执行结果如下：CHECKDB 发现了 0 个分配错误和 0 个一致性错误（在数据库 FDbMis 中）。 DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。 说明没有问题了。 （5）设置数据库为正常状态 sp_dboption fdbmis,dbo use only,false （6）将第一步中设置的数据库允许直接操作系统表一项恢复。使用以下语句 sp_configure allow updates,0 go reconfigure with override 完成，查看数据库中的数据，已经完全恢复。 突然断电或者数据库读写过程中强制关机，导致数据文件损坏，根据检查数据库损坏程度，如果分析能尝试用修复工具进行修复的话，就用工具尝试 （1）数据库损坏的一般现象为：软件能正常打开，做单据入账时报错，或者查询时，或者日结时报错。日结报错多为以下提示： 系统出现异常！错误信息： No/user/transaction\is\currently\in\progress.ROLLBACK\TRANSACTION请求没有对应的BEGIN\TRANSACTION.确认？ （2）查询分析器中执行检测数据库语句 dbcc checkdb(fdbmis) 结果框中显示结果，最后几行为： CHECKDB 发现了 0 个分配错误和 2 个一致性错误（在数据库 FDbMis 中）。 DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。 （3）利用修复工具DBRepair.exe进行修复 A）将DBRepair.exe拷贝到D：\DATA，执行工具进行修复，设置好 B）然后修复完成后，会提示有哪些表没有成功， 如果是流水明细表如detail002没有成功的话，同时要在新库中删除流水汇总表sum002，（delete from sum002）如果是其他表的话，需要知道是什么表，会丢失什么数据。然后检测新的数据库dbcc checkdb(fdbmi，如果结果显示：CHECKDB 发现了 0 个分配错误和 0 个一致性错误（在数据库 FdbMi中），则说明数据库中没有错误。检查数据库中的表文件中是否都有数据，数据都导入到新表中则说明数据库修复完成。 C）将fdbmis数据库删除，将修复成功的数据库FdbMi好备份，还原为fdbmis，然后找到相同版本的安装盘，进行数据库升级，重建修复过程中可能丢失的存储过程 如果修复过程中遇到其他问题，可以联系我们尝试进行修复