甲骨文中的500+百万行表有显著差异吗？

Question

我是数据仓库环境中的数据库设计人员。我习惯于处理最多有100万行的表，现在面对的是5亿行以上的表。与“效率工具箱”中的工具有什么显著差异吗？我能相信我以前对索引、分区之类的知识吗，或者这些特定工具中的一些更多地是阻碍而不是帮助处理这么大的数据呢？还有其他处理这些桌子的窍门吗？

(已经在将7亿行更新为相同值上找到了一篇很棒的文章)

Answer 1

索引等的基本原理都是以完全相同的方式工作的，所以严格地说，唯一的区别是错误的代价！

尽管如此，这里有一个(不一定是完整的)值得记住的事情清单：

• B树索引可能有一个额外的级别，因此使用它们的成本略高一些。但是，在DW中，您应该使用位图索引(假设您有企业版)。
• 计算整个表的统计值需要花费很长的时间--以至于在正常的隔夜窗口中可能不可能。这可以通过来克服
  • 在收集统计数据时使用较小的estimate_percent，因此对表的采样较少。
  • 使用增量统计数据收集(但只有在分区表上有全局索引时才相关)

• 索引的直方图仅限于254个桶。更多的行可能意味着更多不同的值，这意味着“几乎流行”的值对于倾斜的数据来说可能是一个更大的问题。
• 整个表进入缓冲区缓存的可能性接近于零，这意味着您更有可能有更多的物理(磁盘)读取。您的正常工作集也可能太大，无法缓存。
• 分区可以是你的朋友-如果你做得对！如果您通常在多个分区中修改和查询数据，那么它的开销可能会超过普通表。
• 物化视图对于减少工作集非常有用。例如，如果您拥有10+年值的数据，但是绝大多数用户查询都是针对过去两年的，那么创建一个仅限于这些数据的MV将是一个很大的帮助。
• 数据库越大，业务就越不可能(能够)为一个完整复制活动环境的测试数据库提供资金。这使得在测试中更难再现性能问题，因为缓慢的查询可能是由于数据的规模和/或物理存储造成的。您不能指望能够将查询结果从一个小得多的测试DB推断到在活动中的相应性能。

如果您还不熟悉阅读和理解执行计划，我会花一些时间学习以下内容:您在某一时刻一定会遇到性能问题，因此了解如何正确诊断问题将变得更加重要，因为当您的行数更大时，添加新索引或进行模式更改将变得更加困难。

Answer 2

数量本身就有质量。

在处理这种大小的表时，不应将事实表视为表，而应将其视为段级的表，或将其视为离散表的集合。(年龄足够大，可以记住使用分区视图滚动我自己的分区会有帮助。)

蒂姆·戈尔曼( Tim )的缩放到无限论文是一份宝贵的资源。