通过AWR和ASH信息看 ,log file sync和latch:shared pool等待最严重
数据库版本是11.2.0.1 懂行的朋友一看就知道这个版本bug太多，确实再MOS上查到
几个相关bug.对方使用AMM，其实这里最好使用ASMM单独分配SGA和PGA。发现shared pool
波动还是比较大，这种Shrink会引起latch:shared pool的等待。
当时业务写一次全量数据需要36个小时，还没有跑完。

第一次调整：增加日志组，增大日志文件大小为2g ,配置三个日志组。
性能提升： 从36小时提高到12小时，提升大概67%。

第二次修改参数，这次调整比较多，包括如下几个部分。
1 调整内存，增大AMM-24G，或调整为SGA-16g ，PGA-8g 单独设置
alter system set memory_max_target=24G scope=spfile;
shutdown immediate;
startup;
alter system set memory_target=24G;
show parameter meory;

2 调整为异步提交
alter system set commit_write="immediate,nowait";

3 修改log_buffer
alter system set log_buffer=32M scope=spfile;

4 调整参数 _enable_shared_pool_durations=false
alter system set "_enable_shared_pool_durations"=false;
避免Bug 8211733 Shared pool latch contention when shared pool is shrinking

5 Bulk Insert into tables having Clob datatypes very slow
alter system set "_ktb_debug_flag"=2;

6 关闭T_HR_VIEW 得update和select操作相关模块，或者优化改SQL
T_HR_VIEW.UNIQUE_ID字段创建索引 降低全表扫描从而降低DBTime

性能提升：这次全量数据导入需要9个小时，再次提升25%，此时基本满足用户导入数据的需要。

3 但是用户还是感觉起初一个insert操作步骤太耗时，希望解决，这个问题通过观察发现改SQL再执行阶段
事件几乎全部用在CPU上，下是10046跟踪信息
call count cpu elapsed disk query current rows
------- ------ -------- ---------- ---------- ---------- ---------- ----------
Parse 1381 0.20 0.17 0 0 0 0
Execute 1382 83.85 84.76 14 1496 10885 1404
Fetch 0 0.00 0.00 0 0 0 0
------- ------ -------- ---------- ---------- ---------- ---------- ----------
total 2763 84.06 84.93 14 1496 10885 1404

Misses in library cache during parse: 1
Misses in library cache during execute: 540
Optimizer mode: ALL_ROWS
Parsing user id: 102

Rows Row Source Operation
------- ---------------------------------------------------
0 LOAD TABLE CONVENTIONAL (cr=1 pr=0 pw=0 time=0 us)

从这个跟踪看,改SQL执行了1382次，插入了1404行数据，1496次逻辑读，用时84秒，
整个SQL执行时间为84.93秒，执行阶段占比最高，而执行阶段CPU时间是最高的。
也就是这个SQL执行阶段耗费大量的CPU时间，一个insert语句，每次插入一行数据，大概需要0.02秒，这个时间还是有点慢，怀疑跟虚拟环境又问题，建议在实体机做测试。

为了分析是否是虚拟机资源调度问题，我们在实体机上又跑了一次，这次发现根本没有等待，之前需要7个小时跑的最慢A58部分20多分钟就结束了.