All in？跑步入场？清仓？为了这些动作，Ta们在......
国庆节前的几天A股大涨，很多资深股民纷纷狂晒朋友圈，“All in！”、“跑步入场”、“再涨30%，我就回本了”、“ 牛回，速归，记住不要卖掉电动车！”、“3点收盘太早啦，强烈要求国庆节加班”。老股民解套在望，新股民跃跃欲试。交易量和用户活跃度都在急剧增加，证券公司的系统性能成为了保障交易顺利进行的关键。终于，大家期待的证券公司“加班”，真的来啦！
国庆假期期间，为了保障高并发下的系统稳定运行，永利3044浏览器配合一些证券公司客户加班进行了压力测试，其中一个客户遇到了意想不到的瓶颈，可能导致系统运行缓慢，影响交易。我们今天就一起来看看这个“新鲜”的案例！
某证券客户对系统进行性能压测，结果系统运行缓慢，大量会话积压，无法达到交易目标。这一问题亟需优化处理，以确保在股市热潮中系统能够稳定运行。
收集问题时段AWR报告，可以看到系统的等待事件如下：
从系统的负载来看，系统中硬解析的并发量不算大，每秒161.7多左右的：
因主要在解析阶段，在AWR报告中就并不进一步观察SQL语句执行阶段的问题。AWR报告显示，系统异常等待主要是`latch:row cache objects`的等待，即出现在row cache层面的争用。在AWR报告中，对于row cache部分的统计如下：
可以看到在dc_tablespaces和 dc_users 层面出现大量访问请求。压测阶段通过对系统做hanganalyze，可以看到如下相关信息：
分析阻塞链上的各会话的short stack，可以看到：
在short stack中，可以看到此时进程处于硬解析的过程中，为了计算hash join的成本，需要用ktatminextsz函数从row cache中查找临时表空间的最小扩展的大小，作为计算因子。我们知道要想访问row cache，首先要拿到shared pool里的latch: row cache object，以得到相应row cache的地址。当有大量进程需要访问dc_tablespace这个row cache object时，首先会在latch: row cache object发生争用。由于这个争用引发的等待，硬解析时间会变长，从而引发cursor: pin S wait on X的等待。
1、减少CBO对hash join的路径尝试。（显然可能性不大）
2、减少硬解析。(每秒161次不算过分)
3、提高获取临时表空间最小扩展的性能。（查下有没有相应的bug或者enhance）
针对该现象，先核查相关MOS文档，可以查到对应的文档，描述类似情况：对应的文档号为2189126.1：
产生该问题的原因为bug引发：
可以看到，根据bug 13902396 的描述，产生大量对于dc_users和dc_tablespaces的row cache访问是因为，在调用ktatminextsz函数时，高频的访问数据字典获取”minimum extent
size for the users temporary tablespace”这个信息，事实上通过该bug的修复，在于直接设定返回一个值，而不再去数据字典中查找，避免出现latch争用；从实际情况来看，临时表空间的最小扩展基本是个固定的值，通过设备事件直接返回这个值，是可行的，几乎不会存在什么隐患。我们只需要从ts$中查出这个最小扩展的大小，然通过event设置一下，就可以绕过对latch: row cache object及dc_tablespace、dc_user的访问。在修复该bug后，还需要设置事件来进行优化处理。
四、最终选择
经过综合分析，我们最终选择了第三个方案——提高获取临时表空间最小扩展的性能。具体实施步骤如下：
针对客户数据库版本（11.2.0.4版本），为客户打上补丁13902396，修复了高频访问数据字典的问题。
通过设置事件45053，绕过对`latch: row cache object`及`dc_tablespace`、`dc_user`的访问，直接返回临时表空间的最小扩展大小。
通过这一方案，系统性能得到了显著提升，解决了硬解析导致的性能瓶颈问题。在股市热潮中，证券公司的系统性能至关重要。技术优化不仅是提升系统性能的关键，更是抓住市场机遇的重要保障。希望这篇文章能为大家提供有价值的参考。如果大家有相关的技术问题，欢迎留言联系我们。
