1 编写目的

介绍在现场出现Oracle故障和性能问题时的诊断流程，让项目支撑人员在解决Oracle问题时有据可依。

2 适用场景

当现场出现以下问题时，可依照本文档进行处理：

1） Oracle异常关闭、重启、Hang住等故障。

2） PM相关程序出现性能急剧下降的情况。

3） PM相关程序出现Hang住等故障。

3 分析流程

3.1 信息收集及初步诊断

本节介绍以下知识点：

1） 出现问题时，需要收集什么样的信息？

2） 这些信息的作用是什么？

3） 如何进行收集？

4） 如何对这些信息进行分析，从而得到初步诊断结论？

初步诊断结论是指引起问题的原因，但不是根因。例如，初步诊断结论是内存问题、IO问题、等待事件的问题、执行计划的问题、统计信息的问题。

3.1.1 PM运行情况（黄）

反映PM运行情况的数据主要包括运行日志以及存储运行数据的表（例如COUNTERLOADMESSAGE、SUM_SUMMARYTASKQUEUE表等）。从以上内容中，可以分析出PM在运行过程中是否有错误发生，以及是否存在性能问题。以下内容均以C03版本为准，C02和V4.5可能有变化，需结合实际情况作相应调整。

1) 如何收集：

a) 运行日志：加载环境变量后，使用cd $PM4H_LOG进入日志目录

b) 运行数据表：

2) 如何分析：

a) 运行日志：

i. 可以使用cat | grep ERROR的方式，搜索指定日志中是否存在错误信息。可以是具体的日志文件名，也可以是使用了通配符的表达式。例如搜索所有的汇总日志中是否存在错误，可使用如下命令：

cat Summarize* | grep ERROR

ii. 如果某个日志文件中存在ERROR信息，可以使用vi命令编辑该文件，依次输入/ERROR和回车，搜索ERROR信息，查看详细的错误信息。（/是vi编辑器中的搜索命令）

iii. 对于性能分析，可以分为两种情况，一种是程序出现Hang住的情况，表现为日志长时间无内容输出；另一种是程序没有Hang住，但在单位周期内无法处理完一周期的性能数据。

iv. 出现Hang住的情况时，可以使用两种方式找到Hang住的任务。一种是通过日志分析出当前正在执行的任务。以汇总执行日志为例，可以分析Hang住时那一轮的日志中，哪些任务只有start日志，没有end日志，这些任务就是Hang住的任务；另一种是在DB服务器上使用top命令查看当前正在运行的Oracle进程，找到进程运行时间长的进程，并找到进程对应的SQL，进而分析出Hang住的任务。

v. 出现整体性能下降时，可以通过其它方面的信息来查找问题。

b) 运行数据表：

i. 运行数据表的数据主要用于分析核心模块的运行效率以及工作量的变化。

ii. 分析COUNTERLOADMESSAGE表中每天产生的MSG数量，可以得出入库程序的工作量和性能情况。PILOADMESSAGE和COUNTERLOADMESSAGE类似。

iii. 分析SUM_SUMMARYTASKQUEUE表中每小时执行完成的TASK数量，可以得出汇总执行程序的工作量和性能情况。SUM_BHTASKQUEUE和SUM_SUMMARYTASKQUEUE类似。

3.1.2 操作系统资源情况（孙）

● CPU

◆ 信息收集

登录系统后，使用top、vmstat、iostat、mpstat等命令，都可以查看到操作系统的CPU使用情况。相关的解释如下。

表1-1 TOP命令中的CPU信息

表1-2 vmstat命令中的CPU信息

表1-2 iostat命令中的CPU信息

◆ 初步诊断

使用CPU利用率和负载来进行CPU的初步诊断。

1. CPU利用率的参考值：正常情况下<=70%

1） 如果CPU的利用率长期大约70%，说明CPU的已经比较繁忙；

2） 如果故障时刻，连续超过95%以上，说明可能是CPU存在瓶颈。

2. CPU负载的参考值范围：CPU核数*0 - CPU核数*3

1） CPU负载越小越好；如果负载=CPU核数，还可以接受；

2） 如果负载>=CPU核数*3，则说明系统负载非常高。

◆ 更详细的资料，见附录一《TOP命令详解》、附录二《iostat命令详解》、附录三《vmstat命令详解》。

● 内存

◆ 信息收集

登录系统后，使用top、vmstat、free等命令，都可以查看到操作系统的CPU使用情况。相关的解释如下（以free命令为例）。

表1-3 free命令中的内存信息

● 更详细的资料，见附录四《free命令详解》。

◆ 初步诊断

诊断内存是是否是瓶颈的标准：swap和+buffers/cache。

1） 只要不用swap的交换空间，就不用担心自己的内存太少。如果常常swap用很多，可能你就要考虑加物理内存了。这也是linux看内存是否够用的标准。

2） 如果是应用服务器的话，一般只看第二行，+buffers/cache，即对应用程序来说free的内存太少了，也是该考虑优化程序或加内存了。

● IO

◆ 信息收集

登录系统后，使用iostat命令获取服务器的I/O使用情况。如下：

表1-4 iostat命令中的I/O信息

◆ 初步诊断

表1-4中是最主要的I/O参数，使用他们来进初步的诊断：

1） 如果 %util 接近 100%，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘可能存在瓶颈。

2） 如果%util接近100%，表明I/O请求太多，I/O系统已经满负荷，磁盘可能存在瓶颈，一般%util大于70%，I/O压力就比较大，读取速度有较多的wait.同时可以结合vmstat查看查看b参数(等待资源的进程数)和wa参数(IO 等待所占用的CPU时间的百分比，高过30%时IO压力高)。

3） await 的大小一般取决于服务时间(svctm) 以及I/O队列的长度和I/O请求的发出模式。如果 svctm 比较接近 await，说明I/O几乎没有等待时间；如果 await 远大于 svctm，说明I/O队列太长，应用得到的响应时间变慢。

● 持续收集资源信息

◆ 信息收集

需要在系统上部署NMON软件。具体的部署方法见附录五《NMON的部署方法》。

◆ 初步诊断

见附录六《NMON的诊断方法》

3.1.3 Alert日志和Trace文件（孙）

◆ 信息收集

收集方法：

第一步：ftp到alert日志的目录，将alert日志收集下来。

方法一：Alert日志的目录可以通过oracle的参数background_dump_dest找到。如图1-1所示。

方法二：使用这个语句select value from v$diag_info where name ='Diag Trace'得到alert日志的位置。

另外，RAC节点下的日志文件结构和普通的日志文件结构不一样。请参考附件《附录五：Oracle RAC集群环境下日志文件结构》。

第二步：找到故障发生时的时间段的log日志进行分析。

第三步：如果通过alert日志看不到具体的信息，可以通过alert日志的提示，转到相应的trace文件，进行信息收集。示例如下：

其中：

“/opt/oracle/db/diag/rdbms/vmos5200/vmos52001/trace/vmos52001_ora_8723.trc”和

“/opt/oracle/db/diag/rdbms/vmos5200/vmos52001/incident/incdir_28441/vmos52001_ora_8723_i28441.trc”就是trace文件。

第四步：也可以登录https://support.oracle.com网站，查找具体的错误代码。例如：错误代码：kksfbc-wrong-kkscsflgs。

◆ 初步诊断

在alert日志中能够看到大部分严重错误、警告，以及一些重要的操作产生的日志。

从ORACLE的角度来看，alert日志的信息可以分为如下几类：

 所有的内部错误（ORA-00600），块损坏错误（ORA-01578），死锁（ORA-00060）。

 管理性的操作，如create，alter，drop语句和start，shutdown，archivelog语句

 MTS模式（多线程服务器。区别于专用服务器）下共享服务器进程和调度进程的信息和错误

 自动刷新物化视图时发生的错误

 非默认的启动参数

 各个后台进程运行产生的错误。Oracle的后台进程见附录六《Oracle的后台进程》。

同时用户也可以使用Oracle的DBMS_SYSTEM包的KSDWRT过程向alert日志书写自定义信息

 Job执行失败错误

从用户的角度，或者DBA的角度来看，alert日志的信息可以分为如下几类：

1） 故障级错误：这种信息需要优先定位；故障类信息如：

Sat Nov 05 10:13:37 2011

Errors in file /opt/oracle/db/diag/rdbms/vmos5200/vmos52001/trace/vmos52001_ora_8723.trc (incident=28441):

ORA-00600: internal error code, arguments: [kksfbc-wrong-kkscsflgs], [10327733560], [45], [], [], [], [], [], [], [], [], []

Incident details in: /opt/oracle/db/diag/rdbms/vmos5200/vmos52001/incident/incdir_28441/vmos52001_ora_8723_i28441.trc

2） 警告级信息。如：

TNS-12535: TNS:operation timed out

ns secondary err code: 12606

nt main err code: 0

nt secondary err code: 0

nt OS err code: 0

Client address: (ADDRESS=(PROTOCOL=tcp)(HOST=10.129.7.98)(PORT=2243))

WARNING: inbound connection timed out (ORA-3136)

3） 操作级信息：

Errors in file

/opt/oracle/db/diag/rdbms/vmos5200/vmos52001/trace/vmos52001_ora_8480.trc:

ORA-00942: table or view does not exist

更详细的信息请参见：

1） 附录七：《读懂alert日志》

2） 附录八：《读懂trace文件》

3.1.4 AWR报告（房）

3.1.5 ADDM报告（张）

（1）出现问题时，需要收集什么样的信息？

ADDM(Automatic Database Diagnostic Monitor) 是植入Oracle数据库的一个自诊断引擎。ADDM 通过检查和分析AWR获取的数据来判断Oracle数据库中可能的问题。ADDM会找到数据库当前的瓶颈，找出等待时间或占用CPU处理时间较长的事件（比如不合理的SQLID等），并可以给出相应的建议，达到减小系统吞吐量的目的。

