合 Oracle Undo系列

常用SQL

一个DML语句的处理过程描述

update undotest set object_type='VIEW' where object_type='PROCEDURE';
检查shared pool中是否存在相同的语句，如果存在，重用执行计划，执行扫描运算，如果不存在，执行硬解析生成执行计划
根据执行计划中的扫描运算，检查undotest表中的相关数据块是否存在buffer cache中，如果不存在则读取到内存中
检查数据块中符合object_type='PROCEDURE'条件的记录，如果没有符合条件的行记录，则结束语句，如果存在则进入下一步
以当前模式（current）获取符合object_type='PROCEDURE'条件的数据块，准备进行更新
在回滚表空间的相应回滚段头的事务表上分配事务槽，这个动作需要记录redo日志
从回滚段数据块上创建object_type='PROCEDURE'的前映像数据，这个动作也要记录redo日志
修改object_type='VIEW' ，这是DML操作的数据变更，而需要记录redo日志
用户提交时，在redo日志中记录提交信息，将回滚段头上的事务表和回滚段数据块标记为非活动，清除修改数据块上的事务信息（也可能延迟清除）。同时必须确保整个事务的redp日志写到磁盘上的日志文件
注意：如果最后用户回滚了事务，oracle从回滚段中将前映像数据提取出来，覆盖被更新的数据块。这个回滚动作本身也需要产生redo日志，因此，我们要知道回滚的代价非常昂贵。

基本概念和名词解释

UBA: Undo block address
RBA: Redo block address
Dba: Data block address
Rdba: Root dba
Xid: Transaction ID
ITL: Interested Transaction List 保存在数据块的头部（事务信息部分），包含XID,UBA,LCK，FLG等重要信息
Transaction Identifiers
Transaction identifiers (XID) uniquely identify a transaction within the system; they are used within the Interested Transaction List (ITL) of the data block.
A transaction identifier consists of:
Undo segment number 即v$rollname中的usn
Transaction table slot number 对应回滚段头中回滚事务表的第几条记录
Sequence number or wrap#
XID = usn# . slot# . wrap#
Undo Block Address
The undo block address (UBA) uniquely identifies the undo block for a given transaction; it is found within the ITL of the data block.
A UBA consists of:
Data block address (DBA) of the block 前映像undo 块地址
The sequence number of the block 序列号
The record number within the block undo记录的开始地址（针对该块）
UBA = DBA. seq#. rec#

Undo回滚段简介

回滚段用于存放数据修改之前的值（包括数据修改之前的位置和值）。回滚段的头部包含正在使用的该回滚段事务的信息。一个事务只能使用一个回滚段来存放它的回滚信息，而一个回滚段可以存放多个事务的回滚信息。

Undo回滚段的作用

