oracle 专家高级编程 中文第八章.pdf

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

1、 1第 8 章 事务 事务（Transaction）是数据库区别于文件系统的特性之一。在文件系统中，如果你正把文件写到一半，操作系统突然崩溃了，这个文件就很可能会被破坏。不错，确实还有一些“日报式”（journaled）之类的文件系统，它们能把文件恢复到某个时间点。不过，如果需要保证两个文件同步，这些文件系统就无能为力了。倘若你更新了一个文件，在更新完第二个文件之前，系统突然失败了，你就会有两个不同步的文件。这是数据库中引入事务的主要目的：事务会把数据库从一种一致状态转变为另一种一致状态。这就是事务的任务。在数据库中提交工作时，可以确保要么所有修改都已经保存，要么所有修改都不保存。另外，还能保

2、证实现了保护数据完整性的各种规则和检查。在上一章中，我们从并发控制角度讨论了事务，并说明了在高度并发的数据访问条件下，根据 Oracle 的多版本读一致模型，Oracle事务每次如何提供一致的数据。Oracle 中的事务体现了所有必要的 ACID 特征。ACID 是以下 4 个词的缩写：q 原子性（atomicity）：事务中的所有动作要么都发生，要么都不发生。q 一致性（consistency）：事务将数据库从一种一致状态转变为下一种一致状态。q 隔离性（isolation）：一个事务的影响在该事务提交前对其他事务都不可见。q 持久性（durability）：事务一旦提交，其结果就是永久性的

3、。上一章讨论过 Oracle 如何得到一致性和隔离性。这里我们主要关注原子性的概念，并说明 Oracle 中是如何应用这个概念的。这一章我们将讨论原子性的含义，以及 Oracle 中原子性对语句有什么影响。首先会介绍 COMMIT、SAVEPOINT 和 ROLLBACK 等事务控制语句，并讨论事务中如何保证完整性约束。我们会读到，如果你原来一直在其他数据库中开发，可能在事务方面养成一些坏习惯（即后面所说的“不好的事务习惯”）。这里还将介绍分布式事务和两段提交（two-phase commit，2PC）。最后会分析自治事务，指出什么是自治事务以及自治事务所扮演的角色。8.1 事务控制语句 Or

4、acle 中不需要专门的语句来“开始事务”。隐含地，事务会在修改数据的第一条语句处开始（也就是得到 TX 锁的第一条语句）。也可以使用 SET TRANSACTION 或 DBMS_TRANSACTION 包来显示地开始一个事务，但是这一步并不是必要的，这与其他的许多数据库不同，因为那些数据库中都必须显式地开始事务。如果发出 COMMIT 或 ROLLBACK 语句，就会显式地结束一个事务。注意注意 ROLLBACK TO SAVEPOINT 命令不会结束事务！正确地写为 ROLLBACK（只有这一个词）才能结束事务。一定要显式地使用 COMMIT 或 ROLLBACK 来终止你的事务；否则，

5、你使用的工具/环境就会从中挑一个来结束事务。如果正常地退出 SQL*Plus 会话，而没有提交或回滚事务，SQL*Plus 就会认为你希望提交前面做的工作，并为你完成提交。另一方面，如果你只是退出一个 Pro*C 程序，就会发生一个隐式的回滚。不要过分依赖这些隐式行为，因为将来这些行为可能会有改变。一定要显式地 COMMIT或 ROLLBACK 你的事务。Oracle 中的事务是原子性的。这说明无非两种情况：构成事务的每条语句都会提交（成为永久），或者所有语句都回滚。这种保护还延伸到单个的语句。一条语句要么完全成功，要么这条语句完全回滚。注意，我说的是“语句”回滚。如果一条语句失败，并不会导致

6、先前已经执行的语句自动回滚。它们的工作会保留，必须由你来提交或回滚。这里谈到了语句和事务是原子性的，在具体介绍其含义之前，先来看看我们可以使用哪些事务控制语句：q COMMIT：要想使用这个语句的最简形式，只需发出 COMMIT。也可以更详细一些，写为 COMMIT WORK，不过这二者是等价的。COMMIT 会结束你的事务，并使得已做的所有修改成为永久性的（持久保存）。COMMIT 语句还有一些扩展用于分布式事务中。利用这些扩展，允许增加一些有意义的注释为 COMMIT 加标签（对事务加标签），以及强调提交一个可疑的分布式事务。q ROLLBACK：要想使用这个语句的最简形式，只需发出 RO