（2）这些信息的作用是什么？

通过ADDM我们可以找到当前占用数据库资源的事件，并根据Oracle自动给出这些事件的建议来降低对系统资源的占用。

（3）如何进行收集？

收集方法：

①用sqlplus登陆Oracle。

②输入@?/rdbms/admin/addmrpt准备生成ADDM报告

SQL> @?/rdbms/admin/addmrpt

Oracle会把最近的snapshotID号及对应的时间段显示出来，并提示输入snapshotID。

③根据需要诊断的时间段，输入需要的snapshotID开始号和结束号。

Enter value for begin_snap: 191

Enter value for end_snap: 194

④输入ADDM报告的名字，没有的话Oracle会默认为addmrpt_1_（起始snapshot）_（终止snapshot）.txt；这里就用默认的，敲回车即可。

⑤Oracle会把ADDM报告输出到屏幕上并同时写入addmrpt_1_（起始snapshot）_（终止snapshot）.txt文件。生成的文件默认在$ORACLE_HOME/rdbms/admin下。这样ADDM报告就生成完毕了。

（4）如何对这些信息进行分析，从而得到初步诊断结论？

Oracle 11G的ADDM报告分为3部分：

①ADDM报告的生成环境概述：

Analysis Period

---------------

AWR snapshot range from 191 to 194.

Time period starts at 07-DEC-11 07.00.35 AM

Time period ends at 07-DEC-11 10.00.16 AM

Analysis Target

---------------

Database 'MOS5200' with DB ID 3304876993.

Database version 11.1.0.6.0.

ADDM performed an analysis of instance mos5200, numbered 1 and hosted at

creede.

Activity During the Analysis Period

-----------------------------------

Total database time was 437 seconds.

The average number of active sessions was .04.

Analysis Period说明ADDM生成的snapshot范围和时间段；

Analysis Target说明ADDM生成的Oracle实例、主机及版本；

Activity During the Analysis Period说明ADDM生成的数据库消耗时间，活动回话信息。

②问题列表（这是ADDM的主要部分）：

Summary of Findings

-------------------

Description Active Sessions Recommendations

Percent of Activity

--------------------- ------------------- ---------------

1 Top SQL by DB Time .02 | 37.36 5

2 Hard Parse 0 | 10.74 0

3 "User I/O" wait Class 0 | 7.81 0

4 Soft Parse 0 | 4.82 2

5 Undersized SGA 0 | 4.81 1

6 Java Execution 0 | 4.3 1

7 CPU Usage 0 | 2.24 1

Summary of Findings是ADDM找出的Oracle存在的瓶颈总览。下面Description每一行代表一个导致系统瓶颈的事件、对系统的影响比例，以及Oracle自己给出建议的条数。

下面就是对每个事件的具体分析，拿Top SQL by DB Time这个首要问题为例：

Findings and Recommendations

----------------------------

Finding 1: Top SQL by DB Time

Impact is .02 active sessions, 37.36% of total activity.

--------------------------------------------------------

SQL statements consuming significant database time were found.

Recommendation 1: SQL Tuning

Estimated benefit is .01 active sessions, 23.39% of total activity.

-------------------------------------------------------------------

Action

Investigate the SQL statement with SQL_ID "a9bacd1uu35ga" for possible

performance improvements.

Related Object

SQL statement with SQL_ID a9bacd1uu35ga and PLAN_HASH 2060173346.

SELECT /*+NESTED_TABLE_GET_REFS+*/ "PM4H_AD"."SYS_INTERGRATION".*

FROM "PM4H_AD"."SYS_INTERGRATION"

Rationale

SQL statement with SQL_ID "a9bacd1uu35ga" was executed 1 times and had

an average elapsed time of 79 seconds.

Recommendation 2: SQL Tuning

Estimated benefit is 0 active sessions, 9.29% of total activity.

----------------------------------------------------------------

Action

Tune the PL/SQL block with SQL_ID "6gvch1xu9ca3g". Refer to the "Tuning

PL/SQL Applications" chapter of Oracle's "PL/SQL User's Guide and

Reference".

Related Object

SQL statement with SQL_ID 6gvch1xu9ca3g.

DECLARE job BINARY_INTEGER := :job; next_date DATE := :mydate;

broken BOOLEAN := FALSE; BEGIN

EMD_MAINTENANCE.EXECUTE_EM_DBMS_JOB_PROCS(); :mydate := next_date; IF

broken THEN :b := 1; ELSE :b := 0; END IF; END;

Rationale

SQL statement with SQL_ID "6gvch1xu9ca3g" was executed 179 times and had

an average elapsed time of 0.3 seconds.

Recommendation 3: SQL Tuning

Estimated benefit is 0 active sessions, 5.2% of total activity.

---------------------------------------------------------------

Action

Run SQL Tuning Advisor on the SQL statement with SQL_ID "fqmpmkfr6pqyk".

Related Object

SQL statement with SQL_ID fqmpmkfr6pqyk and PLAN_HASH 2805031759.

select s.synonym_name object_name, o.object_type

from sys.all_synonyms s,

sys.all_objects o

where s.owner in ('PUBLIC', user)

and o.owner = s.table_owner

and o.object_name = s.table_name

and o.object_type in ('TABLE', 'VIEW', 'PACKAGE','TYPE', 'PROCEDURE',

'FUNCTION', 'SEQUENCE')

Action

Investigate the SQL statement with SQL_ID "fqmpmkfr6pqyk" for possible

performance improvements.

Related Object

SQL statement with SQL_ID fqmpmkfr6pqyk and PLAN_HASH 2805031759.

select s.synonym_name object_name, o.object_type

from sys.all_synonyms s,

sys.all_objects o

where s.owner in ('PUBLIC', user)

and o.owner = s.table_owner

and o.object_name = s.table_name

and o.object_type in ('TABLE', 'VIEW', 'PACKAGE','TYPE', 'PROCEDURE',

'FUNCTION', 'SEQUENCE')

Rationale

SQL statement with SQL_ID "fqmpmkfr6pqyk" was executed 4 times and had

an average elapsed time of 3.4 seconds.

Recommendation 4: SQL Tuning

Estimated benefit is 0 active sessions, 3.35% of total activity.

----------------------------------------------------------------

Action

Run SQL Tuning Advisor on the SQL statement with SQL_ID "1rswbxwhbpmr7".

Related Object

SQL statement with SQL_ID 1rswbxwhbpmr7 and PLAN_HASH 2506064221.

select decode(bitand(a.flags, 16384), 0, a.next_run_date,

a.last_enabled_time), a.obj#, decode(bitand(a.flags, 16384),

0, 0, 1), a.sch_job from (select p.obj# obj#, p.flags flags,

p.next_run_date next_run_date, p.job_status job_status,

p.class_oid class_oid, p.last_enabled_time last_enabled_time,

p.instance_id instance_id, 1 sch_job from sys.scheduler$_job p

UNION ALL select q.obj#, q.flags, q.next_run_date, q.job_status,

q.class_oid, q.last_enabled_time, q.instance_id, 1 from

sys.scheduler$_lightweight_job q UNION ALL select j.job, 0,

cast(j.next_date as timestamp with time zone), 1, NULL,

cast(j.next_date as timestamp with time zone), NULL, 0 from

sys.job$ j where (:1 = 1) and (j.field1 is null or j.field1 =

0) and j.job not in (select v.id2 from v$lock v where v.type =

'JQ')) a where bitand(a.job_status, 3) = 1 and ((bitand(a.flags,

134217728 + 268435456) = 0) or (bitand(a.job_status, 1024) <>

0)) and bitand(a.flags, 4096) = 0 and a.instance_id is NULL

and (a.class_oid is null or (a.class_oid is not null and

a.class_oid in (select b.obj# from sys.scheduler$_class b

where b.affinity is null))) and decode(bitand(a.flags, 16384), 0,

a.next_run_date, a.last_enabled_time) = (select

min(decode(bitand(c.flags, 16384), 0, c.next_run_date,

c.last_enabled_time)) from (select r.flags flags, r.next_run_date

next_run_date, r.job_status job_status, r.class_oid class_oid,

r.last_enabled_time last_enabled_time, r.instance_id instance_id

from sys.scheduler$_job r UNION ALL select s.flags,

s.next_run_date, s.job_status, s.class_oid, s.last_enabled_time,

s.instance_id from sys.scheduler$_lightweight_job s UNION ALL

select 0, cast(k.next_date as timestamp with time zone), 1, NULL,

cast(k.next_date as timestamp with time zone), NULL from sys.job$

k where (:2 = 1) and (k.field1 is null or k.field1 = 0)

and k.job not in (select w.id2 from v$lock w where w.type = 'JQ')) c

where bitand(c.job_status, 3) = 1 and ((bitand(c.flags, 134217728

+ 268435456) = 0) or (bitand(c.job_status, 1024) <> 0))

and bitand(c.flags, 4096) = 0 and c.instance_id is NULL and

(c.class_oid is null or (c.class_oid is not null and

c.class_oid in (select d.obj# from sys.scheduler$_class d

where d.affinity is null))))

Action

Investigate the SQL statement with SQL_ID "1rswbxwhbpmr7" for possible

performance improvements.

Related Object

SQL statement with SQL_ID 1rswbxwhbpmr7 and PLAN_HASH 2506064221.

select decode(bitand(a.flags, 16384), 0, a.next_run_date,

a.last_enabled_time), a.obj#, decode(bitand(a.flags, 16384),

