前言
 
    oracle7月11日在美国纽约发布了11g版本，可惜迟迟没有可公开下载的版本，只有加入oracle的测试计划的合作客户才可以得到beta版本试用。但这并不妨碍oracle爱好者们根据一些流传出来的文档来了解oracle 11g。7月30日开始的上海oracle open world，oracle宣称11g是30年来最重要的一次版本发布。对这样一个噱头我们还是比较冷静的看待的。OOW期间在一个采访oracle ACE 的活动中，我们几个ACE都不大赞同这样一种说法，其实oracle 一直以来都在前进，不断地改进以满足客户的需要。应该说，11g达到了许多客户所期望的目标，是一个关注细节的版本。那么11g到底有哪些重要的值得关注的地方呢，不妨挑一些特性做个简要分析。
 
 
关注应用、关注性能
 
    SQL replay
 
    OOW后 rich Niemiec(www.tusc.com) 先生趁着来中国的机会各地巡游，期间到了我们公司，他问我在oracle 数据库的使用中我最大的困难是什么？我最大的困难是应用为了应对多变的商业需求，频繁地发布。而应用变化则带来schema的变化，尤其严重的是对于数据库来说可能需要新增加index。增加index绝对是一件危险的事情，这本是为了优化查询而增加，但却可能导致原来的某些查询选择了错误的index，运气好则是应用性能少量下降，运气不好则是数据库立即crash！每年这么多变化，我如何来保证每次都是正常的？数据库可靠性要求很高，任何意外都不是我所期望的。为了避免这种情况，通常我们会尽力在测试环境中做尽量多的测试。但任何的变化若都要进行回归测试，QA通常都是比较紧缺的资源。这种现状，中外都一样，只是我们通常没老外做的好。
    那么这件事情跟SQL replay有什么关系呢。我们来看看这个功能，在系统中捕获某个时段所运行的所有SQL,然后我们可以搭建一个和当前系统一样的测试环境，这样我们可以在测试环境中做我们想做的事情，如增加index，准备好之后我们可以重现搜集时段内数据库所执行的SQL(replay)。 通过观察replay期间的表现和性能信息，我们可以方便的看到哪些sql性能降低了，然后做出修正再replay，直到满意为止。这样做的好处是，我们可以不再倚赖于QA资源。要知道对于一个复杂庞大的系统，做回归测试工作量巨大。Oracle这个特性为我们提供了方便。
 
    Database workload capture and replay
 
    这一项与SQL replay不同的是搜集了整个数据库的负载情况。比如我们曾经出现过一个存储系统IO能力表现不佳的情况，厂商为了证明存储性能新搭建了一套环境，但我们却很难把真实应用放到新环境中去测试。最多也只是使用一些工具来模拟。后来打算换新存储，实际上在新系统上线前，我们无法预测新存储的表现到底能好到什么程度，这就存在着风险。如果有了Database workload capture and replay 这项功能，那么我们的困难也将迎刃而解。包括数据库要升级，也可以通过这个功能来做很好的性能预测。
 
    Result Set Caching
 
    这项功能的推出，再次表明oracle对细节的关注程度。当然，换个角度来讲，现代关系型数据库和计算机技术的发展，一直没有出现重大的突破，都是在几十年前的基础上不断地升级、修补。现在已经关注到客户应用的一些非常具体的需求上。这点其实从很多oracle有关执行计划的特点上也能看出来。Oracle推出了大量的只适合某些特定情况的执行计划，优化的触角伸到了非常精细的领域。回过来说result set caching 这项功能。这其实是我们众多用户在一些特定情况下所期望的但又和早先数据库系统的设计思想不一致的地方。oracle为了满足大家的要求，做出了这么一项功能。在还没有真切地感受这项功能的好处和限制之前，我们不妨先看一看特点。这项功能可以使得用户在使用 /*+result_cache*/ 提示的情况下，将查询的结果缓存。当查询被反复地执行的时候，不再需要到表中去获取，只需要来这个存放结果的地方就可以了。实际上这跟我们当前的一些web cache 的功能非常相似。这种cache应该更倾向于对结果集比较小、查询频繁切查询语句固定的情况。问题接踵而来，如果支持频繁的变化的数据，对性能有多大的影响，在使用上到底有些什么限制？很遗憾，我无法在这里详细地解释这些问题。一切都待我们做更多的实验来检验。
 
    Invisible index
 
    这是一项非常有用的功能，oracle虽然在8i就推出了虚拟索引的功能，但是，毕竟那还只是针对某个session的执行计划的观察和调整。现在我们可以选择实实在在的创建好index但却是invisiable 的状态，DML 也依然在维护这个index。然后我们可以通过使用提示走到index上来测试性能。当我们发现一切正常的时候，可以选择将index设置为visible 状态。如果我们想drop掉某个index但又担心不保险的时候，也可以选择将index设置为invisible状态，发现有问题再设置回visible状态。这样就可以避免经历drop之后再重新create的状况，在联机事务处理的大表上，create  index是一个非常消耗资源的任务。
 
    关于性能方面的补充
 
    当然在应用性能方面除了以上几种特性外，还有很多的新的特性，如SQL Plan Management 提供能类似store outline 的功能，Auto sql tuning可以自动的协助用户来对sql进行优化，更强大的ADDM，提高lob类型数据的io性能，总之，有非常多的值得关注的内容等待大家去探索。
 
 
