【IT168 专稿】本文根据【2016 第七届中国数据库技术大会】现场演讲嘉宾周亮老师分享内容整理而成。录音整理及文字编辑IT168@ZYY@老鱼

　　讲师简介

▲周亮　

　　老A，杭州美创科技首席DBA，10年以上Oracle运维经验。Oracle ACE，OCM。中国南方Oracle用户组发起人。《Oracle DBA实战攻略》作者，《Oracle运维之道》作者，《Oracle数据库性能优化方法论和非常好的实践》审校。擅长高容量、高并发的数据库架构设计、运维、故障诊断、性能优化及数据灾难挽救工作。

　　正文：

　　大家好，我叫周亮，来自杭州美创。我们公司服务和产品主要包括数据库服务，数据库容灾、数据安全以及大数据。今天我演讲的主题是“Oracle数据库性能优化之道”。

　　我想大家经常用oracle多少都会有一些自己的疑惑吧，可能觉得oracle数据库性能优化是比较复杂的事情，因为oracle性能优化不像处理普通的数据库性能问题。Oracle作为商业化数据库，几十年发展至今，有着极为完善的错误定位机制。普通的数据库问题基本上都会是报错，也就是说它们相对都有比较明确的错误提示。所以从我的经验角度来讲，这种错误对新手来讲只要给他时间，只要给他能够上网，基本上都能判断出问题的方向。当然相对比较奇怪的错误就是另外一回事了。今天我们要讲的是数据库性能优化之道，Oracle数据库性能错误往往不报错，这对于数据库运维新手来讲，3年以内(个人工作经验)可能都不知道问题出在哪，这是最致命的。

　　我是做乙方的，有时候很多甲方的水平有限，数据库出现性能问题时，他都不知道问题出在哪。这时候疾病乱投医，这时候就有很多所谓的性能优化专家被跳了出来。比如业务最近很卡，应该怎么解决。软件开发商可能会说我的业务在其他用户那里都运行的很流畅，而且业务量比你这里大很多，配置比你低，但只有你这里很卡，这肯定不是我的问题，我的软件运行的很好。

　　再比如说社保行业客户，虽然社保政策每个地方都大同小异。当数据库出现性能问题时，我们大多数的社保业务厂商都这样跟我说：我的业务程序在某某那里运行的很好，就在你这里不行，肯定是数据库的问题，他就这样否定了他的问题。那么既然不是软件问题，那就是硬件问题吧。因为数据库性能出现问题时，往往CPU资源或者I/O资源不足。所以硬件厂商就跳出来，买新硬件吧!配固态硬盘!在某些业务场景上，固态硬盘确实能解决一些问题，为什么能解决一些问题呢?因为大家都可能没有意识到凡是写的不好的业务程序系统资源的瓶颈往往在I/O上或者CPU上，而且但大部分情况下是在I/O，固态硬盘让I/O响应时间从毫秒变成了微妙。所以在I/O响应敏感的系统上固态硬盘感觉好像是解决了这个问题。但我们往往碰到的场景是：数据库性能不好，但CPU资源90%以上空闲，存储的I/O资源也很空。既然硬件资源很空闲，所以肯定不是硬件的问题，刚才软件厂商说不是软件的问题。那么好，肯定是数据库的问题了。数据库往往就成为一个背黑锅的角色，这就需要我们介入，这都是经常碰到的案例场景。

　　我们团队手头上有1500套数据库，从运维角度来讲，我们不可能对每套数据库的业务系统或者运行节奏都很了解。或者说一个新的客户客户出现性能问题时，在性能优化工作之前我们肯定需要做一些咨询工作，从我的经验来讲我通常会问以下几个问题：

　　1、业务系统。因为我们接触的业务系统领域比较多，所以也基本熟悉业务特征，也就是说每个业务系统都有它的运行节奏在里面。比如社保业务节奏和医院业务节奏虽然有区别的，但由于社保业务和医院业务很多业务是相挂钩的。比如医院业务的特性是早上八点由于办理挂号业务是比较繁忙的，八点到九点可能收费等会变的比较忙。由于这种特性，所以我会问是什么业务系统，他回答的业务系统刚好在我熟悉的领域里，我心里就基本有数了。

　　接下来我会通常问业务出现性能问题时局部变慢还是全局慢。因为局部变慢还好说，往往可能是系统资源争用、局部争用引起的。而全局变慢可能就是硬件资源不足或者系统I/O故障。举个例子，我们经常跟硬件厂商打交道，所以必须要对存储I/O的响应时间心里有数。随着存储越来越高端，不考虑缓存命中的情况下，一个I/O的平均响应时间通常是5毫秒左右，如果超过10毫秒到20甚至到40毫秒以上，那么存储I/O链路内部肯定是有问题的。但郁闷的是，这个时间往往存储是不报错的，这时候硬件厂商就无法查知问题所在，所以说I/O链路比较堵时，业务变慢属于全局慢。对于一些厂商来说，变慢也是有规律的，比如月初很多通信厂商出账时，业务可能相对比较慢。

　　2、评估机器配置。把控好行业特性和业务节奏的前提下，评估机器配置，机器资源的使用率如何等问题，因为主机资源忙和不忙是两种不同的性能处理方法。

　　3、变更管理。最近有没有发生变更是一个非常关键的问题，变更包括硬件升级、存储的微码升级、代码升级等等，因为从理论上讲数据库所有性能的变化都是由变更引起的。没有变化，就没有故障。

　　4、基线管理。有一份业务正常的AWR报告对于性能优化来说也是很重要的，因为比对业务正常的AWR报告，很多性能问题都可以比较出来，尤其是在没掌握这套系统平常的业务情况时，我通常只要比较相同时间点，相同的业务在做的时候的AWR报告，基本的问题方向就会出来。

