oracle_专家高级编程_中文第九章.pdf

《oracle_专家高级编程_中文第九章.pdf》由会员分享，可在线阅读，更多相关《oracle_专家高级编程_中文第九章.pdf（38页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、 1第 9 章 redo 与 undo 这一章将介绍 Oracle 数据库中最重要的两部分数据：redo 与 undo。redo（重做信息）是 Oracle 在在线（或归档）重做日志文件中记录的信息，万一出现失败时可以利用这些数据来“重放”（或重做）事务。undo（撤销信息）是 Oracle 在 undo 段中记录的信息，用于取消或回滚事务。在这一章中，我们讨论的内容很多，包括 redo 和 undo（回滚信息）如何生成，以及事务、恢复等方面如何应用 redo 和 undo。首先我们给出一个高层概述，说明 undo 和 redo 分别是什么，它们如何协作。然后向下细化，更深入地介绍各个主题，并

2、讨论作为开发人员需要了解哪些内容。这一章主要面向开发人员，在此没有涵盖应由 DBA 完全负责确定和调整的问题。例如，如何找到 RECOVERY_PARALLELISM 或FAST_START_MTTR_TARGET 参数的最优设置？这个问题要由 DBA 确定，本章就没有涉及。但是，redo 和 undo 则是 DBA 和开发人员都关心的主题，它们是 DBA和开发人员之间的桥梁。不论是 DBA还是开发人员，都需要对 redo 和 undo 的作用有很好的基本了解，知道它们如何工作，并且知道如何避免与 redo 和 undo 的使用有关的潜在问题。如果掌握了 redo 和 undo 的相关知识，这

3、还有助于 DBA和开发人员更好地理解数据库一般如何操作。在这一章中，我将针对 Oracle 的这些机制提供伪代码，并从概念上解释到底会发生什么。这里不会详尽地介绍所有内部细节，如会用哪些数据字节更新哪些文件等详细内容并不会谈到。具体发生的情况可能比我们介绍的更复杂，但是不管怎样，如果能很好地理解这些机制的工作流程，将很有意义，这有助于理解你的动作会带来怎样的影响。9.1 什么是 redo？重做日志文件（redo log file）对 Oracle 数据库来说至关重要。它们是数据库的事务日志。Oracle 维护着两类重做日志文件：在线（online）重做日志文件和归档（archived）重做日志

4、文件。这两类重做日志文件都用于恢复；其主要目的是，万一实例失败或介质失败，它们就能派上用场。如果数据库所在主机掉电，导致实例失败，Oracle 会使用在线重做日志将系统恰好恢复到掉电之前的那个时间点。如果磁盘驱动器出现故障（这是一个介质失败），Oracle 会使用归档重做日志以及在线重做日志将该驱动器上的数据备份恢复到适当的时间点。另外，如果你“无意地”截除了一个表，或者删除了某些重要的信息，然后提交了这个操作，那么可以恢复受影响数据的一个备份，并使用在线和归档重做日志文件把它恢复到这个“意外”发生前的时间点。归档重做日志文件实际上就是已填满的“旧”在线重做日志文件的副本。系统将日志文件填满时

5、，ARCH 进程会在另一个位置建立在线重做日志文件的一个副本，也可以在本地和远程位置上建立多个另外的副本。如果由于磁盘驱动器损坏或者其他物理故障而导致失败，就会用这些归档重做日志文件来执行介质恢复。Oracle 拿到这些归档重做日志文件，并把它们应用于数据文件的备份，使这些数据文件能“赶上”数据库的其余部分。归档重做日志文件是数据库的事务历史。注意注意 随着 Oracle 10g 的到来，我们现在还有了一种闪回技术（flashback）。利用闪回技术，可以执行闪回查询（也就是说，查询过去某个时间点的数据），取消数据库表的删除，将表置回到以前某个时间的状态，等等。因此，现在使用备份和归档重做日志

