ORA-01555 原因分析

ORA-01555 原因与解决：

由于回滚段是循环使用的，当事务提交以后，该事务占用的回滚段事务会被标记为非活动，回滚段空间可以被覆盖重用。那么一个问题就出现了，如果一个查询需要使用被覆盖的回滚段构造前镜像实现一致性读，那么此时就会出现Oracle著名的ORA-01555错误。

ORA-01555错误的另外一个原因是因为延迟块清除（Delayed Block Cleanout）。当一个查询触发延迟块清除时，Oracle需要去查询回滚段获得该事务的提交SCN，如果事务的前镜像信息已经被覆盖，并且查询SCN也小于回滚段中记录的最小提交SCN，那么Oracle将无从判断查询SCN和事务提交SCN的大小，此时出现延迟块清除导致的ORA-01555错误。

另外一种导致ORA-01555错误的情况出现在使用sqlldr直接方式加载（direct=true）数据时。当通过sqlldr direct=true 方式加载数据时，由于不产生重做和回滚信息，Oracle直接指定Cached Commit SCN 给加载数据，在访问这些数据时，有时会产生ORA-01555错误。

ORA-01555的直观解释是“snapshot too old”，也就是快照太旧，其根本含义就是查询需要的前镜像过于“久远”，已经无法找到了。可以想象，如果一个历时数个小时或十几个小时的查询，如果最后遭遇ORA-01555错误而失败，会是多么令人沮丧的一件事。一直以来，ORA-01555都是ORACLE最为头痛的问题之一。

在Oracle 9i的文档中这样描述ORA-01555错误：

01555, 00000, "snapshot too old: rollback segment number %s with name \"%s\" too small"
// *Cause: rollback records needed by a reader for consistent read are
//         overwritten by other writers
// *Action: If in Automatic Undo Management mode, increase undo_retention
//          setting. Otherwise, use larger rollback segments

转载： http://club.it.sohu.com/read_elite.php?b=zz0588&a=7845728

　ORA-01555(快照过旧)问题让很多人感到十分头痛。最近我们的生产系统上也报出了ORA-01555错误。就结合这次案例将ORA-1555问题作个案例分析，并浅析产生原因和各种解决办法。
　　如果要了解1555错误产生的原因，就需要知道ORACLE的两个特性：一致性读(Consistent Get)和延迟块清除(Delayed Block Cleanout)。此外，还要知道关于回滚段的一些配置参数。
　　相关参数
　　先看下Oracle中关于UNDO有哪些配置参数：
　SQL> show parameter undo

　　NAME TYPE VALUE

　　--------------------- -------------------- -----------------------

　　undo_management string MANUAL

　　undo_retention integer 900

　　undo_suppress_errors boolean FALSE

　　undo_tablespace string UNDOTBS1

　　undo_management　　回滚段的管理方式。值可以为MANUAL/AUTO。9i中默认是MANUAL，10g中默认是AUTO。
　　从9i后，回滚段就以表空间的形式管理，并且支持系统自动管理回滚段。一个回滚表空间上可以创建多个回滚段，一个数据库可以创建多个回滚表空间。但是，一个实例(Instance)只能使用一个回滚表空间。
　　如果undo_management设置为MANUAL，就是手动创建回滚段：
　SQL> create rollback segment undo1 tablespace UNDOTBS1;　　

如果设置为AUTO，Oracle就自动管理回滚段的创建，而手工创建就会失败。
　　undo_retention
　　这个参数设置回滚段中的被提交或回滚的数据强制保留时间，单位是秒。请注意，这个参数和1555错误有非常大的关系。但是，需要提醒的是，并不是回滚段中的数据超过这个时间以后就会被清除掉，而是等到后面事务产生的回滚数据覆盖掉“超期”数据。所以这就是为什么我们往往看到系统的回滚表空间占有率始终是100%的原因了。
　　undo_suppress_errors
　　是否报与回滚段有关的错误。如果为FALSE，就不会产生与回滚段有关的错误。但是，请注意，并不是不会发生回滚段错误，而只是屏蔽错误信息，错误发生了就会存在滴。在10g中，这个参数是隐含参数。
　　undo_tablespace
　　为每个实例制定的唯一当前使用的回滚段表空间。
　　一致性读(Consistent Get)
　　一致性读(Consistent Get)可以说是产生1555错误的主要原因。但它的确是Oracle一个非常优秀的特性。既然这个特性会产生这么烦人的错误，我为什么还说它是ORACLE十分优秀的特性呢?下面就先了解一下这个特性：

