你好,游客 登录 注册 搜索
背景:
阅读新闻

Oracle ORA-01555 快照过旧 说明

[日期:2012-08-01] 来源:blog.csdn.net/tianlesoftware  作者:tianlesoftware [字体: ]

ORA-01555 快照过旧,是数据库中很常见的一个错误,比如当我们的事务需要使用undo来构建CR块的时候,而此时对应的undo 已经不存在了, 这个时候就会报ORA-01555的错误。

ORA-01555错误在Oracle 8i及之前的版本最多。从9i开始的undo自动管理,至现在的10g、11g中的undo auto tuning,使得ORA-01555的错误越来越少。但是这个错误,仍然不可避免。

Oracle undo 管理 http://www.linuxidc.com/Linux/2011-09/42706.htm

1. 出现ORA-01555错误,通常有2种情况:

1SQL语句执行时间太长,或者UNDO表空间过小,或者事务量过大,或者过于频繁的提交,导致执行SQL过程中进行一致性读时,SQL执行后修改的前镜像(即UNDO数据)在UNDO表空间中已经被覆盖,不能构造一致性读块(CR blocks)。  这种情况最多。

2SQL语句执行过程中,访问到的块,在进行延迟块清除时,不能确定该块的事务提交时间与SQL执行开始时间的先后次序。 这种情况很少。

 

 

2. 1种情况解决的办法:

1)增加UNDO表空间大小

2)增加undo_retention 时间,默认只有15分钟

3)优化出错的SQL,减少查询的时间,首选方法

4)避免频繁的提交

 

有关Undo 的更多信息,参考我的文章

Oracle undo 表空间管理 http://www.linuxidc.com/Linux/2011-07/38006.htm

 

3. 第二种情况描述

 

在块清除过程中,如果一个块已被修改,下一个会话访问这个块时,可能必须查看最后一个修改这个块的事务是否还是活动的。一旦确定该事务不再活动,就会完成块清除,这样另一个会话访问这个块时就不必再历经同样的过程。

要完成块清除,Oracle 会从块首部确定前一个事务所用的undo 段(ITL,然后确定从undo 首部能不能看出这个块是否已经提交。

 

可以用以下两种方式完成这种确认:

一种方式是Oracle 可以确定这个事务很久以前就已经提交,它在undo 段事务表中的事务槽已经被覆盖。

另一种情况是COMMIT SCN 还在undo 段的事务表中,这说明事务只是稍早前刚提交,其事务槽尚未被覆盖。

 

当满足以下条件时,就会从defered clean 收到ORA-01555的错误:

首先做了一个修改并COMMIT,块没有自动清理(即没有自动完成“提交清除”,例如修改了太多的块,在SGA 块缓冲区缓存的10%中放不下)。

其他会话没有接触这些块,而且在我们这个“倒霉”的查询(稍后显示)命中这些块之前,任何会话都不会接触它们。

开始一个长时间运行的查询。这个查询最后会读其中的一些块。这个查询从SCN t1 开始,这就是读一致SCN,必须将数据回滚到这一点来得到读一致性。

 

开始查询时,上述修改事务的事务条目还在undo 段的事务表中。查询期间,系统中执行了多个提交。执行事务没有接触执行已修改的块(如果确实接触到,也就不存在问题了)。

 

由于出现了大量的COMMITundo 段中的事务表要回绕并重用事务槽(ITL)。最重要的是,将循环地重用原来修改事务的事务条目。另外,系统重用了undo 段的区段,以避免对undo 段首部块本身的一致读。

此外,由于提交太多,undo 段中记录的最低SCN 现在超过了t1(高于查询的读一致SCN)。如果查询到达某个块,而这个块在查询开始之前已经修改并提交,就会遇到麻烦。正常情况下,会回到块所指的undo 段,找到修改了这个块的事务的状态(换句话说,它会找到事务的COMMIT SCN)。

如果这个COMMIT SCN 小于t1,查询就可以使用这个块。如果该事务的COMMIT SCN 大于t1,查询就必须回滚这个块。不过,问题是,在这种特殊的情况下,查询无法确定块的COMMIT SCN 是大于还是小于t1相应地,不清楚查询能否使用这个块映像。这就导致了ORA-01555 错误。

 

大批量的UPDATE INSERT 会导致块清除(block cleanout),所以在大批量UPDATE 或大量加载之后使用DBMS_STATS收集相关对象的统计信息,加载之后完成这些对象的清理。

 

关于块清除这块,在<Oracle 10g 编程艺术> 一书中有更详细的说明。

 

 

老熊blog上关于defered Clean的场景说明:

1)有事务大量修改了A表的数据,或者A表的数据虽然被事务��量修改,但是一部分修改过的块已经刷出内存并写到了磁盘上。随即事务提交,提交时刻为SCN1而提交时有数据块上的事务没有被清除。

2)在SCN2时刻,开始执行SELECT查询A表,对A表进行全表扫描,而且A表很大。也可能是其他情况,比如是小表,但是是一个游标方式的处理过程,而处理过程中又非常耗时。注意,这里SCN2SCN1之间可能相隔了很远,从时间上来说,甚至可能有数十天。不管怎么样,这SCN1SCN2时间之间,系统中存在大量的事务,使得UNDO表空间的块以及UNDO段头的事务表全部被重用过。

3SELECT语句在读A表的一个块时,发现表上有活动事务,这是由于之前的事务没有清除所致。ORACLE根据数据块中ITLXID检查事务表,这时会有2种情况:

AXID对应的事务表中的记录仍然存在并发现事务已经提交,可以得到事务准确的提交SCNcommit scn),称为SCN3,等于SCN1。很显然,由于查询的时刻SCN2晚于事务提交的时刻SCN1那么不需要构造一致性读块

BXID对应的事务表中的记录已经被重用,这个时候仍然表明表明事务已经被提交。那么这个时候,Oracle没办法准确地知道事务的提交时间,只能记录为这样一个事实,事务提交的SCN小于其UNDO段的事务表中最近一次重用的事务记录的SCN(即这个事务表最老的事务SCN)。这里称这个SCNSCN4           

linux
相关资讯       Oracle错误代码 
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数

       

评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款