主机负载分析
cpus: 80个逻辑核
elapsed: 快照监控时间30分钟
db time: 数据库耗时3331分钟
结论：per cpu平均耗时(3331/80)≈42分钟，cpu利用率为(3332/80/30.10*100%)≈138%，利用率超过100%说明出现了等待现象，继续进一步分析。
数据库负载分析
redo size: redo size每秒(29020707.5/1024/1024)≈27M
logical read: 逻辑读每秒(397362*8k/1024/1024)≈3G
parses sql: 28953
executes sql: 50413
transactions: 9514
结论1：每秒产生日志达到27M，可见数据变更频率非常高，会触发lgwr进程和arch进程写日志，从而造成I/O压力，也有可能造成logbuffer堵塞从而造成等待事件，继续下一步分析。
结论2：每秒执行50413条sql，无硬解析，软解析28953条sql，说明软解析软解析特别高，继续向下分析。
结论3：每秒平均有9514个事务，说明数据库在该这个时间段内很繁忙。
实例运行效率百分比
execute to parse: 42.87
parse cpu to parse elapsd: 8.74
结论1：soft parse高但是execute to parse低，可通过静态SQL、动态绑定、session_cached_cursor、open cursor等技术减少软解析。
结论2：parse cpu to parse elapsd指标值非常低，说明在整个解析过程中，实际在cpu上运算的时间很短，而主要的解析耗费在其他各种非空闲等待上。
top10等待事件分析
从图中可以看出，主要的等待事件为：
cursor: mulex S：该等待事件常常是由于子游标过多的影响，当子游标过多，进程需要去扫描长长的子游标child cursor list，以找到一个合适的子游标child cursor，进而导致cursor sharing性能问题。
log file sync：该等待事件是由于lgwr进程将redo log buffer写入redo log中发生的。从数据库负载那里可以看到每秒平均有27M redo产生，需要进一步分析sql commit次数是否过多，查看redo log buffer是否过大，检查i/o是否存在问题。
db cpu: 数据库运行时消耗的cpu情况（不包含数据库进程在等待cpu的时间），cpu总等待时间为(24.6*1000/60)≈410分钟，cpu等待严重，继续向下分析。
等待事件类型分析
concurrency: 并发类等待时间，由内部数据库资源引起，本报告中主要是由share pool latches导致。
commit: 执行commit命令之后，等待log file sync。
application: 由用户程序的代码引起，锁等待等。
system i/o: 后台进程i/o操作引起，有大量的lgwr等待。
CPU性能分析
Load Average Begin/End: 代表从快照开始到结束这个时间段内，每个CPU的大致运行队列大小。
Total Cpu Used = %User + %System = 18.5 + 4.8 = 23.3
Total Cpu: 代表该实例所使用的Cpu占总Cpu的比例为18.8%，即8018.8%≈16核
Busy Cpu: 代表该实例所使用的被使用Cpu的比例，即1678.4%≈13核，判断该实例占用CPU比例很高。
IO性能分析
从上图中的指标分析，数据库总的I/O写请求压力非常大，每秒有7964个写请求。重做日志写请求非常高，每秒达到7200个请求，数据块和缓冲区的写压力也非常大，均达到3700以上。
内存分析
内存管理方式：
MSMM：手动内存管理方式。
ASMM（sga_target）: 自动SGA内存管理方式。
AMM（memory_target）: 自动内存管理方式，要关注是否发生shared pool和buffer cache之间发生频繁shrink/grow操作的现象。若存在shared pool不断grow的情况，则要关注可能出现大量硬解析的可能。
memory usage: shared pool实时大小，代表shared pool的空间使用率
sql with executions: 复用的sql占总的sql语句的比例。
memory for sql w/exec: 执行2次以上的sql所占内存占总的sql内存的比例。
结论：从上述指标上来看，2次执行sql占总内存的sql内存比例为96.57，可判断shared pool暂时不存在较多共享池内存碎片的问题。