商业源码 SQL2000断电置疑，停止sql服务后，ldf文件复制没任何问题，mdf文件复制提示“数据错误，循环冗余检查
一、正规的SQL服务器需要UPS电源，以保证数据能尽可能不出错的写入到服务器中。至少要求网络交换设备断电先于服务器断电。
二、你这种情况，服务器数据已受损了，不一定能解决，当然，也不排除你运气不错。可以参考下面的操作：
1、新建一同名数据库（文件名，文件组都和原来的一样），然后停止数据库服务，用原来文件替换新建的数据库文件，启动数据库，该数据库被设为suspect
2、把数据库改成紧急模式：
sp_configure 'allow', 1
reconfigure with override
update sysdatabases set status = 32768 where name = '数据库名'
3、把LDF文件改名，再执行
DBCC REBUILD_LOG ('数据库名', 'E:\fdzz\database\fdzz1204_LogLDF' )
4、恢复数据库紧急模式
update sysdatabases set status = 0 where name = '数据库名'
执行
restore database 数据库名 WITH RECOVERY
sp_configure 'allow', 0
reconfigure with override
5、然后用DBCC CHECKDB ('数据库名')看看有没有错误
6、如果上面还是不行，试试吧数据库设为紧急模式，应该可以看到数据了，在把数据导出到一个新的数据库。
服务器数据恢复工程师对客户的服务器进行了初步检查，检查结果与客户描述及故障推测一致，服务器数据丢失的原因确实与异常断电有关，由于突然断电导致了启动信息丢失，另外客户服务器上的数据库也受到了破坏。想要恢复数据除了修复linux操作系统外还需要整理数据库碎片，修复数据库。
服务器数据恢复过程
服务器数据恢复工程师将客户服务器内的所有数据都按扇区备份到专用服务器上，将客户原始服务器状态复原，开始在专用服务器上进行数据分析和恢复。
linux系统修复后尝试启动服务器，服务器成功启动，但数据库无法启动，印证了之前工程师推测的数据库数据遭受破坏的推断。
数据恢复工程师继续分析数据库碎片数据，修改数据库错误数据，尝试修复并挂起数据库，最终成功恢复服务器内的数据库数据。交由客户对所有数据进行验证。
服务器数据恢复结论
经过客户对恢复数据进行验证，确认服务器及服务器上的数据库数据恢复完整、准确，本次数据恢复圆满成功。
服务器数据恢复后记
1、服务器故障后应避免随意拔插硬盘，避免硬盘盘序混乱。
2、避免对需要恢复数据的服务器进行写入和修改操作。
3、求助专业服务器数据恢复公司的专业服务器数据恢复工程师，切忌在未备份的情况对服务器进行操作。
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）后，停止数据库，把损坏的数据库文件Datamdf和Test_logLDF覆盖刚才新建数据库目录下的Datamdf和Test_logLDF，同时删除Test_logLDF文件；启动数据库服务，发现数据库名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_LogLDF') / 重建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
0条评论