服务器型号：IBM3850
硬盘接口：SAS 单盘容量：300G 盘数：8块
简单询问客户得知，服务器由IBM工程师做过硬盘强制上线操作，但没有成功，于是找到我司进行数据恢复。 工程师对8块硬盘一一进行通电测试，发现4号盘有大量坏道，5号盘有少量坏道，判断为4号盘先离线，5号盘因少量坏道，导致最后没有完成事务一致性写入并成功提交至阵列组，造成阵列崩溃。 对8块盘一一镜像，对镜像进行参数分析，此为RAID5类型阵列，经过10多个小时的镜像与分析，成功提取了5个分区1000的数据。虽然4与5号盘先后离线，但依据winhex日志，推测所恢复数据库应无损损坏。 第二天一早，客户与其公司运维服务提供商难证数据，无论是大型软件，还是大压缩包文件，均能正常打开并执行访问等，于是付款取走数据。 第三日，客户致电公司，说数据库附加失败，我司立刻部署了08操作系统与08SQLSERVER，搭好测试环境，附加所恢复数据库，只有本年度3月份以前数据库能正常加载，之后至当机前最新数据库均提示I/O一致性错误--完全出乎意料，数据应该是百分百完好的，如果只用到3月份的数据，客户将损失5个多月的oa及财务数据，是不可接受的。
824错误较为常见，于是进行数据库修复：
但尝试了好多次，均以失败告终，于是告知客户，多给点时间，我司将进行全力课题攻关，一定保证修复数据库。
客户采取双手准备,寻找到北京一家以数据库修复见长的公司，远程修复损坏的三个库文件；同时，也希望我司全力以附，加快进度。
两天后，客户告知北京方面修复了两个库，但数据损失估计有20%左右，虽然成功附加，但金谍系统客户无法登录，估计是用户数据表丢失。要求我司务必全力修复数据库，尽量减少数据记录损失。 经过2天多的努力，我司经过遂一磁盘检测校验，文件无效表删除及ID重建，成功修复了三个库，中间提示无任何数据纪录损失。于是携带数据，来到客户现场，进行了库附加，一次成功。对方IT人员以管理员身份成功登录进系统，立刻通知行政，财务，园林设计各部门登录系统，验证数据，各部门员式均表示已能登录进系统，且最后工作存档都在，我方人员方才松了口气。客户在古尔邦节后第一天，公司各项工作就得以正常运行，对我司的敬业和高度的责任心，表示了赞扬。 此恢复案例的特殊之处在于，同一分区内，其他所有数据类型，均能正常打开，提取数据库文件时，亦无任何异常日志记录提示，完全没有想到会走到数据库修复这一步，发展到了修复数据库这一步，也没有想到常规的824错误，平时的修复手段也没有见效。真是非常罕见。幸运的最终修复了所有数据库，而且没有数据记录损失。
