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 |