0, 0, 1), a.sch_job from (select p.obj# obj#, p.flags flags,

p.next_run_date next_run_date, p.job_status job_status,

p.class_oid class_oid, p.last_enabled_time last_enabled_time,

p.instance_id instance_id, 1 sch_job from sys.scheduler$_job p

UNION ALL select q.obj#, q.flags, q.next_run_date, q.job_status,

q.class_oid, q.last_enabled_time, q.instance_id, 1 from

sys.scheduler$_lightweight_job q UNION ALL select j.job, 0,

cast(j.next_date as timestamp with time zone), 1, NULL,

cast(j.next_date as timestamp with time zone), NULL, 0 from

sys.job$ j where (:1 = 1) and (j.field1 is null or j.field1 =

0) and j.job not in (select v.id2 from v$lock v where v.type =

'JQ')) a where bitand(a.job_status, 3) = 1 and ((bitand(a.flags,

134217728 + 268435456) = 0) or (bitand(a.job_status, 1024) <>

0)) and bitand(a.flags, 4096) = 0 and a.instance_id is NULL

and (a.class_oid is null or (a.class_oid is not null and

a.class_oid in (select b.obj# from sys.scheduler$_class b

where b.affinity is null))) and decode(bitand(a.flags, 16384), 0,

a.next_run_date, a.last_enabled_time) = (select

min(decode(bitand(c.flags, 16384), 0, c.next_run_date,

c.last_enabled_time)) from (select r.flags flags, r.next_run_date

next_run_date, r.job_status job_status, r.class_oid class_oid,

r.last_enabled_time last_enabled_time, r.instance_id instance_id

from sys.scheduler$_job r UNION ALL select s.flags,

s.next_run_date, s.job_status, s.class_oid, s.last_enabled_time,

s.instance_id from sys.scheduler$_lightweight_job s UNION ALL

select 0, cast(k.next_date as timestamp with time zone), 1, NULL,

cast(k.next_date as timestamp with time zone), NULL from sys.job$

k where (:2 = 1) and (k.field1 is null or k.field1 = 0)

and k.job not in (select w.id2 from v$lock w where w.type = 'JQ')) c

where bitand(c.job_status, 3) = 1 and ((bitand(c.flags, 134217728

+ 268435456) = 0) or (bitand(c.job_status, 1024) <> 0))

and bitand(c.flags, 4096) = 0 and c.instance_id is NULL and

(c.class_oid is null or (c.class_oid is not null and

c.class_oid in (select d.obj# from sys.scheduler$_class d

where d.affinity is null))))

Rationale

SQL statement with SQL_ID "1rswbxwhbpmr7" was executed 209 times and had

an average elapsed time of 0.07 seconds.

Recommendation 5: SQL Tuning

Estimated benefit is 0 active sessions, 3.34% of total activity.

----------------------------------------------------------------

Action

Investigate the SQL statement with SQL_ID "3am9cfkvx7gq1" for possible

performance improvements.

Related Object

SQL statement with SQL_ID 3am9cfkvx7gq1.

CALL MGMT_ADMIN_DATA.EVALUATE_MGMT_METRICS(:target_guid,:metric_guid,

:metric_values)

Rationale

SQL statement with SQL_ID "3am9cfkvx7gq1" was executed 167 times and had

an average elapsed time of 0.087 seconds.

Impact is .02 active sessions, 37.36% of total activity.

说明这个事件在快照范围内影响2%的活动回话，对数据库影响为37.36%。

SQL statements consuming significant database time were found.

说明找到了占用数据库资源较大的SQL。

Recommendation 1: SQL Tuning

Estimated benefit is .01 active sessions, 23.39% of total activity.

Recommendation就是Oracle给出的建议，这里建议使用SQL Tuning来解决SQL性能问题，下面预计能够解决1%的会话的问题，有效性为23.39%。

Action

Investigate the SQL statement with SQL_ID "a9bacd1uu35ga" for possible

performance improvements.

Related Object

SQL statement with SQL_ID a9bacd1uu35ga and PLAN_HASH 2060173346.

SELECT /*+NESTED_TABLE_GET_REFS+*/ "PM4H_AD"."SYS_INTERGRATION".*

FROM "PM4H_AD"."SYS_INTERGRATION"

Rationale

SQL statement with SQL_ID "a9bacd1uu35ga" was executed 1 times and had

an average elapsed time of 79 seconds.

Action是基于ADDM给出的建议如何去处理问题，通过Action可以看出SQL ID为a9bacd1uu35ga有性能优化的空间。并给出了大致的SQL语句。可以通过这个SQL ID找到历史SQL并进行处理。

Rationale是ADDM给出的这个SQL的信息，可以看到这个SQL执行了1次，但是花了79秒。

针对Top SQL by DB Time这个事件ADDM总共给出了5条建议，都是不同的SQL，基于上面的方法就可以找出SQL并进行优化。

可以通过select*from v$sqltext t where t.SQL_ID=''来根据SQLID查询SQL语句。

③附加信息

Miscellaneous Information

-------------------------

Wait class "Application" was not consuming significant database time.

Wait class "Commit" was not consuming significant database time.

Wait class "Concurrency" was not consuming significant database time.

Wait class "Configuration" was not consuming significant database time.

Wait class "Network" was not consuming significant database time.

Session connect and disconnect calls were not consuming significant database

time.

Miscellaneous Information是ADDM给出的一些Oracle其他不是瓶颈的信息，就是说明这些事件没有过多占用数据库的资源。

3.2 进阶诊断

本节主要介绍如何根据之前判断出的初步结论，进一步收集信息，进行进一步分析，从而找到问题的根因。

3.2.1 内存分析（孙）

● 通过AWR报告中的Cache Sizes、Advisory Statistics等章节分析内存设置是否合适

◆ 信息收集：

第一步：用oracle用户登录系统，并登录sqlplus；

第二步：运行命令@$ORACLE_HOME/rdbms/admin/awrrpt.sql;，进行awr报告的收集。

第三步：下载awr报告，并分析。

◆ 分析：

因为Oracle 11g是自动内存管理，如果进行内存分析的话，主要看一下：SGA的调整建议、PGA的调整建议，以及SGA的主要组成部分（buffer pool和share pool）的调整建议即可。

第一步：在awr报告中搜索“Advisory Statistics”；

第二步：查看“SGA Target Advisory”部分给出的修改建议。如下图所示，建议调整为5G。调整为5G以后，物理读不会再降低。

第三步：查看“PGA Target Advisory”部分给出的修改建议。从下图可以看到，PGA无需调整。

● 通过ADDM报告查看对内存设置的建议

第一步：运行命令@$ORACLE_HOME/rdbms/admin/addmrpt.sql;，进行addm报告的收集。

第二步：下载，并分析。从addm报告中可以看到对SGA的大小的建议，也是调整为5G。

● 通过AWR报告中的SQL ordered by Sharable Memory章节找到最消耗共享内存的SQL，对这些SQL进行重点分析。

第一步：在awr报告中搜索“SQL ordered by Sharable Memory”：占用library cache（语句缓冲区）最多的sql语句。

第二步：对sql语句进行分析。如何分析？

3.2.2 IO分析（郑、房）

● 分析磁阵的划分是否存在问题

● 分析数据文件的分布是否合理，是否因分布不均导致在某些磁盘上产生IO瓶颈

● 分析Redo日志的大小和位置是否合理

● 分析表的Block信息是否正常，占用空间是否正常

● 通过AWR报告中的SQL ordered by Reads找到物理读最大的SQL，对这些SQL进行重点分析

● 通过AWR报告中的IO Stats分析各表空间和文件的IO是否存在异常

3.2.3 CPU分析（黄）

1) 查看AWR报告中的Top 5 Timed Foreground Events，查看DB CPU占DB Time的百分比，如果DB CPU占比较低，则需要重点分析其它的等待事件。等待事件主要分为以下几类：

a) IO类：如db file sequential read等，是由于等待IO读写导致的，可能原因是SQL执行计划不对，导致大量全表扫描或快速索引全扫描，也有可能是Buffer_cache大小不合适，导致大量的物理读。

b) Redo类：如log file sync等，是由于Redo日志的相关读写等待导致的，可能原因是Redo日志写入量过大，写入不及时，也有可能是Redo日志个数及大小不足，导致Redo日志无法切换等。

c) Cluster类：如gc cr multi block request等，是由于两台RAC机器在争用共享资源产生的等待，可能原因是程序设计问题。

d) 其它类：编译对象、truncate、自动段管理等Oracle内部操作也会产生一些等待事件，消耗CPU资源。

2) 如果DB CPU占比较高，但CPU整体负载仍然很高，则需分析CPU消耗在哪一部分。首先需要观察的是硬解析，可以通过AWR报告中的Load Profile观察每秒硬解析的数量，也可以通过AWR报告中的Time Model Statistics，查看hard parse elapsed time的时间。如果硬解析较高，可能的原因有两个：一是存在大量没有使用绑定变量的SQL导致重复硬解析；二是Shared_pool大小不足，导致SQL被快速置换出。

3) 如果硬解析没有占用大量的CPU时间，则需要去分析消耗大量CPU的SQL，查找SQL的方式是查看AWR报告中SQL ordered by CPU Time列表中的内容。

3.2.4 SQL分析（张）

● 通过SQL的执行计划分析SQL中存在的问题

SQL执行计划是基于CBO模式下，对SQL进行优化的工具，在执行计划中，能看到Oracle对SQ条件的处理方式。

要生成正确的执行计划，必须对查询的表进行统计信息的收集，否则执行计划将不准确。

下面以汇总模块网元间汇总的示例：

