这次出现的ORA-01555,引起的原因很特殊。
报错是回滚段SYSSMU1有问题.
所以断定的是,并不是因为大量的读写,造成的一致性读错误,而且因为回滚段的错误,使快照出现了问题。
首先观察下回滚段:
SQL> select segment_name,tablespace_name,status from dba_rollback_segs;
发现表空间UNDOTBS1的回滚段_SYSSMU1$-10$都是online。
发现表空间UNDOTBS2的回滚段SYSSMU1是竟然是needs recovery,其他都是offline。
最有趣的是这个数据库指定的UNDO是UNDOTBS1,UNDOTBS2实际已经被弃用了。
尝试把该回滚段offline后删除,但是提示非法。
重启数据库后该回滚段状态变成了availabe。
再次尝试offline后删除,还是提示正在使用。
用直接更新数据字典的方法
SQL>update undo$ set status$=2 where name='SYSSMU1';
发现该回滚段状态变更为offline,drop掉即可。
ORA-1555不再出现。
报错是回滚段SYSSMU1有问题.
所以断定的是,并不是因为大量的读写,造成的一致性读错误,而且因为回滚段的错误,使快照出现了问题。
首先观察下回滚段:
SQL> select segment_name,tablespace_name,status from dba_rollback_segs;
发现表空间UNDOTBS1的回滚段_SYSSMU1$-10$都是online。
发现表空间UNDOTBS2的回滚段SYSSMU1是竟然是needs recovery,其他都是offline。
最有趣的是这个数据库指定的UNDO是UNDOTBS1,UNDOTBS2实际已经被弃用了。
尝试把该回滚段offline后删除,但是提示非法。
重启数据库后该回滚段状态变成了availabe。
再次尝试offline后删除,还是提示正在使用。
用直接更新数据字典的方法
SQL>update undo$ set status$=2 where name='SYSSMU1';
发现该回滚段状态变更为offline,drop掉即可。
ORA-1555不再出现。