AWR报表解读

---awr
----------报表头信息
报表的第一部门包含了数据库本身的信息，包括数据库的名称，ID，版本号以及主机等信息。
随后是快照的开始时间和结束时间，以及有多少活动会话的信息。
缓存尺寸部分显示了缓冲区缓存的值（初始化文件中的db_cache_size）;共享池的尺寸（shared_pool_size）;标准数据块的尺寸（db_block_size）;日志缓冲区（log_buffer）

-------------负载简档

提供了负载简档每一秒和每一个事物的统计信息。这是一个监控您的系统的吞吐量和负载变化的重要部分。
当系统的负载增加时，您将看到每一秒的数字会增大。当您将系统调整为最大效率时，每个事务的统计信息
中将显示较低的数字。
负载简档可以帮助识别负载正在执行的活动类型。
1.重做数据块的增加，快更改变得频繁，以及每次读操作%block的增加，这些意味这dml活动的增加。
2.当sql语句不是在共享池中运行时，就会出现硬分析。硬分析率超过100次/秒就意味这绑定变量的效率不高，应当使用cursor_sharing初始化参数，或者说明共享池的大小有问题。
3.当sql语句时在共享池中运行时，就会出现软分析。软分析率超过300次/秒就意味着应用程序的效率不高，语句被反复地执行，而不是对每个会话应只分析语句一次，以保证高效率。

-----------------实例的效率

Instance Efficiency信息展示了许多通用的命中率的信息。dba经常检测这些参数，以便可以通过和历史数据的比较来预警系统行为的显著变化。命中率时一个用来预警最近引入系统的普通潜在问题和特定潜在问题的极佳方法。
1.Buffer Nowait %低于99%：这是一个对特定缓冲区的请求的命中率，在内存中的该缓冲区应当立即可用。如果命中率下降，在buffer wait部分中将发现当前存在（热）数据块争用的现象。
2.Buffer Hit %:低于95%：这是一个对特定缓冲区的请求的命中率，并且缓冲区位于内存中，而无需物理磁盘的I/O操作。尽管原来时作为测量内存效率的少数几种方法之一，但它仍然时一个用于展示您所需的物理磁盘I/O效率的好方法，这将有益于进一步调查性能问题的原因。但是，如果您在访问时经常使用非选择性索引，
它将使您的命中率很高，这将导致有些dba作出认为系统系能很好的错误判断。当您有效地调整了您的sql语句，并在全系统范围内使用了高校的索引，这个问题不会经常遇到，并且命中率将时一个更佳性能的指示器。
（1）命中率稳定在95%，但有一天上升到99%，这时就应该查找糟糕的sql或导致大量逻辑读操作的索引（检查负载简档和首要缓存gets sql）
（2）命中率稳定在95%,但突然下降到45%，这时就应该查找导致大量物理读操作的糟糕的sql（检查首要物理读操作sql），这些物理读操作没有使用索引或索引被删除。
3.Library Hit %低于95%:较低的库命中率通常意味着sql语句被过早地推出了缓冲池（可能是因为缓冲池太小了）。较低的命中率还意味着没有使用绑定变量或者一些其他的问题造成sql没有被重用（在这种情况下，较小的共享池时唯一的权宜之计或许可以修复所引发的库闩锁问题）。尽管声称始终降低共享池来解决库缓存和共享池闩锁问题，但哦见过的大多数千兆字节系统都有以十亿字节为单位的共享池，也没有产生任何问题，因为他们解决了sql问题。您必须解决这个问题（使用绑定变量或者cursor_sharing）并确定共享池的合适尺寸。
4.在OLTP中的In-memory Sort %低于95%：在一个OLTP系统中，您一定不想做磁盘排序。设置初始化参数pga_aggregate_target(或者sort_area_size)可有效地解决该问题
5.Soft Parse %低于95%，正如负载简档中所说的，软分析低于80%意味着sql没有被重用。并需要作进一步调查
6.Latch Hit %:低于99%通常是个大问题：找到特定的闩锁可棒子您解决该问题

------------------共享池的统计信息

显示了正使用的共享池的百分比以及重复执行多次（根据需要）的sql语句的百分比。将该数据与库，分析和闩锁数据相结合，将可帮助您确定共享池的大小。                            Begin    End
Memory Usage %:                    28.37    29.17
% SQL with executions>1:    27.77    30.45
% Memory for SQL w/exec>1:    56.64    67.74
根据上面列表中的数据，在第二次快照时，有29.17%的共享池内存在用。共享池中语句只有30%执行的次数多于一次。说明应用程序内的共享游标需要进一步提高使用效率。