6、文件来完成传统恢复的情况越来越少。不过，执行恢复是 DBA最重要的任务，而且 DBA在数据库恢复方面绝对不能犯错误。每个 Oracle 数据库都至少有两个在线重做日志组，每个组中至少有一个成员（重做日志文件）。这些在线重做日志组以循环方式使用。Oracle 会写组 1 中的日志文件，等写到组 1 中文件的最后时，将切换到日志文件组 2，开始写这个组中的文件。等到把日志文件组 2 写满时，会再次切换回日志文件组 1（假设只有两个重做日志文件组；如果有 3 个重做日志文件组，Oracle 当然会继续写第 3 个组）。数据库之所以成为数据库（而不是文件系统等其他事物），是因为它有自己独有的一些特征，

7、重做日志或事务日志就是其中重要的特性之一。重做日志可能是数据库中最重要的恢复结构，不过，如果没有其他部分（如 undo 段、分布式事务恢复等），但靠重做日志什么也做不了。重做日志是数据库区别于传统文件系统的一个主要因素。Oracle 正写到一半的时候有可能发生掉电，利用在线重做日志，我们就能有效地从这个掉电失败中恢复。归档重做日志则允许我们从介质失败中恢复，如硬盘损坏，或者由于人为错误而导致数据丢失。如果没有重做日志，数据库提供 id 保护就比文件系统多不了多少。29.2 什么是 undo？从概念上讲，undo 正好与 redo 相对。你对数据执行修改时，数据库会生成 undo 信息，这样万一

8、你执行的事务或语句由于某种原因失败了，或者如果你用一条 ROLLBACK 语句请求回滚，就可以利用这些 undo 信息将数据放回到修改前的样子。redo 用于在失败时重放事务（即恢复事务），undo 则用于取消一条语句或一组语句的作用。与 redo 不同，undo 在数据库内部存储在一组特殊的段中，这称为 undo段（undo segment）。注意注意 “回滚段”（rollback segment）和“undo 段“（undo segment）一般认为是同义词。使用手动 undo 管理时，DBA会创建”回滚段“。使用自动 undo 管理时，系统将根据需要自动地创建和销毁”undo 段“。对于

9、这里的讨论来说，这些词的意图和作用都一样。通常对 undo 有一个误解，认为 undo 用于数据库物理地恢复到执行语句或事务之前的样子，但实际上并非如此。数据库只是逻辑地恢复到原来的样子，所有修改都被逻辑地取消，但是数据结构以及数据库块本身在回滚后可能大不相同。原因在于：在所有多用户系统中，可能会有数十、数百甚至数千个并发事务。数据库的主要功能之一就是协调对数据的并发访问。也许我们的事务在修改一些块，而一般来讲往往会有许多其他的事务也在修改这些块。因此，不能简单地将一个块放回到我们的事务开始前的样子，这样会撤销其他人（其他事务）的工作！例如，假设我们的事务执行了一个INSERT语句，这条语句导

10、致分配一个新区段（也就是说，导致表的空间增大）。通过执行这个INSET，我们将得到一个新的块，格式化这个块以便使用，并在其中放上一些数据。此时，可能出现另外某个事务，它也向这个块中插入数据。如果要回滚我们的事务，显然不能取消对这个块的格式化和空间分配。因此，Oracle 回滚时，它实际上会做与先前逻辑上相反的工作。对于每个 INSERT，Oracle 会完成一个 DELETE。对于每个 DELETE，Oracle 会执行一个 INSERT。对于每个 UPDATE，Oracle 则会执行一个“反UPDATE“，或者执行另一个 UPDATE 将修改前的行放回去。注意注意 这种 undo 生成对于直

11、接路径操作（direct path operation）不适用，直接路径操作能够绕过表上的 undo 生成。稍后将更详细地讨论这些问题。怎么才能看到 undo 生成（undo generation）具体是怎样的呢？也许最容易的方法就是遵循以下步骤：（1）创建一个空表。（2）对它做一个全部扫描，观察读表所执行的 I/O 数量。（3）在表中填入许多行（但没有提交）。（4）回滚这个工作，并撤销。（5）再次进行全表扫描，观察所执行的 I/O 数量。首先，我们创建一个空表：ops$tkyteORA10G create table t 2 as 3 select*4 from all_objects 5

12、where 1=0;Table created.然后查询这个表，这里在 SQL*Plus 中启用了 AUTOTRACE，以便能测试 I/O。注意注意 在这个例子中，每次（即每个用例）都会做两次全表扫描。我们的目标只是测试每个用例中第二次完成的 I/O。这样可以避免统计在解析和优化期间优化器可能完成的额外 I/O。最初，这个查询需要 3 个 I/O 来完成这个表的全表扫描：ops$tkyteORA10G select*from t;no rows selected 3 ops$tkyteORA10G set autotrace traceonly statistics ops$tkyteORA1