关注维护、关注管理
 
    Online Patch
 
    作为维护高可用数据库系统的DBA，最担忧的事情之一，就是遭遇无法回避的bug而被要求升级！以往升级有一个很重要的问题，那就是需要数据库停机！如果仅仅是更换rdbms obj文件并重新link，那么似乎rac可能在应用配合切换的前提下做到不停机。但如果升级需要在startup migrate下运行catpatch.sql ，则停机不可避免。虽然正常状况下这个过程不是特别长，如果在正运行的机器上使用独立的安装目录来打补丁，打完再替换原来的rdbms软件，则down time大约是替换时间加上运行catpatch.sql 的时间之和。也就是说运气不错的话能控制在5—10 分钟内。但应用的起停，往往却异常复杂。比如我们有几百台连接数据库的服务器包含了几十种形形色色的应用，做一个停机维护是一件大事。这直接就延长了down time。所以打补丁一事我们非常慎重，新上线数据库选择的版本也非常慎重。一定要选择稳定可靠的版本，应用一定要使用传统、可靠的数据库功能。这也使得很多新出来的数据库新特性我们不能及时地使用。传闻ebay一轮数据库升级大概需要2年时间，希望11g的online  patch 和Database workload capture and replay能缩短这个周期，也让DBA们能轻松一些。
    online patch 这类特性，我一直都期待数据库能实现。现在开放平台os的kernel升级基本做不到online，似乎只有存储在这方面做的不错，高端存储的软件和硬件升级都可以online（基本使用的是cluster接管交替升级模式）。主机也许因为变化太频繁以及成本原因，难以实现cluster交替升级的模式。但其实我也希望尽快研究一下oracle实现online patch的原理，是如何解决link与正在运行的程序之间的关系，以及catpatch时刻如何解决数据库内部对象的变化问题。
 
    Object dependency tracking
 
    在oracle中我们可以通过dba_dependencies查找到对象之间的依赖关系，如果被依赖的对象发生了DDL，不论这个改变是否会影响到依赖对象，依赖对象都invalid并需要重新编译。很多人在繁忙的oltp系统中遭遇过类似困境。比如表中lob的storage属性发生变化会影响到引用这个表的对象如procedure、function、trigger等。往往不经意之间，dba的一个改动，系统突然就挂了。那么11g在这方面有所改进，如果对象属性的变化不会影响到依赖对象，那么依赖对象就不会需要重新编译。
    既然oracle都实现online patch了，强烈希望将来在对象重新进行编译的时候可以手工控制，预先编译完成择机切换，类似表的online redefine一样。希望11g未来某个版本可以实现这个功能。
 
    Data Guard Snapshot
 
    这个特性是使得我们可以在standby上做出快照而保留下standby在若干时间点上状态的版本。这样我们就可以挑选某一个快照出来使用。可以做测试、可以核对数据。当然，我在netapp filesystem 上做oracle 9i版本standby snapshot 已经有几年了，这项功能我非常喜欢，可以随意open read only一个2星期甚至3星期前的数据库去查找当时的某些数据。现在11g提供了这项功能，则我们就不必局限在存储厂商所提供的快照功能上了。
 
    Query on Physical standby database
 
    这个消息犹如一个重磅炸弹，在众多资深DBA中激起了无穷的想象。Oracle在9iR2中实现了logical standby（传闻是quest工程师的支援下用logmnr实现），logical standby只能存在一个，可以被用于产生报表。如果oracle可以在物理standby上做查询，那么这个意义就重大的多。一个主数据库可以拖多个物理standby，假定采用最大数据保护模式（事务能及时地传递到standby并且立即被应用到standby），那么这跟mysql的集群类似了，一个写多个读。ebay就是在负载均衡设备F5 加quest同步工具shareplex的帮助下，实现了一个写入多个读的模式，从而支持了数据库性能的扩展，也使得数据库的维护变的更容易， 不再担心单个数据库的灾难带来致命的影响。那么现在oracle 似乎朝这个方向又迈进了一步。9iR2 提出并在10g大加宣扬的oracle streams在11g中并没有成为重点，看起来streams还不如shareplex和realsync更获得用户的认可。那么query on physical standby 看起来则是一个简单的廉价的解决方案。这个功能最终能做到什么程度，还有待实践来检验。但是，这个消息，给予了我们太多的期望！
 
    Auto Memory Tuning
 
    Oracle 从9i 开始，让PGA可以自动管理，不必为单独进程的各个pga组件设置大小，减轻了dba的工作量，让进程内存管理更容易。同时sga可以通过设置sga max size 上限，sga内部各组件可以动态调整大小，系统也根据动态统计信息给出sga组件设置大小建议。到了10g 开始可以支持sga各组件由系统自动调整分配。虽然这个功能还让大家放心不下，但毕竟自动化管理的方向是得到大家认可的。现在11g走的更进一步，sga和pga合起来可以由数据库自动分配。DBA只需要告诉oracle可以使用多少内存而不必去关注各组件的具体分配。看起来，DBA们的日子又将轻松一些。
 
    ASM and ILM
 
    存储厂商早就提出了信息生命周期管理的概念，看起来一切那么美好。当然，在存储厂商炒作这个概念的时候，我发现对于一般客户这并不是一个可行的低成本方案。我们关注新技术新概念（实际上大多都是老技术组合包装稍微加工一下就成了新技术），切实地分析其对我们能产生什么价值，实际上成本是一个非常重要的因素。Oracle 在10g中推出ASM是一个重大的新特性。但可惜ASM稳定性相对raw device还没得到用户的广泛认可。ASM 是oracle向存储管理软件延伸的一个重要标志。在我看来，除了在无传统cluster软件下做rac之外，更重要的是存储负载均衡的功能。当新增加存储设备的时候，oracle可以在系统IO相对空闲时期将数据移动到新存储设备上达到均衡分布的目的。尤其在数据仓库中这个功能非常好用。
    我一听见oracle  ILM 第一印象就是想到ASM，它应该可以配合ILM做很多的事情，ASM可以帮助DBA将不活跃数据在线迁移到其他设备上，这是信息生命周期管理的基础。oracle在不断地尝试，放弃被市场淘汰的功能，发展被市场认可的特性。
    我以前曾经多次论述oracle 跟 os之间相互学习的过程，现在看起来，数据库不仅跟os，还跟存储搅和在一起了。将来三者之间是相互竞争、相互合作的过程。不管如何，对于我们客户来说，能从中受益，那就是好事。
 
 
