oracle自制事物

各位大侠，以下有几个关于存储过程事物的问题请教下...，本人对oracle事物机制真正学习中，希望高手指点并详细说明下，非常感谢..

例：oracle PACKAGE 里调用3个存储过程，分别为A,B,C; A里面调用B；A和B对同一张表做了update操作；
1）如果在B中添加了自制事物，会影响到A对表的更新操作吗？
2）package有没有自己的事物？
3）在B中对表进行update操作后commit,是不是会对这之前所有的操作都做了提交（包括之前A的操作）？

 

有几点都会产生相互的影响，至于谁影响谁主要看你的逻辑
1 事务，一个事务没完成（即不提交或不回退），只能查看undo段里的信息
2 锁，你的update产生锁，如果不释放，别的事物或者session是不能对这个锁定的行信息进行修改的
我感觉主要是你的逻辑的变化和commit提交的点在什么位置，是不是在你调用B之间就做出提交或者回退。

 

 

数据库事务是一种单元操作，要么是全部操作都成功，要么全部失败。在Oracle中，一个事务是从执行第一个数据管理语言（DML）语句开始，直到执行一个COMMIT语句，提交保存这个事务，或者执行一个ROLLBACK语句，放弃此次操作结束。

事务的“要么全部完成，要么什么都没完成”的本性会使将错误信息记入数据库表中变得很困难，因为当事务失败重新运行时，用来编写日志条目的INSERT语句还未完成。

针对这种困境，Oracle提供了一种便捷的方法，即自治事务。自治事务从当前事务开始，在其自身的语境中执行。它们能独立地被提交或重新运行，而不影响正在运行的事务。正因为这样，它们成了编写错误日志表格的理想形式。在事务中检测到错误时，您可以在错误日志表格中插入一行并提交它，然后在不丢失这次插入的情况下回滚主事务。

因为自治事务是与主事务相分离的，所以它不能检测到被修改过的行的当前状态。这就好像在主事务提交之前，它们一直处于单独的会话里，对自治事务来说，它们是不可用的。然而，反过来情况就不同了：主事务能够检测到已经执行过的自治事务的结果。

要创建一个自治事务，您必须在匿名块的最高层或者存储过程、函数、数据包或触发的定义部分中，使用PL/SQL中的PRAGMA AUTONOMOUS_TRANSACTION语句。在这样的模块或过程中执行的SQL Server语句都是自治的。

触发无法包含COMMIT语句，除非有PRAGMA AUTONOMOUS_TRANSACTION标记。但是，只有触发中的语句才能被提交，主事务则不行。

exp:

Create table Msg (Msg varchar(50)) ;

自制事务：
create or replace procedure AutoNomouse_Insert is

PRAGMA AUTONOMOUS_TRANSACTION;

begin

insert into Msg values('AutoNomouse Insert');

commit;

end;
非自治事务：

CREATE OR REPLACE Procedure NonAutoNomouse_Insert as

begin

insert into Msg Values('NonAutonomouse Insert');

commit;

end;

SQL> begin
2
3 insert into Msg Values('This Main Info');
4
5 NonAutoNomouse_Insert;
6
7 rollback;
8
9 end
10 ;
11 /

PL/SQL procedure successfully completed

SQL> select * from msg;

MSG
--------------------------------------------------
This Main Info
NonAutonomouse Insert
因为过程中有COMMIT;所以匿名块中得RULLBACK 是不起作用的； 由此得出：非自治事务中的COMMIT,ROLLBACK

是会影响整个事务的。

下面我们看一个另外一种情况：
SQL> delete msg;

2 rows deleted

SQL>

这里没有COMMIT;

SQL> begin
2
3 insert into Msg Values('This Main Info');
4
5 rollback; --这里加了ROLLBACK;
6
7 NonAutoNomouse_Insert;
8
9 rollback;
10
11 end
12 ;
13 /

PL/SQL procedure successfully completed

SQL> select * from msg;

MSG
--------------------------------------------------
This Main Info
NonAutonomouse Insert
NonAutonomouse Insert

竟然没有ROLLBACK (DELETE * FROM SSG ;) 为什么了？因为过程就是一个新的SESSION，所以前面的SESSION

被正常EXIT,同时被自动提交； 所以我们会看到三行数据。
SQL> commit;

Commit complete

SQL> select * from msg;

MSG
--------------------------------------------------
This Main Info
NonAutonomouse Insert
NonAutonomouse Insert

SQL> commit;

Commit complete

SQL> select * from msg;

MSG
--------------------------------------------------
This Main Info
NonAutonomouse Insert
NonAutonomouse Insert