Undo主要有以下几个作用：
（1）事务回滚（Rollback Transaction）
当一个事务修改表中数据的时候，该数据修改前的值（即前镜像，Before Image）会被存放在Undo段中，当用户回滚事务（ROLLBACK）时，Oracle将会利用在数据块ITL槽中记录的Undo块地址（Undo Block Address，Uba），然后找到相应的Undo块，接着利用其中的Undo数据（即前镜像）来将修改的数据恢复到原来的值，从而实现对事务所作的改变进行回滚。
（2）事务恢复（Transaction Recovery）
实例恢复（Instance Recovery）的第一阶段称为前滚（Rolling Forward）或者缓存恢复（Cache Recovery），第二阶段称为回滚（Rolling Back）或者事务恢复。前滚和回滚是Oracle数据库实例发生意外崩溃，重新启动的时候，由SMON进行的自动恢复的过程。所谓的前滚，是应用Redo来恢复Buffer Cache的数据，将Buffer Cache恢复到Crash之前状态，所以此时Buffer Cache中既有崩溃时已经提交但还没有写入数据文件的脏块，还有事务被突然终止而导致的既没有提交又没有回滚的事务的脏块（也就是没有COMMIT，但是DBWn已经将改变的数据刷新到底层磁盘）。前滚完成之后就可以确保联机Redo日志中所有已提交的事务操作的数据写回到数据文件中。接下来，前滚之后，任何未提交的更改必须被撤消，而回滚是在数据库做完前滚操作后并打开数据库的情况下完成的，SMON会利用Undo信息将未提交的事务全部进行回滚。具体来说，SMON进程在完成前滚后，查看Undo段头（Undo段的第1个数据块）记录的事务表（每个事务在使用Undo块时，首先要在该Undo块所在的Undo段头记录一个条目，该条目里记录了该事务相关的信息，其中包括是否提交等），将其中既没有提交也没有回滚，而是在实例崩溃时被异常终止的事务全部回滚。
（3）提供一致性读（Consistent Read）
Oracle是一个多用户系统，当一个会话开始读取数据还未结束读取之前，可能会有其他会话修改了该会话将要读取的数据。如果会话读取到修改后的数据，那么就会造成数据的不一致，出现了脏读（Dirty Read）。所以，一致性读是相对于脏读而言的。在Oracle中，一致性读是通过Undo来实现的，一致性读就是为了保证数据的一致性。在一般情况下，普通查询都是一致性读。
举例来说，假设某个表T中有1W条记录，获取所有记录需要15分钟时间。当前时间为9点整，某用户A发出一条查询语句：“SELECT * FROM T;”，该语句在9点15分时执行完毕。当用户A执行该SQL语句到9点10分的时候，另外一个用户B发出了一条DELETE命令，将T表中的最后一条记录删除并提交了。那么到9点15分时，A用户将返回多少条记录？如果返回9999条记录，那么说明发生了脏读；如果仍然返回1W条记录，那么说明发生了一致性读。很明显，在9点钟那个时间点发出查询语句时，表T中确实有1W条记录，只不过由于I/O的相对较慢，所以才会花15分钟完成所有记录的检索。对于Oracle数据库来说，必须提供一致性读，并且该一致性读是在没有阻塞用户的DML操作的前提下实现的。
那么Undo数据是如何实现一致性读的呢？在Oracle数据库中的Buffer Cache中的数据块上都会有最后一次修改数据块时的SCN。如果一个事务需要修改数据块中数据，那么会先在回滚段中保存一份修改前数据和SCN的数据块，然后再更新Buffer Cache中的数据块的数据及其SCN，并标识其为“脏”数据。当其它进程读取数据块时，会先比较数据块上的SCN和自己发出SQL语句时刻的SCN，分为以下两种情况：
①　如果该数据块头部的ITL槽上记录的SCN大于自己查询时刻的SCN，那么表示该块被更新过，此时就要借助Undo块了。在该数据块头部的ITL槽上记录了对应的Undo块的地址（Uba），根据Uba就可以找到对应的Undo块。如果发现该Undo块的ITL槽的SCN号也较大，证明该Undo块也不可用，那么需要在该块的ITL槽上继续寻找上一个Undo块地址，层层递归，最终找到SCN号比发出查询的SCN号小的Undo块，将该Undo块中的被修改前的数据取出，从而构建出发出SQL语句时刻的数据块内容，这样的数据块叫做CR（Consistent Read）块。但是在查找的过程中，可能会发现当前Undo块里记录的ITL槽的SCN号比上一个Undo块里记录的SCN号还要大。这种情况说明由于事务被提交或回滚，导致当前找到的Undo块里的数据已经被其它事务覆盖了，于是就无法再找出小于等于发出查询时的那个时间点的SCN号，这时Oracle就会抛出一个非常经典的错误--ORA-1555，也就是snapshot too old（快照过旧）的错误。对于DELETE来说，其Undo信息就是INSERT，也就是说该构建出来的CR块中就插入了被删除的那条记录。
②　如果数据块头部的ITL槽（事务槽）上记录的SCN小于等于自己查询时刻的SCN，那么分为两种情况：第一，若被查询的块上没有活动的事务，则表示该块没有被更新过，是可用的，可以直接读取该数据块上的数据；第二，若被查询的块上有活动的事务，则需要找Undo的前镜像数据。
（4）实现闪回功能
闪回功能中的闪回查询（Flashback Query）、闪回版本查询（Flashback Version Query）、闪回事务查询（Flashback Transaction Query）和闪回表（Flashback TABLE）都是基于Undo表空间中的回滚信息实现的。