---------------5个首要等待事件
报表显示了五个最重要的等待事件，等待事件的全部列表以及后台的等待时间。标识主要等待事件将帮助您将调整的努力放在系统中最紧追的问题上。
1.db file scattered(分散的，散乱的) read
db file scattered read等待事件意味着等待与全表扫描或快速全索引扫描有关。因为全表扫描时放入内存中进行的，通常情况下它不可能被放入连续的缓冲区中，所以就散步在缓冲区的缓存总。该指数的数量过大说明缺少索引或者限制使用索引。这种情况也可能是正常的，因为执行全表扫描可能比索引扫描效率更高。当您看到这些等待时。需要通过检查来确定全表扫描是否有必需的。尝试将较小的表放入缓存中，避免反复读取他们。将数据定位在磁盘系统上，这些系统有更多磁盘缓存或由OS文件系统缓存缓冲。db_file_multilock_Read_count能够让 全表扫描更快（但它也会影响oracle完成更多扫描）。您也可以将表和索引分区，以便只扫描其中一部分。缓慢的文件I/O（缓慢的磁盘也会导致这些等待。）
2.db file sequential(连续读) read
db file sequential read 等待时间通常时指单一的数据块读操作（例如，索引的读取）该值过大说明表的连接顺序很糟糕，或者使用了非选择性索引。当然，在一个高事务量，做过较好调整的系统中，该数据应该时较大的（通常情况下）。应当将则中等待与statspack报表中其他已知的问题联系起来。例如效率不高的sql。通过检查确保索引扫描时必须的，并确保多表连接的连接顺序。db_Cache_size也是一个决定性因素，它将决定这些等待出现的频率；散列区域的连接引起的问题应当体现在pga内存中，但他们会贪婪地侵占内存，直至使顺序读操作有大量的等待出现，或者他们也能揭示直接路径读/写操作出现的等待。如果数据分布在许多不同块里，范围扫描就要读取许多块（块内的密度会导致范围扫描问题，反转键索引也会产生范围扫描问题）。以排序的方式加载数据有助于范围扫描，还可以减少块读取的数量。分区也很有帮助，因为它可以排除一些块。注意非选择性索引，他们会导致许多块读取。将数据定位在磁盘系统上，这些系统有更多磁盘缓存和/或由OS文件系统缓存缓冲。
3.buffer busy waits IDs及其含义
当一个缓冲区以一种非共享方式被使用，或者正被读入缓存时，就会出现这种等待。 buffer busy waits 不应该高于1%。检查缓冲区等待的统计信息部分（或者是v$waitstat）来确认等待的位置。

（1）buffer busy segment header
（2）buffer busy undo header
（3）buffer busy undo block
（4）buffer busy data block
（5）buffer busy index block

4.latch free
闩锁时底层的队列机制（更加准确的名称应当是互斥机制），用于保护系统全局区（sga）的共享内存结构。闩锁就像内存上的锁，它可以快速的获取和释放。闩锁用于防止对共享内存结构的并行访问。如果闩锁
不可用，就会记录一次空闲闩锁丢失。绝大多数的闩锁问题都与使用绑定变量失败（库缓存闩锁和共享池闩锁），生成重做问题（重做分配闩锁），缓存的争用问题（缓存lru链）以及缓存的热数据块（缓存链）有关。闩锁与bug有关；如果您换衣时这个原因，就检查metalink的不过报告。当闩锁丢失率高于0.5%时，您应当调查一下这个问题。

5.enqueue
入列（enqueue）是保护共享资源的一种锁机制。这种锁保护共享资源。例如一条记录中的数据，以防止两个人同时更新相同的数据。它包含了一个队列机制，即先进先出（FIFO）。需要注意的是，oracle的闩锁机制不是FIFO。入列等待通常是指ST入列 HW入列  TX4入列
ST入列用于字典托管表空间的空间管理和分配。使用本地托管的表空间（LMT），或者设法预留空间，或者至少保证有问题的管理字典表空间有足够大的扩展空间。

HW入列用于一个高容量的段；手工分配扩展空间可以回避这种等待。

