Oracle 关于使用Flashback_Time撤消/撤消保留的基本问题

嘿伙计们，

首先，感谢您在这里所做的出色工作。我在博客中搜索了我的问题的答案，但我觉得它有点基本，因此可能还没有。

因此，根据我的理解，如果我使用flashback_time进行datapump导出，expdp将从架构 “snapshotted” 状态导出所有数据，该状态将从撤消表空间中取出。

对此最重要的设置是撤消保留，它将设置此快照可以在表空间中存储的时间，当然还有tbs的大小，以便快照可以在表空间中空闲以保留时间，而新数据可以分配表空间。

我希望在这里之前我是正确的。现在我遇到了一个测试数据库的情况，那里绝对没有发生任何事情-没有工作，没有会话-只有我。

撤消保留被设置为900的默认值 (这在我看来是非常低的，如果你想做一个expdp？)，我遇到了一个快照太旧的错误。在我将值增加到7200后，它完成了，但也花了3个小时-比我输入的7200秒长。所以我在这里有点迷路了。

长话短说，以下是我关于这种行为的问题:

-如果expdp运行时长于undo_retention时间，undo_retention是否会触发快照太旧的错误-无论撤消tbs是否根本没有新数据？(如果保留设置为7200，那么它将如何运行3个小时)
-为什么此重要参数的900默认值如此之低？
-导出本身或常规rdbms后台作业/进程是否会产生撤消功能，以至于这可能是我的问题的原因？

最好的问候和提前感谢，
马库斯

undo_retention = x就像你对我们说的，

“作为指导，我让您知道两件事

-我不太可能要求早于 “x” 的数据
-一旦undo早于 'x'，我不介意您是否放弃/重新使用它”


因此，如果您的撤消保留设置为900，而我们不会 * 积极地 * 四处寻找比这更古老的东西... 但与此同时，我们也不会对此感到内疚。我们不会创建/消耗 * 更多 * 的撤消空间，因为它通常更快，更有效地回收现在已经过时的东西...因为毕竟，您 * 告诉 * 我们我们可以重复使用它 :-)

因此，它 * 可能 * 只需要几个小的新事务来获取 (和重用) 一些旧的撤消信息，这些信息恰好对您的datapump作业很重要。出于同样的原因，这几笔交易可能同样可能抓住了其他一些撤消插槽，并保留了您需要的撤消插槽。那里有点彩票-因此，如果您的导出运行了 “n” 秒，并且您 * 始终 * 希望它起作用，则强烈考虑至少具有undo_retention。

这里有些讽刺-因为datapump作业本身执行交易 :-)

关于此主题的一篇不错的Oracle杂志文章

http://www.oracle.com/technetwork/oramag/o33asktom-101050.html