Oracle 撤消表空间; 自动扩展或不自动扩展这是一个问题

汤姆，

我正在寻找有关撤消表空间数据文件应具有自动扩展功能的指南。启用了撤消自动调整。我正在通过扩展撤消表空间的大小来使我的用户能够利用闪回查询。当前的表空间大小和工作负载支持每天不到1天的更改，并且根据我的一些用户的意外情况，将其扩展到几周将是有益的。

我继承的数据库是适度大小的数据库20ish TBs; 撤消表空间是14个文件 (〜500 GB)，所有文件都完全预分配了大小，但自动扩展已打开。过去12个月内没有ora-1555错误。如果这是一个传统的表空间，我已经关闭了自动扩展。撤消是另一种野兽，经过一系列网络研究，我得到了相互竞争的建议。但是，如果一切都按照oracle文档所说的方式进行...(总是盐粒)

在我看来，我的数据库的最佳方法是根据自动调谐所做的计算自动扩展。
* 使用自动扩展关闭自动调谐将默认使用undo_retention作为指导，保留阈值为表空间的85%。

我计划将undo_retention参数从默认的15分钟向上更改，可能高达3周。我计划在交替阶段增加撤消表空间和undo_retention参数的大小，以跟踪性能，增长和对备份的影响。

我疯了吗？有更好的方法吗？

谢谢!
标记

关于撤消保留的重要事情不是 * 真正 * 持续时间本身，而是该持续时间在撤消生成方面意味着什么。一个主要是只读的数据库可能具有大规模的撤消保留，几乎没有性能影响，因为在大多数情况下，无论您闪回多远，都不需要任何工作。相反，一个沉重的读/写活动数据库可能会被几个小时后闪回的几个人削弱，因为每个人都可能回滚数百万个事务。

因此，撤消保留3周的时间可能不是戏剧性的事情，但是有人闪回3周的活动可能是一场灾难。特别是，参考

“基于令人高兴的事故，我的一些用户正在将其扩展到几周将是有益的”

我强烈建议您对2周内的闪回查询/闪回表需要多长时间进行一些基准测试。虽然您可能有可用的撤消，但执行该操作所需的时间最终可能会被证明是过高的。

我同意您对自动扩展的想法，因为将其启动-我们将专注于长时间运行的 * 查询 *。因此，如果最长的查询是几个小时，我们不会特别注意您想要闪回2周或更长时间的事实。

这里的一些成本的基本视频演示