OracleIO问题解析.pptVIP

找到热点数据文件（磁盘）后，我们可以考虑将数据文件转移到性能更高的存储设备上去，或者利用我们上述说的条带化、RAID等存储技术来均衡IO负荷。 热点数据段 ? 从Oracle9.2开始，出现了数据段的概念。每个表和索引都存储在自己的数据段中。我们可以通过视图V$SEGMENT_STATISTICS查找物理读最多的段来找到热点数据段。通过对热点段的分析，考虑采用重建索引、分区表等方式来降低该数据段上的IO负荷。 我们还可以根据视图v$session_wait中的P1（热点段所在的数据文件号）、P2（发生db file sequential read事件的起始数据块）、P3（数据块的数量，db file sequential read读取数据块数量为1）来定位出热点段： 然后根据找出的文件号、起始数据块、数据块数量来定位出数据段： 调整Buffer Cache 如果系统中即不存在性能有问题的SQL语句，而且所有磁盘的IO负载也比较均衡（不存在热点磁盘），则我们需要考虑增加Buffer Cache来降低磁盘IO请求。 在8i，主要是根据缓存命中率（Buffer Cache Hit Ratio）来调整buffer cache。当Buffer Cache调整到一定大小，对命中率没什么影响了时，就没有必要在增大Buffer Cache了。可以通过以下语句来查看Buffer Cache命中率： 在9i中，可以利用statspack report中的Buffer Cache建议部分来调整Buffer Cache的大小。 这里，Est Physical Read Factor是估算的从磁盘物理读取次数与从buffer cache中读取的次数的比值。 从估算的图表中，当Buffer Cache的增长对该因子影响不大时，则说明无需在增大Buffer Cache，我们就可以去相应临界点的大小作为Buffer Cache的大小。上述例子中，我们可以考虑设置Buffer Cache大小为2992M。 在Oracle10g中，引入了新的内存管理特性——自动共享内存管理（Automatic Shared Memory Management ASMM）。基于这一特性，oracle能够自动根据当前的负荷计算出最优的Buffer Cache大小。 我们可以采用多尺寸缓冲池技术将热点数据段（表或索引）KEEP在缓冲池中： Housekeep历史数据 对于一些被频繁访问到的大表，我们需要定期对其做housekeep，将一些不用的、老的数据从表中移除，以减少访问的数据块。定期对含有时间轴的Transaction表做housekeep是降低IO负载的重要措施。 db file scattered read 这是另外一个常见的引起数据库IO性能问题的等待事件。 它通常发生在Oracle将“多数据块”读取到Buffer Cache中的非连续（分散的 Scattered）区域。 多数据块读就是我们上述所说的一次读取“DB_FILE_MULTIBLOCK_READ_COUNT”块数据块，前面提到，它通常发生在全表扫描（Full Table Scan）和快速全索引扫描（Fast Full Index Scan）时。 当发现db file scattered read等待事件是系统引起IO性能的主要原因时，我们可以采取以下措施对系统进行优化。 优化存在Full Table Scan和Fast Full Index Scan的SQL语句 ? 我们可以首先从statspack或者awr报告中的“SQL ordered by Reads”部分中找出存在Full Table Scan和Fast Full Index Scan的Top SQL。 因为这些Top SQL往往是整个系统的瓶颈。 从9i开始，我们还可以通过视图V$SQL_PLAN来查找系统中存在Full Table Scan和Fast Full Index Scan的SQL语句。查找Full Table Scan的语句： 查找Fast Full Index Scan的语句 Full Table Scan通常是由于以下几个原因引起的： 1、条件字段上没有索引； ? 在这种情况下，如果表的数据量比较大，我们就需要在相应字段上建立起索引。 ? 2、CBO中，对象的统计数据不正确 ? CBO中，如果对象的统计数据或者其柱状图（Histogram）信息不正确，会导致优化器计算出错误的查询计划，从而选择全表扫描。这种情况下，我们要做的就重新分析（Analyze）表、索引及字段。 3、CBO中，SQL语句中引用到了无法估算统计数据的对象 ? 在PLSQL中，可以建立一些高级的数据类型，如“TABLE OF”、ARRAY等，通过T