前阵子看到一个网友发的一个AWR报告，当时并没有说系统存在什么问题。也有一些朋友对此好奇，分析了一些问题。我简单看了一下，这个系统的每秒执行数高达70万+，CURSOR方面的争用挺厉害的。这种负载泡在Oracle 11.2.0.4上效果还是不错的，如果是Oracle 10.2或者更低版本,很可能数据库的性能会更差一点。
从Load profile上我们可以看到很多信息，首先是REDO量并不大，4.5M/秒都不到，事务数1529还是挺高的，不过事务都不大，每个事务redo 3K左右。每秒解析1.1万+，硬解析1247。无解析执行比例还挺多，说明数据库的一些和CURSOR相关的参数设置还是合理的。SQL也大多使用了绑定变量，并且执行计划也相对稳定。
接下来看一下影响实例性能的一些主要的命中率指标，Parse Cpu 头 Parse Elaspd的百分比是41.85%，对于这种解析数量比较高的系统来说，这个指标往往会偏低，这个指标越低说明解析中的等待越多。这个系统的软解析比例不到90%，这一点在Load Profile里已经能看出来了。Non-Parse CPU是89.85%，说明解析消耗了10%左右的CPU资源。这个指标偏低了，一般系统中都会在95%以上，不过指标异常并不一定说明存在问题，因为本系统是96核，192线程的四路服务器，目前CPU还不存在瓶颈。
从sys%来看，目前系统并没有因为闩锁spin而引发CPU问题，因此解析对系统的影响还是有限的。
从Top 10 Events来看，DB CPU占比达到64.8%，说明大部分CPU还是被SQL执行所占用，也说明系统 整体状态还不太糟糕。而与SQL 执行相关的MUTEX和闩锁来看平均等待时间也还可以。
对于这个系统，我们下一一步要关注什么呢?执行数量最高的SQL是需要重点关注的。可以看最排名前三的SQL，或者前五的SQL是最值得关注的。这些SQL返回的行数都不多。平均每次大概1行或者0行。这种SQL我们一般很难在AWR里看到它出现在GETS/READS的TOP SQL里，不过我们可以在AWR的数据表中去分析，大概每次执行的GETS有多少，再和执行时间作比较，算出CURSOR和共享池方面的并发冲突对它的执行效率有多大影响，是否需要优化。因为这里缺乏数据，我就不做评价了。
从总体上来说，系统的硬件还是比较强悍的，数据库参数设置也基本上合理。除了_cursor_features_enabled不知为何设置成了10，有可能这套系统是从10.2上升级上来的，在10.2的某些版本中 ，为了解决因为CURSOR共享而引发的某些CURSOR版本过多，从而引发大量的kksfbc child completion等待，影响并发执行的性能，会将此参数设置为10，而11g后的建议设置是不同的，11.2.0.3后这个问题需要通过将参数设置为100来解决，而不是当前系统中设置的10。
在一个 超高并发执行的场景中，经常会有一些执行效率较高的SQL，并发执行量很大，而Oracle这样的数据库是全局共享SQL PLAN的，这种场景实际上对于全局共享SQL PLAN的相同要求极高，搞得不好就会引发更为严重的共享池性能问题，从而让全局共享SQL PLAN反而变成了一个负担。
要解决这个问题，最好不要想着直接从数据库的角度去解决问题，共享池的很多优化能力有限，甚至调整得不好还会引发其他问题。因此最好的方法是尽可能减少某个library cache 对象的并发访问次数。我们以前通过在SQL中加入随机数注释的方式让同一条SQL变为多条：select /*+ cursor_x */ count(*) from ...。通过插入cursor_0,cursor_1这样的注释，让这条SQL变成多个cursor，从而降低共享池热点的争用问题。
尺有所短，寸有所长，虽然Oracle很牛，不过这种场景，最好的方式不是由Oracle来做，而是交给redis这样的内存数据库去做。实际上前三条执行数量极高的语句都是很容易在redis中实现的。可以将数据装载到redis中，直接通过kv的访问去查找，这样效率就高多了。如果这些数据偶尔还是会修改的也不怕，变更也可以在redis中完成，定期将数据刷新回Oracle就行了。而如果redis找不到数据再去Oracle中查找，再同时缓冲到redis中就行了。如果redis的命中率不高，再加个布鲁姆过滤器就齐活了。这些方法对大多数开发团队来说，都是轻车熟路的事情。
在超高并发执行的场景，很多时候还是要尽可能避开数据库的缺点。实际上共享SQL PLAN的数据库对于存在某个热点的超高并发执行，也是存在弱点的。很多朋友都建议国产数据库支持全局共享SQL PLAN，这个功能确实很有价值，但是要做好不容易。今天时间有限，就谈到这里吧，对于全局共享SQL PLAN的话题，我们以后找时间再详细聊聊。
