近期某客户的核心数据库出现问题，据了解该环境在近半年内不断重启；每次重启后基本上只能坚持不到2周；整个业务基本上就卡的不行了;
然后就是数据库各种ora-04031错误；高峰期间各种shared pool latch和mutex等待；业务就如蜗牛一样慢。
首先我们来看用户awr基础信息：
Memory Statistics
Begin End
Host Mem (MB): 385,185.1 385,185.1
SGA use (MB): 163,840.0 163,840.0
PGA use (MB): 3,615.0 3,766.7
% Host Mem used for SGA+PGA: 43.47 43.51
Cache Sizes
Begin End
Buffer Cache: 512M 512M Std Block Size: 8K
Shared Pool Size: 150,363M 150,500M Log Buffer: 250,560K
由于是4节点rac（Oracle xd环境),因此这里我就只用其中一个实例信息来做解释。大家可以看到上述该节点整个数据库sga 内存大约160g；
其中shared pool 就消耗了150g左右，Buffer cache只有512MB了。由此可见shared pool膨胀的是有多厉害（实际上其他节点也类似，数据差不多）。
那么问题就来了；Shared Pool这么大？都是什么内存组件所消耗的呢？
Pool Name Begin MB End MB % Diff
java free memory 512.00 512.00 0.00
large free memory 2,551.81 2,551.81 0.00
shared KGLH0 37,942.50 36,475.24 -3.87
shared KGLHD 27,483.32 26,883.60 -2.18
shared KGLNA 6,261.15 6,174.54 -1.38
shared KKSSP 15,332.02 15,415.15 0.54
shared SQLA 31,580.74 31,497.37 -0.26
shared SQLP 5,635.93 5,293.25 -6.08
shared free memory 20,614.23 23,191.14 12.50
shared gcs resources 3,167.77 3,167.77 0.00
shared gcs shadows 2,193.07 2,193.07 0.00
streams free memory 511.97 511.97 0.00
buffer_cache 512.00 512.00 0.00
fixed_sga 2.16 2.16 0.00
log_buffer 244.69 244.69 0.00
从上述数据来看，有几个组件是非常可疑的。其中KGLHD、KGLH0分别跟library cache handle和cursor有关；另外kkssp跟cursor解析有关系。
检查该数据库发现确实存在大量硬解析；再调整cursor_sharding=force之后，发现硬解析并未降低。
监控kkssp发现仍然涨的很快；如下：
看来必须找到解析失败的原因才行。果断打开event 10035，跟踪了5分钟；发现alert log 重存在打下来err=922 类型的解析失败sql；均来自8个Session。
通过关联v$session发现是应用某个exe程序。同时发现该应用程序在不断执行create table 语句；其问题在于create table语句后面option是 ……
….loggingtablespace xxxx.
很明显是create table语句语法存在错误。还真是一个空格引发的血案。
整个case相对简单，跟大家随便分享一下吧。
本文作者Roger, 转载自love wife love life —Roger的Oracle/MySQL数据恢复博客