13、0G select*from t;no rows selected Statistics-0 recursive calls 0 db block gets 3 consistent gets.ops$tkyteORA10G set autotrace off 接下来，向表中增加大量数据。这会使它“扩大“，不过随后再将其回滚：ops$tkyteORA10G insert into t select*from all_objects;48350 rows created.ops$tkyteORA10G rollback;Rollback complete.现在，如果再次查询这个表，会发现这一次读

14、表所需的 I/O 比先前多得多：ops$tkyteORA10G select*from t;no rows selected ops$tkyteORA10G set autotrace traceonly statistics ops$tkyteORA10G select*from t;no rows selected Statistics-0 recursive calls 0 db block gets 689 consistent gets.ops$tkyteORA10G set autotrace off 前面的 INSERT 导致将一些块增加到表的高水位线（high-water ma

15、rk，HWM）之下，这些块没有因为回滚而消失，它们还在那里，而且已经格式化，只不过现在为空。全表扫描必须读取这些块，看看其中是否包含行。这说明，回滚只是一个“将数据库还原“的逻辑操作。数据库并非真的还原成原来的样子，只是逻辑上相同而已。9.2.1 redo和 undo 如何协作？在这一节中，我们来看看在不同场景中 redo 和 undo 如何协作。例如，我们会讨论处理 INSERT 时关于 redo 和 undo 生成会发生什么情况，另外如果在不同时间点出现失败，Oracle 将如何使用执行信息。有意思的是，尽管 undo 信息存储在 undo 表空间或 undo 段中，但也会受到 redo

16、的保护。换句话说，会把 undo 数据当成是表数据或索引数据一样，对 undo 的修改会生成一些 redo，这些 redo 将计入日志。为什么会这样呢？稍后在讨论系统崩溃时发生的情况时将会解释它，到时你会明白了。将 undo 数据增加到 undo 段中，并像其他部分的数据一样在缓冲区缓存中得到缓存。INSERT-UPDATE-DELETE 示例场景示例场景 作为一个例子，我们将分析对于下面这组语句可能发生什么情况：4insert into t(x,y)values(1,1);update t set x=x+1 where x=1;delete from t where x=2;我们会沿着不同

17、的路径完成这个事务，从而得到以下问题的答案：q 如果系统在处理这些语句的不同时间点上失败，会发生什么情况？q 如果在某个时间点上 ROLLBACK，会发生什么情况？q 如果成功并 COMMIT，会发生什么情况？1.INSERT 对于第一条 INSERT INTO T 语句，redo 和 undo 都会生成。所生成的 undo 信息足以使 INSERT“消失“。INSERT INTO T 生成的 redo信息则足以让这个插入”再次发生“。插入发生后，系统状态如图 9-1 所示。图图 9-1 INSERT 之后的系统状态 这里缓存了一些已修改的 undo 块、索引块和表数据块。这些块得到重做日志缓

18、冲区中相应条目的“保护“。l 假想场景：系统现在崩溃假想场景：系统现在崩溃 即使系统现在崩溃也没有关系。SGA会被清空，但是我们并不需要 SGA里的任何内容。重启动时就好像这个事务从来没有发生过一样。没有将任何已修改的块刷新输出到磁盘，也没有任何 redo 刷新输出到磁盘。我们不需要这些 undo 或 redo 信息来实现实例失败恢复。l 假想场景：缓冲区缓存现在已满假想场景：缓冲区缓存现在已满 在这种情况下，DBWR 必须留出空间，要把已修改的块从缓存刷新输出。如果是这样，DBWR 首先要求 LGWR 将保护这些数据库块的 redo 条目刷新输出。DBWR 将任何有修改的块写至磁盘之前，LG