因为这里一个新的SESSION 所以是没有意义的事务控制语句。

SQL> delete msg;

3 rows deleted

SQL> commit;

Commit complete

SQL> select * from msg;

MSG
--------------------------------------------------

可以看到这里是正常的提交；

下面看一下自制事务：

SQL> begin
2
3 insert into Msg Values('This Main Info');
4
5 AutoNomouse_Insert;
6
7 rollback;
8
9 end
10
11 ;
12 /

PL/SQL procedure successfully completed

SQL> select * from msg;

MSG
--------------------------------------------------
AutoNomouse Insert

我们看到是一行数据，显然第一条SQL INSERT 是被ROLLBACK，证明自制事务是一个独立于主程序的事务，

他不会对主事务的控制产生影响。另外在分布式环境中我们经常会遇到 ORA-02064 ERROR ,就是因为主事务

自己有事务控制语句，然而被调用的远程过程也有自己的事物控制语句，当然就会报错，我们将被调用的过程

声明为自制事务那就OK了。

 

在触发器中操作触发此触发器的表,用PRAGMA AUTONOMOUS_TRANSACTION选项。

15.1为何使用自治事务 无法回滚的审计

一般情况下利用触发器禁止某些对表的更新等操作时，若记录日志，则触发器最后抛出异常时会造成日志回滚。利用自治事务可防止此点。

避免变异表

即在触发器中操作触发此触发器的表

在触发器中使用DDL 写数据库

对数据库有写操作（INSERT、UPDATE、DELETE、CREATE、ALTER、COMMIT）的存储过程或函数是无法简单的用SQL来调用的，此时可以将其设为自治事务，从而避免ORA-14552（无法在一个查询或DML中执行DDL、COMMIT、ROLLBACK）、ORA-14551（无法在一个查询中执行DML操作）等错误。需要注意的是函数必须有返回值，但仅有IN参数（不能有OUT或IN/OUT参数）。

开发更模块化的代码

在大型开发中，自治事务可以将代码更加模块化，失败或成功时不会影响调用者的其它操作，代价是调用者失去了对此模块的控制，并且模块内部无法引用调用者未提交的数据。

15.2 如何工作 事务控制

DECLARE整个块都是属于父事务的，自治事务从离PRAGMA后的第一个BEGIN开始，只要此BEGIN块仍在作用域，则都属于自治事务。例如在DECLARE模块中声明一个写数据库的函数，则此函数虽然在自治事务所在存储过程执行，但其属于父事务；而自治事务中调用的任何函数和存储过程、激发的任何触发器等均为此自治事务的一部分。

自治事务可以嵌套，嵌套深度等只受INIT.ORA参数TRANSACTIONS（同时并发的事务数，缺省为SESSIONS的1.1倍）制约。

作用域

1. 包中的变量

自治事务可看到并修改父事务的变量，父事务也会察觉到这一改变，且不存在回滚问题。

2. 会话设置/参数

自治事务与父事务共享同一个会话环境，通过ALTER SESSION作的修改对整个会话均有效。但SET TRANSACTION是事务级的，仅对提起修改的事务有效。

3. 数据库修改

父事务已提交的修改对自治事务可见，未提交的对自治事务不可见，自治事务的修改对父事务是否可见取决于隔离级别（Isolation Level）。

对于游标，取决于其打开的位置，若其在父事务中打开，则之前父事务未提交的修改对其是有效的，在自治事务中这些修改也可见；而在自治事务中打开，则父事务未提交的修改不可见。

若使用缺省的READ COMMITTED隔离级别，则自治事务的修改对父事务可见；若改用SERIALIZABLE，则不可见。

4. 锁

父事务与自治事务是完全不同的事务，因此无法共享锁等。

结束一个自治事务必须提交一个COMMIT、ROLLBACK或执行DDL。

保存点无法在自治事务中回滚到父事务中的一个保存点，只能在内部使用保存点。

15.3 最后说明 不支持分布式事务截至8.1.7在自治事务中不支持分布式事务

仅可用PL/SQL 全部事务回滚若自治事务出错，则全部回滚，即便父事务有异常处理模块。

事务级临时表每个会话仅一个事务可访问事务级临时表（多个会话中的事务可并发操作）。

15.4 可能遇到的错误
ORA-06519 – 检查到活动自治事务，回滚——退出自治事务时没有提交、回滚或DDL操作

ORA-14450 – 试图访问正在使用的事务级临时表

ORA-00060 – 等待资源时检查到死锁

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/25164132/viewspace-749177/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/25164132/viewspace-749177/