TX4是最常见的入列等待。TX4入列等待通常是3种问题中的某一种造成的结果。
第一个问题是唯一索引中的复制，您需要执行提交/回滚操作来释放队列。
第二种问题是对同一个位图索引段的多个更新操作，因为一个单一的位图索引段可能包含多个rowids，当多个用户试图更新同一个段时，您需要提供一个提交或回滚操作以释放入列
第三种也时最有可能的一种问题就是多个用户同时更新同一个数据块。当不同多个用户要在相同数据块的不同行上执行dml时，如果没有空闲的ITL空间，就会出现数据块级的锁。您可以很简单避免这种情况的出现，方法是通过增加initrans来创建更多的ITL空间，以及/或者通过增加表上的PCTFREE值来实现（这样oracle就能够创建所需的ITL空间）。您也可以使用更小的块的尺寸，让块中的数据行更少，因此允许数据上更大的并发性。也有其他两个不太普通的TX4等待：等待准备好的语句和索引（其中另外一个事务正在分裂索引块）中插入一行。当用户要改变块中的相同记录时，结果就是TX6锁。最后，您不再获得TM锁（当您不将外键编入索引时，他们是表锁）时，确保仍然将他们编入索引一面产生性能问题。


6.log file switch
所有的提交操作均要等待日志文件切换（归档所需要的）或日志文件切换（不完整的chkpt）。确保归档的磁盘未满，并且速度足够快。由于I/O的原因，DBWR可能很慢。您可能需要增加更多或更大的重做日志，弄且如果DBWR存在问题，您可能需要增加数据库的写入器。

7.log buffer space
发生改变时，改变的块被复制到日志缓冲区。如果日志缓冲区没有足够快地写入重做日志，就会导致log buffer space问题（备份）。当您一次提交大量数据时也会产生这个问题（让它对于这些类型的事物而言太大）这种等待出现在您写日志缓冲区的速度快于LGWR写重做日志的速度，或者时日志切换太慢了。但通常不是因为日志缓冲区太小（尽管有时这也时原因之一）。为了解决这个问题，可以增加日志文件的尺寸，或者使用更快的磁盘来写数据，但最终手段可以增加日志缓冲区的尺寸（在大型系统中，经常有好几万兆字节的日志缓冲区）您甚至可以考虑使用高速的固态硬盘。


8.log file sync日志文件同步
用户改变记录时，记录被复制到日志缓冲区。当发生提交或回滚时，LGWR将日志缓冲区的内容写入重做日志。提交将改变后的数据从日志缓冲区写入重做日志的操作，以及确认写操作成功完成，这个过程称为日志文件同步（log file sync）。为了减少日志文件的同步等待，应尝试一次提交更多的记录（如果可能的话一次提交50条记录，而不是一次一条）。如果一次提交50个记录，就需要产生50个日志文件同步。将重做日志放到更快的磁盘上，或者将重做日志放在不同的物理磁盘上，以减少LGWR归档时的影响。不要使用raid5，因为应用程序的写操作很多时，它的速度太慢；可以考虑使用直接I/O的文件系统或裸设备，他们在写信息时的速度很快。

9.global cache CR request
当使用多个实例（RAC）时，当一个实例等待另一个实例的缓存的数据块时（通过互连发送）就会发生global cache CR request。这种等待说明，当前实例在局部缓存中没有找到代码块的一致读操作（CR）版本。如果数据块不在远程缓存中，那么这种等待之后就是db file sequential read等待。

10.log file prarllel write
将重做日志放在较快的磁盘上，不要使用raid5.将重做日志与可能让他们变慢的其他数据分离，确保在热备份模式中没有保留表空间。

11.db file parallel write
固定/或加速操作系统I/O或文件系统I/O数据库写入数据库文件。

12.direct path read
oracle通常使用direct path reads直接将数据块读入PGA。它可用于排序，并行查询和提前读操作。这里的时间并不总是反映实际等待时间。这通常时文件I/O的问题（使用OS哦能够将查看一下是否有磁盘时I/Obound）。检查磁盘上而不是内存中的排序。使用异步I/O可以减少消耗时间，尽管它不会减少等待时间。

13.direct path write
直接路径写操作通常用于直接加载操作，并行dml和写入未缓存的LOB（大对象）。这里的时间并不总是反映时间等待时间。这通常时文件I/O的问题。检查磁盘上的排序。使用异步I/O可在减少消耗时间，尽管它不会减少等待时间。