后记
 
    Oracle数据库技术的发展，其实最近几年一直都在朝着关注细节的方向，如何满足客户差异化的需求，为客户提供特定环境下的最佳性能，是oracle领先于其他数据库厂商的重要原因。数据库、os、存储在某些功能上的融合，也有利于我们客户降低投资成本和管理成本。最后要感谢oracle的设计者，你们能真切地感受到客户的需求，并转变为现实。
    今年oracle将在北京、上海、广州、成都四地分别举办oracle DB 11g launch大会，9月19日在上海，开场15分钟我受邀将做一个不限制内容的演讲。从包括今年oracle open world的状况来看，oracle对中国市场的重视程度明显提高，对中国网络社区的关注程度也明显提高。希望大家可以加强交流，共同提高。
 

如磁盘上数据文件的最小io单元叫block一样，buffer cache的最小单元（或者说结构）叫buffer，每个buffer跟x$bh中每条记录有一一对应关系。
 
从使用维护buffer这个角度讲，存在一些链表主要的有LRU list 和dirty list（checkpoint queue），当从磁盘读取数据到buffer中时，需要到LRU list上寻找free buffer，如果没有则采用LRU算法把一些buffer清空，然后继续。buffer修改后，从LRU list上移到dirty list上，dirty list根据低重做值排序，由dbwr写出到数据文件。
 