7、LLBACK。同样地，你也可以罗嗦一些，写为 ROLLBACK WORK，但是二者是等价的。回滚会结束你的事务，并撤销正在进行的所有未提交的修改。为此要读取存储在回滚段/undo 段中的信息，并把数据库块恢复到事务开始之前的状态（后面我将把回滚段/undo 段统称为 undo 段，Oracle 10g 中都喜欢用这个词）。q SAVEPOINT：SAVEPOINT 允许你在事务中创建一个“标记点”（marked point），一个事务中可以有多个 SAVEPOINT。2q ROLLBACK TO：这个语句与 SAVEPOINT 命令一起使用。可以把事务回滚到标记点，而不回滚在此标记点之前的任何

8、工作。所以，可以发出两条 UPDATE 语句，后面跟一个 SAVEPOINT，然后又是两条 DELETE 语句。如果执行 DELETE语句期间出现了某种异常情况，而且你捕获到这个异常，并发出 ROLLBACK TO SAVEPOINT 命令，事务就会回滚到指定的SAVEPOINT，撤销 DELETE 完成的所有工作，而 UPDATE 语句完成的工作不受影响。q SET TRANSACTION：这条语句允许你设置不同的事务属性，如事务的隔离级别以及事务是只读的还是可读写的。使用手动 undo管理时，还可以使用这个 来指示事务使用某个特定的 undo 段，不过不推荐这种做法。我们将在第 9 章更详

9、细地讨论手动和自动 undo 管理。就这么多，没有别的事务控制语句了。最常用的控制语句就是 COMMIT 和 ROLLBACK。SAVEPOINT 语句的用途有点特殊。Oracle在内部频繁地使用了这个语句，你会发现这语句在你的应用中可能也有用。8.2 原子性 前面对事务控制语句做了一个简要的概述后，下面可以看看语句原子性、过程原子性和事务原子性到底有什么含义。8.2.1 语句级原子性 考虑以下语句：Insert into t values(1);看上去很明显，如果它由于一个约束冲突而失败，这一行就不会插入。不过，再考虑下面的例子，这里表T上的一个INSERT或DELETE会触发一个触发器，它