14.Async disk I/O
oracle等待异步写操作完成，或等待写入的异步从属。问题可能是与DBWR（数据库写入器）LGWR（日志写入器）ARCH（归档器）或CKPT（检查点进程）有关的I/O问题，但通常是某个文件I/O问题。

15.idle event
闲置事件通常列在每一部分的底部，包括了一些像sql*net与客户端的交互信息，以及其他的与后台有关的计时信息。


------------------首要的sql语句

    SQL ordered by Elapsed Time      按Elapsed Time排序的SQL
    SQL ordered by CPU Time           按CPU Time排序的SQL
    SQL ordered by User I/O Wait Time  
    SQL ordered by Gets                    
    SQL ordered by Reads                        
    SQL ordered by Physical Reads (UnOptimized)
    SQL ordered by Executions                    
    SQL ordered by Parse Calls              
    SQL ordered by Sharable Memory      
    SQL ordered by Version Count       按Version Count排序的SQL
    Complete List of SQL Text             SQL TEXT的完整列表


------------------实例活动统计信息
比较在磁盘上执行的排序数量和在内存中执行的排序数量；增加pga_aggreagte_target(或者以前版本中的sort_area_size)的值来减少磁盘上的排序。
如果磁盘的读操作数量很高，则表明您可能执行了全表扫描。如果目前存在对大量的对较大表的全表扫描，就应当评估最常用的查询，并通过使用索引来减少这种低效率的事情发生。大量的一致性读操作意味这使用了
过多的索引或使用了非选择性索引。如果观察到的脏读缓冲区数量高于所请求的空闲缓冲区数量（超过5%），那么说明db_cache_size可能太小，或者您没有建立足够多的检查点。如果叶节点的分裂数量很高，可以考虑重建已增长或已碎片化的索引。

consistent gets 没有使用select for update子句的查询在缓存中访问的数据块数量。这个统计信息的值加上db block gets统计信息的值就是逻辑读操作（内存中缓存的所有读操作）。他们通常是数据块的当前（current）版本，也可以是一致性读操作（consistent read，CR）版本。
db block gets insert,update,delete 或者select for update 语句中缓存中访问的数据块数量。他们时数据块的当前版本。发生改变时，他们反映在‘db block changes’值中。
physical reads  没有从缓存读取的数据块数量。可以从磁盘，OS缓存或磁盘缓存读取，以满足select,select for update,insert,update,delete
dirty buffer inspected 从LRU列表中清除掉的脏读（经过修改的）数据缓冲区的数量。这里的值说明DBWR的数量不够。您可以通过增加更多DBWR来获得增益。
enqueue timeouts  请求入列的次数（锁定）以及所请求的特定队列不可用的次数。如果这个统计信息大于0，就需要调整锁定的问题。
free buffer inspected 由于时脏读数据，被固定或者正忙等原因而跳过的缓冲区数量。如果您从统计信息中减去这些值（观察到的脏读数据量和被固定的缓冲区数量），就将剩下由于闩锁的争用而无法重用的缓冲区数量。如果数量很大的话，就很好地说明缓冲区缓存太小了。
parse count 一条sql语句被解析的次数（总次数）
recursive calls 数据库中递归调用的数量。有些原因将导致这种类型的调用，例如，字典缓存中的数据丢失，动态存储的扩展以及pl/sql语句正在执行等原因。通常情况下，如果每个进程中的递归调用数量大于
4，您应当检查数据字典缓存的命中率，以及是否有表或索引的范围过大。除非大量使用了pl/sql，否则在用户调用中，递归调用所占的比例应当低于10%或更低。
redo size写入重做日志中，以字节为单位的重做信息的数量。该信息将有助于确定重做日志的大小。
sorts(disk)无法在内存中执行的排序的数量，必须在临时表空间中创建一个临时段以供排序使用。该统计信息除以内存中排序的数量不应高于5%。如果高于这个值，您应当增加init.ora文件中sort_area_size或者pga_aggregate_target的值。
sorts(memory)在内存中执行排序的数量
sort(rows)参加排序的数据行的数量
table fetch by rowid 通过使用rowid访问的数据行的数量。rowid来自一个索引，或者一个where rowid=语句。该数值很高通常意味着就获取数据的操作而言，应用程序调整得不错。
table fetch continued row获取的数据行的数量，可以是链化数据行，也可以时迁移的数据行。
如果时链化数据行，则应当尽可能快的解决掉这个问题。如果有大量的数据行相链接，会引起性能的严重劣化。
table scans (long tables)大于_small_table_threshold,并且没有使用cache子句的表。_small_table_threshold的默认值是缓存的2%。如果不仔细评估它的影响，修改_small_table_threshold参数会非常危险，因为它将引起数据块失效得更快并降低您的命中率。早oracle中，这个参数时数据块的数量，等于这个数量就认为表太小了。这个阈值用来确定直接读操作的切换点。
比它小的所有对象都不值得执行直接读操作，因此会从缓冲区缓存中读取。如果每个事务表扫描的数量都大于0，您可能要检查应用程序sql语句，并试着增加索引的使用。
table scans（short tables）short table是比缓冲区缓存的2%更短的表。oracle更喜欢在short table上进行全表扫描。