LRU list上的latch是cache buffer lru chain，latch的数量由_db_block_lru_latches控制，当这个latch竞争激烈，可能是数据老化，全表扫描频繁。
 
从如何搜索buffer这个角度讲，存在这么一个数据结构，有一定数量的hash bucket，每个bucket下面是一个双向链表cache buffer chain，链表上挂着一个一个buffer。如何搜索一个buffer在哪里，以及如何定位一个buffer应该放到哪里，是通过hash算法找到那个bucket，然后遍历cache buffer chain。bucket的数量由_db_block_hash_buckets控制。
 
这个链表上的latch是cache buffer chain，latch的数量由_db_block_hash_latches控制，主要是热点块的问题，可以结合v$session_wait,v$latch_children,x$bh,v$sqltext,dba_extents找到sql。
 
------ ------ ------ ------
shared pool的最小单元叫chunk，每个chunk跟x$ksmsp中每条记录有一一对应关系，chunk的状态有4种：free（空的），recreate（需要释放的），freeable（一会儿可以释放的），perm（不能释放的）。
 
可用的chunk由一个叫free list的结构管理，它是由一定数量的bucket组成，oracle9i中有255个bucket，后面的bucket容量较前面的大。每个bucket下面是chunk list。
 
reserved pool是单独开辟出来的供连续的大内存分配，大小由shared_pool_reserved_size决定。当需要一块内存时，先扫描free list，如果找到就分割使用，找不到就通过LRU算法释放一些recreate的，合并一些free的，如果还不够，则到reserved pool中分配一块比_shared_pool_reserved_min_alloc这个值大的空间。
 
如果sql没有绑定变量，则一次一次地分割shared pool，很可能产生大量碎片导致ORA-04031错误。除了绑定变量，还可检查shared_pool_size,shared_pool_reserved_size,shared_pool_reserved_min_alloc这些参数的值，当然，bug也有可能。
 
shared pool中最重要的latch是shared pool latch，library cache latch。shared pool latch是管理和搜索free list时需要获取的，在oracle9i中有7个。library cache latch是增加新的sql到library cache时需要获取的，它的数量由_kgl_latch_count控制。如果sql没有充分共享，反复解析，很容易造成这两个latch的竞争或者ORA-04031错误。解决办法是sql中尽量使用绑定变量，除此，数据库里使用cursor_sharing参数强制绑定变量，当然这个参数有副作用，或者强制刷新共享池alter system flush shared_pool，当然这个治标不治本。
 
还有library cache pin，library cache lock，通常发生在授予权限，重编译对象，以及存在较复杂的dependence的时候。

Windows XP + 9206, google + check

• 
  delete/truncate 只删除数据不删除表，索引的结构。
  drop 将删除表的结构被依赖的 index/constrain/trigger，依赖于该表的 procedure/function 将保留，但是变为 invalid 状态。
• 
  delete 是 dml，写 rollback segement，可回滚，速度慢，事务提交之后才生效。在 9i 满足 undo_retention 条件下可使用 flashback。一次性大批量数据的 delete 可能导致回滚段急剧扩展从而影响到数据库，慎用。触发 trigger。
  truncate/drop 是 ddl，隐式提交，不写 rollback segment，不能回滚，速度快。9i 不能使用 flashback。不触发 trigger。
• 
  delete 不影响表所占用的 extent，HWM 保持原位置不动，即使删除的是最靠近 HWM 的数据。delete 其实也可以释放空间，但是不降低 HWM，delete 后 block 的空闲空间达到 pct_used，就可以重用。
  truncate 缺省情况下将空间（表和索引）释放到 minextents 个 extent，除非使用 reuse storage。truncate 会将高水线复位（回到最开始）。
  drop 将表所占用的空间全部释放，segment 不存在，无所谓 HWM 的概念。
• 
  truncate/drop 的对象必须是本模式下的，或者被授予 drop any table 的权限，但 drop any table 权限不能 truncate/drop sys 的表。
  delete 的对象必须是本模式下的，或者被授予 delete on SCHEMA.table 或 delete any table 的权限，但 delete any table 权限不能 delete sys 的表。
• 
  不能 truncate 一个带有 enable 外键的表，不管表里有没有数据，如果要 truncate，首先要 disable 外键或者删除外键（drop 外键的表肯定是删除了外键）。
  不能 drop 一个带有 enable 外键的表，不管表里有没有数据，如果要 drop，首先要删除外键，或者直接用 drop table TABLE_NAME cascade constraints; 级联删除外键。
  delete 可以。