10、将适当地调整表 T2 中的 CNT 列：ops$tkyteORA10G create table t2(cnt int);Table created.ops$tkyteORA10G insert into t2 values(0);1 row created.ops$tkyteORA10G commit;Commit complete.ops$tkyteORA10G create table t(x int check(x0);Table created.ops$tkyteORA10G create trigger t_trigger 2 before insert or delete on

11、t for each row 3 begin 4 if(inserting)then 5 update t2 set cnt=cnt+1;6 else 7 update t2 set cnt=cnt-1;8 end if;9 dbms_output.put_line(I fired and updated|10 sql%rowcount|rows);11 end;12/Trigger created.在这种情况下，会发生什么就不那么显而易见了。如果触发器触发之后出现了错误，触发器的影响是否还存在？也就是说，如果触发器被触发，并且更新了 T2，但是这一行没有插入到 T 中，结果会是什么？显然答案

12、应该是，如果并没有真正在 T 中插入一行，我们就 3希望 T2 中的 CNT 列递增。幸运的是，在 Oracle 中，客户最初发出的语句（在这里就是 INSERT INTO T）会完全成功或完全失败。这个语句是原子性的。以下可以验证这一点：ops$tkyteORA10G set serveroutput on ops$tkyteORA10G insert into t values(1);I fired and updated 1 rows 1 row created.ops$tkyteORA10G insert into t values(-1);I fired and updated 1

13、rows insert into t values(-1)*ERROR at line 1:ORA-02290:check constraint(OPS$TKYTE.SYS_C009597)violated ops$tkyteORA10G select*from t2;CNT-1 注意注意 使用 Oracle9i Release 2 及以前版本的 SQL*Plus 时，要想看到触发器被触发，需要在第二个插入后面增加一行代码：exec null。这是因为，在这些版本中，SQL*Plus 不会在失败的 DML 语句之后获取和显示 DBMS_OUTPUT 信息。Oracle 10g 版本则不然，这个

14、版本的 SQL*Plus 确实会显示 DBMS_OUTPUT 信息。这样一来，T 中成功地插入一行，而且我们也适当地接收到信息：I fired and updated 1 row。下一个 INSERT 语句违反了 T 上的完整性约束。此时出现了 DBMS_OUTPUT 信息T 上的触发器确实触发了，这个 DBMS_OUTPUT 信息就是证据。触发器成功地完成了 T2的更新。我们可能认为现在 T2 中 CNT 的值是 2，但是可以看到它的值实际上为 1。Oracle 保证最初的 INSET（即导致触发器触发的插入语句）是原子性的，这个 INSERT INTO T 是语句，所以 INSERT IN

15、TO T 的任何副作用都被认为是语句的一部分。为了得到这种语句级原子性，Oracle 悄悄地在每个数据库调用外面包了一个 SAVEPOINT。前面的两个 INSERT 实际上处理如下：Savepoint statement1;Insert into t values(1);If error then rollback to statement1;Savepoint statement2;Insert into t values(-1);If error then rollback to statement2;对于习惯于使用 Sybase 或 SQL Server 的程序员来说，刚开始可能会有点

16、摸不着头脑。在这些数据库中，情况恰恰相反。这些系统中的触发器会独立于触发语句执行。如果触发器遇到一个错误，它必须显式地回滚自己的工作，然后产生另外一个错误来回滚触发语句。否则，即使触发语句（或该语句的另外某个部分）最终会失败，触发器完成的工作也会持久保留。在 Oracle 中，这种语句级原子性可以根据需要延伸。在前面的例子中，如果 INSERT INTO T 触发了一个触发器，这个触发器会更新另一个表，而那个表也有一个触发器，它会删除第三个表（以此类推），那么要么所有工作都成功，要么无一成功。为保证这一点，无需你编写任何特殊的代码，Oracle 本来就会这么做。8.2.2 过程级原子性 有意思

17、的是，Oracle 把 PL/SQL 匿名块也当作是语句。请考虑以下存储过程：ops$tkyteORA10G create or replace procedure p 2 as 3 begin 4 insert into t values(1);5 insert into t values(-1);6 end;47/Procedure created.ops$tkyteORA10G select*from t;no rows selected ops$tkyteORA10G select*from t2;CNT-0 以上创建了一个过程，而且我们知道这个过程不会成功。在这个过程中，第二个 IN

18、SERT 总会失败。下面看运行这个存储过程时会发生什么情况：ops$tkyteORA10G begin 2 p;3 end;4/I fired and updated 1 rows I fired and updated 1 rows begin*ERROR at line 1:ORA-02290:check constraint(OPS$TKYTE.SYS_C009598)violated ORA-06512:at OPS$TKYTE.P,line 5 ORA-06512:at line 2 ops$tkyteORA10G select*from t;no rows selected ops

19、$tkyteORA10G select*from t2;CNT-0 可以看到，Oracle 把这个存储过程调用处理为一个原子语句。客户提交了一个代码块 BEGIN P;END;，Oracle 在它外面包了一个SAVEPOINT。由于 P 失败了，Oracle 将数据库恢复到调用这个存储过程之前的时间点。下面，如果提交一个稍微不同的代码块，会得到完全不同的结果：ops$tkyteORA10G begin 2 p;3 exception 4 when others then null;5 end;6/I fired and updated 1 rows I fired and updated 1

20、rows PL/SQL procedure successfully completed.ops$tkyteORA10G select*from t;X-51 ops$tkyteORA10G select CNT-1 在此，我们运行的代码块会忽略所有错误，这两个代码块的输出结果有显著的差别。尽管前面第一个 P 调用没有带来任何改变，但在这里的 P 调用中，第一个 INSERT 会成功，而且 T2 中的 CNT 列会相应地递增。注意注意 如果代码中包含一个 WHEN OTHERS 异常处理器，但其中没有一个 RAISE 来重新引发异常，我认为这样的代码都是有 bug 的。它会悄悄地忽略错误，这就

21、改变了事务的语义。如果捕获 WHEN OTHERS，并把异常转换为旧式的返回码，这会改变数据库本该有的表现。Oracle 把客户提交的代码块认为是“语句”。这个语句之所以会成功，因为它自行捕获并忽略了错误，所以 If error then rollback没有起作用，而且执行这个语句后 Oracle 没有回滚到 SAVEPOINT。因此，这就保留了 P 完成的部分工作。为什么会保留这一部分工作呢？首要的原因是 P 中有语句级原子性：P 中的每条语句都具有原子性。P 提交其两条 INSERT 语句时就成为 Oracle 的客户。每个 INSERT 要么完全成功，要么完全失败。从以下事实就可以证明

22、这一点：可以看到，T 上的触发器触发了两次，而且将 T2 更新了两次，不过 T2 中的计数只反映了一个 UPDATE。P 中执行的第二个 INSERT 外包着一个隐式的 SAVEPOINT。以上两个代码块的差别很微妙，但是你在应用中必须考虑到这些问题。向一个 PL/SQL 块增加异常处理器可能会显著地改变它的行为。对此可以用另一种方式编写代码，将语句级原子性恢复为整个 PL/SQL 块级原子性，如下所示：ops$tkyteORA10G begin 2 savepoint sp;3 p;4 exception 5 when others then 6 rollback to sp;7 end;8

23、/I fired and updated 1 rows I fired and updated 1 rows PL/SQL procedure successfully completed.ops$tkyteORA10G select*from t;no rows selected ops$tkyteORA10G select*from t2;CNT-0 警告警告 前面的代码代表着一种极其糟糕的实践。一般来讲，不应该捕获 WHEN OTHERS，另外对于事务语义而言，也不应该为 Oracle已经提供的特性显式编写代码。在此模仿了 Oracle 通常用 SAVEPOINT 所做的工作，这样一来，

24、我们不仅仍然能捕获和“忽略”错误，还能恢复原来的行为。这个例子只作说明之用，这是一种非常糟糕的编码实践。8.2.3 事务级原子性 最后，还有一种事务级原子性的概念。事务（也就是一组 SQL 语句作为一个工作单元一同执行）的总目标是把数据库从一种一致状 6态转变为另一种一致状态。为了实现这个目标，事务也是原子性的，事务完成的所有工作要么完全提交并成为永久性的，要么会回滚并撤销。像语句一样，事务是一个原子性的工作单元。提交一个事务后，接收到数据库返回的“成功”信息后，你就能知道事务完成的所有工作都已经成为永久性的。8.3 完整性约束和事务 需要指出到底什么时候检查完整性约束。默认情况下，完整性约束

25、会在整个 SQL 语句得到处理之后才进行检查。也有一些可延迟的约束允许将完整性约束的验证延迟到应用请求时（发出一个 SET CONSTRAINTS ALL IMMEDIATE 命令）才完成，或者延迟到发出COMMIT 时再检查。8.3.1 IMMEDIATE 约束 在讨论的前一部分，我们假设约束都是 IMMEDIATE 模式，这也是一般情况。在这种情况下，完整性约束会在整个 SQL 语句得到处理之后立即检查。注意，这里我用的是“SQL 语句”而不只是“语句”。如果一个 PL/SQL 存储过程中有多条 SQL 语句，那么在每条 SQL 语句执行之后都会立即验证其完整性约束，而不是在这个存储过程完

26、成后才检查它。那么，为什么约束要在 SQL 语句执行之后才验证呢？为什么不是在 SQL 语句执行期间验证？这是因为，一条语句可能会使表中的各行暂时地“不一致”，这是很自然的。尽管一条语句全部完成后的最终结果是对的，但如果查看这条语句所做的部分工作，会导致 Oracle拒绝这个结果。例如，假设有下面这样一个表：ops$tkyteORA10G create table t(x int unique);Table created.ops$tkyteORA10G insert into t values(1);1 row created.ops$tkyteORA10G insert into t va

27、lues(2);1 row created.现在，我们想执行一个多行 UPDATE：ops$tkyteORA10G update t set x=x+1;2 rows updated.如果 Oracle 每更新一行之后都检查约束，那么无论什么时候，UPDATE 都有一半的可能性（50%的机会）会失败。由于会以某种顺序来访问 T 中的行，如果 Oracle 先更新 X=1 这一行，那么 X 就会临时地有一个重复的值，这就会拒绝 UPDATE。由于 Oracle 会耐心等待语句结束（而不是在语句执行期间检查约束），所以这条语句最后会成功，因为等到语句完成时已经不存在重复值了。8.3.2 DEFER

28、RABLE 约束和级联更新 从 Oracle8.0 开始，我们还能够延迟约束检查，对于许多操作来说，这很有好处。首先能想到的是，可能需要将一个主键的 UPDATE级联到子键。也许很多人会说：这没有必要，因为主键是不可变的（我就是这些人之一），但是还有人坚持要有级联 UPDATE。有了可延迟的约束，就使得级联更新成为可能。注意注意 一般认为，完成更新级联来修改主键是很不好的做法。这会破坏主键的意图。如果你必须做一次级联更新来修正不对的信息，这倒是可以的；但是如果你发现自己在不停地完成级联更新，并把这当做应用的一部分，那就是另一码事了，你应该退一步，重新考虑一下这个过程。倘若真是这样，能你就是错把

29、鸡毛当令箭了！在以前的版本中，确实也可以完成 CASCADE UPDATE，但是为此需要做大量的工作，而且存在某些限制。有了可延迟的约束后，这就变得易如反掌了。代码如下：ops$tkyteORA10G create table p 2(pk int primary key)73/Table created.ops$tkyteORA10G create table c 2(fk constraint c_fk 3 references p(pk)4 deferrable 5 initially immediate 6)7/Table created.ops$tkyteORA10G insert

30、into p values(1);1 row created.ops$tkyteORA10G insert into c values(1);1 row created.我们有一个父表 P，还有一个子表 C。表 C 引用了表 P，保证这个规则的约束是 C_FK（子外键）。这个约束创建为一个 DEFERRABLE约束，但是设置为 INITIALLY IMMEDIATE。这说明，可以把这个约束延迟到 COMMIT 或另外某个时间才检查。不过，默认情况下，这个约束在语句级验证。这是可延迟约束最常见的用法。大多数现有的应用不会在 COMMIT 语句上检查约束冲突，你最好也不要这么做。根据定义，表 C

31、与一般的表一样有正常的表现，不过我们可以显式地改变它的行为。下面，在这些表上尝试一些 DML，看看会发生什么：ops$tkyteORA10G update p set pk=2;update p set pk=2*ERROR at line 1:ORA-02292:integrity constraint(OPS$TKYTE.C_FK)violated-child record found 由于约束是 IMMEDIATE 模式，这个 UPDATE 会失败。下面换个模式再试一次：ops$tkyteORA10G set constraint c_fk deferred;Constraint set

32、.ops$tkyteORA10G update p set pk=2;1 row updated.现在更新成功了。为了便于说明，下面将显示如何在提交前显式地检查了一个延迟约束，才中了解我们所做的修改与业务规则是否一致（换句话说，检查目前确实没有违反约束）。应该在提交之前或者在把控制交给程序的另外某个部分（这一部分可能不希望有延迟约束）之前做这个工作，这是一个很好的主意：ops$tkyteORA10G set constraint c_fk immediate;set constraint c_fk immediate*ERROR at line 1:ORA-02291:integrity co

33、nstraint(OPS$TKYTE.C_FK)violated-parent key not found 不出所料，它会失败，并立即返回一个错误，因为我们知道以上更新会违反约束。对 P 的 UPDATE 没有回滚（否则会违反语句级原子性）；它仍在进行。还要注意，我们的事务仍把 C_FK 当作延迟约束，因为 SET CONSTRAINT 命令失败了。下面继续将 UPDATE 级联到 C：ops$tkyteORA10G update c set fk=2;1 row updated.8ops$tkyteORA10G set constraint c_fk immediate;Constraint

34、 set.ops$tkyteORA10G commit;Commit complete.这就是级联更新的做法。注意，要延迟一个约束，必须这样来创建它们：先将其删除，再重新创建约束，这样才能把不可延迟的约束改变为可延迟约束。8.4 不好的事务习惯 许多开发人员在事务方面都有一些不好的习惯。如果开发人员使用过另外某个数据库，其中只是“支持”事务，而没有“提升”事务的使用，执行开发人员就常常有这样的一些坏习惯。例如，在 Informix(默认设置)、Sybase 和 SQL Server 中，必须显式地 BEGIN（开始）一个事务；否则，每条单个的语句本身就是一个事务。Oracle 在具体的语句外包

35、了一个 SAVEPOINT，采用类似的方式，那些数据库则在各条语句外包了一个 BEGIN WORK/COMMIT 或 ROLLBACK。这是因为，在这些数据库中，锁是稀有资源，另外读取器会阻塞写入器，反之，写入器也会阻塞读取器。为了提高并发性，这些数据库希望你的事务越小越好，有时甚至会以数据完整性为代价来做到这一点。Oracle 则采用了完全不同的方法。事务总是隐式的，没有办法“自动提交”事务，除非应用专门实现（更多详细内容请见 8.4.2 节）。在 Oracle 中，每个事务都应该只在必要时才提交，而在此之前不能提交。事务的大小要根据需要而定。锁、阻塞等问题并不是决定事务大小的关键，数据完整

36、性才是确定事务大小的根本。锁不是稀有资源，并发的数据读取器和数据写入器之间不存在竞争问题。这样在数据库中就能有健壮的事务。这些事务不必很短，而要根据需求有足够长的持续时间（但是不能不必要地太长）。事务不是为了方便计算机及其软件，而是为了保护你的数据。8.4.1 在循环中提交 如果交给你一个任务，要求更新多行，大多数程序员都会力图找出一种过程性方法，通过循环来完成这个任务，这样就能提交多行。据我听到的，这样做的两个主要原因是：q 频繁地提交大量小事务比处理和提交一个大事务更快，也更高效。q 没有足够的 undo 空间。这两个结论都存在误导性。另外，如果提交得太过频繁，很容易让你陷入危险，倘若更新

37、做到一半的时候失败了，这会使你的数据库处于一种“未知”的状态。要编写一个过程从而在出现失败的情况下能平滑地重启动，这需要复杂的逻辑。到目前为止，最好的方法是按业务过程的要求以适当的频度提交，并且相应地设置 undo 段大小。下面将更详细地分析这些问题。1.性能影响性能影响 如果频繁地提交，通常并不会更快。一般地，在一个 SQL 语句中完成工作几乎总是更快一些。可以通过一个小例子来说明，假设我们有一个表 T，其中有大量的行，而且我们希望为该表中的每一行更新一个列值。这里使用两个表 T1 和 T2 来进行演示：ops$tkyteORA10G create table t1 as select*fr

38、om all_objects;Table created.ops$tkyteORA10G exec dbms_stats.gather_table_stats(user,T1);PL/SQL procedure successfully completed.ops$tkyteORA10G create table t2 as select*from t1;Table created.ops$tkyteORA10G exec dbms_stats.gather_table_stats(user,T2);PL/SQL procedure successfully completed.9这样一来，更

39、新时，只需简单地在一条 UPDATE 语句中完成，如下：ops$tkyteORA10G set timing on ops$tkyteORA10G update t1 set object_name=lower(object_name);48306 rows updated.Elapsed:00:00:00.31 不过大多数人更喜欢像下面这样做（不管由于什么原因）：ops$tkyteORA10G begin 2 for x in(select rowid rid,object_name,rownum r 3 from t2)4 loop 5 update t2 6 set object_nam

40、e=lower(x.object_name)7 where rowid=x.rid;8 if(mod(x.r,100)=0)then 9 commit;10 end if;11 end loop;12 commit;13 end;14/PL/SQL procedure successfully completed.Elapsed:00:00:05.38 对于这个小例子，倘若在循环中频繁地提交，就会慢上好几倍。如果能在一条 SQL 语句中完成，就要尽量这么做，因为这样几乎总是更快。即使我们“优化”了过程性代码，也要使用批处理来完成更新，如下：ops$tkyteORA10G declare 2 t

41、ype ridArray is table of rowid;3 type vcArray is table of t2.object_name%type;4 5 l_rids ridArray;6 l_names vcArray;7 8 cursor c is select rowid,object_name from t2;9 begin 10 open c;11 loop 12 fetch c bulk collect into l_rids,l_names LIMIT 100;13 forall i in 1.l_rids.count 14 update t2 15 set objec

42、t_name=lower(l_names(i)16 where rowid=l_rids(i);17 commit;18 exit when c%notfound;19 end loop;20 close c;21 end;22/10PL/SQL procedure successfully completed.Elapsed:00:00:02.36 这确实要块一些，但是本来还可以更快的。不仅如此，你还应该注意到这段代码变得越来越复杂。从极其简单的一条 UPDATE 语句，到过程性代码，再到更复杂的过程性代码，我们正沿着错误的反向越走越远！下面再对这个讨论做个补充，给出一个对应的例子。应该记得

43、在第 7 章中，我们讨论过写一致性的概念，并介绍了 UPDATE 语句如何导致重启动。如果要针对一个行子集（有一个 WHERE 子句）执行先前的 UPDATE 语句，而其他用户正在修改这个 UPDATE 在 WHERE子句中使用的列，就可能需要使用一系列较小的事务而不是一个大事务，或者更适合在执行大量更新之前先锁定表。这样做的目标是减少出现重启动的机会。如果要 UPDATE 表中的大量行，这会导致我们使用 LOCK TABLE 命令。不过，根据我的经验，这种大量更新或大量删除（只有这些语句才可能遭遇重启动）都是独立完成的。一次性的大量更新或清除旧数据通常不会在活动高发期间完成。实际上，数据的清

44、除根本不应受此影响，因为我们一般会使用某个日期字段来定位要清除的信息，而其他应用不会修改这个日期数据。2.Snapshot Too Old 错误错误 下面来看开发人员喜欢在过程循环中提交更新的第二个原因，这是因为他们可能被误导，试图节俭地使用“受限资源”（undo 段）。这是一个配置问题；你需要确保有足够的 undo 空间来适当地确定事务的大小。如果在循环中提交，一般会更慢，不仅如此，这也是导致让人胆战心惊的 ORA-01555 错误的最常见的原因。下面将更详细地说明。如果你阅读过第 1 章和第 7 章，就会知道，Oracle 的多版本模型会使用 undo 段数据依照语句或事务开始时的原样来重

45、建块（究竟是语句还是事务，这取决于隔离模式）。如果必要的 undo 信息不再存在，你就会收到一个 ORA-01555：snapshot too old 错误消息，查询也不会完成。所以，如果像前面的那个例子一样，你一边在读取表，一边在修改这个表，就会同时生成查询所需的 undo 信息。UPDATE 生成了 undo 信息，你的查询可能会利用这些 undo 信息来得到待更新数据的读一致视图。如果提交了所做的更新，就会允许系统重用刚刚填写的 undo 段空间。如果系统确实重用了 undo 段空间，擦除了旧的 undo 数据（查询随后要用到这些 undo 信息），你就有大麻烦了。SELECT会失败，而

46、 UPDATE 也会中途停止。这样就有了一个部分完成的逻辑事务，而且可能没有什么好办法来重启动（对此稍后还会更多说明）。下面通过一个小演示例子来看看这个概念具体是怎样的。我在一个很小的测试数据库中建立了一个表：ops$tkyteORA10G create table t as select*from all_objects;Table created.ops$tkyteORA10G create index t_idx on t(object_name);Index created.ops$tkyteORA10G exec dbms_stats.gather_table_stats(user,

47、T,cascade=true);PL/SQL procedure successfully completed.然后创建一个非常小的 undo 表空间，并修改系统，要求使用这个 undo 表空间。注意，通过将 AUTOEXTEND 设置为 off，已经把这个系统中全部 UNDO 空间的大小限制为 2MB 或更小：ops$tkyteORA10G create undo tablespace undo_small 2 datafile size 2m 3 autoextend off 4/Tablespace created.ops$tkyteORA10G alter system set und

48、o_tablespace=undo_small;System altered.现在只能用这个小 undo 表空间，我运行了以下代码块来完成 UPDATE：ops$tkyteORA10G begin 2 for x in(select/*+INDEX(t t_idx)*/rowid rid,object_name,rownum r 3 from t 4 where object_name )5 loop 116 update t 7 set object_name=lower(x.object_name)8 where rowid=x.rid;9 if(mod(x.r,100)=0)then 1

49、0 commit;11 end if;12 end loop;13 commit;14 end;15/begin*ERROR at line 1:ORA-01555:snapshot too old:rollback segment number with name too small ORA-06512:at line 2 我收到了这个错误。应该指出，这里向查询增加了一个索引提示以及一个 WHERE 子句，以确保随机地读取这个表（这两方面加在一起，就能使基于代价的优化器读取按索引键“排序”的表）。通过索引来处理表时，往往会为某一行读取一个块，可是我们想要的下一行又在另一个块上。最终，我们确实

50、会处理块 1 上的所有行，只不过不是同时处理。假设块 1 可能包含 OBJECT_NAME 以字母 A、M、N、Q 和 Z 开头的所有行的数据。这样我们就会多次命中（读取）这个块，因为我们在读取按 OBJECT_NAME 排序的数据，而且可能有很多行的 OBJECT_NAME 以 AM 之间的字母开头。由于我们正在频繁地提交和重用 undo 空间，最终再次访问一个块时，可能已经无法再回滚到查询开始的那个时间点，此时就会得到这个错误。这是一个特意构造的例子，纯粹是为了说明如何以一种可靠的方式发生这个错误。UPDATE 语句正在生成 undo 信息。我只能用一个很小的 undo 表空间（大小为 2