我对以下 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 万（并且正在增长） Tab_a 的容量对于输入 as_of 和与 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 等 where 子句完全相同）与 tab_a 左外连接。
该查询需要不到 10 秒的响应时间，而今天大约需要 2 分钟以上，我正在尝试看看还能做什么。