从Oracle 10中的分区事实表优化SELECT

Question

我有一个包含8百万行的事实表，每月增加1百万行。该表已包含索引。 IBM Cognos环境使用该表来生成报告。目前我正在寻找优化表SELECT语句的方法。

首次尝试时，我对表进行了分区（每个分区都有相同的行分布）并且查询适用于分区，但由于某种原因，我的性能相同甚至更差，这很奇怪。每个查询只影响一个分区。有人可以解释如何优化这个吗？

我遇到的第二个想法是将事实表实现为索引组织表，但它必须将所有列作为主键。这没关系，会有性能提升吗？

第三个想法是以包含从星型模式连接的所有列的方式实现事实表。是否会有性能提升？

编辑：这是执行计划：

我设法将事实表FT_COSTS的访问时间减少了3倍（成本为42000，现在为14900）我创建了包含分区标准的索引之后，但在此之前我的结果比未分区的表更差。我使用此链接来解决我的分区问题Range partition skip check

从我现在看来，主要的瓶颈是GROUP BY，它将成本从34000增加到85000，这是一倍多。有没有人知道解决这个问题？

Answer 1

分区修剪对于开始工作来说可能是一个棘手的问题。

你有查询的EXPLAIN PLAN吗？它显示PARTITION RANGE SINGLE吗？如果没有，则查询忽略该分区。如果确实如此，那么你还有其他一些问题。

我的钱是在这些分支中的第一个：分区物理重新排序表。这意味着不适合分区策略的执行计划可能比未分区表更糟糕。

为了进一步了解这一点，我们需要了解一些细节。至少你的表的分区子句和你说的查询部分适合这种方法。 EXPLAIN PLAN也非常有帮助。你给我们的细节越多越好：调整就是具体细节，因为每个案例都很特殊。

---

  

“你能解释一下原因吗？   group by有如此高的成本和它如何   可以减少？ “

GROUP BY表示排序。如果你有大量数据，这可能会很昂贵，因为它需要内存 - 或磁盘写入 - 以及CPU周期。

至于降低成本，就我未见过的查询提供建议有点困难。我可以这样说：查询需要时间，使用大量数据的查询需要更长时间。调优的秘诀在于了解给定查询的合理时间量。如果查询足够快，则成本无关紧要。

Answer 2

GROUP BY实际上是GROUP BY？

解释计划表示进入GROUP BY的散列连接中的1,238,320行以及来自顶级SELECT的相同数字。这表明优化器实际上并不相信你会在这里做任何真正的聚合。

Answer 3

降低组成本通常要求您创建pe计算聚合，通常是通过创建一个或多个物化视图。

Answer 4

如果您在执行计划结束时看到，则表明已完全访问表FT_COSTS（表访问已满）。因为它是完全访问的，所以在你添加数据时所加入的所有连接中，最后成本看起来很大。我的建议是为表提供适当的索引，以便它引用索引而不是整个表来访问数据，然后看到你的性能发生了巨大的变化!!!!!