与IO相关的等待事件troubleshooting-系列5
- - CSDN博客推荐文章 这是另一种常见的等待事件. 他产生于Oracle从磁盘读取多个块到Buffer Cache中非连续("scattered")缓存的时候. 这种读一次最大值是DB_FILE_MULTIBLOCK_READ_COUNT. 这种典型场景像全表扫描(Full Table Scans)和全索引快速扫描(Fast Full Index.
与IO相关的等待事件troubleshooting-系列5
标签：
io
相关
等待
| 发表时间：2013-10-08 02:16 | 作者：bisal
出处：http://blog.csdn.net
'db file scattered read'
这是另一种常见的等待事件。他产生于Oracle从磁盘读取多个块到Buffer Cache中非连续("scattered")缓存的时候。这种读一次最大值是DB_FILE_MULTIBLOCK_READ_COUNT。这种典型场景像全表扫描(Full Table Scans)和全索引快速扫描(Fast Full Index
scans)。
如果这个等待事件占据大部分等待时间，下面的方法可以用到：
1. 找到执行全表扫描或全索引快速扫描的SQL语句，进行调优以确保这些扫描是必须的，而不是非最优执行计划导致的。
从Oracle 9i开始，新的V$SQL_PLAN视图可以帮上忙：(忽略在这些查询结果中的数据字典SQL)
对于全表扫描：
select sql_text from v$sqltext t, v$sql_plan p
where t.hash_value=p.hash_value and p.operation='TABLE ACCESS'
and p.options='FULL'
order by p.hash_value, t.piece;
where t.hash_value=p.hash_value and p.operation='TABLE ACCESS'
and p.options='FULL'
order by p.hash_value, t.piece;
对于全索引快速扫描：
elect sql_text from v$sqltext t, v$sql_plan p
where t.hash_value=p.hash_value and p.operation='INDEX'
and p.options='FULL SCAN'
order by p.hash_value, t.piece;
where t.hash_value=p.hash_value and p.operation='INDEX'
and p.options='FULL SCAN'
order by p.hash_value, t.piece;
在Oracle 8i，对于这种等待事件，通过查询V$SESSION_EVENT可以找到执行多块读的session，然后使用SQL Tracing跟踪这些session的SQL。另外，物理读Top前几位的SQL语句也能用来研究，判断他们的执行计划是否包含了全表扫描或全索引快速扫描。
2. 在这样最优执行计划就是多块读扫描的场景，可以通过调整多块IO的容量进行调优，需要修改实例参数DB_FILE_MULTIBLOCK_READ_COUNT，计算：DB_BLOCK_SIZE x DB_FILE_MULTIBLOCK_READ_COUNT
= 系统的max_io_size。
(可参考：
Document 30712.1 Init.ora Parameter "DB_FILE_MULTIBLOCK_READ_COUNT" Reference
Document 1037322.6 WHAT IS THE DB_FILE_MULTIBLOCK_READ_COUNT PARAMETER?)
正如之前所说的，从Oracle 10g R2开始，DB_FILE_MULTIBLOCK_READ_COUNT初始化参数现在可以自动调优，当未显示设置时可以使用一个默认值。这个默认值和可以高效执行的最大IO容量相关。参数值依赖于平台，对于大多数平台是1MB。因为参数是以块表示的，所以也可以设置为一个和可以高效执行的最大IO容量相当的值(被标准块容量切分)。
3. 因为使用全表扫描和全索引快速扫描的块会放到Buffer Cache取代链的最少最近使用端，有时使用多Buffer Pools，将这些段放到KEEP池中都会有所帮助。(可参考：Document 76374.1 Multiple Buffer Pools)
4. 使用分区能够降低作为分区剪裁扫描数据的数量，限制段分区的扫描子集。
5. 最后，可以考虑最长访问的段包含的数据数量(通过将旧的、不需要的数据移出数据库)，或将这些段移动到新的、更快的磁盘，以降低IO的响应时间。
(未完待续)
作者：bisal 发表于2013-10-7 18:16:54 原文链接
阅读：37 评论：0 查看评论
相关 [io 相关 等待] 推荐：
与IO相关的等待事件troubleshooting-系列3
- - CSDN博客数据库推荐文章 使用Statspack类似的工具对数据库响应时间分析之后，已经表明与IO相关的等待事件限制了系统性能，有许多的方法可以判断这种问题. 接下来的章节会介绍排查等待事件的方法. 有一些方法可以不用管特定的等待事件. 在这个章节，会介绍和解释每个方法背后的概念和基本原理.
与IO相关的等待事件troubleshooting-系列2
- - CSDN博客数据库推荐文章Troubleshooting步骤：. Troubleshooting与IO相关的等待：. 数据库性能调优方面一项关键的方法就是响应时间分析. 找出时间都花费在数据库的哪些环节. 时间是性能调优中最重要的属性. 用户通过交易或批处理任务的响应时间来感知系统的性能. Oracle的响应时间分析使用如下公式：.
与IO相关的等待事件troubleshooting-系列1
- - CSDN博客数据库推荐文章近来XX应用充分暴露出开发人员最初只关心功能，未考虑性能的问题，夜维、OLTP应用均出现了不同程度的与数据库相关的性能问题. 这个应用所在磁盘的IO较差，原因在于这块磁盘较旧，已进入更换的流程，但短期内还不能更换，对应用是个极大的隐患. 而且也出现过某段时间IO非常差，导致应用处理速度非常缓慢. 针对与IO相关的性能问题，MOS有篇文章(223117.1)介绍的就是与IO相关的troubleshooting，拜读一下.
物理IO与逻辑IO
- - 操作系统 - ITeye博客IO性能对于一个系统的影响是至关重要的. 一个系统经过多项优化以后，瓶颈往往落在数据库；而数据库经过多种优化以后，瓶颈最终会落到IO. 而IO性能的发展，明显落后于CPU的发展. Memchached也好，NoSql也好，这些流行技术的背后都在直接或者间接地回避IO瓶颈，从而提高系统性能. 上图层次比较多，但总的就是三部分.
linux异步IO浅析
- Sepher - kouu's home知道异步IO已经很久了，但是直到最近，才真正用它来解决一下实际问题（在一个CPU密集型的应用中，有一些需要处理的数据可能放在磁盘上. 预先知道这些数据的位置，所以预先发起异步IO读请求. 等到真正需要用到这些数据的时候，再等待异步IO完成. 使用了异步IO，在发起IO请求到实际使用数据这段时间内，程序还可以继续做其他事情）.
java nio和io的比较
- - 互联网 - ITeye博客第一部分：简单介绍NIO. 服务器在合理时间内处理大量客户机的请求的能力取决于服务器使用I/O流的效率，同时为成百上千的客户提供服务的服务器必须能并发的使用I/O服务. 用Java语言写的服务器，由于其线程与客户机之比几乎是一比一，因而易受到大量线程开销的影响，其结果是即导致性能问题，又缺乏伸缩性.
C++之文件IO操作流
- Nanqi - 博客园-首页原创精华区 前两节介绍了C++的IO流类库，标准设备IO操作流中部分预定义流对象的成员函数以及IO格式控制. 那今天我将继续介绍关于C++中的流操作内容——文件IO操作流fstream. 并会着重讲解C++是如何对文件进行操作的. 文件指存放在外部介质上的数据的集合. 大家都知道操作系统是以文件为单位来对数据进行管理的.
异步IO一定更好吗？
- Wolf - CNode社区在长林的文章《nodejs异步IO的实现》中提到，NodeJS通过libeio来实现IO操作的异步化，而libeio采用多线程的方式来模拟异步操作. 这里我需要强调一个观点，异步IO虽然是NodeJS一个非常重要的特点，但异步IO并不总是最好的，其他语言也一样. 在我的磁盘上有2个文件，我希望在一个程序里读取这2个文件，每次输出一个字符.
linux AIO （异步IO） 那点事儿
- zffl - CNode社区这时候进程至少会阻塞10次，而这可能会导致其他的上千个用户请求得不到处理，这当然是不能接受的.. Linux AIO 早就被提上议程，目前比较知名的有 Glibc 的 AIO 与 Kernel Native AIO. 我们用Glibc 的AIO 做个小实验，写一个简单的程序：异步方式读取一个文件，并注册异步回调函数：.