我来补充一些

这里有一个讨论讲得很清楚：heartbeat

1. oracle 7 中只有全局检查点，因为没有checkpoint queue，dirty buffer是无序的，所以必须一次性写出，写出的过程中要lock dirty buffer不能再被修改。

oracle 8 中全局检查点变成了增量检查点，它是和checkpoint queue一起出现的。增量检查点发生的时候，ckpt检查点进程将已经完成的最后一个检查点写到数据文件头和控制文件，通知dbwr开始写数据文件写到检查点触发这个时刻（也就是当前时刻）。在checkpoint queue中，dirty buffer按照低重做值（第一次变脏的顺序）排序，所以在写出的时候dirty buffer可以同时被修改。这是增量检查点最重要的作用。

有一个叫heartbeat的概念，也就是ckpt检查点进程每3秒将当前dbwr写的进度（rba）写到控制文件中。于是这个就缩短了instance recovery和media recovery的过程（当然这个过程也不是越短越好，否则dbwr写太频繁会带来I/O方面的问题）。这是增量检查点的另一个好处。

2. 这几个参数就是通过oracle的算法，决定了下一次增量检查点发生的时间或者说位置。

3. 9i开始推荐使用fast_start_mttr_target，另外的参数都置0。

Whenever you set FAST_START_MTTR_TARGET to a nonzero value, and while MTTR advisory is ON, Oracle Corporation recommends that you disable (set to 0) the following parameters:

• LOG_CHECKPOINT_TIMEOUT
• LOG_CHECKPOINT_INTERVAL
• FAST_START_IO_TARGET

Because these initialization parameters either override FAST_START_MTTR_TARGET or potentially drive checkpoints more aggressively than FAST_START_MTTR_TARGET does, they can interfere with the simulation.

这里“MTTR advisory is ON”的条件是，STATISTICS_LEVEL is set to TYPICAL or ALL，以及the initialization parameter FAST_START_MTTR_TARGET is set to a nonzero value。

摘自blue_prince的blog，注意拉注意拉，某公司的一面试题。^_^

由于Oracle中LGWR和DBWR工作的不一致，Oracle引入了检查点的概念，用于同步数据库，保证数据库的一致性。在Oracle里面，检查点分为两种：完全检查点和增量检查点。下面我们分别介绍这两种检查点的作用：

1、 完全检查点

在Oracle8i之前，数据库的发生的检查点都是完全检查点，完全检查点会将数据缓冲区里面所有的脏数据块写入相应的数据文件中，并且同步数据文件头和控制文件，保证数据库的一致。完全检查点在8i之后只有在下列两种情况下才会发生：

（1、）DBA手工执行alter system checkpoint的命令；

（2、）数据库正常shutdown（immediate,transcational,normal）。

由于完全检查点会将所有的脏数据库块写入，巨大的IO往往会影响到数据库的性能。因此Oracle从8i开始引入了增量检查点的概念。

2、 增量检查点

Oracle从8i开始引入了检查点队列这么一种概念，用于记录数据库里面当前所有的脏数据块的信息，DBWR根据这个队列而将脏数据块写入到数据文件中。检查点队列按时间先后记录着数据库里面脏数据块的信息，里面的条目包含RBA（Redo Block Address，重做日志里面用于标识检查点期间数据块在重做日志里面第一次发生更改的编号）和数据块的数据文件号和块号。在检查点期间不论数据块更改几次，它在检查点队列里面的位置始终保持不变，检查点队列也只会记录它最早的RBA，从而保证最早更改的数据块能够尽快写入。当DBWR将检查点队列里面的脏数据块写入到数据文件后，检查点的位置也要相应地往后移，CKPT每三秒会在控制文件中记录检查点的位置，以表示Instance Recovery时开始恢复的日志条目，这个概念称为检查点的“心跳”（heartbeat）。检查点位置发生变更后，Oracle里面通过4个参数用于控制检查点位置和最后的重做日志条目之间的距离。在这里面需要指出的是，多数人会将这4个参数看作控制增量检查点发生的时间。事实上这是错误的，这4个参数是用于控制检查点队列里面的条目数量，而不是控制检查点的发生。

（1、）fast_start_io_target

该参数用于表示数据库发生Instance Recovery的时候需要产生的IO总数，它通过v$filestat的AVGIOTIM来估算的。比如我们一个数据库在发生Instance Crash后需要在10分钟内恢复完毕，假定OS的IO每秒为500个，那么这个数据库发生Instance Recovery的时候大概将产生500*10*60=30,000次IO，也就是我们将可以把fast_start_io_target设置为30000。

