ora-00115,快照过期,查看undo_retention参数
见原因是查询操作要去读取的回滚段信息已经被覆盖掉,不能完成一致性读操作
1看查询的执行计划是否正确。ORA-01555错误发生的概率和查询所需的时间成正比,查询时间越长,发生ORA-01555的概率越大。
2. 如果执行计划正确,估算一下运行时间,如果运行时间不是很长,这时候我喜欢登陆到server本地上执行一下SQL看看需要多少时间
如果本地很快就执行完了,说明问题出在application媏,转入下面第三点。如果确实很慢,转入第四点。
3.Application媏的问题可能类型很多,我所遇到的大致有一下几种
3.1 网络速度太慢
3.2 Cursor open时间太长
3.3 commiting in a loop
4.这时候我们要考虑一下数据库本身了。首先看看产生这么多undo 信息是否正常,如果正常的话,考虑是否可以挑选一个系统比较空闲的时段跑查询。
如果本身查询运行的时间就是系统比较空闲的时段或者系统从来就没闲过
, 那就加大回滚段吧。
5. 如果第四步仍然没有效果(我们不可能无限制的加大回滚段),那么可以考虑其他的方法
对于ORA-01555比较频繁的系统,可以考虑转为auto management undo tablespace
auto管理下处理的基本思想是,获得最长查询的时间,预估keep这段时间undo所需的回滚段大小,扩大undo tablespace,修改undo_retention
见原因是查询操作要去读取的回滚段信息已经被覆盖掉,不能完成一致性读操作
1看查询的执行计划是否正确。ORA-01555错误发生的概率和查询所需的时间成正比,查询时间越长,发生ORA-01555的概率越大。
2. 如果执行计划正确,估算一下运行时间,如果运行时间不是很长,这时候我喜欢登陆到server本地上执行一下SQL看看需要多少时间
如果本地很快就执行完了,说明问题出在application媏,转入下面第三点。如果确实很慢,转入第四点。
3.Application媏的问题可能类型很多,我所遇到的大致有一下几种
3.1 网络速度太慢
3.2 Cursor open时间太长
3.3 commiting in a loop
4.这时候我们要考虑一下数据库本身了。首先看看产生这么多undo 信息是否正常,如果正常的话,考虑是否可以挑选一个系统比较空闲的时段跑查询。
如果本身查询运行的时间就是系统比较空闲的时段或者系统从来就没闲过
![](https://i-blog.csdnimg.cn/blog_migrate/ebeb01fbca05d2b45d5b007f95033ffc.png)
5. 如果第四步仍然没有效果(我们不可能无限制的加大回滚段),那么可以考虑其他的方法
对于ORA-01555比较频繁的系统,可以考虑转为auto management undo tablespace
auto管理下处理的基本思想是,获得最长查询的时间,预估keep这段时间undo所需的回滚段大小,扩大undo tablespace,修改undo_retention
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/8362857/viewspace-703805/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/8362857/viewspace-703805/