案情分析：数据库的基本情况

今天又遇到了一些问题，然后又有了新的发现，从1.3G的sysstemstate dump文件中看到很多明确的线索。

继续说一下数据库的基本状况，原本是10.2.0.3的数据库，然后升级到10.2.0.4，数据库硬解析稍高，相关数据是15分钟的采样：

User calls:	10,845.57	166.13
Parses:	3,100.26	47.49
Hard parses:	368.77	5.65

通常row cache objects的竞争高，可能会考虑到DC层指标会高，其实不然：

dc_histogram_data	20,773,204	0.03	0		0	13,568
dc_histogram_defs	10,247,344	0.06	0		0	8,351
dc_object_grants	491	8.96	0		0	38
dc_object_ids	26,478,232	0.00	0		0	1,470
dc_objects	435,039	0.19	0		0	770
dc_profiles	1,546	0.00	0		0	1
dc_rollback_segments	9,579	0.00	0		0	829
dc_segments	2,813,316	0.04	0		4	1,556
dc_sequences	4,814	0.19	0		4,814	5
dc_table_scns	26,895	0.09	0		61	35
dc_tablespace_quotas	2	100.00	0		0	1
dc_tablespaces	782,069	0.00	0		0	17
dc_usernames	42,627	0.04	0		0	13
dc_users	760,063	0.00	0		0	53

看起来dc_object_ids,dc_histogram_data 稍微高一点。

数据库不存在简单的SQL问题、Sequence问题，物化视图的Bug已经考虑屏蔽掉，升级后证实与其无关，Cursor Pin S的相关Bug也与此无关。

Row Cache的使用主要集中在以下三个方面：

row cache objects	kqrpre: find obj	0	162,138	161,288
row cache objects	kqreqd	0	151,788	153,686
row cache objects	kqreqd: reget	0	151,463	152,029

内存管理都是静态的，不存在动态调整引发问题的可能。内存基本设置如下：

	Begin	End
Buffer Cache:	20,480M	20,480M	Std Block Size:	8K
Shared Pool Size:	4,000M	4,000M	Log Buffer:	14,284K

这些都是关键的因素，有些我现在还在思考。