mergeinto INDICATOR_11547_1 tt
using(select t1.*, t2.INSTANCE_NUMBER
from(SELECT NVL(summarypath.outputmo, 'UnknowMOEntityid') moentityid,
input.startday,
input.starttime,
SUM(INDICATOR_11538_1_006) INDICATOR_11538_1_006,
SUM(INDICATOR_11538_1_004) INDICATOR_11538_1_004,
SUM(INDICATOR_11538_1_005) INDICATOR_11538_1_005,
SUM(INDICATOR_11538_1_003) INDICATOR_11538_1_003,
SUM(INDICATOR_11538_1_008) INDICATOR_11538_1_008,
SUM(INDICATOR_11538_1_001) INDICATOR_11538_1_001,
SUM(INDICATOR_11538_1_002) INDICATOR_11538_1_002,
SUM(INDICATOR_11538_1_007) INDICATOR_11538_1_007,
max(state) state
FROM(SELECT t1.moentityid,
t0.moentitycode,
t1.startday,
starttime,
1 state,
INDICATOR_11538_1_006,
INDICATOR_11538_1_001,
INDICATOR_11538_1_003,
INDICATOR_11538_1_007,
INDICATOR_11538_1_005,
INDICATOR_11538_1_008,
INDICATOR_11538_1_002,
INDICATOR_11538_1_004
FROM(select moentityid, moentitycode
from pm4h_db.qtm_modata_p) t0,
pm4h_db.indicator_11538_1 t1
WHERE t1.moentityid = t0.moentityid
AND t1.startday = 20110910
AND t1.starttime = 210000
) input,
(select moentityid, outputmo
from pm4h_db.qtm_summarypath) summarypath
WHERE input.moentityid = summarypath.moentityid(+)
GROUPBY summarypath.outputmo,
input.startday,
input.starttime) t1,
v$instance t2
where t1.state > 0) st
on(st.moentityid = tt.moentityid and st.startday = tt.startday and st.starttime = tt.starttime)
whenmatchedthen
update
set tt.period = '3000',
tt.INDICATOR_11547_1_006 = st.INDICATOR_11538_1_006,
tt.INDICATOR_11547_1_001 = st.INDICATOR_11538_1_001,
tt.INDICATOR_11547_1_003 = st.INDICATOR_11538_1_003,
tt.INDICATOR_11547_1_007 = st.INDICATOR_11538_1_007,
tt.INDICATOR_11547_1_005 = st.INDICATOR_11538_1_005,
tt.INDICATOR_11547_1_008 = st.INDICATOR_11538_1_008,
tt.INDICATOR_11547_1_002 = st.INDICATOR_11538_1_002,
tt.INDICATOR_11547_1_004 = st.INDICATOR_11538_1_004
whennotmatchedthen
insert
(moentityid,
startday,
starttime,
period,
instanceid,
tt.INDICATOR_11547_1_006,
tt.INDICATOR_11547_1_001,
tt.INDICATOR_11547_1_003,
tt.INDICATOR_11547_1_007,
tt.INDICATOR_11547_1_005,
tt.INDICATOR_11547_1_008,
tt.INDICATOR_11547_1_002,
tt.INDICATOR_11547_1_004)
values
(st.moentityid,
st.startday,
st.starttime,
3000,
st.INSTANCE_NUMBER,
st.INDICATOR_11538_1_006,
st.INDICATOR_11538_1_001,
st.INDICATOR_11538_1_003,
st.INDICATOR_11538_1_007,
st.INDICATOR_11538_1_005,
st.INDICATOR_11538_1_008,
st.INDICATOR_11538_1_002,
st.INDICATOR_11538_1_004)

生成的执行计划如下：

执行计划共有6列：

Description：描述Oracle在处理SQL时的方式；

Object owner：对象的用户；

Object name：SQL处理过程中用到的对象（包含表、视图、索引等）；

Cost：处理的成本（这是调优的关键）；

Cardinality：处理返回的基数；

Bytes：处理返回结果的大小。

执行计划第一行显示Oracle处理SQL所采用的优化器，11G里默认是ALL_ROWS。Cost显示的是处理整个SQL所花费的成本。

下面是整个SQL执行的过程，建议从里向外看，即是说整个执行计划是一个树形结构，建议从树的叶子开始看。

（1）这里叶子是QTM_SUMMARYPATH和INDICATOR_11538_1的关联，采用的是HASH JOIN连接；但是两表均采用TABLE ACCESS FULL全表扫描，没有走该表的索引，效率是非常低的，这从后面的COST里也能够看出，对于INDICATOR_11538_1这张大表，全表扫描COST为8042。QTM_SUMMARYPATH虽然也是全表扫描，但是COST只有2，且该表是临时表，可忽略不计。整个SQL直接计划最终COST为8049，在INDICATOR_11538_1表上进行全表扫描COST就为8042，可以看出整个SQL瓶颈就在INDICATOR_11538_1的查询上。

（2）向外一层是QTM_SUMMARYPATH和INDICATOR_11538_1关联的结果集与QTM_MODATA的关联查询，这里查询方式是NESTED LOOPS，且QTM_MODATA引用索引QTM_MODATA_P_IDX1。采用INDEX UNIQUE SCAN是最快的扫描方式，可以看到COST为0，几乎没有成本，所以这个查询没有问题。

（3）在向外一层是和INDICATOR_11547_1的关联，对应于SQL中的ON条件，这里也引用了INDICATOR_11547_1_G_IDX1这个索引，且采用INDEX UNIQUE SCAN扫描，成本也很低，所以这个查询没有问题。

（4）外面是一些和X$表的关联，是Oracle系统内部表的关连查询，这些就不用管了，也管不了。

解决第一个查询COST很大的问题，尝试建立索引

createindex INDICATOR_11538_1_D_IDX4 on INDICATOR_11538_1(STARTDAY,STARTTIME)

之后看执行计划：

总的COST只有157，比之前降了近80倍。

总结：

（1）对于执行计划，对于比较大的表应该尽量避免TABLE ACCESS FULL和MERGE SORT，MERGE SORT及BUFFER SORT都是在内存中完成的，如果数据量太大会占用临时大量表空间，小表可以考虑采用。

（2）大表尽量采用NESTED LOOPS，这样可以有效利用索引。但是NESTED LOOPS也要区分，尽量采用INDEX UNIQUE SCAN（最快）和INDEX RANGE SCAN；避免INDEX FULL SCAN和INDEX SKIP SCAN。

（3）等值连接尽量采用HASH JOIN，理论上最快。

● 使用SQL Tuning工具分析SQL需要优化的内容

● 使用10046事件追踪SQL执行的具体过程

Oracle 的事件很多。10046 事件主要用来跟踪SQL语句，它并不是ORACLE 官方提供

给用户的命令，在官方文档上也找不到事件的说明信息。但是用的却比较多，因为10046事件获取SQL的信息比SQL_TRACE 更多。更有利于我们对SQL的判断。

10046 事件按照收集信息内容，可以分成4个级别：

Level 1：等同于SQL_TRACE 的功能

Level 4：在Level 1的基础上增加收集绑定变量的信息

Level 8：在Level 1 的基础上增加等待事件的信息

Level 12：等同于Level 4+Level 8, 即同时收集绑定变量信息和等待事件信息。

为了使信息显示的最全，一般用以下命令：

alter session set events '10046 trace name context forever, level 8';

这条命令等于打开本回话的trace，执行完这条命令后在本回话内执行的SQL都会被记录在trace文件中。

在本回话执行完SQL后，如果想看本回话的trace，执行下面这条SQL可以找到trace文件位置。

selectdistinct t3.TRACEFILE
from v$mystat t1, v$session t2, v$process t3
where t1.SID = t2.SID
and t2.PADDR = t3.ADDR

由于trace文件不易阅读，所以找到trace后，可以用tkprof命令将trace转换一下格式。但是trace文件的信息量更大，如果想要深层了解Oracle对SQL的执行过程，可以看trace。

用下面命令转换trace文件

tkprof /opt/oracle/app/oracle/diag/rdbms/mos5200/mos5200/trace/mos5200_ora_5073.trc（trace文件） 5073.txt （这个名字是导出文件名字，可以自己取）[sys=no]

sys=no是个可选参数，默认转换是yes但是同时会导出很多Oracle系统内部处理的一些信息，比如递归SQL等，选no就不会导出这类信息。还有很多其他参数，如果需要可以添加。

这样就获取到了10046事件文件。

下面是截取的10046一段内容：

********************************************************************************

merge into INDICATOR_11547_1 tt

using (select t1.*, t2.INSTANCE_NUMBER

from (SELECT NVL(summarypath.outputmo, 'UnknowMOEntityid') moentityid,

input.startday,

input.starttime,

SUM(INDICATOR_11538_1_006) INDICATOR_11538_1_006,

SUM(INDICATOR_11538_1_004) INDICATOR_11538_1_004,

SUM(INDICATOR_11538_1_005) INDICATOR_11538_1_005,

SUM(INDICATOR_11538_1_003) INDICATOR_11538_1_003,

SUM(INDICATOR_11538_1_008) INDICATOR_11538_1_008,

SUM(INDICATOR_11538_1_001) INDICATOR_11538_1_001,

SUM(INDICATOR_11538_1_002) INDICATOR_11538_1_002,

SUM(INDICATOR_11538_1_007) INDICATOR_11538_1_007,

max(state) state

FROM (SELECT t1.moentityid,

t0.moentitycode,

t1.startday,

starttime,

1 state,

INDICATOR_11538_1_006,

INDICATOR_11538_1_001,

INDICATOR_11538_1_003,

INDICATOR_11538_1_007,

INDICATOR_11538_1_005,

INDICATOR_11538_1_008,

INDICATOR_11538_1_002,

INDICATOR_11538_1_004

FROM (select moentityid, moentitycode

from pm4h_db.qtm_modata) t0,

pm4h_db.indicator_11538_1 t1

WHERE t0.moentityid = t1.moentityid

AND t1.startday >= 20110910

AND t1.startday <= 20110910

AND t1.starttime >= 210000

AND t1.starttime < 212959) input,

(select moentityid, outputmo

from pm4h_db.qtm_summarypath) summarypath

WHERE input.moentityid = summarypath.moentityid(+)

GROUP BY summarypath.outputmo,

input.startday,

input.starttime) t1,

v$instance t2

where t1.state > 0) st

