问题描述
你好，汤姆。
我们有一个事实表，它按天分区，并存储最近90天的数据。有时，应用程序的用户可以将记录的状态从 “激活” 更改为 “已取消”。
对该表有很多繁重的分析查询，其中包括完整扫描，但仅考虑 “活动” 记录。从5% 到60%，随着时间的推移，“取消” 记录的数量可能会引起极大的警惕。现在它有3700万活跃的，6700万取消了，所以我的全扫描可能会快3倍。
我的问题是: 快速访问所有活动记录的最佳选择是什么？
B树索引无济于事，因为要检索的行太多了。
位图索引似乎是一个糟糕的选择，因为有很多DML操作。
我想尝试按列表进行细分，并将行移动到 “已取消” 的子分区，但我立即感到担忧:
现在表上有7个索引。在部分之间移动大量行将需要大量时间，并且如果有人决定一次更改数千万行的状态 (用户可以这样做，并且将这样做)，则可能会填充撤消。
由于该表是按天划分的，因此在比今天更早的部分中，行运动后留下的任何空白都不会被重复使用或回收，并且完全扫描将花费很多时间。这使得整个想法几乎毫无用处。
恐怕缩小整个表可能会填满撤消段。
我没有一个与我们的产品环境接近规格的环境，所以我什至无法真正测试我对撤消的担忧。
不幸的是，我们不能再升级到12.2几个月，所以不能在线移动。
我是否缺少其他选择，还是应该每天逐个分区运行收缩空间？
我们有一个事实表，它按天分区，并存储最近90天的数据。有时，应用程序的用户可以将记录的状态从 “激活” 更改为 “已取消”。
对该表有很多繁重的分析查询，其中包括完整扫描，但仅考虑 “活动” 记录。从5% 到60%，随着时间的推移，“取消” 记录的数量可能会引起极大的警惕。现在它有3700万活跃的，6700万取消了，所以我的全扫描可能会快3倍。
我的问题是: 快速访问所有活动记录的最佳选择是什么？
B树索引无济于事，因为要检索的行太多了。
位图索引似乎是一个糟糕的选择，因为有很多DML操作。
我想尝试按列表进行细分，并将行移动到 “已取消” 的子分区，但我立即感到担忧:
现在表上有7个索引。在部分之间移动大量行将需要大量时间，并且如果有人决定一次更改数千万行的状态 (用户可以这样做，并且将这样做)，则可能会填充撤消。
由于该表是按天划分的，因此在比今天更早的部分中，行运动后留下的任何空白都不会被重复使用或回收，并且完全扫描将花费很多时间。这使得整个想法几乎毫无用处。
恐怕缩小整个表可能会填满撤消段。
我没有一个与我们的产品环境接近规格的环境，所以我什至无法真正测试我对撤消的担忧。
不幸的是，我们不能再升级到12.2几个月，所以不能在线移动。
我是否缺少其他选择，还是应该每天逐个分区运行收缩空间？
专家解答
鉴于没有人查看数百万行，我假设查询是某种形式的聚合，例如
在这种情况下，我会在内存中查看物化视图或数据库。
物化视图的优点是它们包含在您的许可证中。缺点是使用它们 (自动通过查询重写或直接使用它们)，您必须能够从MV中得出查询结果。这可能意味着您需要大量的这些来覆盖关键查询。由于您的进程可以一次更改数百万行的状态，因此刷新这些进程也可能是一个挑战。
数据库内存的缺点是一个额外的成本选择 (虽然从19.8可以分配到16Gb，没有额外的成本)。好处是所有使用内存表的查询都可以利用这一点。
Bitmap index seems to be a bad choice, since there are a lot of DML operations.
这只是一个问题，如果你有concurrent写。
Moving a lot of rows between sections would require a lot of time and could potentially fill up the undo if someone decides to change the status of tens of millions of rows at a time(users can do and will do that).
...
I don't have an environment close in specs to our PROD environment, so I can't even really test my concerns with undo.
为什么不呢？如果您可以创建相同大小和相似数据的表，则可以测量此创建的撤消量。假设生产套件的速度更快，它也为您提供了合理的最坏情况。
您可能还需要查看压缩表，这取决于您的数据，这可能会大大减小大小。
最终，无论您做什么，都将涉及某种权衡。您需要进行测试，看看各种行动有什么影响，并比较成本/收益。
但是，与其抽象地问 “如何使全表扫描更快？”，不如查看特定的查询，看看如何使它们更快。
select count/sum/max/etc, ... from ... group by ...
在这种情况下，我会在内存中查看物化视图或数据库。
物化视图的优点是它们包含在您的许可证中。缺点是使用它们 (自动通过查询重写或直接使用它们)，您必须能够从MV中得出查询结果。这可能意味着您需要大量的这些来覆盖关键查询。由于您的进程可以一次更改数百万行的状态，因此刷新这些进程也可能是一个挑战。
数据库内存的缺点是一个额外的成本选择 (虽然从19.8可以分配到16Gb，没有额外的成本)。好处是所有使用内存表的查询都可以利用这一点。
Bitmap index seems to be a bad choice, since there are a lot of DML operations.
这只是一个问题，如果你有concurrent写。
Moving a lot of rows between sections would require a lot of time and could potentially fill up the undo if someone decides to change the status of tens of millions of rows at a time(users can do and will do that).
...
I don't have an environment close in specs to our PROD environment, so I can't even really test my concerns with undo.
为什么不呢？如果您可以创建相同大小和相似数据的表，则可以测量此创建的撤消量。假设生产套件的速度更快，它也为您提供了合理的最坏情况。
您可能还需要查看压缩表，这取决于您的数据，这可能会大大减小大小。
最终，无论您做什么，都将涉及某种权衡。您需要进行测试，看看各种行动有什么影响，并比较成本/收益。
但是，与其抽象地问 “如何使全表扫描更快？”，不如查看特定的查询，看看如何使它们更快。
文章转载自ASKTOM，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