Undo回滚段的类型

回滚段可分为系统回滚段和非系统回滚段, 其中非系统回滚段又分为PUBLIC回滚段和PRIVATE回滚段。

回滚段：

1 系统回滚段

2 非系统回滚段：

• PUBLIC回滚段
• PRIVATE回滚段

系统回滚段用于处理涉及系统的CATALOG的事物(比如大多数的DDL), 它位于SYSTEM表空间, 由于只有SYSTEM表空间可以随时保持可用, 因此,不要把SYSTEM回滚段放在其他的表空间中.

原则1: 系统回滚段应放在SYSTEM表空间中, 并且应该永远保持ONLINE状态.

PUBLIC回滚段对于数据库的所有实例(INSTANCE)都是可用的, 除非将其显式设置为OFFLINE.

PRIVATE回滚段是指对于数据库的某个实例是私有的, 为了使用PRIVATE回滚段, 某个实例应当在其INITsid.ORA的ROLLBACK_SEGMENTS中标明所有要使用的PRIVATE回滚段, 或通过使用ALTER ROLLBACK SEGMENT XXX ONLINE来使用某一个回滚段.

建议1: 在单实例系统中,建议将所有回滚段设为PUBLIC.

建议2: 在多实例系统中(如OPS,RAC), 建议将每个实例的PRIVATE回滚段放置到访问比较快的本地设备上.

Undo段存储的内容：不同的DML操作，UNDO BLOCK中保存的前映像内容

Redo中只会记录少量信息，这些信息足以重演事务；同样Undo中也只记录精简信息，这些信息足以撤销事务。具体来说：

• 对于INSERT操作，回滚段只需要记录插入记录的ROWID，如果回退，那么只需将该记录根据ROWID删除即可；

• 对于UPDATE操作，回滚段只需要记录被更新字段的旧值即可（前镜像），回退时通过旧值覆盖新值即可完成回滚；

• 对于DELETE操作，Oracle则必须记录整行的数据，在回滚时，Oracle通过一个反向操作恢复删除的数据。

总结一下：对于相同数据量的数据操作，通常INSERT产生最少的Undo，UPDATE产生的Undo居中，而DELETE操作产生的Undo最多。所以，当一个大的DELETE操作失败或者回滚，总是需要很长的时间，并且会有大量的Redo生成。所以通常在进行大规模数据删除操作时，推荐通过分批删除分次提交，以减少对于回滚段的占用和冲击。

其中bdba表示file 4，block 1150 ,hdba表示file 4，block 810 与我们上面查询出来的地址相符。
我们可以看到，undo块中并没有直接保存rowid信息，但是oracle完全可以根据上面的几个信息（bdba,slot,objd)定位回滚时需要删除的具体数据，因此对于Insert操作，ORACLE只需保留上述信息，即可完成回滚操作

回滚段的数量规划

对于OLTP系统，存在大量的小事务处理，一般建议：

数量多的小回滚段；每四个事务一个回滚段；每个回滚段不要超过十个事务。

对于批处理，一般建议：

少的大回滚段；每个事务一个回滚段。

回滚段的查询

1 查询数据库的的回滚段情况

2 查看系统回滚段基本信息

从上面仅仅是查询到回滚段的基本信息，要了目前各个回滚段的动态信息，还要查询V$ROLLNAME和V$ROLLSTAT视图。V$ROLLNAME视图只存放各回滚段的编号和名字，V$ROLLSTATS存放各个回滚段当前的情况信息。要想得到每个回滚段的信息，就要查询两个表的信息才能得到。如：

3 查看回滚段的使用情况，哪个用户正在使用回滚段的资源(当提交或回滚后资源释放):

4 回滚段当前活动的事物(事务提交或回滚后自动清空)

5 分析 UNDO 的使用情况

6 监控undo表空间

7 查询是否有回滚段的争用

8 查看回滚段的统计信息：

9 查询回滚段的事务回退率

10 查询回滚段在使用,扩展,回缩的时候extent在循环的次数

11 查询回滚段收缩的情况

块清除