19、WR 必须先刷新输出与这些块相关的 redo 信息。这是有道理的如果我们要刷新输出表 T 中已修改的块，但没有刷新输出与 undo 块关联的 redo 条目，倘若系统失败了，此时就会有一个已修改的表 T 块，而没有与之相关的 redo 信息。在写出这些块之前需要先刷新输出重做日志缓存区，这样就能重做（重做）所有必要的修改，将 SGA 放回到现在的状态，从而能发生回滚。从第二个场景还可以预见到一些情况。这里描述的条件是“如果刷新输出了表 T 的块，但没有刷新输出 undo 块的相应 redo，而且此时系统失败了“，这个条件开始变得有些复杂。随着增加更多用户、更多的对象，再加上并发处理等因素，条件

20、还会更复杂。此时的情况如图 9-1 所示。我们生成了一些已修改的表和索引块。这些块有一些与之关联的 undo 段块，这 3 类块都会生成 redo 来保护自己。如果还记得第 4 章中对重做日志缓冲区的讨论，应该知道，它会在以下情况刷新输出：每 3 秒一次；缓冲区 1/3 满时或者包含了1MB 的缓冲数据；或者是只要发生提交就会刷新输出。重做日志缓冲区还有可能会在处理期间的某一点上刷新输出。在这种情况下，其状态如图 9-2 所示。5 图图 9-2 重做日志缓冲区刷新输出后的系统状态 2.UPDATE UPDATE 所带来的工作与 INSERT 大体一样。不过 UPDATE 生成的 undo 量更

21、大；由于存在更新，所以需要保存一些“前“映像。系统状态如图 9-3 所示。图图 9-3 UPDATE 后的系统状态 块缓冲区缓存中会有更多新的 undo 段块。为了撤销这个更新，如果必要，已修改的数据库表和索引块也会放在缓存中。我们还生成了更多的重做日志缓存区条目。下面假设前面的插入语句生成了一些重做日志，其中有些重做日志已经刷新输出到磁盘上，有些还放在缓存中。l 假想场景：系统现在崩溃假想场景：系统现在崩溃 启动时，Oracle 会读取重做日志，发现针对这个事务的一些重做日志条目。给定系统的当前状态，利用重做日志文件中对应插入的redo 条目，并利用仍在缓冲区中对应插入的 redo 信息，O

22、racle 会“前滚”插入。最后到与图 9-1 类似的状态。现在有一些 undo 块（用以撤销插入）、已修改的表块（刚插入后的状态），以及已修改的索引块（刚插入后的状态）。由于系统正在进行崩溃恢复，而且我们的会话还不再连接（这是当然），Oracle 发现这个事务从未提交，因此会将其回滚。它取刚刚在缓冲区缓存中前滚得到的 undo，并将这些 undo 应用到数据和索引块，使数据和索引块“恢复”为插入发生前的样子。现在一切都回到从前。磁盘上的块可能会反映前面的 INSERT，也可能不反映（这取决于在崩溃前是否已经将块刷新输出）。如果磁盘上的块确实反映了插入，而实际上现在插入已经被撤销，当从缓冲区缓

23、存刷新输出块时，数据文件就会反映出插入已撤销。如果磁盘上的块本来就没有反映前面的插入，就不用去管它这些块以后肯定会被覆盖。这个场景涵盖了崩溃恢复的基本细节。系统将其作为一个两步的过程来完成。首先前滚，把系统放到失败点上，然后回滚尚未提交 6的所有工作。这个动作会再次同步数据文件。它会重放已经进行的工作，并撤销尚未完成的所有工作。l 假想场景：应用回滚事务假想场景：应用回滚事务 此时，Oracle 会发现这个事务的 undo 信息可能在缓存的 undo 段块中（基本上是这样），也可能已经刷新输出到磁盘上（对于非常大的事务，就往往是这种情况）。它会把 undo 信息应用到缓冲区缓存中的数据和索引块

24、上，或者倘若数据和索引块已经不在缓存中，则要从磁盘将数据和索引块读入缓存，再对其应用 undo。这些块会恢复为其原来的行值，并刷新输出到数据文件。这个场景比系统崩溃更常见。需要指出，有一点很有用：回滚过程中从不涉及重做日志。只有恢复和归档时会当前重做日志。这对于调优是一个很重要的概念：重做日志是用来写的（而不是用于读）。Oracle 不会在正常的处理中读取重做日志。只要你有足够的设备，使得 ARCH 读文件时，LGWR 能写到另一个不同的设备，那么就不存在重做日志竞争。许多其他的数据库（非 Oracle）都把日志文件处理为“事务日志”。这些数据库没有把 redo 和 undo 分开。对于这些系

