导致Oracle性能抖动的参数提醒

前言

不知不觉，技术人生系列·我和数据中心的故事来到了第四期。小y又和大家见面了！

当您看到业务系统压测呈现以下波浪形的tps曲线时，你会怎么下手？

小y(中亦科技)今天要和大家分享的就是这样一个业务系统压测性能问题的分析和解决过程。这个问题困扰了客户相当长一段时间，幸运的是，小y通过远程在10分钟定位到了问题的原因并帮助客户最终解决了问题。需要说明的是，在这个CASE中，只调整数据库参数是不够的，还需要做其他分析和调整才可以解决问题。

为了保持原汁原味，同时增加文章的趣味性，小y除了会继续坚持以往分析报告的写法外，会尝试开始引入一些问题处理的心理历程，希望朋友们可以了解到小y的真实工作状态。

我们能学到什么

Ø  Oracle数据库在11.2.0.3及以上的版本上必须要调整的一个重要的性能相关的参数！

Ø  如何在诊断失败后坚持或快速调整问题甄别方向的技巧！

Ø  如何在处理跨团队/部门的综合型问题中掌握主动权的一些经验！

温馨提示

如果您的高并发、事务型的OLTP核心业务系统中中经常会出现一些性能的抖动。比如交易响应时间突然急剧上升,同时伴随着ap服务器端口数/进程活动数/jdbc连接数升高、数据库每秒DB TIME升高等现象，并且Oracle版本在11.2.0.3或以上，那么很可能和该文章提到的一个重要参数有关系哦！如果调整参数后还无法解决，可以联系小y诊断哦(mian fei de)。

你们的点赞和转发就是小y继续坚持分享的动力！

更多Oracle数据库实战经验分享的首发，尽在“中亦安图”公众号！欢迎关注。

Part 1

问题来了

上午10点，QQ突然闪了起来，来活了！

小y,有空吗？帮忙看个awr。

我一会跟你电话说一下情况。

今年他们新上的一个关键业务系统，在做上线前的压力测试时，应用的并发无法达到上线前的并发指标和响应时间指标要求。压测时TPS的曲线如下所示：发来QQ消息的是国内一个大型航空公司的DBA，一般的问题他都可以自己解决，这次看上去他遇到麻烦了。

可以看到，压测时的TPS呈现波浪形，极不稳定。

客户自己做了很多分析，资源层面，CPU、内存使用率、IO均正常，不过客户自己也发现了，压测时后端Oracle数据库中出现了大量的异常等待，主要是gc类型的等待，客户怀疑是不是私网交换机有问题。但可惜的是，网络团队却未检查出异常。

这个问题，他们也请现有的Oracle服务商进行了分析，但问题迟迟没有解决。这样一来，离业务系统要求上线的时间越来越近了，客户的压力也越来越大！

小y最近一直在跟这个客户，从心里真心希望能有机会为他们提供服务，所以这样的机会来了，小y自然是打起了十二分精神，准备开始战斗。

环境介绍：

操作系统Redhat 64   bit，64C 128G

数据库   Oracle   11.2.0.3 ,2节点RAC

Part 2

分析过程

2.1分析Oracle数据库每秒的DB TIME

我们用DB Time除以Elapsed，可以看到每秒DB TIME达到75！这是极度不正常的。

说明数据库正在经历严重的等待，需要查看数据库top等待事件继续分析。

2.2分析交易时间都消耗到哪了（TOP 5 wait event）

1）节点1等待事件如下所示：

事件分析

Ø  Oracle top 5等待里，gc buffer busy acquire排在第一位，占了51.2%，平均每次等待时间达到惊人的277毫秒！这里的gc buffer busy acquire表示在进程A之前已经有进程B先行向节点2请求同样的一个数据块，并且还没有完成，因此处在等待上。