改参数一时爽，救火火葬场！本次案例就给大家来分享一下，客户随意改动Oracle数据库参数造成的一次生产重大事故！

故障现象为业务高峰期，整个数据库直接hang死！通过一次案例回顾和总结ACS(Adpative Cursor Sharing)

1.load profile的信息

除了硬解析比例稍微高点，会话登录有点频繁，并没有什么大问题，

那我们再往下看看命中率，Library Hit比较低，该指标主要代表SQL在共享区的命中率。通常应在95%以上，否则需要考虑加大共享池。

2. 等待事件

cursor: pin S wait on X等待占比最高，接近90%。这个等待事件的意思是有会话试图以共享模式获取mutiex pin，但其他会话以独占方式持有游标对象的mutex pin，于是造成该等待。

产生cursor: pin S wait on X
该等待的主要原因，有以下几种
1.shared pool设置不合理
2.硬解析过多
3.大量的version count
4.bug
5.解析失败

3. SQLStatistics检查

在AWR中检查SQLStatistics部分，在version count类里，发现明显异常

明显发现有类似":SYS_B_X"字样，看起来是不是很像绑定变量？确实是，但一般应用的绑定变量都是类似":B1"之类，这个却明显不一样。设置过cursor_sharing参数的同学应该知道，这是数据库自己生成的绑定变量。

Version Count：表示一个父游标下子游标的数量，每个子游标对应一个独立的执行环境。AWR报告中Version Count > 20的SQL会被标记为潜在问题，高版本数（如数百/数千）会导致库缓存争用（Library Cache Latch/Lock），CPU利用率剧增。

什么情况下，会造成Version Count剧增呢？

4.初始化参数排查

继续检查初始化参数，发现了问题

cursor_sharing这个参数对系统性能和稳定性都非常重要，可惜经常被忽略，建议使用该参数的默认值：即 cursor_sharing=EXACT，而不是FORCE或similar。

5.总结

使用绑定变量的地方，必须使用绑定变量。这个对于OLTP系统来说是铁律，不容置疑，cursor_sharing=FORCE通常就是为了解决该使用绑定变量而没有使用绑定变量的情况。但是绝对不能通过改参数，而是通过应用来调整更为稳妥。

不该使用绑定变量的地方，不用绑定变量，比如对那些唯一值较少的字段，特别是数据分布不均的情况，不建议使用绑定变量，这种情况如果使用了绑定变量，就是绑定变量窥视和ACS发挥作用的时候。

如果cursor_sharing=FORCE或者cursor_sharing=EXACT，但是在数据分布不均的字段上也使用了绑定变量（两者基本上是等同的，虽然后一种略好于前一种情况），那么就要考虑“绑定变量窥视”和“自适应游标”两个参数的影响了。