共计 2217 个字符，预计需要花费 6 分钟才能阅读完成。
本篇内容主要讲解“怎么解决数据库中没有索引导致的 DIRECT PATH READ”，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让丸趣 TV 小编来带大家学习“怎么解决数据库中没有索引导致的 DIRECT PATH READ”吧!
直接看 TOP 5 EVENTS，这是数据库问题诊断的最快捷径。
先看占 DB TIME 达 63.33% 的 direct path read 事件。等待次数 78586 次，等待总时间 3833s（约 64 分钟），而 elapsed time 只有 20 分钟。因此我们需要弄清楚是什么动作导致这么高的 direct path read。
那什么是 direct path read 呢？一般来说，数据块 BLOCK(即 ORACLE 的最小存储单元) 总是先由后台服务器进程缓冲至 buffer cache，而后才被服务器进程获取。但对于一些大表，将其缓冲至 buffer cache 势必会将 buffer cache 中的许多其它对象挤出，即 ageing out。为了避免这一情况，产生了 direct path read, 即不需要缓冲到缓存区，而是直接由服务器进程从磁盘获取。ORACLE 通过一些参数控制在何种情况下采取 direct path read。
既然 direct path read 很高，那就直接去查看对于哪些对象的 direct path read 高。通过查看 segment by direct physical reads，可以获得这一信息：
显而易见，direct physical reads 是由于访问 tbcm_catalogfile 引起的。因为 physical reads= physical reads cache + physical reads direct，因此，除了查看 segment by direct physical reads，也有必要查看一下 segment by physical reads 的情况：
Physical reads 最多的仍然是表 tbcm_catalogfile。现在我们知道了 physical reads 主要发生在哪个对象上，但仍然不知道发生在哪个业务上（即哪个 SQL 逻辑上）。即然 Physical reads 是等待最多，自然地，我们需要去查看 Physical reads 最多的 SQL 语句：
根据 SQL_ID 查看第一条 SQL 语句，其文本为：
SELECT F_ID, F_OBJECTID, F_FILELOCATION, f_filesrclocation, F_ISONSERVER, F_DATASIZE, F_PACKAGEPATH, F_SERVERID, F_ISMAINFILE, F_FILEPROPERTY, F_DIRTYPE FROM TBCM_CATALOGFILE where F_OBJECTID=: SYS_B_0 and F_PACKAGEPATH=: SYS_B_1 order by F_OBJECTID
果然与表 tbcm_catalogfile 有关，接下来，我们查看该表的相关信息。得知，该表有 4,000,000 多条记录，F_OBJECTID 字段几乎是唯一的，然而表上没有任何索引。由于没有索引，有执行上述 SQL 时，ORACLE 只有选择全表扫描的方式，而对于如此大的一张表，恰好符合了 DIRECT PATH READ 的条件，因此执行计划选择使用 DIRECT PATH READ 的方式来获取数据。如果是单个进程，事实上已经很糟了。多个进程是，同于是 direct path read，没有将 block 缓冲至缓存区，所以每个进程都得通过 direct path read 获取自己想要的数据。情况因此变得更糟。
分析完 TOP 5 EVENTS 中和第 1 名，接下来，我们分析一下第 2 名。
第 2 名是 log file sync。当发出 COMMIT 或 ROLLBACK 命令的时间，服务器进程会唤醒 LGWR 进程，LGWR 负责将 REDO BUFFER 中的日志缓存刷新到日志文件中。而 LGWR 后台进程产生的等待事件是 log file parallel write。因此一般说来，前台 log file sync 等待事件高，后台 log file parallel write 也会高，我们在 AWR 报告中验证一下：
果不其然。另外 log file parallel write 的 avg wait 为 28ms，高于 20，根据经验意味着存在日志文件 IO 急用。
继续看：
日志在 20 分钟内切换了 5 次，平均每 4 分钟切换一次，这个是远高于 15-20 分钟公认的切换一次。这说明 REDO FILE 文件可能过小。
继续看：
20 分钟之内，没有发生回退，即 user rollback=0。User calls/(user commints + user rollback) =9.87，该值小于经验值 25，说明系统是提交过于频繁的。
针对上述问题，给出以下应对办法：
在 tbcm_catalogfile 表的 F_OBJECTID,F_PACKAGEPATH 字段上创建组合索引
由于硬件无法更换，所以日志文件的 IO 争用可不管它
将日志文件从现在的 50M，改为 2G 大小
由于调整代码工作量过大，COMMIT 提交过于频繁的问题可不用管它。
调整之后，再次执行入库作业，并收集 15:00-15:15 之间的 AWR 报告。通过验看报告，上述问题解决：
到此，相信大家对“怎么解决数据库中没有索引导致的 DIRECT PATH READ”有了更深的了解，不妨来实际操作一番吧！这里是丸趣 TV 网站，更多相关内容可以进入相关频道进行查询，关注我们，继续学习！
