0

甲骨文大师，

我们正在决定设计一个 500 列宽的表与一个 8 列宽但 40 亿行深的表的最佳方法。该表将每周更新一次，每个星期天都会在表中添加新一周（过去的最后一周）的数据。由于数据因周数（财政）而异，我们对上述设计的优缺点有两组想法 -

对于宽表 - 想法是设计一个表，其中包含一个包含 3 个属性列的每个周数，一直追溯到过去 160 周。所以这给了我们 160 x 3 = 480 列宽。这个想法是，每周当我们将上周的数据添加到表中时，我们将从表中删除最旧的周列，并将最新的周列添加到表中。根据 ColA - ColD 上定义的键，该表将包含大约 4000 万行（请参阅下图）。这是示例 -

宽表视图

对于深表 - ColA - ColD 字段保持不变，除了有一个新的周列，该列因 ColA-ColD 上定义的键而异。当我们构建这个表时，我们的想法是只将最近的一周粘贴到带有适当周数的表中，并有一个单独的清除（维护）过程来从表中删除最旧的周行。该表将有大约 40 亿行和 8 列宽。这是一个关于它看起来如何的示例 -

深表视图

我们绝对理解需要在此处按周数对任一表进行分区，无论我们选择哪个表。表格的使用 - 并发用户将多次查询该表格以获取过去 52 周的匹配周数和 ColA 值，并且期望在不到 5 分钟的时间内从中创建报告。我在这里向 Oracle 专家寻求建议，无论您是否根据经验看到一个表宽到近 500 列，并且在我们向表中构建数据时每周都会删除或添加列，以及它如何影响性能用于高度并发的报告生成工具。反过来，

谢谢你，非常感谢你的时间！！布伦登

4

1 回答 1

3

您需要一个具有一致投影的表格。这意味着八列四十亿行的配置。

删除列本身就是一项昂贵的任务。除此之外，您将需要每周更改引用该表的所有代码，这似乎不是一个好主意。另一种方法是对该表的每次调用都使用动态 SQL，这更加不可取。

拥有 40 亿行，您绝对应该购买 Partitioning 选项。假设您的大多数查询使用WeekNumber. 但是，通过 Partition Exchange 加载数据并使用 Drop Partition 将其删除的能力在处理大量数据时非常宝贵。

于 2018-03-28T07:41:51.823 回答