1.背景
1.1.Linux 服务器情况
# cat /etc/issue@H_502_6@Red Hat Enterprise Linux Server release 6.1 (Santiago)
Kernel \r on an \m@H_502_6@
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();@H_502_6@
匿名块已完成@H_502_6@
隔几分钟后再执行一次，生成俩快照。
这个间隔时间越长约好，越能说明问题。
2.2.以系统 DBA 登录 sql shell
SSH 登录远程 Oracle 所在 Redhat 主机，依次执行以下命令以登录 sql shell：# export ORACLE_HOME=/u01/oracle/product/10.2.0/db_1@H_502_6@
# export oracle_sid=defonds@H_502_6@
# cd /u01/oracle/product/10.2.0/db_1/bin@H_502_6@
# ./sqlplus sys/sysdefonds@defonds as sysdba@H_502_6@
sql>
登录 sql shell 成功。
注： /u01/oracle/product/10.2.0/db_1/@H_502_6@ 是为 Oracle 安装路径。
2.3.生成 AWR 报告
sql> @/u01/oracle/product/10.2.0/db_1/rdbms/admin/awrrpt.sql@H_502_6@进入 AWR 操作步骤：
Enter value for report_type@H_502_6@ 输入 html@H_502_6@：
我们看当天的， Enter value for num_days@H_502_6@ 输入 1@H_502_6@：
如上图所示，列出的是当天生成的所有快照，可以看到：ID 为 27810@H_502_6@ 和 27811@H_502_6@ 的两个是我们刚才手工生成的，我们就用 AWR 采集这两个快照之间的数据了。因此 Enter value for begin_snap@H_502_6@ 我们输入 27810@H_502_6@：
Enter value for end_snap@H_502_6@ 我们输入 27811@H_502_6@：
报告名字我们就用默认的 awrrpt_1_27810_27811.html@H_502_6@ 即可，直接回车，awr 报告生成：
生成的文件就在 /u01/oracle/product/10.2.0/db_1/bin/@H_502_6@ 目录下：
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 | 948 | 0.00 | 0.01 | gcmm5zzw0rfdn | JDBC Thin Client | select count(*) from T_DFON_SI... | |
| 2 | 37 | 0.04 | 0.00 | bv1s464t92bxr | Spotlight on Oracle | SELECT KSLLTNUM INDX,SUM(NVL(... | |
| 1 | 1.00 | 0.00 | bc7gjv3ppdtbz | sqlplus@psfpsh (TNS V1-V3) | BEGIN dbms_workload_repository... | ||
| 1 | 990 | 0.00 | 77dz3cvdtnsj8 | insert into T_DFON_TRADE (TRD_... | |||
| 0 | 947 | 6z98fw5jsxy8g | insert into T_DFON_ORDER (ORD_... | ||||
| 2,871 | 40cwkqqbjn3z8 | select ORD_BILLNO,ORD_PRDCODE... | |||||
| 36 | 0.02 | 6fmr9b8vxw54j | Spotlight on Oracle | SELECT event,quest_soo_pkg.ev... | |||
| 0 | a23whc5rsjt5a | select TRD_BILLNO,ORD_BILLNO,... | |||||
| 0.55 | bunssq950snhf | insert into wrh$_sga_target_ad... |
如上表所示，top1 是 T_DFON_SINOPAY_STATDAY 表的修改操作，它占据了 99.98% 的数据库时间；
top2 是针对 T_DFON_SINOPAY_STATDAY 表的一个统计操作。
据此基本可以判定发生了行锁定，导致性能提不上去，Top 5 Timed Events 证实了这一点：
| 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 | .0 | Commit | ||
| db file sequential read | 769 | .0 | User I/O | ||
| log file parallel write |
