数据库性能问题处理及监控解析.docVIP

`数据库性能问题处理及监控 思想重视 掌握方法 主动学习 善于协调 一、培训背景 系统性能是功能的延伸和深化。从某种程度上说，性能问题比单一的功能问题对客户造成的影响更大、更深、更恶劣，没有人愿意使用功能完备却性能糟糕的系统。改善和提升客户的系统操作体验，提高产品及客户服务满意度，系统的优异性能必不可少。从技术层面来说，这需要通过良好的数据库结构设计及应用程序架构设计来保证。 然而实际上，无论前期做多么的周密设计，都无法保证系统在客户实际使用过程中持续优良的性能。随着业务的提升，功能和数据也随之膨胀，性能稳定的挑战越来越大。此时，就需要现场系统维护人员迅速跟进并做有效的问题处理。 二、培训目的 明确系统维护人员性能问题处理的职责分工 明晰数据库性能问题的处理流程 性能调整需要团队协作，涉及DBA、操作系统管理人员、网络管理人员、应用程序设计及开发人员、应用系统现场维护人员等岗位 性能调整方法：调整业务功能、调整数据设计、调整过程设计、调整SQL语句、调整内存分配、调整IO、调整资源争用、调整OS 现场人员性能调整工作的角色分配：调整业务功能、调整SQL语句 明确、清晰的问题处理流程，可以规范问题处理步骤，缩短问题处理时间最小化性能问题的影响，有利于缓解后期解决问题的压力，进而促进问题的最终解决！ 三、数据库性能故障处理流程 所谓数据库故障，简单讲就是数据库响应缓慢甚至不能响应客户端发起的请求。例如，客户端提交一个SQL请求后，会话处于等待数据库实例返回结果的状态。很多现场情况下，用户有7*24的运行需求。在系统突然遭遇性能问题时，我们并没有时间去收集数据，对比统计数据，进行索引分析和调整操作。 此时，需要几分钟或者几十分钟内解决这样的突发性能问题，我们工作重点应该是迅速确定发生了什么问题，并尽可能快速的恢复正常服务，严谨的优化方式并不现实。因此，应该先处理问题，再研究问题。 如何处理问题 ？没有简单答案！性能调整的普遍规则并不存在，但制定一个规范的工作流程和实施步骤是切实可行的。性能问题千差万别，需要有一个符合实际情况的性能问题处理的流程图，作为性能问题搜寻的方法指导。否则，由于性能问题分布在系统的各个层面，性能调整就会变成大海捞针。 在OS层面杀死异常进程的操作简单说明如下： 首先，根据sid查找系统进程号spid select spid, s.sid, osuser, s.program from v$session s, v$process p where s.paddr = p.addr and s.sid in (sid1, sid2) 然后，简单浏览一下osuer、program列是否和应用程序相关。慎重考虑之后，在OS层面通过kill – 9 pid 操作（pid是上一步查询出来的spid）杀死进程之前，最好再用ps -ef|grep pid 看一下最后一列，如果显示 (LOCAL=NO)则可以考虑杀死， 如果是 (LOCAL=YES)的则不要杀死。 需要引起注意的是，对于现场系统维护人员来讲，为避免不当操作引起的性能故障，在日常工作中需要注意做到正确的维护操作： 应避免在业务高峰时做大的维护操作，一些DDL操作比如像加主外键约束、alert、create index、rebuild index…online compute statistics、grant、revoke 、compile、analye、dmbs_stats…. 上述语句的一个共同点就是可能会使库缓存中解析过的SQL失效、会使存储过程等对象失效，进而发生重编译引起执行计划的改变。这些操作可能会导致一个繁忙的业务系统的灾难性事故。如果大量的SQL同时失效，同时重新解析，就可能导致严重的内存竞争及CPU消耗，进而导致数据库挂起。 四、发现及监控数据库性能问题 数据库作为整个应用系统的数据核心，可能是主要的性能瓶颈。为保证数据库良好的运行状况，有效的日常监控必不可少，不要等待问题出现才去关注。 性能调优可用的基本监控工具包括： Em页面、动态性能视图（v$视图）及数据字典、警告日志、跟踪文件、快照等 性能问题监控没有简单的答案，太多的脚本只会加重问题的复杂性。动态性能视图需要对Oracle数据库有很深入的理解。优化本来应该是简单的，em工具是一个图形的用户管理界面，我们可以使用它方便地进行数据库管理而不必记住复杂的Oracle数据库管理的命令，减少监控的复杂度。 实际登陆em，展示利用该工具监控TOP SQL、锁、未绑定变量的SQL的方法。 访问数据库主页： 五、SQL优化相关 六、培训总结 系统性能调优是一个庞大的课题和系统性工程，对现场人员来讲，性能问题的处理不仅仅是技术上的事情。一方面系统性能调优需要对应用、数据库、操作系统等有广泛而深刻的理解