oracle undo-itlaowu

颇为阿娇978

　　UNDO表空间用于存放UNDO数据,当执行DML操作(INSERT,UPDATE和DELETE)时,oracle会将这些操作执行前的旧数据 写入到 UNDO段,在oracle9i之前,管理UNDO数据时使用(Rollback  Segment)完成的.从oracle9i开始,管理UNDO数据不仅可以使用回滚段,还可以使用UNDO表空间.因为规划和管理回滚段比较复杂,所有  oracle database 10g已经完全丢弃用回滚段.并且使用UNDO表空间来管理UNDO数据.
　　在网上找到相关的描述，大致内容如下：

　　回滚段可 以说是用来保持数据变化前映象而提供一致读和保障事务完整性的一段磁盘存储区域。当一个事务开始的时候，会首  先把变化前的数据和变化后的数据先写入日志缓冲区，然后把变化前的数据写入回滚段，最后才在数据缓冲区中修改（日志缓冲区内容在满足一定的条件后可能被写  入磁盘，但在事务提交的时候日志必须写入磁盘，而数据缓冲区中的数据依赖于检查点的发生和DBWR进程的活动）  Rollback是一个代价昂贵的操作，如果一个系统的事务回退率过高，应该检查系统是否正常或者程序设计思路是否存在问题。查询数据库启动依赖的  事务回退率，如果发现太高，一定要引起重视。 --查询回退率的sql SELECT NAME, VALUE FROM v$sysstat  WHERE NAME IN ('user commits', 'transaction rollbacks');  关于回滚段的数据，如果是delete操作，则回滚段将回记录整个行的数据；如果是update，则只记录被修改了的字段的变化前的数据（前映像）；如果  是insert，则只记录插入记录的rowid。所以，假如commit，那么回滚段中简单标记该事务已经提交；假如rollback，则操作是  delete的话，把回滚段中的数据重新写回数据块，操作是update的话则把变化前的数据修改回去，操作是insert的话则根据rowid把该记录  删除。这个过程是保障事务的完整性，保障数据不会丢失。 一致性读（consisitent reads)  Oralce的查询集是根据时间点来判定的。Oracle内部通过系统改变号SC作为相对时间点的标准，任何对数据库的改变都会产生SCN，对数据块的数  据改变的时候会把该改变所对应的SCN记录在块中。假设查询开始的时候SCN为T，则在查询所扫描的数据块中，如果数据块的COMMIT  SCN小鱼T，则查询接受该数据，如果COMMIT SCN大于T或者说还没有产生COMMIT  SCN，则查询会尝试去回滚段中查找数据。这保证了数据的读取时间点的一致性。  在通过回滚段中获取数据的时候，本质上是把数据缓冲区中的数据块做一个拷贝，然后将回滚段中记录的内容恢复到该块中，然后查询使用这个块来进行读取。 系统回滚段和延迟回滚段  SYSTEM回滚段是创建在系统表空间中，主要用于系统级的事务和分配普通事务于其他回滚段上。当手工创建数据后需要创建普通回滚段之前必须首先创  建系统回滚段。按oracle文档说，当普通事务异常多的事情可能会使用系统回滚段的情况。正常情况下，系统回滚段主要用于两个方面：一是系统事务，不如  针对数据字典的操作的truncate table 和 drop table。如果truncate or drop  table的过程中没有成果，则系统会根据系统回滚段中的数据字典操作信息对该DDL操作进行回退。另一个方面，就是延迟回滚段(Deferred  Rollback  Segment)。延迟回滚段表示，当我们使一个表空间OFFLINE之后，由于表空间不可用，这个时候若有事务数据位于该空间并执行回滚命令，在  client看起来该事务已经回滚，但对于数据块来说回滚并没有真正完成，这个时候数据库将该回滚信息写入系统回滚段（这就是延迟回滚段），等表空间重新  ONLINE的时候，数据块从系统回滚段中将回滚信息写入表空间。 回退段的设置和管理 Oracle9i之前需要手动设置回退段，我们需要考虑如下问题： 1．系统并发事务数有多少 2．系统是否存在大查询或者大事务，是否频繁 3．能提供给系统回滚段的表空间的磁盘空间是多少 9i的UNDO TABLESPACE  从9i开始，推荐使用UNDO TABLESPACE,系统自动管理回滚段 Sql> show parameter undo  undo_management                       string    AUTO  undo_retention                        integer   900  undo_tablespace                       string    UNDOTBS1 UNDO  TABLESPACE变的很大，我们不能缩小，这个时候我们需要考虑创建新的UNDO  TABLESPACE，然后换到新的表空间。这时即使UNDO表空间有事务也可以切换，只不过不能立即删除该表空间，切换之后等到原来的表空间中所有的事  务出力完毕，并且达到undo_retention的时间后，就可以drop原来的UNDO表空间。 SQL>>回滚段著名的ORA-01555问题  从应用角度来看ORA-01555 1.查询执行时间太长。首先是优化查询，然后考虑在数据块不繁忙的时候运行，最后考虑加大回滚段。  2.过渡频繁的提交。把能够成批提交的单条事务改成成批提交 3.exp的时候使用而来consistent = y.  这个参数主要是为了保证在exp的时候使得所有的到处的表在时间点上具有一致性，避免存在主外键关系的表由于不同的时间点的不一致而破坏了数据的完整性。 建议该操作在系统空闲的时候进行。  4.由于回滚段回缩导致回滚段还没有循环使用的情况下就出现了回滚段中找不着数据的情况。只能加大回滚段增大optimal设置。 UNDO scripts 查询数据块当前某个session的事务所使用的回滚段大小 SELECT b.SID, a.xidusn, a.xidusn FROM v$transaction a, v$session b WHERE a.addr = b.taddr 回滚段表空间中的一个数据文件丢失或者损害的恢复方法  ……………. 由于对应的undo block/或者undo header slot信息被覆盖,导致consistent read不能完成,  系统会报出ora-01555的错误信息.. 出现这种情况的原因可能有以下几种. 1. 对于早期的manual undo,  可能是由于系统设置了optimal>　　

SET TRANSACTION USE ROLLBACK SEGMENT rollback_segment；　　

　　给 大事务指定回滚段，即降低大事务回滚信息覆盖其他事务的回滚信息的几率，又降低了他自身的回滚信息被覆盖的几率。大事务的存在，往往是1555错误产生的 诱因。 6、使用游标时尽量使用显式游标，并且只在需要的时候打开游标，同时将所有可以在游标外做的操作从游标循环中拿出。  当游标打开时，查询就开始了，直到游标关闭。减少游标的打开时间，就减少了1555错误发生的几率。