我在以下oracle查询中遇到了性能问题：
select tab_a.col1,tab_a.col2,tab_b.col1 etc etc from tab_a,tab_b
where
tab_a.AS_OF = TO_DATE ('10-MAY-2013','DD-MON-YYYY')
and val.PORTFOLIO_CODE IN ('91000906', '03352', '22503', '03335', '17369', '960', '04390', '02076', '52998', '02449', '02348', '17389', 'B5000', '17077', '46400',
'B6600', '53068', '52334A', '03363', '94654', 'SOFT2', 'B9000', '17137F', '03593', '04228', '04450', '17372', '52334')
AND tab_a.NEXT_AS_AT =TO_TIMESTAMP ('12/31/9999 12:00:00.000000 AM','MM/DD/YYYY HH:MI:SS.FF6 AM')
AND tab_a.POSITION_INTERVAL_TYPE = 'E'
AND tab_a.POSITION_TYPE = 'T'
and tab_a.row_type = 0
AND tab_b.NEXT_AS_AT(+) = TO_TIMESTAMP ('12/31/9999 12:00:00.000000 AM','MM/DD/YYYY HH:MI:SS.FF6 AM')
AND tab_b.AS_OF(+) <= TO_DATE ('10-MAY-2013','DD-MON-YYYY')
AND tab_b.NEXT_AS_OF(+) > TO_DATE ('10-MAY-2013','DD-MON-YYYY')
AND tab_b.ROW_TYPE(+) = 0
AND tab_a.SECURITY_CODE_PRIMARY = tab_b.SECURITY_CODE_PRIMARY(+)
AND tab_a.SECURITY_CODE_TYPE_PRIMARY = tab_b.SECURITY_CODE_TYPE_PRIMARY(+);
我意识到每个查询都有不同的行为，我会尽量提供信息。 但是，在这一点上，我正在研究关于表格结构或where子句结构的方法的指针和方向。
环境：Oracle 11g 这两个表都通过dbms_stats更新了统计信息（索引列上的直方图：method_opt：FOR ALL INDEXED COLUMNS SIZE AUTO）。 Tab_a：在AS_OF上分区的每日范围和PORTFOLIO_CODE上的散列分区（128） Tab_b：SECURITY_CODE_PRIMARY上的散列分区（128个分区） Tab_a总量：6000万（并且还在增长） Tab_b总量：1500万（并且还在增长） 输入as_of的Tab_a的体积和与tab_a相关的其他过滤条件：约6000
Tab_b具有本地分区多列索引 - SECURITY_CODE_PRIMARY，SECURITY_CODE_TYPE_PRIMARY，NEXT_AS_AT，NEXT_AS_OF，AS_OF，ROW_TYPE Tab_A上没有任何索引，因为我注意到已经发生了有效的分区修剪（tab_a.as_of的分区范围单一，分区哈希inlist为tab_a.portfolio_codes），因此没有看到任何增加创建索引的值可能是一种矫枉过正。 预期的输出记录数量：6000
查询中以下突出显示的部分是这样的，它确保只从tab_b获得一行（我们已经实现了标记机制来识别记录，因为我们在白天的不同时间间隔获取日内数据，并且需要存储它）。 但是，我们只关注SECURITY_CODE_PRIMARY和as_of记录的最新时间间隔。 因此，下面的部分确保我们只从驱动程序表tab_a中获取每个security_code_primary的一个和最新内容，在这种情况下，大约有5000个不同的security_code_primary：
AND tab_b.NEXT_AS_AT(+) = TO_TIMESTAMP ('12/31/9999 12:00:00.000000 AM','MM/DD/YYYY HH:MI:SS.FF6 AM')
AND tab_b.AS_OF(+) <= TO_DATE ('10-MAY-2013','DD-MON-YYYY')
AND tab_b.NEXT_AS_OF(+) > TO_DATE ('10-MAY-2013','DD-MON-YYYY')
我的问题是： Tab_a似乎是精细的分区和索引方案。 我看到一个瓶颈，当它与一个像tab_b这样的结构的表连接时，我们有范围（as_of和next_as_of）。 我想对我们现有的分区方案（和索引）以及可能导致性能问题的方法有所了解。
另外，我只提供了与辅助表连接的驱动程序表的部分查询。 通常，我们的一些查询最多有8-10个表，就像tab_b一样（与tab_b一样突出显示的子句完全相同）左外连接tab_a。
查询需要10秒内的响应时间，而今天大约需要2分钟以上，我正在尝试查看还能做些什么。