块清除（Block Cleanout）是指清除存储在数据块头部与锁相关的信息，其实质是在清除块上的事务信息，包括数据的行级锁和ITL信息（包括提交标志、SCN等），块清除不需要生成Redo日志。Oracle的块清除有两种：快速块清除（Fast Commit Cleanout）和延时块清除（Delayed Block Cleanout）。

通过命令“alter system dump undo header '回滚段名称';”可以将Undo段头信息dump出来，可以很明显地看到事务表（TRN TBL）信息，其中，状态（state）为10代表活动事务，状态（state）为9表示INACTIVE。Dba列表示该事务对应的Undo Block Dba地址。

每个事务处理只分配给一个Undo段，一个Undo段可以同时服务多个事务处理。UPDATE事务的内部流程如下所示：

①　首先当一个事务开始时，需要在Undo段事务表上分配一个事务槽。

②　在数据块头部获取一个ITL事务槽，该事务槽指向Undo段头的事务槽。

③　在修改数据之前，需要记录前镜像（Before Image）信息，这个信息以Undo Record的形式存储在回滚段中，回滚段头事务槽指向该记录。

④　锁定修改行，修改行锁定位（lb-lock byte）指向ITL事务槽。

⑤　进行数据修改。

在提交事务的时候，如果被修改过的数据块仍然在Buffer Cache之中，那么Oracle可以清除ITL信息，这叫作快速块清除（Fast Block Cleanout），也叫提交清除（Fast Commit Cleanout）。快速块清除还有一个限制，当修改的块数量超过Buffer Cache约10％，则对超出部分不再进行快速块清除。

在提交事务的时候，如果被修改过的数据块已经被写回到数据文件上（或大量修改超出Buffer Cache的10％的部分），再次读出该数据块进行修改，显然成本过于高昂，对于这种情况，Oracle选择延迟块清除（Delayed Block Cleanout），即在提交的时候只会清理Undo Segment Header中的事务表信息，而Data Block上的事务标志不会清除，等到下一次访问该Block时再来清除ITL锁定信息，这就是延迟块清除。Oracle通过延迟块清除来提高数据库性能，加快提交操作。如果Oracle不对块完成这种延迟清除，那么COMMIT的处理可能会很长，COMMIT必须重新访问每一个块，可能还要从磁盘将块再次读入内存。在一个OLTP系统中，可能很少看到这种情况发生，因为OLTP系统的特点是事务都很短小，只会影响为数不多的一些块。

如果执行一个大的INSERT、UPDATE或DELETE，会影响数据库中的许多块，那么就有可能在此之后，第一个“接触”块的查询会做延迟块清除，从而生成Redo日志，所以，SELECT语句也有可能会产生Redo日志。

如果有如下的操作，那么可能会受到块清除的影响：

• 将大量新数据批量加载到数据仓库中；

• 在刚刚加载的所有数据上运行UPDATE（产生需要清理的块）；

• 让别人查询这些数据

因此，建议在批量加载了数据后，通过运行DBMS_STATS实用程序来收集统计信息，就能自然的完成块清除工作。Oracle提供了一个内部事件（10203事件）可以用来跟踪数据库的块清除操作，可以通过以下命令设置：

延时块清除

Delayed logging block cleanout(延时块清除)是ORACLE用来提高写性能的一种机制: 当修改操作(INSERT/UPDATE/DELETE)发生时, ORACLE将原有的内容写入回滚段, 更新每个数据块的头部使其指向相应的回滚段, 当该操作被COMMIT时, ORACLE并不再重新访问一遍所有的数据块来确认所有的修改, 而只是更新位于回滚段头部的事务槽来指明该事务已被COMMIT, 这使得写操作可以很快结束从而提高了性能接下来的任何访问该操作所修改的数据的操作会使先前的写操作真正生效, 从而访问到新的值. Delayed logging block cleanout 虽然提高了性能,但却可能导致ORA-01555. 这种情况下, 在OPEN/FETCH前对该表做全表扫描(保证所有的修改被确认)会有所帮助.

后续精彩内容已被小麦苗无情隐藏，请输入验证码解锁本站所有文章！

验证码：

请先关注本站微信公众号，然后回复“验证码”，获取验证码。在微信里搜索“DB宝”或者“www_xmmup_com”或者微信扫描右侧二维码都可以关注本站微信公众号。