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)	Executions	Elap per Exec (s)	% Total DB Time	SQL Id	SQL Module	SQL Text
51,510	9	991	51.98	99.98	8jj6zhxbk0fhm	JDBC Thin Client	update T_DFON_SINOPAY_STATDAY ...
3	3	948	0.00	0.01	gcmm5zzw0rfdn	JDBC Thin Client	select count(*) from T_DFON_SI...
2	2	37	0.04	0.00	bv1s464t92bxr	Spotlight on Oracle	SELECT KSLLTNUM INDX, SUM(NVL(...
1	1	1	1.00	0.00	bc7gjv3ppdtbz	sqlplus@psfpsh (TNS V1-V3)	BEGIN dbms_workload_repository...
1	1	990	0.00	0.00	77dz3cvdtnsj8	JDBC Thin Client	insert into T_DFON_TRADE (TRD_...
1	0	947	0.00	0.00	6z98fw5jsxy8g	JDBC Thin Client	insert into T_DFON_ORDER (ORD_...
1	1	2,871	0.00	0.00	40cwkqqbjn3z8	JDBC Thin Client	select ORD_BILLNO, ORD_PRDCODE...
1	1	36	0.02	0.00	6fmr9b8vxw54j	Spotlight on Oracle	SELECT event, quest_soo_pkg.ev...
1	1	0		0.00	a23whc5rsjt5a	JDBC Thin Client	select TRD_BILLNO, ORD_BILLNO,...
1	1	1	0.55	0.00	bunssq950snhf		insert into wrh$_sga_target_ad...

如上表所示，top1 是 T_DFON_SINOPAY_STATDAY 表的修改操作，它占据了 99.98% 的数据库时间；
top2 是针对 T_DFON_SINOPAY_STATDAY 表的一个统计操作。
据此基本可以判定发生了行锁定，导致性能提不上去，Top 5 Timed Events 证实了这一点：

Event	Waits	Time(s)	Avg Wait(ms)	% Total Call Time	Wait Class
enq: TX - row lock contention	93,526	51,258	548	99.5	Application
CPU time		32		.1
log file sync	2,846	1	0	.0	Commit
db file sequential read	769	1	2	.0	User I/O
log file parallel write