首页 / MYSQL / 一个非典型的ORA-01555的解决

一个非典型的ORA-01555的解决

内容导读

互联网集市收集整理的这篇技术教程文章主要介绍了一个非典型的ORA-01555的解决，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含2408字，纯文字阅读大概需要4分钟。

内容图文

ORA-01555:快照过旧。 一个对于ORACLE DBA来说最经典问题。发生的根本原因：一致性读出了问题。看到网上有个同学，举例说明，

ORA-01555:快照过旧。 一个对于Oracle DBA来说最经典问题。
发生的根本原因：一致性读出了问题。

看到网上有个同学，举例说明，觉得不错，拿来用下：
假设有张表，叫table1，里面有5000万行数据，假设预计全表扫描1次需要1个小时，我们从过程来看：

1、在1点钟，有个用户A发出了select * from table1;此时不管将来table1怎么变化，正确的结果应该是用户A会看到在1点钟这个时刻的内容。这个是没有疑问的。
2、在1点30分，有个用户B执行了update命令，更新了table1表中的第4000万行的这条记录，这时，用户A的全表扫描还没有到达第4000万条。毫无疑问，这个时候，第4000万行的这条记录是被写到了回滚段里去了的，我假设是回滚段RBS1，如果用户A的全表扫描到达了第4000万行，是应该会正确的从回滚段RBS1中读取出1点钟时刻的内容的。
3、这时，用户B将他刚才做的操作commit了，但是这时，系统仍然可以给用户A提供正确的数据，因为那第4000万行记录的内容仍然还在回滚段RBS1里，系统可以根据SCN来到回滚段里找到正确的数据，但是大家注意到，这时记录在RBS1里的第4000万行记录已经发生了一点重大的改变：就是这个第4000万行的在回滚段RBS1里的数据有可能随时被覆盖掉，因为这条记录已经被提交了！！！
4、由于用户A的查询时间漫长，而业务在一直不断的进行，RBS1回滚段在被多个不同的tracnsaction使用着，这个回滚段里的extent循环到了第4000万行数据所在的extent，由于这条记录已经被标记提交了，所以这个extent是可以被其他transaction覆盖掉的！
5、到了1点40分，用户A的查询终于到了第4000万行，而这时已经出现了第4条说的情况，需要到回滚段RBS1去找数据，但是已经被覆盖掉了，于是01555就出现了。

这次出现的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;
发现该回滚段状态变更为offline，drop掉即可。
ORA-1555不再出现。

一个非典型的ORA-01555的解决 - 文章图片

内容总结

以上是互联网集市为您收集整理的一个非典型的ORA-01555的解决全部内容，希望文章能够帮你解决一个非典型的ORA-01555的解决所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。

内容备注

版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。

内容手机端

扫描二维码推送至手机访问。

本文链接：https://qyyshop.com/info/548405.html

来源：【匿名】