小心扩展undo_retention的值

小心扩展undo_retention的值

平台:sun 5.9

Oracle9206

错误描述：
在增大undo_retention到36000后rac中一节点crash.
见alert_strac1.log:

ALTER SYSTEM SET undo_retention=36000 SCOPE=BOTH;

情节描述：
在执行一个存储过程时发生01555错误，修改undo_retention参数至36000导致实例宕掉。
这是一个很危险的做法，且不说对系统是否有影响，这么做很容易引发oracle 的一个bug。matalink上的bug号为2431450。在undo_retention>10000以后就很容易触发了。而直接后果可能就是数据库的crash，严重的会损坏undo tablespace，导致数据库无法再次启动。只有重新恢复该undo tablespace。

这次事故主要的发生原因还在于应用程序端的性能问题，因为系统中一个运行很慢的存储过程而导致ora-01555错误的发生，这里简单的描述一下ora-01555的产生原因,这里引用BITI博客中的一段： 当执行一个大事务的时候，事务早已经被提交， 而查询中的scn 比undo里的scn小，于是产生了ora-01555.

还有一种情况是delay block cleanout，也就是说已经提交的数据，需要标志为已经提交，从而使得后面的会话访问该数据的时候不再产生一致读而直接读该块。而如果事务提交的时候块已经被写入磁盘，则当时不会对块进行清除，需要延迟清除(delay block cleanout)。当被提交但没有来得及标志为提交的块在下次被会话读取的时候会话会检查该块上最新的事务状态是否是活动的，如果已经不是活动的则修改事务标志。这样做一次后就不再产生不必要的一致读。但这种情况仅仅出现在：事务很大可能产生这种情况，事务早已提交，回滚段已经被覆盖，块中没有被标记是否提交，而当前查询 SCN T也比目前回滚段中记录的最小的SCN小（查询已经运行较长时间回滚段都已经被覆盖）。这个时候数据库不能判定当前查询的SCN T 与该块的COMMIT SCN之间的大小关系，于是返回了错误。
这里主要要从应用角度来着手诊断，有以几原因：
1． Sql性能低下，需要调整应用中的SQL语句，使之执行速度加快而不会wipe out
2． 应用中过度频繁的提交。假如可以成批提交的事务，我们可能是单条提交了，应该考虑对整个处理一起提交，或者说分段提交而不是单条提交。
3． exp的时候使用了consistent = y。这个参数主要是为了保证在exp的时候使得所有导出来的表在时间点上具有一致性，可避免存在主外键关系的表由于不同表时间点的不一致而破坏了数据的完整性。建议该操作在系统空闲的时候进行。

诊断描述：
减小undo_retention至10000以内后重启数据库，Tuning导致01555错误的procedure后故障解决。

建议：联系开发商，逐步调整应用程序中的sql和pl/sql，以使错误发生率减至最小，对于一些频繁变动数据的表进行分析，尽量使用cbo.因为系统中一部分表和对象已经进行过分析，这样的情况即使未分析的表与分析过的表一起作查询时都会走cbo模式，这样将会导致错误的执行计划。9i以上版本建议使用dbms_stats包来收集统计信息，特别是对于分区表。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/104152/viewspace-139969/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/104152/viewspace-139969/