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

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

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

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

就是说，这是一些（不一定完整的）值得牢记的事项：

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

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

数量本身具有质量。

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

蒂姆·戈曼（Tim Gorman）的《缩放到无限》论文是宝贵的资源。