---------------------表空间和文件I/O的统计数据

在init.ora中可以设置的参数db_file_multiblock_read_count将有助于提高读取的时间。db_File_multiblock_read_count参数控制在全表扫描时，一次I/O中读入的数据块的数量。
这将减少扫描一张表所需的I/O数量，从而提高了全表扫描的性能，但是，设置db_File_multiblock_read_count参数的结果时优化器可能会执行更多的全表扫描，所以您也需要将
optimizer_index_cost_adj设置为一个数值，例如10，来消除这个问题并驱动索引的使用。

Tablespace    Reads    Av Reads/s    Av Rd(ms)    Av Blks/Rd    Writes    Av Writes/s    Buffer Waits    Av Buf Wt(ms)
SYSTEM     2,104    0    8.76    1.38    153    0    1    10.00
SYSAUX     272    0    19.56    3.92    1,550    0    0    0.00
UNDOTBS1     405    0    0.74    1.00    583    0    3    3.33
TEMP     3    0    0.00    1.00    3    0    0    0.00
USERS     5    0    2.00    1.00    0    0    0    0.00
SALE     2    0    35.00    1.00    2    0    0    0.00

Tablespace  表空间名称
Reads   从数据文件检索数据的误了读取操作次数
Av Blks/Rd 从数据文件读取数据块的读操作的平均次数
Writes  对数据文件执行写操作的次数

Tablespace    Filename    Reads    Av Reads/s    Av Rd(ms)    Av Blks/Rd    Writes    Av Writes/s    Buffer Waits    Av Buf Wt(ms)
SALE    /u01/app/oracle/oradata/orcl11g/sale.dbf     2    0    35.00    1.00    2    0    0    0.00
SYSAUX    /u01/app/oracle/oradata/orcl11g/sysaux01.dbf     272    0    19.56    3.92    1,550    0    0    0.00
SYSTEM    /u01/app/oracle/oradata/orcl11g/system01.dbf     2,104    0    8.76    1.38    153    0    1    10.00
TEMP    /u01/app/oracle/oradata/orcl11g/temp01.dbf     3    0    0.00    1.00    3    0    0    
UNDOTBS1    /u01/app/oracle/oradata/orcl11g/undotbs01.dbf     405    0    0.74    1.00    583    0    3    3.33
USERS    /u01/app/oracle/oradata/orcl11g/users01.dbf     5    0    2.00    1.00    0    0    0    0.00
如果一个数据文件获得了主要的读和写操作，那么您就可以通过在分离的磁盘上创建多个文件，或者将数据文件强制分布在多个磁盘上来提高性能。同样，不要使用raid5，否则您的写操作将显得非常缓慢。
如果一个物理磁盘上的物理读操作的数量很高，合理平衡数据将有可能提高性能。


--------------------------其他内存统计数据
Instance Recovery Stats  实例恢复统计数据
Buffer Pool Advisory   缓冲池顾问
PGA Aggr Summary   pga aggr概述
PGA Aggr Target Stats   pga aggr目标统计数据
PGA Aggr Target Histogram  pga aggr目标柱状图
PGA Memory Advisory   pga内存顾问
Shared Pool Advisory  共享池顾问
SGA Target Advisory   sga目标顾问
Streams Pool Advisory  streams池顾问
Java Pool Advisory   java池顾问
报表根据共享池（默认共享池，keep共享池以及recycle共享池）来列出缓存的统计数据，实例恢复统计数据
（重做数据块数量），以及pga内存统计数据。

-----------------------撤销统计数据

