在你的环境中，问题的发生是由于 柱状图的大量访问造成的。

例如后台的递归SQL：
select /*+ rule */ bucket_cnt, row_cnt, cache_cnt, null_cnt, timestamp#, sample_size, minimum, maximum, distcnt, lowval, hival, density, col#, spare1, spare2, avgcln from hist_head$ where obj#=:1 and intcol#=:2

所以，你要检查一下，是怎样的查询引发了大量的后台递归。
TOPSQL 中几乎没有用户SQL，你需要按照ash中的时间序列，找到最初的起点，主要的触发SQL。

也去确认一下，是否存在已知BUG的影响。

谢谢盖总。

topSQL中都是递归调用SQL，是因为系统设计了1万个表，每个表相关SQL至少10个，导致一些硬解析问题，而且解析SQL的消耗聚合后超过了每个表上的应用SQL。

我观察了SQLA与latch: shared pool的关系，目前注意到在SQLA大幅减小时，才会出现较长时间的latch: shared pool:

LSH = latch: shared pool

基本上可以判断是性能瓶颈的一种，不知道将共享池扩到足够大，有没有用。有一万个表TABNAME0000~9999，看到其中某个表相关SQL至少有10个，1万个表至少会有10万条SQL。V$sqlarea中与JDBC Thin Client相关的约有8万行，其中有1万个还是seq.nextval查询SQL，当前共享池还不足够容下所有SQL。

想请教一下，如果把共享池再扩容30%，是否会有较大的正面效果吗，假设所有SQL都能放进去。

histogram的数据访问也确实是一个问题，1万个表的情况下，柱状图信息超过2000多万行。有取消柱状图信息统计的想法，但要测试验证，SQL是否可适应。

目前shared pool从13G扩容到16G，SQLA先是增涨到9550M，然后Xkghlu中各子池出现flush,SQLA空间回落，目前稳定在8500M~9000M，Vactive_session_history中latch shared pool基本为0，偶尔会有1~2个。