有关ORA-01555错误

接连几天，在我的某个数据库的alert.log里面发现下面的这个错误：
发生时间在早上5点左右:
Wed Apr  6 05:15:18 2005
ORA-01555 caused by SQL statement below (Query Duration=17292 sec, SCN: 0x0002.ce17e741):
下面详细的列出了sql的脚本。

我一开始以为是在这个时间点执行的，所以一直在找这个时间点附近的任务有哪些，通过logminer看了半天的归档日志，因为是个select，没有在logminer中找到。
检查数据库的过程、函数和触发器也没有发现这个sql。
检查数据库服务器的crontab，也没有发现调用的地方。

察看回滚段，使用的是自动回滚段管理，现在自动建立了10个回滚段，每个都不大，UNDOTBS1表空间2G多。我为该表空间增加了1G，但是第二天早上仍然发现出现该错误。

后来我才看到这个脚本的执行时间是17292 sec，也就是按照时间推算应该已经执行了将近5个小时了，应该是在零点左右调度的任务。
检查v$sql这个视图，也可以找到这个sql对应的纪录，可以找到他是执行的某个机器上的某个目录下面的sql脚本，在0：27分开始执行的。

下面是摘录的一段有关回滚段的说明：
=======================================================================
http://blog.csdn.net/kamus/archive/2004/10/10/131387.aspx
4． 回滚段的平衡

在Oracle 9i和Oracle9i之前如果没有使用回滚段自动管理，那么对于回滚段的性能仍然是需要监控并且调整的。

检查是否使用了回滚段自动管理：
select name, value from v$parameter where name like '%undo_%';

如果返回结果中undo_management的值是AUTO，则表示使用了回滚段自动管理，同时undo_tablespace值显示了自动管理使用的回滚表空间，undo_retention值显示了在回滚表空间中保留回滚数据的时限，以秒为单位。
注意：如果undo_management的值是AUTO但是undo_tablespace没有设置相应的值，那么就会使用SYSTEM表空间中的SYSTEM回滚段，这个是绝对应该避免的现象。

如果没有使用回滚段自动管理，那么需要监控用户使用回滚段的频度，原则上认为不应该有超过1个用户同时使用1个回滚段。
检查方法：
select a.name,b.extents,b.rssize,b.xacts,b.waits,b.gets,optsize,status from v$rollname a, v$rollstat b where a.usn = b.usn;

检查输出结果，对于所有回滚段而言，如果xacts（活动事务）和waits（段头等待）经常超出1，那么就表明需要增加回滚段数目，以避免可能出现的争用。

增加回滚段的方法：

create rollback segment rs_name tablespace RBS storage(initial 1M next 2M);
alter rollback segment rs_name online;

如果使用了回滚段自动管理，那么可以从v$undostat, v$rollstat, dba_undo_extents等视图中查询当前回滚段的使用和分配情况。

评估准则：
等级    分数
有回滚段等待现象  0
无回滚段等待现象  30
使用了回滚段自动管理 30
=======================================================================

按照上面的说明，我调整了undo_retention参数，今天早上没有看到类似的错误提示，但是不幸的是，这个sql还在执行中，所以下一步的工作应该是如何优化这个脚本了。
ALTER SYSTEM SET undo_retention=21600 SCOPE=BOTH;

有关这个参数，还有些不甚清楚的地方，原来这个参数的值是7200，也就是回滚段中保留两个小时的回滚数据，但是原来是执行了将近5个小时的时候才报错的，我调整了这个参数到21600，也就是6个小时，执行的效果是到现在都没有报错，也就是这个时间并不是执行开始到报错的时间，那应该如何设置这个参数呢，有什么规律呢。

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

转载于:http://blog.itpub.net/51862/viewspace-180628/