昨天,一个朋友的数据库数据被误操作删除掉了,请求我帮忙进行恢复。
数据库版本是Oracle10g Release 2的,我首先想到的是使用Flashback Query进行闪回恢复,不幸的是ORA-01555,数据已经不能被闪回了。
查看当时的数据库参数undo_retention设置,发现这个参数被在10g中缺省的被设置为900秒,这个时间长度是不足够的。
马上将这个参数修改为10800,3个小时:
记得以前一度这个参数的缺省值被设为10800,可是随之而来的是UNDO表空间的过分扩展,难以回收,Oracle在不同版本中,也在进行不停的加权和折中。
Oracle也许会这样想:如果很少有人使用Flashback Query,而过大的undo_retention又会带来麻烦,那么干脆,设小点。
恢复之后,将朋友的另外几个数据库的undo_retention同样修改为10800。
这一设置,应该被更新如安装手册,安装完数据库后即刻作出调整。
另外一点需要记录的是,误删除操作是由于应用程序逻辑错误导致的,这种情况真是屡见不鲜;8.31时还处理过一个重大故障,同样是由于程序编写错误,导致数据库崩溃。
可见,我们的程序员们在编码过程中,同样疏忽不得。
-The End-
数据库版本是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时还处理过一个重大故障,同样是由于程序编写错误,导致数据库崩溃。
可见,我们的程序员们在编码过程中,同样疏忽不得。
-The End-
「喜欢这篇文章,您的关注和赞赏是给作者最好的鼓励」
关注作者
【版权声明】本文为墨天轮用户原创内容,转载时必须标注文章的来源(墨天轮),文章链接,文章作者等基本信息,否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容,欢迎发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。