　　并发事务和脏读
　　需要先了解一下这一特性的产生的背景原因。看下以下这个例子。在一个银行系统中(一般涉及到钱的问题对并发事务要求是最严格的^_^)，会计正在统计当月某地区的个人存款总额，她的这个操作，在后台肯定要产生一条SQL语句，对这一地区的所有用户的存款额作SUM()，我们假设这一操作产生的语句为A，时间点是T1。由于存款用户非常多，再加上会有一些对其他表的JOIN条件，语句A的执行时间可能比较长。这时，在A的执行过程中，A已经统计了账户X的钱，但还没有统计到账户Y的钱的时候，正好有一个客户通过ATM机从账户X中转250元钱到帐户Y，他的操作也产生了一条语句B，对存款表进行更新。开始时间点是T2，结束时间是T3。因为只更新两条记录，这个过程非常短。A结束时的时间点是T4。让我们看下过程图，看看会产生什么结果：

　　从图中，我们可以看到，T2时刻A已经统计过帐户X中的钱，但在这时B从X中转了250元到帐户Y中，在B结束的时刻T3，A还没有统计到Y，但Y已经多出了250元了，所以到T4，统计结束时，A实际上多统计出250元。这就是并发事务中的“脏读(dirty read)”问题。
　　在标准SQL中，为了防止并发事务中产生脏读，就需要通过加锁来控制。这样就会带来死锁、阻塞的问题，即时是粒度最小的行级锁，也无法避免这些问题。再看下上面这个例子。为了防止脏读，A在开始时就需要对表加锁，防止其他事务更新表。这样，B就会被阻塞，假如A事务要执行1个小时，B可能最长就要被阻塞1个小时(如果你是那个倒霉的客户，可能早就***骂出来了)。再看下图，

　　从图中，可以看到，B开始时，存款表被加锁了，所以B被A阻塞，只有等A释放锁以后，B才能更新表。所以B被阻塞了很长时间。在大量并发事务系统中，可能会使整个系统慢得不可想象。

　　一致性读
　　为了解决这一矛盾。Oracle充分利用的回归段，通过回滚段进行一致性读取，即避免了脏读，又大大减少了系统的阻塞、死锁问题。下面就看下Oracle是如何实现一致性读的：
　　当Oracle更新数据块(Data Block Oracle中最小的存储单位)时，会在两个地方记录下这一更新动作。一个是重做段(Redo Segment)，是用于数据库恢复(Recover)用的。一个是回滚段(UNDO Segment)，而回滚段是用于事务回滚(Rollback)的(我们只关心回滚段了)。并在数据块头部标示出来是否有修改数据。一个语句在读取数据快时，如果发现这个数据块是在它读取的过程中被修改的(即开始执行读操作时并没有被修改)，就不直接从数据块上读取数据，而是从相应的回滚段条目中读取数据。这就保证了最终结果应该是读操作开始时的那一时刻的快照(snapshot)，而不会受到读期间其他事务的影响。这就是Oracle的一致性读，也可以叫做多版本(Multi-Versioning)。
　　以上面的例子为例，A在读取到Y帐户时，发现这条记录已经被修改了，于是就从回滚段读取保留的回滚数据，最终就能正确得到T1时刻的正确存款总额了。看下图：

　　从图上看出，A即能得出正确的数据，又保证B不会被阻塞。

Forward from http://wangwei.cao.blog.163.com/blog/static/102362526201201613840410/