有朋友和我讨论根因分析的问题，他认为大多数情况下根因分析是空中楼阁，因为数据库的问题的根因都在数据库产品的原代码上。这个观点有一定的道理，他所说的根因是绝对的根因，并不是日常为解决问题而去寻找的根因。这个世界上我们无法穷尽自然规律去找到最终的根因，但是我们能够找到那个与解决问题有关的关键问题，我们暂且称之为“根因”。不过当我们对某些原理理解不够深入和全面的时候，我们就无法找到那个解决问题的关键，这就是我一直坚持的那个理解数据库的本质的主要原因。我写《DBA的思想天空》也是希望DBA在成长过程中多去掌握一些数据库原理性的技术，而不是仅仅学习一些技巧。
有时候我们发现数据库中有几条SQL总是有点问题，而且问题出在CURSOR共享上，但是我们经常找不出根因来。实际上共享池问题的复杂性超出了一些DBA的认知极限，里面涉及的技术原理实在是太复杂了。
Oracle的CURSOR SHARING技术的关键部分是LIBRARY CACHE的管理。LIBRARY CACHE也是按照HASH CHAINS的方式来管理的，会被分为多个HASH BUCKET。当要定位某条SQL的时候是通过HASH算法来快速定位的。
图片
首先根据SQL语句生成HASH值，然后通过HASH CHAINS找到相关的的Object Handle。对于Hash Chains，大家都不陌生，数据库中的很多链表管理，都是采用HASH桶的方式管理的。对于HASH桶，大家立即就会想到均衡问题，对于CACHE BUFFER CHAINS，不均衡的HASH桶会产生访问性能不佳的HOT BUFFER，而对于LIBRARY CACHE HASH BUCKETS，则会产生访问延时过大的library cache handle。过于长的HASH CHAINS在数据库中的表现可能会导致library cache闩锁的等待出现异常。
图片
如果某个bucket上的链表比较长，那么如果OBJECT HANDLE在这条链上，相关的SQL的执行效率就会受到一定的影响。因此一般情况下，HASH CHAIN的深度都不会太大。我们可以通过下面的命令来DUMP一下LIBRARY CACHE。用SYSDBA登录数据库，然后执行：
oradebug setmypid;
oradebug dump library_cache 2;
图片
可以看到LIBRARY CACHE TABLE一共有131072个BUCKET，一共有52101个对象。Oracle的 library cache bucket机制是十分古老的机制，我第一次了解到这个概念是在Oracle 7上遇到的一个BUG。这个BUG让我认识了_KGL_BUCKET_COUNT这个隐含参数。Oracle的LIBRARY CACHE HASH BUCKET的最小数量是509。不过这个值相当小，如果一个数据库实例中只有这么多个BUCKET，那么一个桶上将会链接过多的HANDLE了。从上面DUMP的例子可以看到，13万+的桶上有5万多个HANDLE。
Oracle的算法是，当桶上的平均深度超过2的时候，BUCKET会自动扩容一倍。当数据库实例启动后，最多自动扩容7次，也就是会扩大到128倍。似乎这个算法也没啥毛病。不过当HASH BUCKET扩容的时候，所有的HASH链都要重组，这是一个十分高开销的操作。二十多年前我就在一套ORACLE 7上遇到过这样的问题。当时我通过开SR知道了一个参数:_kgl_bucket_count。这个隐含参数确定了当数据库实例启动的时候，HASH BUCKET的数量。1代表509，2代表1021，3代表2041，都是对应2的幂次略小的素数。以此类推，9是最大值，代表131071，可以管理131072个桶。这正好和上面DUMP的例子相吻合。
图片
下面我们先来刷新一下共享池，再来做一个DUMP，看看会有什么结果出现。
图片
可以看出，存在较多对象的Buckets消失了。这个时候去访问这些library cache objects，性能就不会有问题了。在大多数情况下，刷新共享池是可以解决此类library cache问题的。当然，刷新共享池对于一些关键系统来说依然是有风险的。因为大量的SQL会重新解析，共享池争用会在瞬间加大，因此此类操作不能在业务高峰期执行。另外一个风险是重新编译SQL可能会因为某些数据库表和索引的统计信息不准确而导致新的SQL执行计划变坏，引发其他的性能问题。
今天我们可以学到的一个技巧就是，遇到一些无法解释根因的SQL解析性能问题，如果只是集中在某个或者某几个SQLID上，那么可以通过对library cache做一个 level 2的DUMP就可以分析今天所说的这个原因了。也许我们以后做数据库巡检的时候，也可以在非业务高峰期做一下DUMP，分析一下共享池是否存在这种风险。
说到今天的这个话题，想起了20多年前的一个案例，当时的数据库是7.3，当时的服务器配置都不高，SGA也比较小，因此_kgl_bucket_count默认还是1。用户经常出现bucket扩容而引发的系统几乎HANG死的情况，引起系统卡顿十多分钟甚至更长。那时候这个数据库每个月都会进行重启维护以避免共享池 碎片严重而引发的严重系统问题。
不过自从这个制度制定后，共享池碎片导致ORA-4031的问题解决了。不过重启后过一段时间就会一定出现一次卡顿，随后就基本上就不再出现了。这个问题十分诡异，我查了很久都没有找到问题的根因，于是只能开了SR。经过Oracle原厂排查，定位到了这个问题 。将该参数改为2之后，就没有出现过这个问题。客户的领导也是一个技术达人，他觉得既然这个问题存在，那么把这个参数再设大一点不是更加安全。于是我帮他们调整了参数。结局很悲催，当时的数据库版本中这个参数设置得过大会触发一个BUG，高负载时引发实例宕机。这个宕机问题很难定位，过了好久才被真正定位出来。
