3

I have two queries, one of which involves a partitioned table in the query while the other query is the same except that it involves the non-partitioned equivalent table. The original (non-partitioned table) query is performing better than the partitioned counter-part. I am not sure how to isolate the problem for this. Looking at the execution plan, I find that the indexes used are the same b/w the two queries and that the new query shows the PARTITION RANGE clause in its execution plan meaning that partition pruning is taking place. The query is of the following form:-

Select rownum, <some columns> 
from partTabA 
inner join tabB on condition1
inner join tabC on condition2
where partTabA.column1=<value> and <other conditions>
and partTabA.column2 in (select columns from tabD where conditions)

where partTabA is the partitioned table and partTabA.column1 is the partitioning key(range partition). In the original query, this gets replaced by the non-partitioned equivalent of the same table. What parameters should I look at to find out why the new query performs badly. Tool that I have is Oracle SQL Developer.

4

2 回答 2

2

PARTITION RANGE ITERATOR并不一定意味着分区修剪正在发生。您还需要查看说明计划中的Pstart和Pstop，以了解正在使用哪些分区。

分区查询会变慢有几个潜在原因，即使它正在读取相同的数据。（假设分区查询没有正确修剪，而是从整个表中读取。）

  1. 从多个本地索引读取可能比从单个更大的索引读取效率低得多。
  2. 较大的初始段大小、大量分区等可能会浪费大量空间。将段大小与此进行比较：select * from dba_segments where segment_name in ('PARTTABA', 'TABA'); 如果这是问题所在，您可能需要查看表空间设置，或使用延迟段创建。
于 2012-10-03T18:10:47.220 回答
1

我相信您正在处理分区开销，如果您有分区表，那么 oracle 必须首先找到要扫描的分区。

你能把两个执行计划都贴在这里吗？桌子有多大？此处使用的索引的选择性如何？

您是否尝试收集统计数据？

您也可以尝试查看跟踪文件以查看发生了什么。

于 2012-10-03T18:04:59.657 回答