25、统，回滚可能是灾难性的，回滚进程必须读取日志，而日志写入器正在试图写这个日志。这就向系统中最薄弱的环节引入了竞争。Oracle 的目标是：可以顺序地写日志，而且在写日志时别人不会读日志。3.DELETE 同样，DELETE 会生成 undo，块将被修改，并把 redo 发送到重做日志缓冲区。这与前面没有太大的不同。实际上，它与 UPDATE如此类似，所以我们不再啰嗦，直接来介绍 COMMIT。4.COMMIT 我们已经看到了多种失败场景和不同的路径，现在终于到 COMMIT 了。在此，Oracle 会把重做日志缓冲区刷新输出到磁盘，系统状态如图 9-4 所示。图图 9-4 COMMIT 后的系

26、统状态 已修改的块放在缓冲区缓存中；可能有一些块已经刷新输出到磁盘上。重做这个事务所需的全部 redo 都安全地存放在磁盘上，现在修改已经是永久的了。如果从数据文件直接读取数据，可能会看到块还是事务发生前的样子，因为很有可能 DBWR 还没有（从缓冲区缓存）写出这些块。这没有关系，如果出现失败，可以利用重做日志文件来得到最新的块。undo信息会一直存在，除非 undo段回绕重用这些 undo 块。如果某些对象受到影响，Oracle 会使用这个 undo 信息为需要这些对象的会话提供对象的一致读。9.3 提交和回滚处理 有一点很重要，我们要知道重做日志文件对开发人员有什么影响。下面介绍编写代码的

27、不同方法会对重做日志的利用有怎样的影响。在本章前面已经了解了 redo 的原理，接下来介绍一些更特定的问题。作为开发人员，你能检测到许多这样的场景，但是它们要由 DBA来修正，因为这些场景会影响整个数据库实例。我们先来介绍 COMMIT 期间会发生什么，然后讨论有关在线重做日志的一些经常被问到的问题。79.3.1 COMMIT 做什么？作为一名开发人员，你应该深入了解 COMMIT 期间会做些什么。在这一节中，我们将分析 Oracle 中处理 COMMIT 语句期间发生的情况。COMMIT 通常是一个非常快的操作，而不论事务大小如何。你可能认为，一个事务越大（换句话说，它影响的数据越多），CO

28、MMIT 需要的时间就越长。不是这样的。不论事务有多大，COMMIT的响应时间一般都很“平”（flat，可以理解为无高低变化）。这是因为 COMMIT 并没有太多的工作去做，不过它所做的确实至关重要。这一点很重要，之所以要了解并掌握这个事实，原因之一是：这样你就能心无芥蒂地让事务有足够的大小。在上一章曾经讨论过，许多开发人员会人为地限制事务的大小，分别提交太多的行，而不是一个逻辑工作单元完成后才提交。这样做主要是出于一种错误的信念，即认为可以节省稀有的系统资源，而实际上这只是增加了资源的使用。如果一行的 COMMIT 需要 X 个时间单位，1,000 次 COMMIT 也同样需要 X 个时间单

29、位，倘若采用以下方式执行工作，即每行提交一次共执行 1,000 次 COMMIT，就会需要 1000*X 各时间单位才能完成。如果只在必要时才提交（即逻辑工作单元结束时），不仅能提高性能，还能减少对共享资源的竞争（日志文件、各种内部闩等）。通过一个简单的例子就能展示出过多的提交要花费更长的时间。这里将使用一个 Java 应用，不过对于大多数其他客户程序来说，结果可能都是类似的，只有 PL/SQL 除外（在这个例子后面，我们将讨论为什么会这样）。首先，下面是我们要插入的示例表：scottORA10G desc test Name Null?Type-ID NUMBER CODE VARCHAR2

30、(20)DESCR VARCHAR2(20)INSERT_USER VARCHAR2(30)INSERT_DATE DATE Java 程序要接受两个输入：要插入（INSERT）的行数（iters），以及两次提交之间插入的行数（commitCnt）。它先连接到数据库，将autocommit（自动提交）设置为 off（所有 Java 代码都应该这么做），然后将 doInserts()方法共调用 3 次：q 第一次调用只是“热身”（确保所有类都已经加载）。q 第二次调用指定了要插入（INSERT）的行数，并指定一次提交多少行（即每 N 行提交一次）。q 最后一次调用将要插入的行数和一次提交的行数设

