昨天,一个朋友的数据库数据被误操作删除掉了,请求我帮忙进行恢复。
数据库版本是Oracle10g Release 2的,我首先想到的是使用Flashback Query进行闪回恢复,不幸的是ORA-01555,数据已经不能被闪回了。
查看当时的数据库参数undo_retention设置,发现这个参数被在10g中缺省的被设置为900秒,这个时间长度是不足够的。
马上将这个参数修改为10800,3个小时:
ALTER SYSTEM SET undo_retention=10800 SCOPE=BOTH;
记得以前一度这个参数的缺省值被设为10800,可是随之而来的是UNDO表空间的过分扩展,难以回收,Oracle在不同版本中,也在进行不停的加权和折中。
Oracle也许会这样想:如果很少有人使用Flashback Query,而过大的undo_retention又会带来麻烦,那么干脆,设小点。
恢复之后,将朋友的另外几个数据库的undo_retention同样修改为10800。
这一设置,应该被更新如安装手册,安装完数据库后即刻作出调整。
另外一点需要记录的是,误删除操作是由于应用程序逻辑错误导致的,这种情况真是屡见不鲜;8.31时还处理过一个重大故障,同样是由于程序编写错误,导致数据库崩溃。
可见,我们的程序员们在编码过程中,同样疏忽不得。
本文转自
http://www.eygle.com/archives/2006/09/undo_retention_need_change.html
数据库版本是Oracle10g Release 2的,我首先想到的是使用Flashback Query进行闪回恢复,不幸的是ORA-01555,数据已经不能被闪回了。
查看当时的数据库参数undo_retention设置,发现这个参数被在10g中缺省的被设置为900秒,这个时间长度是不足够的。
马上将这个参数修改为10800,3个小时:
ALTER SYSTEM SET undo_retention=10800 SCOPE=BOTH;
记得以前一度这个参数的缺省值被设为10800,可是随之而来的是UNDO表空间的过分扩展,难以回收,Oracle在不同版本中,也在进行不停的加权和折中。
Oracle也许会这样想:如果很少有人使用Flashback Query,而过大的undo_retention又会带来麻烦,那么干脆,设小点。
恢复之后,将朋友的另外几个数据库的undo_retention同样修改为10800。
这一设置,应该被更新如安装手册,安装完数据库后即刻作出调整。
另外一点需要记录的是,误删除操作是由于应用程序逻辑错误导致的,这种情况真是屡见不鲜;8.31时还处理过一个重大故障,同样是由于程序编写错误,导致数据库崩溃。
可见,我们的程序员们在编码过程中,同样疏忽不得。
本文转自
http://www.eygle.com/archives/2006/09/undo_retention_need_change.html