《Oracle数据库性能优化方法论和最佳实践》——1.4Oracle性能优化工作的分类...

本节书摘来自华章计算机《Oracle数据库性能优化方法论和最佳实践》一书中的第1章&＃xff0c;第1.4节&＃xff0c;作者&＃xff1a;柳遵梁　潘敏君　应以峰著&＃xff0c;更多章节内容可以访问云栖社区“华章计算机”公众号查看

1.4　Oracle性能优化工作的分类

在Oracle上进行性能优化时&＃xff0c;不同场景下的优化工作方法和内容有很大的不同。下面从实践角度来展开优化工作的分类。
1.4.1　上线优化或从未达到过性能期望的系统优化
如果业务系统未进行充分的性能测试就上线&＃xff0c;那么有相当一部分会出现性能问题&＃xff0c;不会出现性能问题的系统往往建立在有强大硬件的基础之上。这类缺乏性能设计考虑的业务系统部分或全部具有以下特点。
开发人员&＃xff08;业务系统&＃xff09;假设资源是无限的&＃xff0c;可以任意使用&＃xff0c;忘记了任何系统都是在一个资源受限的系统中运行业务。
开发人员&＃xff08;业务系统&＃xff09;认为只有我一个人在做事&＃xff0c;忘记了同时会有很多人在使用&＃xff0c;缺乏并发性方面的考虑。
开发人员&＃xff08;业务系统&＃xff09;认为程序在任何时候的处理效率都是一样的&＃xff0c;不应该出现大的波动&＃xff0c;不应该出现异常。
各种任务调度频率远远超过业务实际需要。
SQL语句消耗了无限的资源。
无法充分利用资源&＃xff0c;缺乏并行处理或异步处理的能力。
缺乏有效的索引设计&＃xff0c;业务系统并发能力低下。
具有很长的同步处理链条&＃xff0c;性能表现极其脆弱。
运行在默认的完全不匹配物理资源的数据库上。
上线优化的场景有些比较简单&＃xff0c;有些会很复杂。也许你的运气足够好&＃xff0c;仅仅是简单的数据库配置问题或操作系统配置问题&＃xff0c;这在DBA力量比较弱的开发商中存在。更多时候&＃xff0c;你遇到的会是索引优化问题或SQL优化问题&＃xff0c;当然&＃xff0c;只要你愿意付出精力&＃xff0c;总能完成这类任务。如果你运气不好&＃xff0c;遇到除此之外的复杂性能优化问题&＃xff0c;就需要你拥有更多的知识和经验&＃xff0c;以及更好的协调和沟通能力了。
1.4.2　响应速度逐步变慢的系统优化
在业务正常运行了一段时间或很长时间之后&＃xff0c;可能会感觉到业务系统在渐渐地变慢&＃xff0c;甚至到了不可忍受的地步&＃xff0c;而这是Oracle数据库&＃xff0c;或者不仅是它&＃xff0c;也是任何IT设备、任何提供服务的物品以及生命体&＃xff08;包括人动物和植物&＃xff09;都会体现出的特征。这时我们需要对其进行保养、修理或优化。一般来说&＃xff0c;这类系统具有以下部分或者全部的特征&＃xff1a;
随着时间的推移&＃xff0c;数据量渐渐变大&＃xff0c;而业务系统和数据量具有比较强的线性关系设计。
随着时间的推移&＃xff0c;业务在发展&＃xff0c;公司在变大&＃xff0c;而业务系统和业务及资源具有较强的线性关系。
随着时间的推移&＃xff0c;访问量在增大&＃xff0c;而业务系统在并发性上的设计考虑不够。
随着时间的推移&＃xff0c;数据不断被分享使用&＃xff0c;不同业务之间出现并发性和资源上的碰撞。
当然&＃xff0c;可能还存在其他的时间堆积&＃xff0c;但是主要为以上变化度量。既然业务系统性能是一个逐渐变化的过程&＃xff0c;那么只要记录相关指标的长时间关系&＃xff0c;自然就可以知道为什么性能会变差&＃xff0c;甚至可以简单掌握哪些因子的线性关系比较重大&＃xff0c;进而可以通过打破这个线性关系或降低线性斜率来进行性能优化&＃xff0c;使业务系统恢复正常运行。
1.4.3　运行过程中突然变慢的系统优化
在Oracle中&＃xff0c;除了系统bug外&＃xff0c;没有无缘无故的性能问题。即使是Oracle bug&＃xff0c;也是因为变化引起了bug而被触发。对这类问题的优化相对比较简单&＃xff0c;只要简单检测突然变化即可。即使不知道为什么&＃xff0c;只要把变化恢复原状&＃xff0c;一般业务系统就可以恢复。当然&＃xff0c;对于这类业务系统的性能故障&＃xff0c;用户的紧迫度也往往比较高。
应急性性能优化是日常运行中针对业务系统的最为常见的优化工作&＃xff0c;类似于故障处理场景。由于OWI方法所具有的实时针对性&＃xff0c;所以它在这类优化中被广泛利用&＃xff0c;并且效果良好。只要日常收集关键指标及版本变化&＃xff0c;通常都能较为快速地完成应急性优化。
从变化的角度来看&＃xff0c;一般存在以下几种情况。
新的业务模块上线或进行了补丁修复。
SQL语句执行计划发生变化。
DDL操作导致SQL依赖对象发生变化。
意外的配置变化。
依赖资源发生故障或性能降低&＃xff0c;导致吞吐量下跌。
执行了某个意外操作。
某关键进程挂住或死掉。
1.4.4　突然变慢&＃xff0c;持续一段时间后又恢复正常的业务系统优化
本书介绍的发生的现象虽然与1.4.3节介绍的类似&＃xff0c;但其形成原因往往不同。这种业务系统性能降低的场景通常是周期性发作&＃xff0c;维持时间从几秒、几分到几小时不等。一般来说&＃xff0c;发生原因为应用系统无法度过业务高峰期&＃xff0c;达到了吞吐量限制。
针对达到吞吐量限制的业务性能进行优化时&＃xff0c;优化者需要通晓吞吐量与响应时间的关系曲线&＃xff0c;了解各种资源的最大吞吐量或能力限制。扩容往往是针对吞吐量限制型优化最为直接的建议&＃xff0c;但由于涉及额外投资且需要持续较长时间&＃xff0c;因此性能优化者必须有充分的理由来支持扩容&＃xff0c;并且要100%保证扩容后可以满足业务性能的要求。扩容是通过扩展资源来支持更高的吞吐量突变点&＃xff0c;从而完成业务性能的改善。与扩容相对应的另一种方式自然是更加有效地利用资源&＃xff1a;降低单位操作数量或降低单位操作消耗的资源。
1.4.5　基于降低资源消耗的系统优化
事实上&＃xff0c;当针对实际的业务系统进行性能优化时&＃xff0c;你会发现有相当一部分并未观察到明显的吞吐量或未观察到响应时间的异常&＃xff0c;而仅仅是资源消耗达到了非预期值。对于这类问题&＃xff0c;可用于优化的时间会相对充裕&＃xff0c;优化操作也比较简单&＃xff0c;只要简单分析特定资源的影响因子&＃xff0c;并从大到小进行排序&＃xff0c;逐步优化或只优化影响大的影响因子即可。
1.4.6　预防性日常性能优化
基于降低资源消耗的系统优化应该是预防性日常性能优化的一个变种。预防性日常性能优化依赖于日常监测的性能因子&＃xff0c;当这些性能因子达到预先设定的警戒值时就会进行优化&＃xff0c;使其回归到正常范围或减缓其增加速度。想要保证一个系统始终保持高性能的运行&＃xff0c;预防性的日常性能优化是关键因子&＃xff0c;甚至比一种性能设计还重要。作为一个性能优化工作者或运维DBA来说&＃xff0c;虽然业务系统的性能设计不由他控制&＃xff0c;但是尽可能地延缓业务系统性能问题的来临是完全可以的。
预防性优化的作用主要在于&＃xff1a;首先&＃xff0c;延缓业务系统的硬件扩容&＃xff0c;延迟资金投入&＃xff1b;其次&＃xff0c;可以使用户对未来性能预期有一定的明确性&＃xff0c;从而可以合理安排扩容采购窗口&＃xff0c;避免业务系统出现性能问题&＃xff0c;提高服务质量。而缺乏预防性优化意识往往意味着一段时间内糟糕的业务系统性能表现以及硬件扩容的紧急采购。若业务系统预防性的日常性能优化做到位&＃xff0c;则具备图1-8所示的特征&＃xff0c;再次回到吞吐量和响应时间曲线。

预防性性能优化的目的在于不断延缓突变点&＃xff0c;使其后移&＃xff0c;如图1-8中使突变点从1100左右转移到1380左右&＃xff0c;使业务系统可以支持的最大吞吐量不断增加。虽然任何硬件平台和软件平台都会有其自身的吞吐量限制&＃xff0c;但预防性维护可通过延迟硬件采购来节省大量的金钱&＃xff0c;真正体现出性能优化的价值。
下面来做一个简单的计算。
一个价值500万元的硬件平台&＃xff0c;假设将其扩容要求延迟了一年的时间&＃xff0c;因此节约了100万元&＃xff0c;这代表我们并不是仅仅多获得了1年时间的100万现金使用权&＃xff0c;更重要的是这一年时间里硬件的价格会快速下跌&＃xff0c;相比1年前&＃xff0c;100万元具有更高的使用价值。特别是如果到了知识产权严格保护的年代&＃xff0c;硬件的扩容往往意味着软件License授权费用的大幅度增加&＃xff0c;这时预防性性能优化的价值几乎是不可估量的。