（2、）fast_start_mttr_target

我们从上面可以看到fast_start_io_target来估算检查点位置比较麻烦。Oracle为了简化这个概念，从9i开始引入了fast_start_mttr_target这么一个参数，用于表示数据库发生Instance Recovery的时间，以秒为单位。这个参数我们从字面上也比较好理解，其中的mttr是mean time to recovery的简写，如上例中的情况我们可以将fast_start_mttr_target设置为600。当设置了fast_start_mttr_target后，fast_start_io_target这个参数将不再生效，从9i后fast_start_io_target这个参数被Oracle废除了。

（3、）log_checkpoint_timeout

该参数用于表示检查点位置和重做日志文件末尾之间的时间间隔，以秒为单位，默认情况下是1800秒。

（4、）log_checkpoint_interval

该参数是表示检查点位置和重做日志末尾的重做日志块的数量，以OS块表示。

（5、）90% OF SMALLEST REDO LOG

除了以上4个初始化参数外，Oracle内部事实上还将重做日志文件末尾前面90%的位置设为检查点位置。在每个重做日志中，这么几个参数指定的位置可能不尽相同，Oracle将离日志文件末尾最近的那个位置确认为检查点位置。

我摘了以下几个人写过的话，基本上可以搞清楚instance crash之后instance recovery的过程，这个比看英文文档要简单多多了。^_^

wanghai－－－

1. 增量检查点
在checkpoint queue的基础上实现了增量检查点，每3秒发生一次checkpoint heartbeat，记录dbwr上次写成功的最大RBA(redo block address)。这样的话做instance recovery的时候就从这个rba开始，而不是从上次checkpoint scn开始，大大节省了恢复时间。
 
2. twice scan of redo log
在应用redo之前，redo将会被操作两次，第一次去扫描哪些redo record需要被应用，因为9i在redo里添加了dbwr写数据块的信息，所以dbwr发生前的日志将不会被应用。第二步就是选出需要被应用的日志然后开始rollforward。
 
3. rollforward
在做instance recovery时必须先定位到redo log 然后应用所有日志到datafile，这时候包括了committed和uncommitted的数据。当做完rollward，数据库就可以open了。
 
4. rollback
因为rollforward产生了uncommitted数据，所以必须回滚这些数据。这将由smon和on-demand rollback来实现。smon将会扫描undo segment header去标志所有活动事务为dead，然后会逐渐去回滚这些事务。另外on-demand rollback提供了前台进程进行rollback，当前台进程企图获得被dead事务占用row lock，这时候前台进程将会去undo segment取得before image去回滚这个块，至于其他被这个dead事务lock的块就等待smon去回滚。
 
另外，如果在数据库打开的过程中process crash导致transaction dead，resource不能被释放的情况，这时候如果另一个进程需要这些resource，那么这个进程将会等待直到pmon清理dead process释放出resource。

eygle－－－

如果数据库Crash，重新启动，很久远以前的未提交事务并不在Redo的恢复序列中。
但是未提交事务一定在回滚段事务表上存在，并且State＝10，为活动事务。这就够了。

数据库启动之后，这些事务会被SMON逐个标记为Dead（不可能再活过来了），然后由SMON慢慢去回滚这些事务；也存在另外一种情况，后来的进程会去读这些未提交数据，发现Dead事务未提交，则主动进行回滚。

kamus－－－

1. 一个数据块发生更新，必然写回滚
2. 回滚段的block变化也记录在redo中

一份未提交的数据必定在回滚中有相应的前镜像，任何正常的恢复都一定会把这些变化重新构建出来。

想像一下

1. update事务1更新了block 1
2. 回滚段1记录了block1的前镜像
3. checkpoint
4. update事务2更新了block2
5. 回滚段2记录了block2的前镜像
6. instance crash

现在重启数据库

1. 根据redo重新构建block2
2. 根据redo重新构建回滚段2
3. database open
4. SMON用回滚段2的数据回滚block2，SMON用回滚段1的数据回滚block1

最后一步也可能是
在另外一个select检索到block1或者block2的时候，发现这两个block的数据都是未提交的，此时再回滚block1和block2。

所以，只要有相应的回滚数据存在，无论什么时候oracle都可以找到一致的数据，oracle只需要知道这个事务是提交了的还是没提交了的，而这点在block header ITL中有记录。