Oracle AWR 报告的生成和分析

1.背景

1.1.Linux 服务器情况

# cat /etc/issue
Red Hat Enterprise Linux Server release 6.1 (Santiago)
Kernel \r on an \m

1.2.Win7 客户端情况

Win7 旗舰版 sp1，4G内存，双核 CPU 主频 3.0G。

1.3.Oracle 服务器情况

10.2.0，部署在上述 RedHat 上。

2.AWR 报告的生成

2.1.手工刷出快照

默认情况下 Oracle 的快照每一小时生成一次，也就是说 AWR 分析的是一小时以内这一段时间的负载情况。
用这个默认的不够灵活，而且浪费调试时间——我们总不能压一小时才能看结果吧？一般取压力高峰时的两个快照之间的几分钟就可以了。
数据库 DBA 用户登录 SQL shell(或者直接用 Oracle 客户端打开 sql 执行窗，如 SQL Developer)，执行以下 sql：
SQL> exec dbms_workload_repository.create_snapshot();
匿名块已完成
隔几分钟后再执行一次，生成俩快照。
这个间隔时间越长约好，越能说明问题。

2.2.以系统 DBA 登录 SQL shell

SSH 登录远程 Oracle 所在 Redhat 主机，依次执行以下命令以登录 SQL shell：
# export ORACLE_HOME=/u01/oracle/product/10.2.0/db_1
# export oracle_sid=defonds
# cd /u01/oracle/product/10.2.0/db_1/bin
# ./sqlplus sys/sysdefonds@defonds as sysdba
SQL>
登录 SQL shell 成功。
注：/u01/oracle/product/10.2.0/db_1/ 是为 Oracle 安装路径。

2.3.生成 AWR 报告

SQL> @/u01/oracle/product/10.2.0/db_1/rdbms/admin/awrrpt.sql
进入 AWR 操作步骤：

Enter value for report_type 输入 html：

我们看当天的，Enter value for num_days 输入 1：

如上图所示，列出的是当天生成的所有快照，可以看到：ID 为 27810 和 27811 的两个是我们刚才手工生成的，我们就用 AWR 采集这两个快照之间的数据了。因此 Enter value for begin_snap 我们输入 27810：

Enter value for end_snap 我们输入 27811：

报告名字我们就用默认的 awrrpt_1_27810_27811.html 即可，直接回车，awr 报告生成：

生成的文件就在 /u01/oracle/product/10.2.0/db_1/bin/ 目录下：

3.AWR报告分析

可以直接跳到 SQL ordered by Elapsed Time 查看 SQL 排行榜：
Elapsed Time (s)CPU Time (s)ExecutionsElap per Exec (s)% Total DB TimeSQL IdSQL ModuleSQL Text51,510999151.9899.988jj6zhxbk0fhmJDBC Thin Clientupdate T_DFON_SINOPAY_STATDAY ...339480.000.01gcmm5zzw0rfdnJDBC Thin Clientselect count(*) from T_DFON_SI...22370.040.00bv1s464t92bxrSpotlight on OracleSELECT KSLLTNUM INDX, SUM(NVL(...1111.000.00bc7gjv3ppdtbzsqlplus@psfpsh (TNS V1-V3)BEGIN dbms_workload_repository...119900.000.0077dz3cvdtnsj8JDBC Thin Clientinsert into T_DFON_TRADE (TRD_...109470.000.006z98fw5jsxy8gJDBC Thin Clientinsert into T_DFON_ORDER (ORD_...112,8710.000.0040cwkqqbjn3z8JDBC Thin Clientselect ORD_BILLNO, ORD_PRDCODE...11360.020.006fmr9b8vxw54jSpotlight on OracleSELECT event, quest_soo_pkg.ev...110 0.00a23whc5rsjt5aJDBC Thin Clientselect TRD_BILLNO, ORD_BILLNO,...1110.550.00bunssq950snhf insert into wrh$_sga_target_ad...
如上表所示，top1 是 T_DFON_SINOPAY_STATDAY 表的修改操作，它占据了 99.98% 的数据库时间；
top2 是针对 T_DFON_SINOPAY_STATDAY 表的一个统计操作。
据此基本可以判定发生了行锁定，导致性能提不上去，Top 5 Timed Events 证实了这一点：

EventWaitsTime(s)Avg Wait(ms)% Total Call TimeWait Classenq: TX - row lock contention93,52651,25854899.5ApplicationCPU time 32 .1 log file sync2,84610.0Commitdb file sequential read76912.0User I/Olog file parallel write