数据库异常处理技术汇报.doc

数据库异常处理 技术报告 文档控制 修改记录 日期 作者 版本 修改记录 审阅 姓名 职位 目录 背景概述 1 报告内容 2 技术细节 3 数据库CRASH 3 数据库性能不理想导致业务停顿 4 数据库挂起 6 关键业务由于持续错误无法完成工作 7 结论 8 附录 9 背景概述 在日常数据库维护过程中，经常遇到数据库CRASH，数据库一些性能问题，数据库HANG，某些关键业务无法正常完成。一般出现这些问题后，为了保障业务正常运行，经常直接重新启动数据库。这样无法保留当时的数据库的一些状态信息，在后期进行问题分析的时候有很大的难度。经常是一个问题不了了之。 报告内容 在该报告中，会针对数据库的各种不同异常情况，在出现这种情况下，应该做那些相关的信息收集。通过收集的信息判断数据库在不同异常情况下暴露的问题，提供相关的技术手段避免问题的再次发生。 该报告分析数据库在下列四种情况下发生异常时要做的分析操作： 数据库CRASH 数据库性能不理想导致业务停顿 数据库挂起 关键业务由于持续错误无法完成工作 技术细节 数据库CRASH 当数据库CRASH后，整个数据库服务已经完全停止。这个时候请查看数据库警告日志，检查是否有对应的TRACE文件生成。收集数据库TRACE文件，RDA报告。如果客户购买有ORACLE的标准服务，针对该问题创建一级TAR。 具体处理流程如下 数据库CRASH相对来说是一个综合问题，导致数据库异常CRASH有很多钟情况。一般如果由于是硬件原因导致，那么数据库很难在短时间内启动。那么要确认数据库有没有很完善的备份策略。 如果是数据库软件配置问题，可以调整部分参数，在短时间内将数据库启动。 数据库性能不理想导致业务停顿 在某些特殊情况下，数据库性能急剧下降，部分应用大量消耗系统资源。严重时导致整个系统运行缓慢。在这种情况下，对数据库做相关的下列操作。 1 如果是CPU/Memory紧张，用glance/topas检查top process 消耗时间1分钟 如果alert_sid.log文件有出错信息，找出问题关键的session id/ OS process id 消耗时间1分钟 如没有OS/DB出错信息，使用脚本检查两阶段事务和lock handle事务。然后使用event 10046/10053采集sql plan 消耗时间5分钟 使用statspack来收集数据库性能报告， 如果系统性能极低，。 Snap间隔5分钟。 然后做hanganalyze dump,间隔90秒。 消耗时间10分钟 2 (3a)如果top process不是数据库服务器进程，立即kill -9 ospid (如果是oracle应用进程则在执行kill -9前先做收集processstate dump信息) 消耗时间2分钟 (3b)如session id没有指向数据库服务器进程，收集processstate dump信息然后立即用kill session命令关闭这个数据会话 消耗时间2分钟 (3c)删除pending两阶段事务和lock handle事务。收集processstate dump信息然后用kill session命令关闭这个数据会话 消耗时间2分钟 3 观察业务情况，如没有解决则重复step2,3 4 如果问题长时间未能排除，建议重新启动数据库 5 收集trace文件 6 生成RDA报告和STATSPACK报告 7 使用OSW收集CPU/Memory信息，oracle alert文件 2分钟 收集事物状态 收集两阶段事务 SELECT local_tran_id FROM dba_2pc_pending; Execute dbms_transaction.purge_lost_db_entry(LOCAL_TRAN_ID); Commit; 收集某个进程的信息 10046主要是对应在数据库使用基于规则模式下的统计信息，10053主要对应数据库使用基于成本优化模式下的统计信息。 Event 10046: Sql oradebug setospid [pid] Sql oradebug unlimit Sql oradebug event 10046 trace name context forever,level 12 sql oradebug event 10046 trace name context off Event 10053: Sql oradebug setospid [pid] Sql oradebu