这篇文章主要讲解了“怎么解决Oracle没有索引导致的DPR”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“怎么解决Oracle没有索引导致的DPR”吧！
直接看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获取自己想要的数据。情况因此变得更糟。
解决办法：在tbcm_catalogfile表的F_OBJECTID,F_PACKAGEPATH字段上创建组合索引即可。
感谢各位的阅读，以上就是“怎么解决Oracle没有索引导致的DPR”的内容了，经过本文的学习后，相信大家对怎么解决Oracle没有索引导致的DPR这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是亿速云，小编将为大家推送更多相关知识点的文章，欢迎关注！