on (st.moentityid = tt.moentityid and st.startday = tt.startday and st.starttime = tt.starttime)

when matched then

update

set tt.period = '3000',

tt.INDICATOR_11547_1_006 = st.INDICATOR_11538_1_006,

tt.INDICATOR_11547_1_001 = st.INDICATOR_11538_1_001,

tt.INDICATOR_11547_1_003 = st.INDICATOR_11538_1_003,

tt.INDICATOR_11547_1_007 = st.INDICATOR_11538_1_007,

tt.INDICATOR_11547_1_005 = st.INDICATOR_11538_1_005,

tt.INDICATOR_11547_1_008 = st.INDICATOR_11538_1_008,

tt.INDICATOR_11547_1_002 = st.INDICATOR_11538_1_002,

tt.INDICATOR_11547_1_004 = st.INDICATOR_11538_1_004

when not matched then

insert

(moentityid,

startday,

starttime,

period,

instanceid,

tt.INDICATOR_11547_1_006,

tt.INDICATOR_11547_1_001,

tt.INDICATOR_11547_1_003,

tt.INDICATOR_11547_1_007,

tt.INDICATOR_11547_1_005,

tt.INDICATOR_11547_1_008,

tt.INDICATOR_11547_1_002,

tt.INDICATOR_11547_1_004)

values

(st.moentityid,

st.startday,

st.starttime,

3000,

st.INSTANCE_NUMBER,

st.INDICATOR_11538_1_006,

st.INDICATOR_11538_1_001,

st.INDICATOR_11538_1_003,

st.INDICATOR_11538_1_007,

st.INDICATOR_11538_1_005,

st.INDICATOR_11538_1_008,

st.INDICATOR_11538_1_002,

st.INDICATOR_11538_1_004)

call count cpu elapsed disk query current rows

------- ------ -------- ---------- ---------- ---------- ---------- ----------

Parse 1 0.48 1.24 1 12 4 0

Execute 1 9.98 45.11 29224 30167 6 4

Fetch 0 0.00 0.00 0 0 0 0

------- ------ -------- ---------- ---------- ---------- ---------- ----------

total 2 10.47 46.35 29225 30179 10 4

Misses in library cache during parse: 1

Optimizer mode: ALL_ROWS

Parsing user id: 83

Rows Row Source Operation

------- ---------------------------------------------------

2 MERGE INDICATOR_11547_1 (cr=30167 pr=29224 pw=29224 time=6 us)

4 VIEW (cr=30167 pr=29224 pw=29224 time=142 us)

4 MERGE JOIN CARTESIAN (cr=30167 pr=29224 pw=29224 time=139 us cost=8057 size=292700 card=100)

4 NESTED LOOPS OUTER (cr=30167 pr=29224 pw=29224 time=120 us cost=8057 size=2927 card=1)

4 MERGE JOIN CARTESIAN (cr=30157 pr=29221 pw=29221 time=8 us cost=8056 size=245 card=1)

1 MERGE JOIN CARTESIAN (cr=0 pr=0 pw=0 time=0 us cost=0 size=60 card=1)

1 FIXED TABLE FULL X$KSUXSINST (cr=0 pr=0 pw=0 time=0 us cost=0 size=26 card=1)

1 BUFFER SORT (cr=0 pr=0 pw=0 time=0 us cost=0 size=34 card=1)

1 FIXED TABLE FULL X$KVIT (cr=0 pr=0 pw=0 time=0 us cost=0 size=34 card=1)

4 BUFFER SORT (cr=30157 pr=29221 pw=29221 time=4 us cost=8056 size=185 card=1)

4 VIEW (cr=30157 pr=29221 pw=29221 time=7 us cost=8056 size=185 card=1)

4 FILTER (cr=30157 pr=29221 pw=29221 time=4 us)

4 SORT GROUP BY (cr=30157 pr=29221 pw=29221 time=3 us cost=8056 size=225 card=1)

9526 NESTED LOOPS (cr=30157 pr=29221 pw=29221 time=4588 us cost=8055 size=2451375 card=10895)

9526 HASH JOIN OUTER (cr=29457 pr=29221 pw=29221 time=2090 us cost=8053 size=1884662 card=10894)

9526 TABLE ACCESS FULL INDICATOR_11538_1 (cr=29238 pr=29221 pw=29221 time=161 us cost=8044 size=751686 card=10894)

10172 INDEX FAST FULL SCAN QTM_SUMMARYPATH_IDX1 (cr=219 pr=0 pw=0 time=99 us cost=9 size=1022840 card=9835)(object id 70095)

9526 INDEX UNIQUE SCAN QTM_MODATA_IDX1 (cr=700 pr=0 pw=0 time=0 us cost=0 size=52 card=1)(object id 70090)

4 TABLE ACCESS BY INDEX ROWID INDICATOR_11547_1 (cr=10 pr=3 pw=3 time=0 us cost=1 size=2682 card=1)

4 INDEX UNIQUE SCAN INDICATOR_11547_1_G_IDX1 (cr=6 pr=2 pw=2 time=0 us cost=0 size=0 card=1)(object id 75290)

4 BUFFER SORT (cr=0 pr=0 pw=0 time=0 us cost=8056 size=0 card=100)

1 FIXED TABLE FULL X$QUIESCE (cr=0 pr=0 pw=0 time=0 us cost=0 size=0 card=100)

Elapsed times include waiting on following events:

Event waited on Times Max. Wait Total Waited

---------------------------------------- Waited ---------- ------------

db file scattered read 434 2.04 35.94

db file sequential read 3 0.32 0.48

SQL*Net message to client 1 0.00 0.00

SQL*Net message from client 1 0.12 0.12

可以看到大致分为4部分：

（1）执行的SQL；

（2）执行分析；

从这里可以看出SQL花费的时长、物理读、逻辑读等。

call count cpu elapsed disk query current rows

------- ------ -------- ---------- ---------- ---------- ---------- ----------

Parse 1 0.48 1.24 1 12 4 0

Execute 1 9.98 45.11 29224 30167 6 4

Fetch 0 0.00 0.00 0 0 0 0

------- ------ -------- ---------- ---------- ---------- ---------- ----------

total 2 10.47 46.35 29225 30179 10 4

Misses in library cache during parse: 1

Optimizer mode: ALL_ROWS

Parsing user id: 83

CALL:代表操作类型，Parse是SQL解析（包括软硬解析），Execute是执行，Fetch是取回记录（只对Select语句有效）

Misses in library cache during parse：硬解析次数。

Optimizer mode：执行SQL使用的优化器。

Parsing user id：处理解析的用户ID。

（3）生成的执行计划；

（4）等待事件；

可以看到这个SQL等待事件有4个，主要是db file scattered read和db file sequential read，分别是全表扫描和块间等待引起的。

通过以上分析可以看出此SQL执行存在以下问题：

①存在全表扫描，导致执行时间很长；

②存在硬解析，没有绑定变量；

③有大量的物理读，这个可能是因为SGA设置过小或该表长期没有被访问导致。

3.3 故障恢复方法

4 操作方法列表

4.1 信息收集方法

4.2 分析方法

4.3 恢复方法

附录：

附录一：TOP命令详解

top命令是Linux下常用的性能分析工具，能够实时显示系统中各个进程的资源占用状况，类似于Windows的任务管理器。下面详细介绍它的使用方法。

统计信息区

前五行是系统整体的统计信息。第一行是任务队列信息，同 uptime 命令的执行结果。其内容如下：

第二、三行为进程和CPU的信息。当有多个CPU时，这些内容可能会超过两行。内容如下：

最后两行为内存信息。内容如下：

进程信息区

统计信息区域的下方显示了各个进程的详细信息。首先来认识一下各列的含义。

默认情况下仅显示比较重要的 PID、USER、PR、NI、VIRT、RES、SHR、S、%CPU、%MEM、TIME+、COMMAND 列。可以通过下面的快捷键来更改显示内容。

更改显示内容

通过 f 键可以选择显示的内容。按 f 键之后会显示列的列表，按 a-z 即可显示或隐藏对应的列，最后按回车键确定。

按 o 键可以改变列的显示顺序。按小写的 a-z 可以将相应的列向右移动，而大写的 A-Z 可以将相应的列向左移动。最后按回车键确定。

按大写的 F 或 O 键，然后按 a-z 可以将进程按照相应的列进行排序。而大写的 R 键可以将当前的排序倒转。

命令使用

1使用格式
top [-] [d] [p] [q] [c] [C] [S] [s] [n] 
2参数说明
d 指定每两次屏幕信息刷新之间的时间间隔。当然用户可以使用s交互命令来改变之。
p 通过指定监控进程ID来仅仅监控某个进程的状态。
q该选项将使top没有任何延迟的进行刷新。如果调用程序有超级用户权限，那么top将以尽可能高的优先级运行。
S 指定累计模式
s 使top命令在安全模式中运行。这将去除交互命令所带来的潜在危险。
i 使top不显示任何闲置或者僵死进程。
c 显示整个命令行而不只是显示命令名
3其他
下面介绍在top命令执行过程中可以使用的一些交互命令。从使用角度来看，熟练的掌握这些命令比掌握选项还重要一些。这些命令都是单字母的，如果在命令行选项中使用了s选项，则可能其中一些命令会被屏蔽掉。
Ctrl+L 擦除并且重写屏幕。
h或者? 显示帮助画面，给出一些简短的命令总结说明。
k 终止一个进程。系统将提示用户输入需要终止的进程PID，以及需要发送给该进程什么样的信号。一般的终止进程可以使用15信号；如果不能正常结束那就使用信号9强制结束该进程。默认值是信号15。在安全模式中此命令被屏蔽。
i 忽略闲置和僵死进程。这是一个开关式命令。
q 退出程序。
r 重新安排一个进程的优先级别。系统提示用户输入需要改变的进程PID以及需要设置的进程优先级值。输入一个正值将使优先级降低，反之则可以使该进程拥有更高的优先权。默认值是10。
S 切换到累计模式。
s 改变两次刷新之间的延迟时间。系统将提示用户输入新的时间，单位为s。如果有小数，就换算成m s。输入0值则系统将不断刷新，默认值是5 s。需要注意的是如果设置太小的时间，很可能会引起不断刷新，从而根本来不及看清显示的情况，而且系统负载也会大大增加。
f或者F 从当前显示中添加或者删除项目。
o或者O 改变显示项目的顺序。
l 切换显示平均负载和启动时间信息。
m 切换显示内存信息。
t 切换显示进程和CPU状态信息。

