朋友昨天问我在对一个生产环境进程压力测试时候，当并发达到1000时候等待时间很长，怎么弄？
这是他的环境：
双机rac
M8000,128G的内存，SGA设置为64G，PGA设置为13G
测试的插入表大约有3000多万的数据量
为教育部的一个库。
———————————————–
首先就是让他先查看告警日志，看看有什么异常提示
结果并没有发现什么异常，日志是30秒切换一次
把日志扩大到6组，每组1G
依然是这样情况
采集AWR发现：
首要等待事件为：
根据上面的tx 等待事件 从index下手
接着从awr往下看，可以发现
这里的一个主键索引引起的等待事件，
采取措施：
ALTER INDEX PK_MVS_B_STUDENT REBUILD ONLINE INITRANS 32；
ALTER INDEX MVS.STUDENT INITRANS 16;
性能改善明显，提高500%
郁闷，只是价格count 就不扫描表了
SQL> create index idx_luda_zhutou_obna on zhutou(upper(object_name)) online;
Index created.
SQL> select /*+ INDEX(a IDX_LUDA_ZHUTOU_OBNA)*/ count(a.object_name)
2 from zhutou a
3 where upper(a.object_name) like ‘LUDA%’;
Execution Plan
———————————————————-
Plan hash value: 4142235787
—————————————————————————————————–
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
—————————————————————————————————–
| 0 | SELECT STATEMENT | | 1 | 66 | 158 (0)| 00:00:02 |
| 1 | SORT AGGREGATE | | 1 | 66 | | |
| 2 | TABLE ACCESS BY INDEX ROWID| ZHUTOU | 8 | 528 | 158 (0)| 00:00:02 |
|* 3 | INDEX RANGE SCAN | IDX_LUDA_ZHUTOU_OBNA | 464 | | 4 (0)| 00:00:01 |
—————————————————————————————————–
Predicate Information (identified by operation id):
—————————————————
3 – access(UPPER(“OBJECT_NAME”) LIKE ‘LUDA%’)
filter(UPPER(“OBJECT_NAME”) LIKE ‘LUDA%’)
Note
—–
– dynamic sampling used for this statement
Statistics
———————————————————-
28 recursive calls
0 db block gets
73 consistent gets
1 physical reads
0 redo size
527 bytes sent via SQL*Net to client
492 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
SQL> ^Cselect /*+ INDEX(a IDX_LUDA_ZHUTOU_OBNA)*/ count(upper(a.object_name))
SQL> from zhutou a
SP2-0734: unknown command beginning “from zhuto…” – rest of line ignored.
SQL> where upper(a.object_name) like ‘LUDA%’
SP2-0734: unknown command beginning “where uppe…” – rest of line ignored.
SQL>
SQL> select /*+ INDEX(a IDX_LUDA_ZHUTOU_OBNA)*/ count(upper(a.object_name))
2 from zhutou a
3 where upper(a.object_name) like ‘LUDA%’;
Execution Plan
———————————————————-
Plan hash value: 3214512578
——————————————————————————————
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
——————————————————————————————
| 0 | SELECT STATEMENT | | 1 | 66 | 4 (0)| 00:00:01 |
| 1 | SORT AGGREGATE | | 1 | 66 | | |
|* 2 | INDEX RANGE SCAN| IDX_LUDA_ZHUTOU_OBNA | 8 | 528 | 4 (0)| 00:00:01 |
——————————————————————————————
Predicate Information (identified by operation id):
—————————————————
2 – access(UPPER(“OBJECT_NAME”) LIKE ‘LUDA%’)
filter(UPPER(“OBJECT_NAME”) LIKE ‘LUDA%’)
Note
—–
– dynamic sampling used for this statement
Statistics
———————————————————-
4 recursive calls
0 db block gets
71 consistent gets
0 physical reads
0 redo size
534 bytes sent via SQL*Net to client
492 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
SQL>
MYSQLDUMP
在linux下的mysql在刚安装时候的默认用户都是root
导出的语句
mysql -uusername -ppassword -hlocalhost database_name > name.sql
导入的语句
mysql -uusername -ppassword -hlocalhost database_name < name.sql
1 10.*********（单实列）存在的问题：
1. 业务高峰期响应慢，处理步骤如下所示，
1.1 创建如下索引：
create index idx_ZZJGDM_20100617_sh on TAX_SI_ZZJGDM_20100617(sh,aac001) online tablespace IND_DATAEXCHANGE; create index idx_F_KBH1_aac001 on F_KBH1(aac001,ekc092) online tablespace IND_DATAEXCHANGE; create index idx_iaa2_aac001 on iaa2(aac001) online tablespace DATAEXCHANGE; create index idx_SBDI_BANKFEE_sblsh on SBDI_BANKFEE(sblsh,sbbm) online tablespace IND_SIBUSI; create index idx_ic13_aad124 on ic13(aad124,aac001,aic142) online tablespace DATAEXCHANGE; create index idx_kca1_aac001_aae140 on kca1(aac001,aae140,aae109,eae003) online tablespace DATAEXCHANGE; create index idx_userlog_aab001 on sbds_userlog(aab001,functionid,eae024) online tablespace SIBUSI; create index idx_sbds_userlog_flag on sbds_userlog(userflag) online tablespace SIBUSI;
1.2 发现oem消耗较大的数据库资源，关闭oem的job程序
exec emd_maintenance.remove_em_dbms_jobs;（要在sysman下才能关闭的一个进程）
1.3 select min(bitmapped) from ts$ where dflmaxext =:1 and bitand(flags, 1024) = 1024语句
查metalink：
Oracle Server – Enterprise Edition – Version: 10.1 to 10.2；This problem can occur on any platform. Symptoms；After the
introduction of temporary tablespace groups following query using a lot of CPU and executed many times，Cause：
Temp tablespace group uses a recursive query on ts$ to get the minimum extent size among its temp tablespaces.
Solution1> Use single temp tablespace as user’s temp tablespace.
Solution2> Apply patch for the bug 5455880
1.4 占用资源比较多，需要程序开发人员介入的SQL：
Buffer Gets Executions per Exec %Total Time (s) Time (s) SQL Id -------------- ------------ ------------ ------ -------- --------- ------------- 1,926,819 478 4,031.0 12.5 10.35 13.58 6hpkyfr0cmm4c Module: repsc2.exe SELECT "CUI" ,"REP_SERVER_NAME" ,"REP_MODE" ,"REP_BEGIN_TIME" ,"REP_END_TIME" , "REPID" ,"QUERYID" ,"PARAM_STR" ,"OP_ID" ,"OP_NAME" ,"DEP_ID" ,"DEP_NAME" , "EXEC_STATE" ,"EXEC_DESC" FROM "REPSERVERLOG" ORDER BY "CUI" ASC
该SQL执行较频率，且无任何过滤条件。
1.5 占用资源比较多，需要程序开发人员介入的SQL：
Buffer Gets Executions per Exec %Total Time (s) Time (s) SQL Id
-------------- ------------ ------------ ------ -------- --------- -------------
2,203,673 60 36,727.9 18.2 44.73 44.95 3q1h43vdhaxz9 Module: sxdb2
SELECT '330699' YYCSDM, '3' KLB, '1.00' GFBB, '91560000023306003301005D' JGDM, T
O_CHAR(B.EKC184, 'yyyymmdd') FKRQ, TO_CHAR(B.EKC185, 'yyyymmdd') KYXQ, B.EKC183KH, A.AAC002 SFZH, A.AAC003 XM, A.AAC004
XB, C.AAC005 MZ, SUBSTR(A.AAC002, 1, 6) CSD, TO_CHAR(A.AAC006, 'yyyymmdd') CSRQ, C.AAE005 LXFS, C.AAE006 JTZZ, A.EAC109
ZJLX, C.AAB027 YHBM, A.AAC001 GRBM, B.EKC101 KZT, A.AAB001 DWBM
, C.EAE033 SJHM FROM AC01 A, KCK1 B, ACA1 C WHERE A.AAC001 = B.A
AC001 AND A.AAC001 = C.AAC001 AND B.EKC101 IN ('0', '1')
表kck1，ac01，aca1无有效过滤条件，3个表全扫描，每1分钟运行1次。
1.6 占用资源较多，需要程序开发人员介入的SQL：
Buffer Gets Executions per Exec %Total Time (s) Time (s) SQL Id -------------- ------------ ------------ ------ -------- --------- ------------- 2,003,652 9 222,628.0 7.1 11.28 18.31 8yn7yvp8gdz41 UPDATE ACC8 SET AAC001=:B2 WHERE AAC001=:B1 1,259,027 9 139,891.9 4.4 8.18 33.94 6jrq2qfz2c2bb INSERT INTO ACC8MERGE SELECT * FROM ACC8 WHERE AAC001=:B1
这两个SQL单次执行逻辑读很高，怀疑:B1这个SQL绑定变量的数据类型代入有问题
1、CPU和wait time调节尺寸
当在调节system时，比较系统的CPU time 和wait time是十分重要的，从而确定在相应时间中多少是用于有效的工作时间，多少是在等待由其他进程占用的资源。
从一般规律来看，wait time占主要部分的系统比CPU time占主要部分的系统更需要调节。另一方面，CPU的大量使用可能是由不好的SQL写操作造成了。
尽管CPU time与wait time的比率总是随着系统装载的增加而趋于减小的，wait time的急剧增加是存在冲突的表现，必须被有效的处理。
给node增加更多的CPUs或是给cluster增加nodes，在资源竞争中提供的benefit是非常有限的。相反，当加载系统装载增加时，CPU time的比率没有大幅下降的系统可能规模较好，更可能通过添加CPUs或是RAC Instances获得更多的benefit。
note：如果CPU time比率在前五个事件中，则automatic workload repository（AWR）报告在Top 5 Event段中显示了CPU时间和wait 时间。
2、RAC特有的调节
尽管对于RAC有其特有的调节方法，例如互联的传输，但通过对每个Instance进行像single-Instance 系统那样的调节会带来较大的benefit。至少它应该tuning的第一步。
显然，如果在single-Instance环境中存在序列化问题，在RAC中，该问题会更加严重。
RAC-reactive调节工具主要有：特定的等待事件、系统和队列统计、database control 性能页面、statspack和AWR 报告
RAC-proactive调节工具：AWR snapshots、ADDM（Automatic Database Diagnostic Monitor）报告
如上，RAC的调节工具和single-Instance系统的基本类似。但部分特殊等待事件和统计信息的结合是RAC比较关键的调节情况。
3、分析在RAC中cache fusion（缓冲融合）的影响
在全局缓冲中访问blocks的影响和维护cache的相融合（coherency）是通过下面来表现的：
* 对当前和cr blocks的全局缓冲服务统计：例如，gc当前的blocks received、gc cr blocks received等。
* 全局缓冲服务等待事件（对gc 当前 block 3-way、gc cr grant 2-way等）
cache fusion传输的响应时间是由物理交换链接组件、IPC协议和GCS协议使用的messaging时间和processing 时间决定的。
除了相关的log写操作，它是不受磁盘I/O因素的影响的。cache fusion 协议不需要对data files进行I/O，从而确保缓冲的coherency。并且RAC并不会引起比非clustered Instance更多的I/O操作。
4、RAC操作特有的潜在因素
在RAC AWR报告中，在RAC统计一章包含了一个表，用于记录一些全局cache services和全局队列services操作的平均时间。该表被称作是Global cache and Enqueue services: workload characteristics。这些潜在因素应该得到定期的监控，并且应该对部分值的重大增加进行调查。基于经验观察，此表显示了一些代表值。引起这些潜在因素变更的因素主要有：
* IPC协议的使用。用户模式的IPC协议更快
* 当系统在CPU高效使用的情况下，时序安排的延迟
* 对当前blocks 服务的log flush
其他在AWR报告中，RAC潜在因素多数是从V$GES_STATISTICS中获得的，并可能对调试非常有效。但无需进行频繁的监控。
note：处理缓存中一致读（consistent read CR）block的时间与（build time+flush time+send time）一致；处理缓存中当前block请求的时间与（pin time+ flush time+ send time）一致。
5、RAC的等待事件
分析哪些sessions在等待是一个确定时间开销在哪里的重要方法。在RAC中，等待时间主要归因于影响获得实际请求结果的事件上。例如，当在某Instance上的一个session在Global cache查询某个block，并不知道是否将收到cache在其他Instance中的data或是是否将获得从disk上读取的消息。对于Global cache的等待事件反映了准确信息并等待全局缓冲block或是messages。它们主要是按照下述进行分类的：
* 在较广的分类的概括，被称作是cluster wait class
* 用占位符代表的临时事件，主要出现在block的等待
* 当获得请求结果的精确事件
RAC的等待事件对性能分析是非常重要的。它们被应用于ADDM中，从而获得cache fusion方面的精确诊断。
1）等待事件视图
对于一个事件的总的等待信息——V$SYSTEM_EVENT
一个session的等待事件分类——V$SESSION_WAIT_CLASS
一个session等待的事件——V$SESSION_EVENT
这三个视图汇集了等待时间、timeouts和特定事件等待次数。
最近活动的sessions的活动行为——V$ACTIVE_SESSION_HISTORY
每个活动的session最近10个等待事件——V$SESSION_WAIT_HISTORY
活动的sessions正在等待的事件——V$SESSION_WAIT
受到互联因素影响的一致的SQL语句——V$SQLAREA
这四个视图用于实时监控等待的sessions，包括最近的等待时间历史信息。
通过其name和假设的参数，来区分单个事件自己。对于多数Global cache等待事件，参数包括文件号、块号、块的类型和访问模式的配置（如held和request模式）。在这些视图中显示并统计的等待时间在调试相应时间时是非常有用的。注意，等待时间是累积计算的，有最大的该值的不一定就是问题所在。但可用的CPU被占尽或是一个Application的相应时间过长，top 等待事件提供了有效的性能诊断信息。
note：在V$SQLAREA中使用CLUSTER_WAIT_TIME字段辨别SQL语句受到互联因素的影响程度，或是在AWR snapshot上执行一个ADDM报告。
2）Global cache wait event概览
Oracle Database 10g中主要的Global cache等待事件的简要描述如下：
* gc current/cr request：当一个进程访问需要一个或者多个块时，oracle会首先检查自己的CACHE是否存在该块，如果发现没有，就会先通过global cache赋予这些块共享访问的权限，然后再访问。假如，通过global cache 发现这些块已经在另一个实例的CACHE里面，那么这些块就会通过CACHE FUSION,在节点之间直接传递，同时出现global cache cr request等待事件。current 和cr的不同，如果是读的话，那就是cr request，如果是更改的话，那就是current request。
* gc [current/cr] [2/3]-way：具体解释见后面实例
* gc [current/cr] block busy：一个current 或是 cr block被请求并收到，但LMS并没有立即发送，因为某些特定的推迟发送的情况被发现。
* gc [current/cr] grant 2-way：当请求一个block时，receive了一个message，该message应该是赋予了requester instance可以访问这个block。如果这个block没有在local cache中，则随后的动作就是去磁盘上读该block。（插一点别的，oracle的对数据的访问的控制，是在row级别和object级别，但是实际操作的对象却是block，传递的对象也是block，对于一个block，来说，会有一个master instance，也就是这个block的管理者，然后还有零到多个参与者，比如有的instance为了读一致性，可能会在自己的local cache中存着该block的过去某个时间的image，有的instace为了修改该block，可能会在自己的local cache中存着该block的past image）
* gc current grant busy：当请求一个current block时，收到grant message。该busy表示请求被阻塞，主要是其他请求在前面或是该请求不能马上被处理。
* gc [current/cr] [block/grant] congested ：无论是对于current还是cr类型block的请求，block或者grant都获得了，但是在过程中有拥堵。也就是在内部的队列中等待超过1msec（纳秒）。
* gc [current/cr] [failure/retry]：一个block被请求，却收到失败的状态或是有其他意外事件的发生。
* gc buffer busy：对此，我的理解就是gc的内存不足，有大量的block请求，需要等待将刚刚被pin入内存并使用的block unpin后再使用。（好像没理解对，看后面实例吧）
3）2-way block request实例
上图显示了当一个master Instance请求一个block，该block不在本地cache中时，具体的操作。这里假设master Instance为SGA1，SGA2中包含了请求的block。具体如下：
①SGA1向SGA2直接发送一个请求，此时，SGA1发生gc current block request等待事件
②当SGA2接到请求，它的本地LGWR进程需要flush 部分恢复信息到其本地redo log文件中。例如，如果缓冲的block被频繁的修改，该修改尚未被写入log中，LMS就需要在传输block前令LGWR对log进行flush。这可能会增加一个延迟，可能在请求的node上显示一个busy wait。
③随后，SGA2发送请求的block给SGA1。当该block到达SGA1，等待事件完成，这被反映为gs current block 2-way。
note：如果R表示在请求者的time，W为消息传输的time延迟，S为在server的time。则整个来回的总时间为：R(send) + W(small msg) + S(process msg, pocess block, send) + W(block) + R(receive block)
4）3-way block request的实例
在此，与上一个实例不同的就是block的请求者与block的master、block的缓冲不在同一个node上。所以总体时间为：
R(send) + W(small msg) + S(process msg, send) + W(small msg) + S(process msg, process block, send) + W(block) + R(receive block)
当远程读被挂起，任何在请求Instance上的尝试读写缓冲在buffer中的data 的进程将等待gc buffer busy事件，直到block到达。
5）2-way grant实例
6）considered “Lost“ Blocks实例
如图，此情况为：在请求的block到达前先收到了side channel message。在普通环境中，这是不会发生的。多数情况下它是转换问题的显示或是缺少私有互联。这常与OS或是网络的配置问题有关。
note：可尝试避免此类现象的发生，通过减小参数DB_FILE_MULTIBLOCK_READ_COUNT的值，使其低于16 。
7）Global 队列等待overview
队列等待并不是RAC特有的，但是在RAC环境中涉及到Global lock的操作。多数对队列的Global请求是同步的，并且有前台进程等待。因此，队列冲突在RAC环境中更明显。多数队列等待发生在下列类型的队列：
* TX：transaction 队列，用于事务的划分和追踪
* TM：table或是partition队列，用于保护DML执行期间table的定义
* HW：高水位线队列，取得用于新的block操作的同步
* SQ：sequence队列，用于Oracle sequence number的序列化增加
* US：undo segment 队列，主要用于自动undo 管理（AUM）的特性
* TA：主要用于事务恢复的队列
上述情况下，等待是同时的，可能造成严重的序列化，从而导致RAC环境的恶化。
6、session和system 统计
使用基于V$SYSSTAT的系统统计使得基于平均的Database描述成为可能。它是很多通过各种工具和方法获得Database的度量和比率的基础，例如AWR、statspack和Database control。
为了进一步对sessions进行深化的了解，V$SESSTAT视图是非常有用的。此外，如果使用了MODULE、ACTION模式的统计，将更有效。
V$SEGMENT_STATISTICS对于RAC环境也非常重要，因为它跟踪了CR的数量以及object当前获得的blocks
RAC相关的统计可以被分为以下几组：
* Global cache service 统计：gc cr blocks received, gc cr block recevie time等
* Global Enqueue service 统计：global enqueue gets等
* messages发送的统计：gcs messages sent和ges messages sent
可以通过查询V$ENQUEUE_STATISTICS确定哪个队列对Database service时间和最终的响应时间有最大的影响。
V$INSTANCE_CACHE_TRANSFER显示了每个block类中有多少current和CR blocks从Instance中接受，包括多少传输引起延迟。
7、RAC tuning的tips
首先，在RAC环境中，必须先利用传统的调节技术对每个Instance进行调节，此外，下面的内容也很重要：
* 尽量避免较长的全表扫描来缩小GCS的请求。由Global CR请求引起的开支主要是因为当所查询的结果在本地cache中不存在，先尝试在其他cache中尝试找到相应数据。
* 自动段空间管理可以给table blocks提供Instance 关联（affinity）
* 增加sequences的caches改善Instance关联的通过sequences获得索引关键字的值的性能。
* 当把range或是list类型的partitioning和data-dependent routing相结合，可以有效的提高性能。
* hash partitioning可有效降低buffer busy的冲突，使得buffer访问分布格局松散，可以使buffers用于更多的并发访问。
* 在RAC中，library cache和row cache操作都是全局协调的。所以过度的解析意味着额外的互联传输。当packages或是procedure需要被重新编译时，需要以排他模式获得library cache locks。
* 因为transaction locks 是全局协调的，在RAC中，也应的到特殊的对待。例如使用tables代替Oracle sequences产生唯一numbers是不推荐的，可能引起严重的冲突，即使是在single Instance系统中。
* 选择性不好的indexes不会提高查询性能，反而会降低DML操作的性能。在RAC环境中，unselective index blocks可能导致Instance间的冲突，增加cache对indexes传输的的频度。
8、index block冲突的思考
由于index多数是单调递增的，往往造成热块争用的问题；而且对于大量的insert操作，可能引起频繁的splits；所有leaf block的访问都是通过root block的。所以index可能造成性能的降低。对此：
* 全局索引hash partitioning
* 增加sequence cache，如果必要的话
9、undo block 考虑
当index blocks包含了从多个Instances发起的事务被频繁的读，过度的undo block传输和undo buffers的争用经常会发生。当一个select语句需要读取一个block，该block正被一个active的事务使用，就不得不用undo来重建一个CR版本。如果block所在的active 事务属于不只一个Instance，则需要结合本地和远程undo information用于一致读，依据被多个Instances修改的index blocks的数量和transaction的并发，undo block的传输可能成为瓶颈。
这多发生在频繁读取近期插入的数据但提交不频繁的应用中。对此应：
* 使用shorter transaction从而降低这样的可能性：从cache中获得的index block含有未提交的data，从而降低访问undo information用于一致读的可能
* 增加sequence cache size，从而减少需要进行远程undo 信息组合的需求。
10、高水位线的考虑
数据的insert操作是业务领域的主要功能，新的blocks需要频繁的分配给segment。如果data的insert操作比率较高，如果没有找到空闲空间时，需要申请新的blocks。这需要获得相应的high-water mark（HWM）队列。
因此，最为普遍的状况为：
* 较高比率的队列等待时间 enq: HW – contention
* 较高比率的等待时间对于 gc current grant events
前者是HWM队列序列化的结果，后者是由于当前访问新的data blocks是需要对新的blocks进行操作。在RAC环境中，这个空间管理操作的时间长短是与获得HW队列和获得所有新的blocks的Global locks所用的时间成比例的。这个时间在普通环境中比较小，因为在访问新的blocks时是不存在任何冲突的。然而，这种冲突可能会出现在有大量data load的业务需求中。对此，建议在本地管理及自动空间管理segments中定义一致的较大的extent size，从而适当解决相应的问题。
11、automatic workload repository
1）overview
AWR是Oracle Database 10g提供的基础服务工具，用于收集、维护和应用统计信息来检测问题并进行自我的调节。
AWR主要由两部分组成：
* 一个在内存的统计收集设施，由Oracle Database 10g使用并收集统计信息。这些统计被存储在内存中，可以通过动态性能视图查看到（V$）
* AWR snapshots 代表了设备的持久部分。可以通过data dictionary视图和Database control来访问。
处于以下几个原因，统计需要保存在永久的设备中：
* 统计需要用于激活Instance crashes
* 一些分析需要历史数据作为基线的比较
* 内存的溢出：当由于内存不足，旧的统计数据需要被新的统计数据替换时，可以将旧的统计数据存储在磁盘上以备后用
统计的内存版本由新的后台进程manageability monitor（MMON）定期的传输的disk上。通过AWR，Oracle Database提供了自动捕获历史统计data的方法，无需DBA干涉。
2）AWR tables
AWR包括两类表：
* 元数据表：用于控制、处理、描述AWR 表。例如，Oracle Database 使用元数据表来确定何时执行snapshots，并将什么数据捕获到disk上。此外，元数据包含了snapshots_id和相应通讯时间之间的映射。
* 历史统计表：存储了Oracle Database的历史统计信息。每个snapshots就是在特定时间点捕获的内存中的Database 统计数据。
AWR表的names都有 一个WRx$前缀，其中x指明了tables的种类：
* WRM$ 表存储了AWR中的元数据
* WRH$表中存储了历史数据和snapshots
可以是使用字典视图来查询AWR数据。在AWR中任何相关的历史信息有DBA_HIST_的前缀
AWR使用分区用于有效的查询和数据的清理。snapshots tables是按照以下分类组织的：file 统计、一般系统统计、并发统计、Instance调节统计、SQL 统计、segment 统计、 undo 统计、time-model 统计、恢复统计和RAC统计。
3）在RAC中的AWR snapshots
在RAC环境中，每个AWR snapshot是从所有的活动的Instances获得data的。从每个活动的Instances获得的每个snapshot数据集合是大致来自相同的时间点的。此外，每个Instance的数据是单独存储的，是以Instance的标识符来区分的。例如，buffer_busy_wait统计显示了在每个Instance上buffer waits的次数。AWR不会存储cluster中的合计数据。换句话说，data是存放在各自的Instance上的。
由AWR产生的统计snapshots可以用于评估、产生报告显示data 摘要。
12、statspack 和AWR
可以通过手工的对statspack操作获得历史统计数据。但是将statspack获得的数据迁移到AWR中是不支持的，也不存在为其创建的视图
13、Automatic Database diagnosis monitor
默认下，Database每隔60分钟，会自动的从SGA中捕获相应的统计信息，并将其以snapshots的形式存储在AWR中。这些snapshots被存储在disk上，和statspack snapshots是一致的，但比statspack的信息更精确。此外，ADDM是通过在每个Database Instance中的新的MMON进程自动运行相应的计划，来主动找到问题的所在。每次获得一个snapshot。ADDM会被触发执行一个与上一个snapshots进行阶段一致性比较的操作。
每个ADDM分析被存储在AWR中（WRI$表）也可通过EM访问。
1）ADDM问题分类
ADDM使用树形结构代表所有可能需要调节的问题。该tree是基于新的等待和时间统计模式的。树根代表的是Database当前的症状
