顺义做网站公司,wordpress即时新闻,优建网站,南京维露斯网站建设UNDO表空间用于存放UNDO数据,当执行DML操作(INSERT,UPDATE和DELETE)时,oracle会将这些操作执行前的旧数据 写入到 UNDO段,在oracle9i之前,管理UNDO数据时使用(Rollback Segment)完成的.从oracle9i开始,管理UNDO数据不仅可以使用回滚段,还可以使用UNDO表空间.因为规划和管理回滚… 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 alter system set undo_tablespace undotbs02; System altered. 切换了UNDO表空间后应该修改pfile或者spfile使得下次启动应用新的UNDO表空间。 回滚段著名的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 size, rollback segment wrap 导致部分undo信息被丢弃.. 2. 由于undo retention 设置的时间小于sql执行的长度,这样从这条sql开始时候其他session产生的部分undo由于retention的原因被覆盖,导致无法完成 consistent read. 3. 由于commit over fetch loop. 导致transaction slot 被覆盖,无法完成consistent read .. ORA-01555错误浅析 http://www.hellodba.com/Doc/ORA-01555_analysis(1).htm 总结出以下方法来解决1555错误问题 1、扩大回滚段 因为回滚段是循环使用的如果回滚段足够大那么那些被提交的数据信息就能保存足够长的时间是那些大事务完成一致性读取。 2、增加undo_retention时间 在undo_retention规定的时间内任何其他事务都不能覆盖这些数据。 3、优化相关查询语句减少一致性读。 减少查询语句的一致性读就降低读取不到回滚段数据的风险。这一点非常重要 4、减少不必要的事务提交 提交的事务越少产生的回滚段信息就越少。 5、对大事务指定回滚段 通过以下语句可以指定事务的回滚段 SET TRANSACTION USE ROLLBACK SEGMENT rollback_segment 给 大事务指定回滚段即降低大事务回滚信息覆盖其他事务的回滚信息的几率又降低了他自身的回滚信息被覆盖的几率。大事务的存在往往是1555错误产生的 诱因。 6、使用游标时尽量使用显式游标并且只在需要的时候打开游标同时将所有可以在游标外做的操作从游标循环中拿出。 当游标打开时查询就开始了直到游标关闭。减少游标的打开时间就减少了1555错误发生的几率。 转载于:https://blog.51cto.com/itlaowu/959721