附录二：vmstat命令详解

vmstat的语法

　　其中，－V表示打印出版本信息；－n表示在周期性循环输出时，输出的头部信息仅显示一次；delay是两次输出之间的延迟时间；count是指按照这个时间间隔统计的次数。对于vmstat输出各字段的含义，可运行man vmstat查看。

Procs

　　r: 等待运行的进程数 b: 处在非中断睡眠状态的进程数 w: 被交换出去的可运行的进程数。此数由 linux 计算得出，但 linux 并不耗尽交换空间

Memory

　　swpd: 虚拟内存使用情况，单位：KB

　　free: 空闲的内存，单位KB

　　buff: 被用来做为缓存的内存数，单位：KB

Swap

　　si: 从磁盘交换到内存的交换页数量，单位：KB/秒

　　so: 从内存交换到磁盘的交换页数量，单位：KB/秒

IO

　　bi: 发送到块设备的块数，单位：块/秒

　　bo: 从块设备接收到的块数，单位：块/秒

System

　　in: 每秒的中断数，包括时钟中断

　　cs: 每秒的环境（上下文）切换次数

CPU

　　按 CPU 的总使用百分比来显示

　　us: CPU 使用时间

　　sy: CPU 系统使用时间

　　id: 闲置时间

附录三：iostat命令详解

CPU部分：

Device部分：

如果 %util 接近 100%，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘可能存在瓶颈。

比较重要的参数

%util: 一秒中有百分之多少的时间用于I/O操作，或者说一秒中有多少时间I/O队列是非空的

svctm: 平均每次设备I/O操作的服务时间

await: 平均每次设备I/O操作的等待时间

avgqu-sz: 平均I/O队列长度

如果%util接近100%，表明I/O请求太多，I/O系统已经满负荷，磁盘可能存在瓶颈，一般%util大于70%，I/O压力就比较大，读取速度有较多的wait.同时可以结合vmstat查看查看b参数(等待资源的进程数)和wa参数(IO 等待所占用的CPU时间的百分比，高过30%时IO压力高)。

await 的大小一般取决于服务时间(svctm) 以及I/O队列的长度和I/O请求的发出模式。如果 svctm 比较接近 await，说明I/O几乎没有等待时间；如果 await 远大于 svctm，说明I/O队列太长，应用得到的响应时间变慢。

形象的比喻

r/s+w/s 类似于交款人的总数

平均队列长度(avgqu-sz)类似于单位时间里平均排队人的个数

平均服务时间(svctm)类似于收银员的收款速度

平均等待时间(await)类似于平均每人的等待时间

平均I/O数据(avgrq-sz)类似于平均每人所买的东西多少

I/O操作率 (%util)类似于收款台前有人排队的时间比例

设备IO操作:总IO(io)/s = r/s(读) +w/s(写) =1.46 + 25.28=26.74

平均每次设备I/O操作只需要0.36毫秒完成，现在却需要10.57毫秒完成，因为发出的请求太多(每秒26.74个)，假如请求时同时发出的，可以这样计算平均等待时间:

平均等待时间=单个I/O服务器时间*(1+2+…+请求总数-1)/请求总数

每秒发出的I/0请求很多，但是平均队列就4，表示这些请求比较均匀，大部分处理还是比较及时

svctm 一般要小于 await (因为同时等待的请求的等待时间被重复计算了)，

svctm 的大小一般和磁盘性能有关，CPU/内存的负荷也会对其有影响，请求过多

也会间接导致 svctm 的增加。await 的大小一般取决于服务时间(svctm) 以及

I/O队列的长度和I/O请求的发出模式。如果 svctm 比较接近 await，说明

I/O几乎没有等待时间；如果 await 远大于 svctm，说明I/O队列太长，应用

得到的响应时间变慢，如果响应时间超过了用户可以容许的范围，这时可以考虑

更换更快的磁盘，调整内核 elevator 算法，优化应用，或者升级 CPU。

队列长度(avgqu-sz)也可作为衡量系统I/O负荷的指标，但由于 avgqu-sz 是

按照单位时间的平均值，所以不能反映瞬间的I/O洪水。

附录四：free命令详解

第一行:
total 物理内存总数: 4038116
used 已经使用的内存数: 4010292
free 空闲的内存数: 27824
shared 当前已经废弃不用，总是0
buffers 即Buffer Cache内存数: 205228
cached 即Page Cache内存数: 1343276

关系：total = used + free

第二行:
-/+ buffers/cache的意思相当于：
-buffers/cache 的内存数：2461788 (等于第1行的 used – buffers – cached)，实际上是应用程序所使用的内存。
+buffers/cache 的内存数: 1576328 (等于第1行的 free + buffers + cached)，是对应用程序来说还剩余的内存。

可见-buffers/cache反映的是被程序实实在在吃掉的内存，而+buffers/cache反映的是可以挪用的内存总数。
对操作系统来讲buffers/cached 都是属于被使用，所以它认为free只有27824.
对应用程序来讲是(-/+ buffers/cach).buffers/cached 是等同可用的，因为buffer/cached是为了提高程序执行的性能，当程序使用内存时，buffer/cached会很快地被使用。

第三行是交换分区swap， 列出已使用、空闲的swap.

那buffers和cached都是缓存，两者有什么区别呢？
为了提高磁盘存取效率， Linux做了一些精心的设计， 除了对dentry进行缓存(用于VFS，加速文件路径名到inode的转换)， 还采取了两种主要Cache方式：Buffer Cache和Page Cache。前者针对磁盘块的读写，后者针对文件inode的读写。这些Cache有效缩短了 I/O系统调用(比如read，write，getdents)的时间。
磁盘的操作有逻辑级（文件系统）和物理级（磁盘块），这两种Cache就是分别缓存逻辑和物理级数据的。
Page cache实际上是针对文件系统的，是文件的缓存，在文件层面上的数据会缓存到page cache。文件的逻辑层需要映射到实际的物理磁盘，这种映射关系由文件系统来完成。当page cache的数据需要刷新时，page cache中的数据交给buffer cache，因为Buffer Cache就是缓存磁盘块的。但是这种处理在2.6版本的内核之后就变的很简单了，没有真正意义上的cache操作。
Buffer cache是针对磁盘块的缓存，也就是在没有文件系统的情况下，直接对磁盘进行操作的数据会缓存到buffer cache中，例如，文件系统的元数据都会缓存到buffer cache中。
简单说来，page cache用来缓存文件数据，buffer cache用来缓存磁盘数据。在有文件系统的情况下，对文件操作，那么数据会缓存到page cache，如果直接采用dd等工具对磁盘进行读写，那么数据会缓存到buffer cache。

所以我们看linux，只要不用swap的交换空间，就不用担心自己的内存太少.如果常常swap用很多，可能你就要考虑加物理内存了.这也是linux看内存是否够用的标准.
如果是应用服务器的话，一般只看第二行，+buffers/cache，即对应用程序来说free的内存太少了，也是该考虑优化程序或加内存了。

附录五：Oracle RAC集群环境下日志文件结构

在Oracle RAC环境中，对集群中的日志的定期检查是必不可少的。通过查看集群日志，可以早期定位集群环境中出现的问题，以便将问题消灭在萌芽状态。

简单介绍一下有关Oracle集群环境中日志的结构，方便快速查找所需的日志文件。

1.Oracle集群日志藏匿之处

Oracle集群涉及的日志主要位于“$ORA_CRS_HOME/log”和“$ORACLE_HOME/log”目录中。

2.日志目录结构

RACDB1@rac1 /home/oracle$ tree -d $ORA_CRS_HOME/log

/oracle/app/crs/log

|-- crs

`-- rac1

|-- admin

|-- client

|-- crsd

|-- cssd

| |-- oclsmon

| `-- oclsomon

|-- evmd

`-- racg

|-- racgeut

|-- racgevtf

`-- racgmain

13 directories

RACDB1@rac1 /home/oracle$ tree -d $ORACLE_HOME/log

/oracle/app/oracle/product/10.2.0/db_1/log

`-- rac1

|-- client

`-- racg

|-- racgeut

|-- racgimon

|-- racgmain

