【故障描述】
数据库WINDOWS 2003下的DB2（部门OA系统数据库），RAID故障时表现为两块硬盘离线，操作多次后系统及数据仍无法访问。
【故障分析】
RAID5中两块硬盘掉线很少属于同时离线的情况，两块硬盘掉线的时间间隔少则几天，多则几个月甚至几年，究其原因，主要有两点：一是RAID5在任一硬盘离线的情况下是不影响其自身正常工作的，只是系统负载可能会加重一些；二是服务器及存储一般都位于机房，用户在服务器及存储未出现异常时很少到机房进行巡检，所以即便此时RAID出现报警信息用户也很难察觉。
该案例中损坏硬盘的离线时间很有可能是两个间隔不短的时间点，既然硬盘已经掉线，表明此时硬盘很难继续正常工作，再加上数据库文件对于自身一致性和完整性的严格要求，随机选择硬盘上线REBUILD的操作成功率要远低于50，REBUILD后数据很可能再一次受到破坏，只能依靠第三方提供数据恢复服务来解决。
【恢复过程】
1.首先针对用户提供的4块SCSI硬盘进行严格的物理检测，有2 块硬盘读取缓慢并伴有坏道；
2.分别镜像用户故障RAID组中的4块硬盘，为保证绝对的数据安全，目标存储为带有冗余功能的阵列存储；
3.镜像完成后，对所生成的4个备份文件进行RAID结构分析，依据文件系统存储规则确定4块硬盘在构建RAID5的盘序、数据块大小及校验方式，并于虚拟环境中重新构建RAID组；
4.在确保各种RAID参数完全正确的情况下，对5种不同的掉盘组合情况进行详细比较，发现在任一RAID组合中，实时数据库文件大小均为0（估计系由于更换硬盘反复REBUILD导致文件RUNLIST丢失），而备份数据库则呈现不同程度、不同范围的损坏
5.将5种不同RAID组合情况中的同一数据库备份文件迁移至安全存储，并依据各个备份文件损坏程度及范围的规律性算法通过程序比对生成一个相对完好的数据库备份目标文件D
6.依据DB2备份文件的数据存储特性提取备份文件D中的所有文档，并通过程序提取文档的主题、摘要或关键词信息对文档进行再次命名并做详细的整理分类
7.将恢复的所有数据交于用户验证，用户确认最终百分之八十以上的文档数据得以完整恢复，至此数据恢复完成
【服务器存储安全建议】
1.对存储硬件状态及服务器运行情况做定期检测（存储服务商一般可提供技术支持），发现异常情况时及时采取相应解决方案；
2.在存储出现多块硬盘离线的情况下，切忌贸然对硬盘强制上线或REBUILD，以免数据受到进一步破坏；
3.对于服务年限已久的服务器进行整体运行状态评估以决定是否进行硬件及系统的全面升级，同时提前制定突发数据灾难的紧急处理方案，以降低数据灾难带来的业务损失。
【数据恢复服务承诺】
1 . 免费检测
2. 与客户签订保密协议，对客户的数据严格保密
3. 数据恢复不成功不收费
4. 专业工程师提供服务
5. 数据恢复前报价，客户确认后工程师开始数据修复
6. 整个恢复过程不会对客户的原盘有任何的写操作，以确保原盘的数据完全
存储过程执行突然执行缓慢，问题解决思路?
对于以往执行正常，当前执行缓慢的情况，思路如下：
将存储过程中的语句进行拆分，逐条执行动态SQL，观察执行时间
如果很快，1、需要先了解最近是否有大量新数据导入；2、是否新建索引
获取当前存储过程执行计划A
检查最近是否正常runstats
如果异常先将该存储过程所涉及的所有表runstats
执行存储过程
如果还是缓慢，rebind package重新绑定该存储过程所涉及的包
获取rebind后的存储过程的执行计划B
最后，对比 执行计划A 与 执行计划B
--获得存储过程的包名
1、先指定存储过程名 rpt.aa10001
2、获取 pkgname
select b.*,c.PROCSCHEMA,c.PROCNAME from
syscat.STATEMENTS b, syscat.PROCEDURES c,syscat.ROUTINEDEP d
where b.pkgname=d.bname
and c.SPECIFICNAME=d.SPECIFICNAME
and c.PROCSCHEMA=d.ROUTINESCHEMA
and c.PROCSCHEMA='FLT' and c.PROCNAME='FLIGHTDATA' --指定存储过程名
PS：runstats仅是更新执行计划的一方面（对于动态SQL生效，但对于存储过程无效）；另一方面还需rebind包（对于更新存储过程执行计划方才有效）
--重新绑定包，rebind包
db2 rebind package rpt.P621357
动态SQL立即生效，更新package cache中的执行计划
flush package cache dynamic
对全库package重新绑定
db2rbind dbname -l dbrbind.log all
当你在分区(DPF)数据库里面使用了REDISTRIBUTE DATABASE PARTITION GROUP这个命令，那么就需要用runstats来收集新的统计信息
db2 runstats on table odr.order with distribution and detailed indexes all
如果我们要处理的表数据量是快速变化的，比如在电信移动行业，需要在月末进行处理的汇总表。在不长的时间范围内数据量变化特别大，从而使得RUNSTATS 得到的统计信息不准确，原因是这些统计信息只是某个时间点的信息。
您可以用这条语句来把表修改为volatile alter table table_name volatile cardinality
这样优化器将考虑使用索引扫描而不是表扫描。无论统计信息如何，优化器将使用索引扫描而不是使用表扫描