通常来说我们可以认为是全表扫描类型的读,因为根据索引读表数据的话一次只读一个block,如果这个数字过大,就表明该表找不到索引,或者只能找到有限的索引,可能是全表扫描过多,需要检查sql是否合理的利用了索引,或者是否需要建立合理的索引。 当全表扫描被限制在内存时,它们很少会进入连续的缓冲区内,而是分散于整个缓冲存储器中。尽管在特定条件下执行全表扫描可能比索引扫描更有效,但如果出现这种等待时,最好检查一下这些全表扫描是否必要,是否可以通过建立合适的索引来减少对于大表全表扫描所产生的大规模数据读取。 对于经常使用的小表,应该尽量把他们pin 在内存中,避免不必要的老化清除及重复读取。
db file sequential read: DB文件连续读取。通常显示单个块的读取(通常指索引读取),表示的是读进磁盘的block被放在连续的内存块中。 事实上大部分基本代表着单个block的读入,可以说象征着 IO 或者说通过索引读入的比较多。因为一次IO若读进多个的block,放入连续的内存块的几率是很小的,分布在不同block的大量记录被读入就会遇到此事件。因为根据索引读数据的话,假设100条记录,根据索引,不算索引本身的读,而根据索引每个值去读一下表数据,理论上最多可能产生100 buffer gets,而如果是full table scan,则100条数据完全可能在一个block里面,则几乎一次就读过这个block了,就会产生这么大的差异。 这种等待的数目很多时,可能显示表的连接顺序不佳,或者不加选择地进行索引。 对于高级事务处理(high-transaction)、调整良好(welltuned)的系统,这一数值很大是很正常的,但在某些情况下,它可能暗示着系统中存在问题。 你应当将这一等待统计量与Statspack 报告中的已知问题(如效率较低的SQL)联系起来。检查索引扫描,以保证每个扫描都是必要的,并检查多表连接的连接顺序。 DB_CACHE_SIZE 也是这些等待出现频率的决定因素。有问题的散列区域(Hash-area)连接应当出现在PGA 内存中,但它们也会消耗大量内存,从而在顺序读取时导致大量等待。它们也可能以直接路径读/写等待的形式出现。
Free Buffer Wait: 释放缓冲区。 这种等待表明系统正在等待内存中的缓冲,因为内存中已经没有可用的缓冲空间了。如果所有SQL 都得到了调优,这种等待可能表示你需要增大DB_BUFFER_CACHE。释放缓冲区等待也可能表示不加选择的SQL 导致数据溢出了带有索引块的缓冲存储器,没有为等待系统处理的特定语句留有缓冲区。 这种情况通常表示正在执行相当多数量的DML(插入/更新/删除),并且可能说明DBWR 写的速度不够快,缓冲存储器可能充满了相同缓冲器的多个版本,从而导致效率非常低。为了解决这个问题,可能需要考虑增加检查点、利用更多的DBWR 进程,或者增加物理磁盘的数量。
Buffer Busy Wait: 缓冲区忙。 该等待事件表示正在等待一个以unshareable方式使用的缓冲区,或者表示当前正在被读入buffer cache。也就是当进程想获取或者操作某个block的时候却发现被别的进程在使用而出现等待。一般来说Buffer Busy Wait不应大于1%。 检查缓冲等待统计部分(或V$WAITSTAT),看一下等待是否位于段头。如果是,可以考虑增加自由列表(freelist,对于Oracle8i DMT)或者增加freelist groups. 其修改语法为: SQL> alter table sp_item storage (freelists 2); Table altered。
对于Oracle8i而言,增加freelist参数,在很多时候可以明显缓解等待,如果使用LMT,也就是 Local Manangement Tablespace,区段的管理就相对简单还可以考虑修改数据块的pctused\pctfree值,比如增大pctfree可以扩大数据的分布,在某种程度上就可以减少热点块的竞争。
如果这一等待位于undo header,可以通过增加回滚段(rollback segment)来解决缓冲区的问题。 如果等待位于undo block上,我们可能需要检查相关应用,适当减少大规模的一致性读取,或者降低一致性读取(consistent read)的表中的数据密度或者增大DB_CACHE_SIZE。 如果等待处于data block,可以考虑将频繁并发访问的表或数据移到另一数据块或者进行更大范围的分布(可以增加pctfree 值,扩大数据分布,减少竞争),以避开这个"热点"数据块,或者可以考虑增加表中的自由列表或使用本地化管理的表空间(Locally Managed Tablespaces)。 如果等待处于索引块,应该考虑重建索引、分割索引或使用反向键索引。反向键索引在很多情况下,可以极大地缓解竞争,其原理有点类似于hash分区的功效。反向键索引(reverse key index)常建在一些值是连续增长的列上,例如列中的值是由sequence产生的。
为了防止与数据块相关的缓冲忙等待,也可以使用较小的块:在这种情况下,单个块中的记录就较少,所以这个块就不是那么"繁忙";或者可以设置更大的pctfree,使数据扩大物理分布,减少记录间的热点竞争。 在执行DML (insert/update/ delete)时,Oracle向数据块中写入信息,对于多事务并发访问的数据表,关于ITL的竞争和等待可能出现,为了减少这个等待,可以增加initrans,使用多个ITL槽。 以下是一个生产系统v$waitstat 试图所显示的等待信息: SQL> select * from v$waitstat where count<>0 or time <>0;
复制本页网址和标题,发送给你QQ/Msn的好友一起分享
上一篇:Recordset.Open方法参数介绍
下一篇:很有用的oracle 函数