31、置为相同的值（也就是说，所有行都插入之后才提交）。然后关闭连接，并退出。其 main 方法如下：import java.sql.*;import oracle.jdbc.OracleDriver;import java.util.Date;public class perftest public static void main(String arr)throws Exception DriverManager.registerDriver(new oracle.jdbc.OracleDriver();Connection con=DriverManager.getConnection (jd

32、bc:oracle:thin:localhost.localdomain:1521:ora10g,scott,tiger);Integer iters=new Integer(arr0);Integer commitCnt=new Integer(arr1);on.setAutoCommit(false);doInserts(con,1,1);doInserts(con,iters.intValue(),commitCnt.intValue();doInserts(con,iters.intValue(),iters.intValue();mit();8 con.close();现在，doIn

33、serts()方法相当简单。首先准备（解析）一条 INSERT 语句，以便多次反复绑定/执行这个 INSERT：static void doInserts(Connection con,int count,int commitCount)throws Exception PreparedStatement ps=con.prepareStatement (insert into test +(id,code,descr,insert_user,insert_date)+values(?,?,?,user,sysdate);然后根据要插入的行数循环，反复绑定和执行这个 INSERT。另外，它会检

34、查一个行计数器，查看是否需要 COMMIT，或者是否已经不在循环范围内。还要注意，我们分别在循环之前和循环之后获取了当前时间，从而监视并报告耗用的时间：int rowcnt=0;int committed=0;long start=new Date().getTime();for(int i=0;i TRUE);end;);doInserts(con,iters.intValue(),iters.intValue();对于 main 方法，要增加以下代码：PreparedStatement commit=con.prepareStatement (begin/*commit size=+com

35、mitCount+*/commit;end;);int rowcnt=0;int committed=0;.if(rowcnt=commitCount)commit.executeUpdate();rowcnt=0;committed+;如果运行这个应用来插入 10,000 行，每行提交一次，TKPROF 报告显示的结果如下：begin/*commit size=1*/commit;end;.Elapsed times include waiting on following events:Event waited on Times Max.Wait Total Waited-Waited -

36、10SQL*Net message to client 10000 0.00 0.01 SQL*Net message from client 10000 0.00 0.04 log file sync 8288 0.06 2.00 如果还是插入 10,000 行，但是只在插入了全部 10,000 行时才提交，就会得到如下的结果：begin/*commit size=10000*/commit;end;.Elapsed times include waiting on following events:Event waited on Times Max.Wait Total Waited-Wa

37、ited -log file sync 1 0.00 0.00 SQL*Net message to client 1 0.00 0.00 SQL*Net message from client 1 0.00 0.00 如果在每个 INSERT 之后都提交，几乎每次都要等待。尽管每次只等待很短的时间，但是由于经常要等待，这些时间就会累积起来。运行时间中整整 2 秒都用于等待 COMMIT 完成，换句话说，等待 LGWR 将 redo 写至磁盘。与之形成鲜明对比，如果只提交一次，就不会等待很长时间（实际上，这个时间实在太短了，以至于简直无法度量）。这说明，COMMIT 是一个很快的操作；我们希望

38、响应时间或多或少是“平”的，而不是所完成工作量的一个函数。那么，为什么 COMMIT 的响应时间相当“平”，而不论事务大小呢？在数据库中执行 COMMIT 之前，困难的工作都已经做了。我们已经修改了数据库中的数据，所以 99.9%的工作都已经完成。例如，已经发生了以下操作：q 已经在 SGA中生成了 undo 块。q 已经在 SGA中生成了已修改数据块。q 已经在 SGA中生成了对于前两项的缓存 redo。q 取决于前三项的大小，以及这些工作花费的时间，前面的每个数据（或某些数据）可能已经刷新输出到磁盘。q 已经得到了所需的全部锁。执行 COMMIT 时，余下的工作只是：q 为事务生成一个 S

39、CN。如果你还不熟悉 SCN，起码要知道，SCN 是 Oracle 使用的一种简单的计时机制，用于保证事务的顺序，并支持失败恢复。SCN 还用于保证数据库中的读一致性和检查点。可以把 SCN 看作一个钟摆，每次有人 COMMIT 时，SCN 都会增 1.q LGWR 将所有余下的缓存重做日志条目写到磁盘，并把 SCN 记录到在线重做日志文件中。这一步就是真正的 COMMIT。如果出现了这一步，即已经提交。事务条目会从 V$TRANSACTION 中“删除”，这说明我们已经提交。q V$LOCK 中记录这我们的会话持有的锁，这些所都将被释放，而排队等待这些锁的每一个人都会被唤醒，可以继续完成他们

40、的工作。q 如果事务修改的某些块还在缓冲区缓存中，则会以一种快速的模式访问并“清理”。块清除（Block cleanout）是指清除存储在数据库块首部的与锁相关的信息。实质上讲，我们在清除块上的事务信息，这样下一个访问这个块的人就不用再这么做了。我们采用一种无需生成重做日志信息的方式来完成块清除，这样可以省去以后的大量工作（在下面的“块清除”一节中将更全面地讨论这个问题）。可以看到，处理 COMMIT 所要做的工作很少。其中耗时最长的操作要算 LGWR 执行的活动（一般是这样），因为这些磁盘写是物理磁盘 I/O。不过，这里 LGWR 花费的时间并不会太多，之所以能大幅减少这个操作的时间，原因是

41、 LGWR 一直在以连续的方式刷新输出重做日志缓冲区的内容。在你工作期间，LGWR 并非缓存这你做的所有工作；实际上，随着你的工作的进行，LGWR 会在后台增量式地刷新输出重做日志缓冲区的内容。这样做是为了避免 COMMIT 等待很长时间来一次性刷新输出所有的 redo。因此，即使我们有一个长时间运行的事务，但在提交之前，它生成的许多缓存重做日志已经刷新输出到磁盘了（而不是全部等到提交时才刷新输出）。这也有不好的一面，COMMIT 时，我们必须等待，直到尚未写出的所有缓存 redo 都已经安全写到磁盘上才行。也就是说，对 LGWR 的调用是一个同步（synchronous）调用。尽管 LGWR

42、 本身可以使用异步 I/O 并行地写至日志文件，但是我们的事务会一直 11等待 LGWR 完成所有写操作，并收到数据都已在磁盘上的确认才会返回。前面我提高过，由于某种原因，我们用的是一个 Java 程序而不是 PL/SQL，这个原因就是 PL/SQL 提供了提交时优化（commit-time optimization）。我说过，LGWR 是一个同步调用，我们要等待它完成所有写操作。在 Oracle 10g Release 1 及以前版本中，除 PL/SQL 以外的所有编程语言都是如此。PL/SQL 引擎不同，要认识到直到 PL/SQL 例程完成之前，客户并不知道这个 PL/SQL 例程中是否发

43、生了COMMIT，所以 PL/SQL 引擎完成的是异步提交。它不会等待 LGWR 完成；相反，PL/SQL 引擎会从 COMMIT 调用立即返回。不过，等到 PL/SQL 例程完成，我们从数据库返回客户时，PL/SQL 例程则要等待 LGWR 完成所有尚未完成的 COMMIT。因此，如果在 PL/SQL 中提交了 100 次，然后返回客户，会发现由于存在这种优化，你只会等待 LGWR 一次，而不是 100 次。这是不是说可以在 PL/SQL 中频繁地提交呢？这是一个很好或者不错的主意吗？不是，绝对不是，在 PL/SQ;中频繁地提交与在其他语言中这样做同样糟糕。指导原则是，应该在逻辑工作单元完成

44、时才提交，而不要在此之前草率地提交。注意注意 如果你在执行分布式事务或者以最大可能性模式执行 Data Guard，PL/SQL 中的这种提交时优化可能会被挂起。因为此时存在两个参与者，PL/SQL 必须等待提交确实完成后才能继续。为了说明 COMMIT 是一个“响应时间很平”的操作，下面将生成不同大小的 redo，并测试插入（INSERT）和提交（COMMIT）的时间。为此，还是在 SQL*Plus 中使用 AUTOTRACE。首先创建一个大表（要把其中的测试数据插入到另一个表中），再创建一个空表：ops$tkyteORA10G big_table 100000 ops$tkyteORA10

45、G create table t as select*from big_table where 1=0;Table created.然后在 SQL*Plus 中运行以下命令：ops$tkyteORA10G set timing on ops$tkyteORA10G set autotrace on statistics;ops$tkyteORA10G insert into t select*from big_table where rownum commit;在此监视 AUTOTRACE 提供的 redo size（redo 大小）统计，并通过 set timing on 监视计时信息。我执

46、行了这个测试，并尝试插入不同数目的行（行数从 10 到 100,000，每次增加一个数量级）。表 9-1 显示了我的观察结果。表表 9-1 随事务大小得到的提交时间随事务大小得到的提交时间*插入行数插入行数 插入时间（秒）插入时间（秒）redo 大小（字节）大小（字节）提交时间（秒）提交时间（秒）10 0.05 116 0.06 100 0.08 3,594 0.04 1,000 0.07 372,924 0.06 10,000 0.25 3,744,620 0.06 100,000 1.94 37,843,108 0.07*这个测试在一个单用户主机上完成，这个主机有一个 8MB 的日志缓冲区

47、和两个 512MB 的在线重做日志文件。可以看到，使用一个精确度为百分之一秒的计数器度量时，随着生成不同数量的 redo（从 116 字节到 37MB），却几乎测不出 COMMIT时间的差异。在我们处理和生成重做日志时，LGWR 也没有闲着，它在后台不断地将缓存的重做信息刷新输出到磁盘上。所以，我们生成37MB 的重做日志信息时，LGWR 一直在忙着，可能每 1MB 左右刷新输出一次。等到 COMMIT 时，剩下的重做日志信息（即尚未写出到磁盘的 redo）已经不多了，可能与创建 10 行数据生成的重做日志信息相差无几。不论生成了多少 redo，结果应该是类似的（但可能不完全一样）。9.3.2

48、 ROLLBACK 做什么？把 COMMIT 改为 ROLLBACK，可能会得到完全不同的结果。回滚时间绝对是所修改数据量的一个函数。修改上一节中的脚本，要求完成一个 ROLLBACK（只需把 COMMIT 改成 ROLLBACK），计时信息将完全不同（见表 9-2）。表表 9-2 随事务大小得到的回滚时间随事务大小得到的回滚时间 插入行数插入行数 回滚时间（秒）回滚时间（秒）提交时间（秒）提交时间（秒）10 0.04 0.06 12 100 0.05 0.04 1,000 0.06 0.06 10,000 0.22 0.06 100,000 1.6 0.07 这是可以想见的，因为 ROLLB

49、ACK 必须物理地撤销我们所做的工作。类似于 COMMIT，必须完成一系列操作。在到达 ROLLBACK之前，数据库已经做了大量的工作。再复习一遍，可能已经发生的操作如下：q 已经在 SGA中生成了 undo 块。q 已经在 SGA中生成了已修改数据块。q 已经在 SGA中生成了对于前两项的缓存 redo。q 取决于前三项的大小，以及这些工作花费的时间，前面的每个数据（或某些数据）可能已经刷新输出到磁盘。q 已经得到了所需的全部锁。ROLLBACK 时，要做以下工作：q 撤销已做的所有修改。其完成方式如下：从 undo 段读回数据，然后实际上逆向执行前面所做的操作，并将 undo 条目标记为已

50、用。如果先前插入了一行，ROLLBACK 会将其删除。如果更新了一行，回滚就会取消更新。如果删除了一行，回滚将把它再次插入。q 会话持有的所有锁都将释放，如果有人在排队等待我们持有的锁，就会被唤醒。与此不同，COMMIT 只是将重做日志缓冲区中剩余的数据刷新到磁盘。与 ROLLBACK 相比，COMMIT 完成的工作非常少。这里的关键是，除非不得已，否则不会希望回滚。回滚操作的开销很大，因为你花了大量的时间做工作，还要花大量的时间撤销这些工作。除非你有把握肯定会 COMMIT 你的工作，否则干脆什么也别做。听上去这好像是一个常识，这是当然的了，既然不想 COMMIT，又何苦去做所有这些工作！不