现象描述

我们在进行一个大的查询的时候，往往会碰到这个错误：

回滚记录版本太旧，无法获取用户记录

碰到这种问题，我们怎么解决呢？

有三个方法

Ø   择机执行

Ø   适当调整 undo_retention

Ø   考虑启用 ENABLE_IGNORE_PURGE_REC 参数

处理方法

处理方法一：

在涉及到的数据，无人改动时，执行对应的操作（查询，或者查询建表等），

可以简单理解为（不是对等的情况，但是可以大概这么理解）：在你执行这个语句开始后，数据被其他人修改，而且提交了。数据库保留了一份最新的值，这是修改后的值，基于事务可见性，你执行的那个语句，是在修改之前开始的，不应该查询到被修改的数据。你应该查询到的是，修改之前的数据 —— 这时候，修改过的旧值，就在回滚段里。

但是，数据库不是一个可以无限存储的机器啊，在回滚段里面的值，对应的事务已经提交的情况下，它本应该可以被清理了，但是为了 我们当前执行的这类查询不报错，我们也需要适当留一留。

那么，留多久，有一个 undo_retention 的参数 决定，2017 年往后的版本，默认值是 300s 了（以前默认是 900s ）

如何查看这个值：

  `select * from v$dm_ini where para_name LIKE 'UNDO_RETENTION'`

这个就是说，如果你这个sql 执行时，涉及到的数据，被其他人修改了，而且超过 300s 了，就有可能遇到报错（回滚记录版本太久）。

那么，我们 只要在无人修改相关数据的时候执行，无论执行多少个 300s 都不会报错。

处理方法二：

暂时修改 undo_retention ，比如我们预期这个语句需要执行 30min ，那么我么可以暂时修改这个参数为 30*60 = 1800

在执行完后，在修改回原先的默认值。

这是修改为 18000 的sql 语句，直接通过 执行sql 的方式，执行这个语句，就对这个参数进行了调整

  `sp_set_para_value(1,'UNDO_RETENTION',1800);`

相应 的，这个就是修改回 300s

  `sp_set_para_value(1,'UNDO_RETENTION',300);`

修改之前，确认下之前是多少。以免改错（过大或过小）影响其他人或者其他应用使用。（该值 过大对性能 是有负面影响的）

处理方法三：

在知道怎么回事的时候，我们也可以知道，数据库给我们提供了这样一个参数，毕竟，对于数据库的性能来说 undo_retention 保持较小的值比较好，个别的查询，其实可以忽略那条数据，不影响我们的执行预期。那么，我们可以启用这个参数（而且也是 动态参数）