　　数据库的性能问题的根源是等待，所以说等待引起了数据库性能问题。Oracle据此也推出了各种等待事件。DBA们可以通过研究OWI知道数据库的性能慢在哪里。但Oracle OWI有它自己的缺陷，它只会告诉你数据库慢在哪个环节，而且#FormatImgID_1#只是一个局部的观点看问题。

　　等待分两种，一种是顺序等待。比如在中国政府里办事就要走很多流程，一个章盖完要去另一个地方盖章，这就是顺序等待，每个部门之间要严格按照上个部门的章来决定这个部门做什么，所以说顺序等待会导致很长的同步列表;另一个是无序等待，可能会导致资源冲突。无序的等待导致大量的进程、会话涌进来做同样一个事情。

　　举个简单的例子，大家开车的时候应该有过这种感觉，前面是红灯，比如等一个灯次要10秒钟，像北京很堵，过一个路口我可能要等10个灯次，我等待红绿灯时间不会简单的10乘以10，也就是说这个时间肯定远远大于100秒，可能要200、300秒。原因是在前面等红绿灯的时候很多车辆会插队，在进行冲突。所以这就是为什么每个红绿灯前面都禁止实线变道，说白了也是不要让大家发生冲突。

　　顺序等待会导致很长的同步列表，无序等待会导致资源冲突，怎样解决这些问题呢?很简单，减少等待时间。第一、减少请求延时，比如说10秒钟做的事情压缩到5秒。第二、减少资源冲突，即增加资源，或者分散处理。

　　减少延时有很多方法，这是几种比较常规的方法：

　　1、增加CPU的计算能力。这里扯开一点题外话，网上的很多文章都把IBM POWER CPU和至强CPU进行比较，但很多文章都是在比较没有并发处理的时候，一个CPU处理了多少逻辑运算。很少有文章比较，当有32个活动会话往上压的时候，它的冲突管理或上下文切换能力哪个强，这才是OLTP系统要考虑的东西。但从我的工作经验来讲，当很多进程往上压的时候，POWER芯片的上下文切换管理能力要比X86好20%左右。

　　2、减少网络请求延迟。比如千兆网络升级到IB网络。其实很多时候数据库出现性能问题，网络往往不是瓶颈，为什么好多年前就有的IB网络最近几年才火起来?我想很大一部分原因是闪存的出现。机械硬盘主要慢在机械臂的摆动上，和其他主机资源比起来，I/O的响应时间相对较慢，水桶能装多少水取决于它最短的那块木板。所以IB网络的出现感觉并没有太大的优势，因为千兆网络已经足够了。一个请求发过来，网络很快就发到存储上面，是存储在拖慢整个响应时间。闪存推出之后，直接把机械硬盘的响应时间从毫秒变到微妙，这时网络就可能成为拖慢计算机的原因。所以，这时候IB网络由此焕发了第二次青春。

　　3、减少IO方面的请求延时。使用裸设备，这是一个很古老的性能优化方法，使用裸设备确实会比使用文件系统快一些，但也没有快很多，除非是大量的并发I/O下发时会快的明显一点。因为裸设备比文件系统的IO执行路径要短很多，系统调用要少很多。其次，是使用闪存替代机械盘，或者说使用Oracle二级缓存特性。我个人比较推荐不要把数据文件直接放在闪存上，除非你的闪存做了很好的冗余，可以考虑。我个人相对比较保守，我通常把数据文件放在机械盘上面，然后打开Oracle数据库二级缓存特性。这样的话对于业务响应速度也会快很多。还有一个相对比较重要的是，但如果你的系统I/O压力比较大，我建议大家使用闪存卡的时候，调大磁盘的队列长度和队列深度。很多时候问题集中在队列长度和队列深度不够上。

　Mutex争用是比较常见常见的性能问题。每条sql执行之前，首先会访问一下handle，检查有没有相应的sql在里面。类似很多哈希值相同的数据块挂载在同一条hash chain一样，相同hash值的SQL都会挂载在同一个handle链条里面，不停地扫描这个handle会导致这个handle很热。尤其是Oracle11g推出了自适应游标之后，我们应该怎样解决这个问题呢?

　　第一，不要让子游标太高，幸好Oracle有参数可以调整，可以通过参数调整，不产生这么多子游标。

　　第二，当有很多相同哈希值的sql放在同一个列表里时，也可以把它打散，oracle10和11都可以通过参数调整把它打散。当然以前我不知道有参数调整的时候，用了一个比较土的办法，同样的select* from…这样一条sql语句，假如有100条进程都在执行这样的sql时，大家同时扫一下这个handle就会很热，我之前用的土办法是在sql中间加个hint，加完之后，Oracle一算哈希词就会发现，第一个sql对应一个handle，第二个sql可能就对应着别的handle，这样就可以把SQL打散到数据库其他handle了。

　　锁资源在很多应用上会产生很多冲突。很多时候锁资源只是一个表象，比如I /O慢导致执行慢，进而导致锁资源冲突的概率就大了。比如你本来的执行计划是索引读(假设索引读优于全表扫)，由于执行计划突变，索引读变成全表读，就会导致变慢。所以说加快执行速度很大情况下能够改善锁资源。

　　除此之外，改善业务逻辑。详见PPT中的案例。

　　数据库性能优化还有很多方面，今天我讲的都是突发性能故障处理。在这里再强调一下，我们心里应该要清楚地知道每个硬件的吞吐量指标，他的性能拐点在哪里?另外，处理突发应急故障的时候，要有一个正常情况下的AWR报告与其进行前后对比，对比之后就有方向了。

　　由于时间关系。我的分享到此结束，谢谢大家!