显示撤销表空间以及事务和整个表空间撤销块的数量。接着它提供了有关使用的撤销块数量信息，以及给定段（undostat行）发生的事物数量。

--------------------------闩锁统计数据

latch free
libarary cache and shared pool
redo copy
redo allocation
row cache object
cache buffers chains(CBC)
for a given block
hot blocks
cache buffers LRU chain

--------------------------在块级别的调整和查看

---------------------------段统计数据
    Segments by Logical Reads                 按逻辑读分类的段
    Segments by Physical Reads                 按物理读分类的段
    Segments by Physical Read Requests   
    Segments by UnOptimized Reads
    Segments by Optimized Reads
    Segments by Direct Physical Reads
    Segments by Physical Writes
    Segments by Physical Write Requests
    Segments by Direct Physical Writes
    Segments by Table Scans
    Segments by DB Blocks Changes
    Segments by Row Lock Waits         按Row Lock Waits分类的段
    Segments by ITL Waits              按ITL Waits分类的段
    Segments by Buffer Busy Waits      按Buffer Busy Waits分类的段
这对于查找哪个特定index或data段导致某种类型的瓶颈特别有用。但查找特定ITL（感兴趣的事物列表）等待也很难，现在在段统计数据部分，您可以看到ITL等待的准确数量
按所有者，表空间名词，对象名词和子对象名词（例如索引分区子对象名称排列）
v$segment_statistics
 
---------------------数据字典和库缓存的统计数据

数据字典的信息属于数据库中的所有对象。当sql语句分析和执行时，均要访问这些信息。该区域的活动负载应当非常重，维持一个很好的命中率时非常重要的，可以阻止递归调用返回数据库中进行权限验证。也可以通过查询v$rowcache视图来评估数据字典缓存的效率。
Namespace    Get Requests    Pct Miss    Pin Requests    Pct Miss    Reloads    Invali- dations
BODY    3,187    0.35    4,313    0.30    0    0
CLUSTER    841    0.00    159    0.00    0    0
DBLINK    6    0.00    0         0    0
EDITION    250    0.00    453    0.00    0    0
INDEX    11    0.00    7    0.00    0    0
OBJECT ID    4    100.00    0         0    0
QUEUE    189    0.00    647    0.00    0    0
RULESET    2    0.00    2    0.00    0    0
SCHEMA    845    0.36    0         0    0
SQL AREA    5,181    21.98    57,366    2.36    1    5
SUBSCRIPTION    21    0.00    21    0.00    0    0
TABLE/PROCEDURE    6,922    3.89    11,917    6.41    4    0
TRIGGER    22    0.00    184    0.00    0    0
报表中该节处理库缓存的性能情况。这些统计数据通常从v$librarycache视图中得到。库缓存包含了共享sql和pl/sql区域。这些区域的代表是booy,sqlarea,table/procedure以及trigger值。他们包含了缓存在内存中的所有sql和pl/sql语句。其他的区域由oracle使用。如果报表中
pct miss值过高，您应当提高应用程序中游标的共享程度或者增加共享池的尺寸。
Namespace库命名空间名称
Get Requests在该命名空间中系统请求对象句柄的次数
Pct Miss（get miss ratio）gethits的数量除以get的数量就是get命中率。gethits时发起对一个对象和已经在缓存中的对象的请求数。该命中率应当尽可能的接近99%。pct miss应当低于1%
Pin Requests缓存中的一个项执行的次数。您应当追求尽可能高的数字
Pct Miss（pin miss ratio）pinhits数量除以固定（pin）的数量就是固定命中率。pinhits是系统中已经存在于缓存中的对象被固定的次数。该点击率应当尽可能的接近100%。丢失率应当低于1%
Reloads在一个执行步骤中库缓存丢失的次数。重载的数量除以固定的数量应当接近于0.如果这个比率高于1%，您就应当增加共享池的尺寸
Invali- dations该命名空间中的对象因为依赖的对象被修改过而被标记为无效的次数

-------sga内存统计数据
sga用的的摘要信息（从v$sga中获得），以及在快照间隔期间内存变化的列表，报表在开始和结束的地方列出了在用的数据库初始化参数
从总体上看，报表产生了大量的数据，允许您来涉及数据库以及使用状况的简档。根据初始化过程，文件I/O以及SGA数据，您可以对数据库配置中的主要组件有更好的理解。