现象描述
我们在进行一个大的查询的时候，往往会碰到这个错误：
回滚记录版本太旧，无法获取用户记录
碰到这种问题，我们怎么解决呢？
有三个方法
Ø
择机执行
Ø
适当调整 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
保持较小的值比较好，个别的查询，其实可以忽略那条数据，不影响我们的执行预期。那么，我们可以启用这个参数（而且也是
动态参数）
|
ENABLE_IGNORE_PURGE_REC
当返回 |
