版本：Oracle 11.2.0.4.0
操作系统：linux redhat 6.4
前台：Mstr
场景：
昨天开发组反馈，之前平常执行时间只需要26秒的存储，结果当前执行时间变成了35分钟。怀疑可能是环境资源被占用导致，当然也有其他问题原因比如表对应的数据量猛增，或者错误的执行计划等造成执行时间变慢等原因。当时查看临时表空间被占用情况，发现将近有百分之九十多被占用 （该Sql 段类型 为 hash 表示 Hash 连接所使用的临时段）。于是将该进程杀掉。之前存储立马执行完成。于是问题转向该进程对应的Sql如下：
select
*
FROM ia.IC_PRIVILEDGE_DETAILS_VIEW@pydb1 a, --100589
FDM.F_ZQ_SEC_PROJECTINFOMAPPING w, --8112
mdm.DIM_PROJECT Z --8112
where A.SECPROJECTID = W.SECPROJECTID
and W.PRIMARYKEY = Z.PROJ_ID
and BIZSYSNAME = 'rtSys'
AND CHANGE_CODE IN ('1', '3')
AND PROJ_STATE IN ('运行中', '已结束');
最后根据Hiht指定执行计划做了优化。
问题描述：
查看该Sql 发现执行计划中存在笛卡尔乘积（Cartesian）。
问题分析
a） 根据执行计划可以看出，首先 视图 IC_PRIVILEDGE_DETAILS_VIEW 和 DIM_PROJECT 将结果集放入到临时段（导致临时表空间被占满），最后和F_ZQ_SEC_PROJECTINFOMAPPING 做关联。而我们可以查看 视图和项目维表关联数据数据量为：815977968
b）而正确的执行计划，应当是DIM_PROJECT 和 F_ZQ_SEC_PROJECTINFOMAPPING 做关联结果集在和IC_PRIVILEDGE_DETAILS_VIEW关联。（执行计划顺序，参照Order） 。通过Hiht 指定执行计划，发现表连接顺序发生了变化，数据也立呈现。
比如：
c）可以参考查询计划中的笛卡尔积 这篇博文来，对参数笛卡尔乘积有更深的了解，我对表做了统计信息收集。发现该执行计划依旧选择视图 IC_PRIVILEDGE_DETAILS_VIEW 和 DIM_PROJECT 做关联，但是数据可以在四分钟出来，之前相当于Hang住了。而且从执行计划对比，Bytes 等确实发生了更改。说明统计信息确实存在问题。 但也没有和预想的DIM_PROJECT 和 F_ZQ_SEC_PROJECTINFOMAPPING 一样，所以还是采用了基于规则的Hiht。
1：未收集统计信息之前
2：收集统计信息之后
执行计划顺序：
可以根据上面贴出的执行计划中的Order列来判断执行顺序。下面是手工绘制执行计划图。
问题解决：
目前暂时指定基于规则的Hiht来使对表关联顺序做了调整。后续会将该视图落地。
备注：
注：BUFFER SORT不是一种排序,而是一种临时表的创建方式。
BUFFER是执行计划想要表达的重点,是其操作: 在内存中存放一张临时表。
SORT修饰BUFFER,表示具体在内存的什么地方存放临时表: 在PGA的SQL工作区里的排序区。
