DB2故障诊断.pptVIP

IBM Internal Use Only * IBM Internal Use Only * IBM Internal Use Only * IBM Internal Use Only * IBM Internal Use Only * IBM Internal Use Only * IBM Internal Use Only * IBM Internal Use Only * IBM Internal Use Only * IBM Internal Use Only * * 操作系统故障 API故障 分析过程（结论形成和推断）： 　　由于核心系统使用嵌入式C程序，每个程序编译后成为一个独立的可执行程序，每次调用均会先连接数据库、最后再断开数据库连接；通过topas和ps命令发现日终批处理启动了10多个程序，说明日终批处理确实是会在同一时刻发生多次的数据库连接，从而出现CPU使用率高。 分析过程（结论验证）：由于可能存在相似的APAR，为了保证结论的正确性，将进行验证。 * 操作系统故障 API故障 分析过程（结论验证）： 　 * 操作系统故障 API故障 分析过程（解决过程）： 　　向IBM实验室申请基于DB2 V9.1 FP10解决APAR IZ12129的特殊补丁，在3天后下载特殊补丁，并进行安装，常规安装后进行以下操作： 　 * 操作系统故障 API故障 分析过程（解决过程）： 　　客户端操作： 执行b.sh时，CPU最高为30%，日终批处理时CPU降为40%，问题解决 　 * 实例故障 文件系统配置故障 现象：系统响应缓慢、宕机 可能的问题根源： 文件系统速度慢 文件系统不成熟 文件系统权限问题 推荐的解决方法： 使用高速稳定的存储 更换成稳定成熟的文件系统 设置正确的权限 案例：某电信集团数据下发系统（AIX 6.1 + DB2 V9.5 FP5　+　第三方并行文件系统）自上线以来，性能越来越差，时不时会出现短暂的停顿，经检查发现实例目录、数据库目录和活动日志均建在并行文件系统上。将诊断日志目录、数据库目录和活动日志从并行文件系统迁移到本地文件系统，重启完性能大幅提高。 　 　 * 实例故障 参数配置故障 现象：系统响应缓慢、资源消耗大、进程异常、宕机 推荐的解决方法： 根据问题现象调整参数 案例：某股份银行ECM系统（AIX 5.3 + DB2 V9.1 FP3）近一段时间来经常出现db2fmp32进程CPU使用率达100%，系统命令和DB2命令无法正常执行，必须每天早上重启才能维持一天的运行。 分析过程：查看最近一段时间的DB2诊断日志，发现近一段时间每天（早上7时重启数据库）20时30分以后报以下错误 * 实例故障 参数配置故障 分析过程：从以上日志看，DB2内核进程db2sysc在清理IPC 资源时出错，可能是某些DB2进程存在异常。执行ps aux|grep db2发现db2fmp32进程有异常，如下 * 实例故障 参数配置故障 分析过程：正常情况下，停止DB2实例时会终止所有db2fmp32进程，启动实例再启动db2fmp32进程。而从以上日志看有不少db2fmp32的启动时间并非实例启动时间，说明进程db2fmp32在终止应该存在异常。建议设置实例参数KEEPFENCED=NO，确保进程db2fmp32在执行完C存储过程后终止。 　停止实例后，并通过ps –ef|grep db2|awk ‘{print $2}’|xargs kill -9终止所有不能正常停止的db2fmp进程，并设置实例参数KEEPFENCED=NO 后重启实例。 变更后的10多天，系统运行正常，未再进行重启，系统一切正常。 * 数据库故障 数据损坏故障 现象：宕机 可能的原因： SMS文件或裸设备被删除、损坏 存储硬件引起的数据损坏 文件系统引起的数据损坏 推荐的解决方法： 如果表数据损坏，可删除或数据库恢复 如果索引损坏，标记为失效 案例（表数据损坏）：某电信集团仓库系统（AIX 5.3 + DB2 V9.1 FP5）出现访问部分表时数据库宕机，分析日志后，发现大概有3个表访问时出错，出现数据库“DB2 Marked Bad”的宕机错误；重启实例后连接数据库，根据日志中的tablespaceid和objectid定位到相应的表空间userspace1，容器目录为/dkpiinst/dkpi/NODE0001/SQL00001/SQLT0002.0。 * 数据库故障 数据损坏故障 案例（表数据损坏）：表空间录/dkpiinst/dkpi/NODE0001/SQL00001/SQLT0002.0下，执行以下命令判断数据损坏情况： *