oracle 10035 err 942,love wife love life —Roger的Oracle/MySQL数据恢复博客

近期某客户的核心数据库出现问题，据了解该环境在近半年内不断重启；每次重启后基本上只能坚持不到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相对简单，跟大家随便分享一下吧。