`-- racgmdb

7 directories

其中“rac1”是具体的主机名。

3.日志目录功能说明

1）CRS日志存放在“$ORA_CRS_HOME/log//crsd”目录，系统会对该日志每10M进行归档一次；

2）CSS日志存放在“$ORA_CRS_HOME/log//cssd”目录，系统会对该日志每20M进行归档一次；

3）EVM日志存放在“$ORA_CRS_HOME/log//evmd”目录；

4）“$ORA_CRS_HOME/log/”和“$ORACLE_HOME/log/”目录中的racg目录中记录了RACG可执行文件对应的日志；

5）“$ORA_CRS_HOME/log//client”和“$ORACLE_HOME/log//client”目录记录了与srvctl、ocrdump、ocrconfig以及ocrcheck命令对应的日志信息。

4.Oracle集群的alert日志

类似Oracle实例的alert日志一样，Oracle集群环境中同样存在alert日志文件。该文件位于“在 $ORA_CRS_HOME/log/”目录下，命名规则为“alert.log”

该警告日志记录了有关Oracle集群的重要警告信息。

RACDB1@rac1 /oracle/app/crs/log/rac1$ tail -10f alertrac1.log

[cssd(10098)]CRS-1610:node rac2 (2) at 90% heartbeat fatal, eviction in 2.178 seconds

2010-11-15 09:09:11.264

[cssd(6656)]CRS-1605:CSSD voting file is online: /dev/raw/raw2. Details in /oracle/app/crs/log/rac1/cssd/ocssd.log.

[cssd(6656)]CRS-1601:CSSD Reconfiguration complete. Active nodes are rac1 rac2 .

2010-11-15 09:09:14.029

[evmd(5878)]CRS-1401:EVMD started on node rac1.

2010-11-15 09:09:14.868

[crsd(6015)]CRS-1012:The OCR service started on node rac1.

2010-11-15 09:09:27.545

[crsd(6015)]CRS-1201:CRSD started on node rac1.

5.小结

熟悉Oracle集群环境下日志文件的位置和功能有助于快速定位故障的位置，善用之。

附录六：Oracle的后台进程

通过如下的语句，可以看到ORACLE的所有后台进程和描述：

SQL> select name,description from v$bgprocess where paddr !=’00’

解释如下：

1. DBWn (database writer,数据库写入进程）

将数据缓冲的数据写入数据文件，是负责数据缓冲区管理的一个background process，默认数量1个，最多10个。参数为db_writer_processes

dbwr的作用：

● 通过LRU算法管理数据缓冲区，将dirty buffer写入到datafile中，维护数据缓冲区的clean，以使用户进程总能找到足够的空闲缓冲区。

● 通过延迟写数据来优化disk I/O读写。

Dbwr writes when：

·no free buffers

·dirty buffer threshold reached

·checkpoint

·tablespace offline

·time out

·drop table/truncate table

2. LGWR（log writer，日志写入进程）

将redo log buffer写入redo log file

logr的作用：

● 管理日志缓冲区，将数据库的更改写入日志文件，以便维护数据的一致性，并为数据丢失后进行恢复提供依据。

● 通过延迟写日志来优化disk I/O读写

lgwr writes when：

·3s，commit,redo log buffer 1/3，1M满时，都会触发lgwr写
·beforc dbwn writes

3. ARCH（archiver，归档进程）

当数据库运行在archivelog模式下时，将循环使用的redo log file组在被复写覆盖前进行归档备份。

arch的作用：

● 管理redo log file，归档保存因循环复写而将被覆盖的log file，为数据丢失后进行恢复提供依据。

● Arch works when：

·Redolog file switch

4. CKPT （check point,检查点进程）

负责通知dbwn和lgwr将dirty buffer写入disk，以及时消除因dbwn/lgwr延迟写所造成的数据不一致情况，确保内存中的数据块被规律地写入file，并对数据库数据库控制文件和数据文件进行更新同步（修改文件时间头部），以记录下当前的数据库结构和状态。

ckpt的作用：

● 及时保证进行延迟写，防止数据库出现不一致情况。

● 及时同步各类数据文件，防止各类数据文件出现不一致情况。

Ckpt works when:

·redolog switch

·database shutdown

·alter tablespace begin/end backup

·alter tablespace/datafile readonly

·log_checkpoint_timeout value reached

·log_checkpoint_interval value reached

5. SMON (system monitor,系统监控进程)

smon负责对数据库进行恢复操作，若上次数据库为非正常关闭，则下次启动时smon会自动读取重做日志文件，对数据库进行恢复，同时还负责在临时段或临时表空间中回收不再使用的存储空间，并将各个表空间中的空间碎片进行合并。

Smon’s works

·clean up临时空间：真正的临时段不需要clean up，但某些操作，比如create index产生的临时段当create index的session不正常终止时，此时需要smon来清理；

·Recovers transactions active against unavailable files: 这个过程和实例启动时进行的instance crash recovery(自动前滚和回滚)相似，只不过由于实例启动时某些文件无法访问，而实例启动后的某个时间这些文件可以访问时，smon就会对其执行recover；

·Coalesces free space：如使用字典管理表空间，smon负责将连续的空闲extent合并

·Performs instance recovery of a failed node in RAC: 当rac的某个节点失败时，某个剩余的节点会打开失败节点对应的redo log，进行recover;

·Cleans up OBJ$: obj$是个底层的数据字典，包括所有的数据库对象信息，很多时候，某些对象被删除时，由smon进程来clean up 该视图;

·Shrinks rollback segments：如果设置了optimal size参数，smon进程负责执行回滚段的自动收缩

·"Offlines" rollback segments：当用户offline某个回滚段，但此时该回滚断有active trancsaction，这是回滚段的状态其实是pending offline,而smon进程会定期的检查该回滚段的事务是否完成，完成即将其变为offline；

6. PMON (process monitor,进程监控进程）

pmon在用户进程出现故障时进行恢复，清除失效的用户进程，负责清理内存区域和释放该进程所使用的资源，同时监控oracle所有background process。

Smon’s works:

·connection在不正常终止时,pmon负责释放资源，rollback未提交的事务；

·监控后台进程，如果某些后台进程不正常终止，则会重启它（比如dispatcher），或者直接终止实例；

7. RECO（recovery，恢复进程）

reco用于分布式数据库，维持在分布式环境中的数据的一致性。

reco有个主要工作，就是recover那些两阶段提交的但由于网络或其它原因造成状态为prepared 的挂起事务。

当某些节点反馈yes给事务协调器可以提交时，但事务协调器还未正式发出可以提交的最后指示时，由于网络的原因，这些节点失去了和事务协调节点的联系，此时这些事务就成为了an in-doubt distributed transaction。此时，RECO就负责定期的联系事务协调器，当联系到时，就会提交或者回滚这些事务了。

8. LCKn (lock，锁进程）

在具有并行服务器环境下使用，最大可启用10个lckn进程，哟娜与实例间的封锁。

9. Dnnn （dispatcher，调度进程）

dnnn存在于MTS体系结构中，负责接受用户进程的请求，将其放入请求队列中，并为之分配一个服务进程。

10. server process服务器进程

是用户进程与服务器交互的桥梁，在oracle server与用户之间，处理用户启动用户进程（如sqlplus）后对oracle server的连接请求，用户进程不能直接连接oracle服务器，而必须通过服务器进程进行交互。

Service process的作用：

·分析并执行用户提交的sql语句

·在sga区缓存中搜索用户进程访问的数据，不存在则访问disk并将其复制在缓存中

·将数据返回给用户进程。

服务器进程的分类：

·Dedicated server process （默认）每个用户单独一份PGA

·MultiTreaded server process 多用户共用一份PGA

SQL>select server,count(*) from v$session group by server;查询当前服务器运行模式

11. Uer process （用户进程）

由用户创建，通过服务器进程连接数据库，将用户的sql语句传递给服务器进程并接收运行结果反馈给用户

12. MMON、MMNL和Mnnn：可管理性监视器（Manageability Monitor）

这些进程用于填充自动工作负载存储库（Automatic Workload Repository，AWR），这是Oracle 10g中新增的一个特性。MMNL进程会根据调度从SGA将统计结果刷新输出至数据库表。MMON进程用于“自动检测”数据库性能问题，并实现新增的自调整特性。Mnnn进程类似于作业队列的Jnnn或Qnnn进程；MMON进程会请求这些从属进程代表它完成工作。Mnnn进程本质上是临时性的，它们将根据需要来来去去。

RAC下的所有进程：

附录七：读懂alert日志

如果把从数据库的启动到数据库的关闭认为是一个完整的过程，那么一个完整的Alert日志包含如下信息：

◆ oracle的启动提示；

◆ oracle的参数提示；

◆ oracle的各个进程启动提示；

◆ oracle的启动信息

◆ oracle的各个进程的工作情况；

◆ oracle出现故障（严重错误、警告，以及一些重要的操作产生的日志）的日志；

◆ oracle的停止。

分别举例如下：

oracle的启动提示：

Wed Dec 28 09:32:41 2011

Starting ORACLE instance (normal)

LICENSE_MAX_SESSION = 0

LICENSE_SESSIONS_WARNING = 0

Interface type 1 eth1 10.10.10.0 configured from OCR for use as a cluster interconnect

Interface type 1 eth0 10.129.7.64 configured from OCR for use as a public interface

Picked latch-free SCN scheme 3

Using LOG_ARCHIVE_DEST_1 parameter default value as /opt/oracle/db/product/11g/db_1/dbs/arch

Autotune of undo retention is turned on.

LICENSE_MAX_USERS = 0

SYS auditing is disabled

Starting up ORACLE RDBMS Version: 11.1.0.7.0.

Using parameter settings in server-side pfile /opt/oracle/db/product/11g/db_1/dbs/initvmos52001.ora

oracle的参数提示：

System parameters with non-default values:

processes = 1000

sessions = 1105

shared_pool_size = 3776M

streams_pool_size = 0

_shared_pool_reserved_pct= 10

spfile = "+DATA/vmos5200/spfilevmos5200.ora"

_ksmg_granule_size = 33554432

sga_target = 10G

memory_target = 12G

memory_max_target = 12G

control_files = "+DATA/vmos5200/controlfile/current.416.766163729"

db_block_size = 8192

db_cache_size = 5376M

_db_handles_cached = 0

compatible = "11.1.0.0.0"

db_files = 1024

cluster_database = TRUE

cluster_database_instances= 2

db_create_file_dest = "+DATA"

thread = 1

undo_tablespace = "UNDOTBS1"

instance_number = 1

remote_login_passwordfile= "EXCLUSIVE"

db_domain = ""

local_listener = "LISTENER_VMOS52001"

remote_listener = "LISTENERS_VMOS5200"

cursor_sharing = "force"

audit_file_dest = "/opt/oracle/db/admin/vmos5200/adump"

audit_trail = "NONE"

db_name = "vmos5200"

open_cursors = 300

diagnostic_dest = "/opt/oracle/db"

oracle的各个进程启动提示：

Wed Dec 28 09:32:47 2011

PMON started with pid=2, OS id=16523

Wed Dec 28 09:32:47 2011

VKTM started with pid=3, OS id=16534 at elevated priority

VKTM running at (20)ms precision

Wed Dec 28 09:32:47 2011

DIAG started with pid=4, OS id=16541

Wed Dec 28 09:32:47 2011

DBRM started with pid=5, OS id=16546

Wed Dec 28 09:32:47 2011

PING started with pid=6, OS id=16551

Wed Dec 28 09:32:47 2011

PSP0 started with pid=7, OS id=16556

Wed Dec 28 09:32:47 2011

ACMS started with pid=8, OS id=16561

Wed Dec 28 09:32:47 2011

DIA0 started with pid=9, OS id=16566

Wed Dec 28 09:32:47 2011

LMON started with pid=10, OS id=16571

Wed Dec 28 09:32:48 2011

LMD0 started with pid=11, OS id=16576

Wed Dec 28 09:32:48 2011

LMS0 started with pid=12, OS id=16581 at elevated priority

Wed Dec 28 09:32:48 2011

LMS1 started with pid=13, OS id=16588 at elevated priority

Wed Dec 28 09:32:48 2011

RMS0 started with pid=14, OS id=16595

Wed Dec 28 09:32:48 2011

MMAN started with pid=15, OS id=16600

Wed Dec 28 09:32:48 2011

DBW0 started with pid=16, OS id=16605

Wed Dec 28 09:32:48 2011

DBW1 started with pid=17, OS id=16610

Wed Dec 28 09:32:48 2011

LGWR started with pid=18, OS id=16615

Wed Dec 28 09:32:48 2011

CKPT started with pid=19, OS id=16620

Wed Dec 28 09:32:48 2011

SMON started with pid=20, OS id=16625

Wed Dec 28 09:32:48 2011

RECO started with pid=21, OS id=16630

Wed Dec 28 09:32:48 2011

RBAL started with pid=22, OS id=16635

Wed Dec 28 09:32:48 2011

ASMB started with pid=23, OS id=16640

Wed Dec 28 09:32:48 2011

MMON started with pid=24, OS id=16645

Wed Dec 28 09:32:48 2011

MMNL started with pid=25, OS id=16650

Oracle的启动信息：

SUCCESS: diskgroup DATA was mounted

Database mounted in Exclusive Mode

ORACLE_BASE from environment = /opt/oracle/db

Wed Dec 28 09:32:49 2011

ALTER DATABASE MOUNT

This instance was first to mount

Database mounted in Shared Mode (CLUSTER_DATABASE=TRUE)

Completed: ALTER DATABASE MOUNT

ALTER DATABASE OPEN

This instance was first to open

oracle的各个进程的工作情况：

Wed Nov 02 15:15:52 2011

Thread 1 advanced to log sequence 2 (LGWR switch)

Current log# 2 seq# 2 mem# 0: +DATA/vmos5200/onlinelog/group_2.418.766163729

Wed Nov 02 15:16:17 2011

Thread 1 cannot allocate new log, sequence 3

Checkpoint not complete

Current log# 2 seq# 2 mem# 0: +DATA/vmos5200/onlinelog/group_2.418.766163729

Thread 1 advanced to log sequence 3 (LGWR switch)

Current log# 1 seq# 3 mem# 0: +DATA/vmos5200/onlinelog/group_1.417.766163729

oracle出现故障（严重错误、警告，以及一些重要的操作产生的日志）的日志：

Sat Nov 05 10:13:37 2011

Errors in file /opt/oracle/db/diag/rdbms/vmos5200/vmos52001/trace/vmos52001_ora_8723.trc (incident=28441):

ORA-00600: internal error code, arguments: [kksfbc-wrong-kkscsflgs], [10327733560], [45], [], [], [], [], [], [], [], [], []

Incident details in: /opt/oracle/db/diag/rdbms/vmos5200/vmos52001/incident/incdir_28441/vmos52001_ora_8723_i28441.trc

oracle的停止：

Thu Dec 15 14:42:14 2011

Shutting down instance (abort)

License high water mark = 6

USER (ospid: 6108): terminating the instance

Instance terminated by USER, pid = 6108

Thu Dec 15 14:42:16 2011

Instance shutdown complete

附录八：读懂trace文件

文件名：

示例：

vmos52001_ora_2782_i36402.trc；

vmos52001_lms0_14390_i44099.trc；

pm4h_m000_12095.trc；

pm4h _j000_660.trc

其中：

● vmos52001是实例名；

● ora是系统进程号；lms0是global cache service process 0；m000是MMON进程；j000代表oracle Job的进程号

● 2782和14390是系统进程号

● i36402和i44099是事故号

内容：

1)数据库版本：
Oracle9i Enterprise Edition Release 9.2.0.7.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.7.0 - Production
SQL>select * from v$version;

2)主机信息
ORACLE_HOME = /u01/app/oracle/product/9.2.0
System name: SunOS #主机操作系统
Node name: hostname_name #主机名
Release: 5.9 #操作系统版本
Version: Generic_117171-10 #内核版本
Machine: sun4u #主机环境

%env | grep ORACLE_HOME
%uname -ar

3)数据库信息(发生这个错误的进程，会话信息主要就靠从这里得到的信息跟踪了)
Instance name: ora #$ORACLE_SID名称，即例程名称.v$instance.instance_name
Redo thread mounted by this instance: 1 #v$instance.instance_number
Oracle process number: 34 #v$process.pid
Unix process pid: 17965, #v$process.spid，也是操作系统的进程号，trace文件名里包含了这个进程号
image: oracle@hostname_name (TNS V1-V3) #连接描述符
*** SESSION IDword/media/image25.gif396.57066) 2006-04-14 11:54:03.663 #SESSION IDword/media/image25.gif396.57066)，即是v$session里的(sid和serial#)
*** 2006-04-14 11:54:03.663 #发生错误的时间(不是会话的登陆时间)

转换：

使用ass109.awk可以转换成为容易理解的格式。示例：

awk -f ass109.awk vmos52001_diag_14350.trc

附录九：主要的内部事件号

内部事件号
1、10013：用于监视事务恢复
2、10015：转储UNDO SEGMENT头部
event = "10015 trace name context forever"
3、10029：用于给出会话期间的登陆信息
4、10030：用于给出会话期间的注销信息
5、10032：转储排序的统计信息
6、10033：转储排序增长的统计信息
7、10045：跟踪Freelist管理操作
8、10046：跟踪SQL语句
alter session set events '10046 trace name context forever, level 4'; --跟踪SQL语句并显示绑定变量
alter session set events '10046 trace name context forever, level 8'; --跟踪SQL语句并显示等待事件
9、10053：转储优化策略
10、10059：模拟redo日志中的创建和清除错误
11、10061：阻止SMON进程在启动时清除临时段
12、10079：转储 SQL*NET统计信息
13、10081：转储高水标记变化
14、10104：转储Hash连接统计信息
15、10128：转储分区休整信息
16、10200：转储一致性读信息
17、10201：转储一致性读中Undo应用
18、10209：允许在控制文件中模拟错误
19、10210：触发数据块检查事件
event = "10210 trace name context forever, level 10"
20、10211：触发索引检查事件
21、10213：模拟在写控制文件后崩溃
22、10214：模拟在控制文件中的写错误
levelnumber从1-9表示产生错误的块号，大于等于10则每个控制文件将出错
23、10215：模拟在控制文件中的读错误
24、10220：转储Undo头部变化
25、10221；转储Undo变化
26、10224：转储索引的分隔与删除
27、10225：转储基于字典管理的区间的变化
28、10229：模拟在数据文件上的I/O错误
29、10231：设置在全表扫描时忽略损坏的数据块
alter session set events '10231 trace name context off'; -- 关闭会话期间的数据块检查
event = "10231 trace name context forever, level 10" -- 对任何进程读入SGA的数据块进行检查
30、10232：将设置为软损坏（DBMS_REPAIR包设置或DB_BLOCK_CHECKING为TRUE时设置）的数据块dump到跟踪文件
31、10235：用于内存堆检查
alter session set events '10235 trace name context forever, level 1';
32、10241：转储远程SQL执行
33、10246：跟踪PMON进程
34、10248：跟踪dispatch进程
35、10249：跟踪MTS进程
36、10252：模拟写数据文件头部错误
37、10253：模拟写redo日志文件错误
38、10262：允许连接时存在内存泄漏
alter session set events '10262 trace name context forever, level 300'; -- 允许存在300个字节的内存泄漏
39、10270：转储共享游标
40、10285：模拟控制文件头部损坏
41、10286：模拟控制文件打开错误
42、10287：模拟归档出错
43、10357：调试直接路径机制
44、10500：跟踪SMON进程
45、10608：跟踪位图索引的创建
46、10704：跟踪enqueues
47、10706：跟踪全局enqueues
48、10708：跟踪RAC的buffer cache
49、10710：跟踪对位图索引的访问
50、10711：跟踪位图索引合并操作
51、10712：跟踪位图索引OR操作
52、10713：跟踪位图索引AND操作
53、10714：跟踪位图索引MINUS操作
54、10715：跟踪位图索引向ROWID的转化
55、10716：跟踪位图索引的压缩与解压
56、10719：跟踪位图索引的修改
57、10731：跟踪游标声明
58、10928：跟踪PL/SQL执行
59、10938：转储PL/SQL执行统计信息
最后要说明的是，由于版本不同以上语法可能有些变化，但大多数还是可用的