Oracle 中 500+ 万行表有显着差异吗？

Question

我是数据仓库环境中的数据库设计人员。我习惯于处理最多有 100 万行的表，现在面临着超过 50 亿行的表。与“效率工具箱”中的工具有什么显着差异？我可以相信我以前对索引、分区等的了解吗，或者这些特定工​​具中的一些是否比对如此大数据的帮助更多的障碍？处理表格的任何其他技巧？

（已经找到了一篇关于将7 亿行更新为相同值的好文章）

Answer 1

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

也就是说，这里有一个（不一定是完整的）值得记住的事情清单：

• B-tree 索引中很可能有额外的一层，所以使用它们的成本会稍微高一些。但是，在 DW 中，您应该使用位图索引（假设您有企业版）
• 计算整个表的统计数据需要更长的时间 - 以至于在正常的隔夜窗口中可能无法实现。这可以通过
  • estimate_percent收集统计数据时使用较小的值，因此表中的样本较少。
  • 使用增量统计信息收集（仅当您在分区表上有全局索引时才相关）
• 索引的直方图限制为 254 个桶。更多的行可能意味着更多不同的值，这意味着“几乎流行”的值对于倾斜数据可能是一个更大的问题。
• 整个表适合缓冲区缓存的可能性接近零，这意味着您更有可能进行更多物理（磁盘）读取。您的正常工作集也可能太大而无法缓存。
• 分区可以成为你的朋友 - 如果你做对了！如果您通常跨多个分区修改和查询数据，那么它可能比普通表花费更多。
• 物化视图对于减少您的工作集非常有用。例如，如果您有 10 年以上的数据，但绝大多数用户查询都与过去 2 年相反，那么创建仅限于这些数据的 MV 可能会有很大帮助。
• 数据库越大，企业就越不可能（能够）资助完全复制实时环境的测试数据库。这使得在测试中重现性能问题变得更加困难，因为缓慢的查询可能是由于数据的规模和/或物理存储。您不能指望能够将查询结果从一个小得多的测试数据库外推到相应的实时性能。

如果您还不熟悉阅读和理解执行计划，我会花一些时间来学习这些：您一定会在某个时候遇到性能问题，因此知道如何正确诊断问题将变得更加重要，因为添加新计划变得更加困难当您的行数较大时，索引或进行架构更改。