Using Autonomous Transaction in dbms_job on Oracle 8.1.6

I am submitting a package.procedure job to run using dbms_job.run procedure on Oracle 8.1.6 database.
The package.procedure calls another autonomous transaction procedure to handle the exceptions.
The dbms_job.run works fine if no exception is encountered, however if
there were to be an exception, resulting in a call to auto. trans.,
I encounter -
SQL> exec dbms_job.run(152404);
ERROR:
ORA-01041: internal error. hostdef extension doesn't exist
begin dbms_job.run(152404); end;
ERROR at line 1:
ORA-03113: end-of-file on communication channel
If I submit this thru an Oracle Form, the form also throws me out for this unhandled exception.
When I comment out the auto. trans. procedure in exception handling section, dbms_job.run works fine.
Also when I directly execute the package.procedure without submitting thru dbms_job, the auto. trans. is able to handle the exception.
Does it mean auto. trans. is not compatible with dbms_job in Oracle 816 or there is any patch out there ?
Any clues will be highly appreciated.
thanx

There is a rollback before the auto. trans. guy gets called.
The auto. pragma itself gets committed too and is also rollbacked in event of a failure.
The transaction works fine in all situations when not submittted thru dbms_job.run
null

Similar Messages

Performing DDLs in themiddle of a transaction: use Autonomous Transactions?

We want to use Oracle Spatial to store some of our data, for example SDO_PC, a Spatial type for arbitrarily large point clouds. The problem is that the standard way to populate a SDO_PC instance (in a row) is via SDO_PC_PKG.CREATE_PC, which turns out to be a DDL operation, and furthermore operates on an input table containing just the points to inserts for that SDO_PC instance, thus one needs to create a temp table as well per point cloud (or reuse the same, serializing access to it), another DDL.
But when the user hit save in our application, she may have 10 or 20 or 100 point clouds to save, and I'd want the entire save to be in a single large transaction (I asked about it in this forum a while back, and was answered to make my transactions as large as they should "logically" be, which is a "save" operation in this case).
How does one resolve doing the save in a single transaction, when the save itself requires calling SDO_PC_PKG.CREATE_PC (which is a DDL) multiple times?
Are "Autonomous Transactions" the solution? (I've read in Ask Tom that Autonomous Transactions are miss-used most of the time; would it be true here as well?)
Must the application open a separate Connection to the same server, and perform the DDLs in this other connection? If so, will the first "transactional save" connection be able to access the side effects (tables, etc...) of the DDLs of the "DDL" connection?
What other solution to this issue could be implemented?
In a related issue, in this Spatial thread Performance of insert with spatial index someone proposed dropping a Spatial Index before an insert to recreate it afterward, to overcome a large overhead on the insert, but this also implies DDLs in the middle of a large multi-table transaction, so would a solution to the SDO_PC_PKG.CREATE_PC issue above apply equally well in this case as well?
As everyone can tell, I'm fairly new to databases and Oracle, so I'd appreciate the help of more experienced DBAs / Application Database Architects on this. Thanks, --DD

Thanks Justin. I didn't think of this, even though I've looked at Workspace Manager a bit, and it's something we are considering using in the future.
But I'm worried about 1) the complexity that Workspace Manager adds, where every table is renamed and replaced by a view, and 2) the performance implications of all the instead of triggers to write to the underlying data tables.
Furthermore, I wonder how Workspace Manager would scale with hundreds of users, since having the save done in a separate branch kinda implies having a branch per user, and thus hundred of branches. Plus Workspace Manager uses VPD I think, yet another complication (again, we'll probably have to bite the bullet eventually, but I'd rather that be later than sooner).
Thus I'm reluctant to go the Workspace Manager route at this point, because we already have so much going on with Oracle that I'd rather leave this layer out, at least for now.
What about the parallel connection or autonomous transaction options? Thanks, --DD

How do I verify that Trap autonomous transactions is enabled in Oracle 10G?

The Center for Internet security suggests the following parameter be set in Oracle 10G databases:
13.02 Auditing Trap autonomous transactions is enabled. This will ensure that audit captures actions performed by users even if they are later rolled back.
How do I verify that this is set in our production database?

Ask them ... and while you are at it ask for an explanation of it is about an anonymous transaction running that makes it a security threat.
I haven't a clue what they're talking about and it is likely they don't either.

Ora 02290 when using qms_transaction_mgt and autonomous transactions

Hi all,
I'm using the qms procedures:
qms_transaction_mgt for openeing and closing transactions.
Somewhere in my procedure when the transaction is opened i call another procedure which contains a autonomous transaction.
The next time qms_transaction_mgt.close_transaction is called i get an ORA-02290: check constraint (HST65.QMS_NEED_TO_CLOSE_TRANSACTION) violated
When i debug the qms_transaction_mgt.close transaction the g_current_trans_id variable is empty, which indicates the transaction is allready closed.
When i remove the pragma autonomous_transaction statement and the commit statement from the procedure i call, the problem is resolved.
Version information:
Designer 9.0.2 with a with a Oracle 9i 9.2 database and Headstart 9i.
Does anybody know how i can resolve this or if this is a bug and how to fix it?
Thanks,
Yvon

Ian, Yvon,
It is unfortunately a know restriction that the CDM RuleFrame component of both Headstart for Designer 6i and Headstart for Designer 9i doesn't work in combination with autonomous transactions.
The reason is that the RuleFrame administration relies on information stored in 1. pl/sql package variables and 2. database tables. Using autonomous transactions (that involve CDM RuleFramed DML) causes this information to dissynchronize.
A year ago I investigated the possibilities to make autonomous transactions possible with RuleFrame but unfortunately this is fundamental problem: RuleFrame wants to combine multiple DML-actions into one logical transaction (gards this with the "need_to_close_transaction" constraint), while autonomous transactions intend to to the opposite: commit a part of a transaction while the rest of the transaction still is posted/not committed.
There is one exception: if you call an atonomous procedure that does DML on a non-ruleframe-enabled table (no TAPI triggers that intend to open/close the transaction, no CAPI etc), everything functions.
Problem explanation:
====================
1. Outer transaction is opened (by front end or TAPI triggers of first DML)
2. DML takes place
3. Autonomous transaction-procedure is called
4. Auto-transaction again tries (and succeeds!) to open the transaction, it doesn't see that the transaction is opened (db table qms_transactions is empty for the autonomous transaction on query)
5. DML within auto-transaction is posted
6. Auto-transaction closes transaction
7. Auto-transaction is committed
8. Outer transaction thinks the transaction is already closed, because the auto-transaction cleaned out the package variables when it closed the transaction.
9. Commit of the outer transaction fails as the deferred check constraint need_to_close_transaction avoids this to happen (rollback takes place because of this violation).
Hope this helps
Kind Regards
Marc Vahsen
Headstart Team Oracle NL

Autonomous transactions / Oracle 7.3

I have a client running 7.3 still and need a way of getting
information out of a procedure after a rollback. I currently
use autonomous transactions, but these are not supported on 7.3.
Any ideas?
Regards
Tim

... unless of course you mean "client" in the sense of "customer". I think that the only thing you could do would be to investigate the use of the DBMS_PIPE package, which allows asynchronous communications between two sessions (ie. it does not wait for a commit as DBMS_ALERT does).

Can u use autonomus transaction in trigger

hi friends,
Can you use autonomous in a trigger?
if yes ...then can you pass commit ...statement inside the autonomous transaction ?
if yes then what are the limitations of this scenario.
regards
raj

yes, you can use autonomous transaction in triggers.
I don't understand your 2nd question, but maybe this article from Tom Kyte can clarify things
http://asktom.oracle.com/~tkyte/autonomous/index.html
If not, just come back and explain a little bit more what you are trying to achieve

Is commit necessary to end autonomous transaction?

CREATE OR REPLACE TRIGGER TRIG_EMP
AFTER UPDATE
ON EMP
FOR EACH ROW
DECLARE
PRAGMA AUTONOMOUS_TRANSACTION;
CNT NUMBER := 0 ;
BEGIN
--PROCE_TRIG_TEST_EMP;
SELECT COUNT(*)
INTO CNT
FROM EMP;
UPDATE EMP_bkp
SET COMM=999
WHERE ENAME ='SMITH';
-- COMMIT;
DBMS_OUTPUT.put_line('TRIG_EMP CALLED.. DONE: '||CNT);
END;
Error: "autonomous transaction detected "
if i open update n block commit code then error.
if i block both update n commit code then without commit code is running fine.
My Ques: If commit is necessary to end autonomous transaction then when i m blocking update n commit lines then too running without above error?
plz clear my concept..
pc

PC wrote:
thanks ..I will take care of it i.e. "IM".
In above code when I am blocking both "update & commit code lines" then there is no error raised by program.
I am using commit when I need that my "update transaction must be commit",if I am only taking "count of table emp" then no need of commit...
Like this I am not getting any exception..!Doing anything on the same table that caused the trigger to fire can lead to you getting a mutating table error, so care should be taken in that respect.
I got your point that I must commit and I will use it but here if I am using autonomous transaction without commit then I must get error but I am not facing ..plz guide me againThe point of an autonomous transaction is to effectively make Oracle spawn off a seperate transaction. Usually we consider that we have just a single transaction per session at any one time, but there are times, like when we need to log errors or audit something, that we want to ensure something get's written to a table, even if the transaction we are in needs to be rolled back or is about to raise an exception. In such cases we use an autonomous transaction to spawn the seperate transaction to perform that task. Good design would have that autonmous transaction as a seperate procedure to be called (rather than in the trigger itself) to keep it completely seperate from the current transaction, and thus when that seperate procedure finishes, any changes it has made must be committed or rolled back because the autonomous transaction that has been spawned is about to finish. Of course, if that procedure doesn't actually do any work on the database that requires committing or rolling back, then it's not necessary to issue one, but then there would be no need for an autonomous transaction in the first place.
So, with your trigger (let's ignore that fact that making the trigger autonomous is p!ss poor design), if you only do the count and don't do the update statement, then there is nothing to be committed, so there's no need for a commit statement, even if the trigger is defined as an autonomous transaction. But, if you include the update statement, then that spawned transaction must be committed before the trigger ends, so that the transaction is completed and control can return to the calling transaction. So, making your trigger autonomous doesn't mean that it must commit by itself... but making it autonomous and including something that needs committing, does mean it must commit.

Autonomous Transactions usage in PL/SQL anonymous block coding

Hi,
I am trying to incorporate Autonomous Transaction for our work. I am using the tables provided below,
CREATE TABLE T1
F1 INTEGER,
F2 INTEGER
CREATE TABLE T2
F1 INTEGER,
F2 INTEGER
insert into t1(f1, f2)
values(20, 0)
insert into t2(f1, f2)
values(10, 0)
Now, when I use the code snippet given below, it is working as expected.
create or replace procedure p1 as
PRAGMA AUTONOMOUS_TRANSACTION;
begin
     update t2
     set f2 = 25
     where f1 = 10;
     commit;
end;
declare
PRAGMA AUTONOMOUS_TRANSACTION;
a integer;
begin
     update t1
     set f2 = 15
     where f1 = 20;
     p1();
     rollback;
end;
Here, updation in t2 table is commited and t1 is rolled back, it is working as
expected. I would like to achieve the same functionality through PL/SQL
anonymous block coding, to do this, I use the following code snippet,
declare
PRAGMA AUTONOMOUS_TRANSACTION;
a integer;
begin
     update t1
     set f2 = 15
     where f1 = 20;
     begin
          update t2
          set f2 = 35
          where f1 = 10;
          commit;
     end;
     rollback;
end;
Here, data in both the tables are commited, how do I change it to work as I
mentioned above like committing t2 alone, please help, thank you.
Regards,
Deva

Can you explain what you're trying to accomplish from a business perspective? This doesn't look like a particularly appropriate way to use autonomous transactions, so you may be causing yourself problems down the line.
That said, padders's solution does appear to work for me
SCOTT @ nx102 Local> CREATE TABLE T1
2 (
3 F1 INTEGER,
4 F2 INTEGER
5 )
6 /
Table created.
Elapsed: 00:00:01.03
SCOTT @ nx102 Local>
SCOTT @ nx102 Local>
SCOTT @ nx102 Local> CREATE TABLE T2
2 (
3 F1 INTEGER,
4 F2 INTEGER
5 )
6 /
Table created.
Elapsed: 00:00:00.00
SCOTT @ nx102 Local>
SCOTT @ nx102 Local> insert into t1(f1, f2)
2 values(20, 0)
3 /
1 row created.
Elapsed: 00:00:00.01
SCOTT @ nx102 Local>
SCOTT @ nx102 Local> insert into t2(f1, f2)
2 values(10, 0)
3 /
1 row created.
Elapsed: 00:00:00.01
SCOTT @ nx102 Local> commit;
Commit complete.
Elapsed: 00:00:00.01
SCOTT @ nx102 Local> DECLARE
2     a INTEGER;
3
4     PROCEDURE update_t2
5     IS
6        PRAGMA AUTONOMOUS_TRANSACTION;
7     BEGIN
8        UPDATE t2
9           SET f2 = 35
10         WHERE f1 = 10;
11
12        COMMIT;
13     END update_t2;
14 BEGIN
15     UPDATE t1
16        SET f2 = 15
17      WHERE f1 = 20;
18
19     update_t2;
20
21     ROLLBACK;
22 END;
23 /
PL/SQL procedure successfully completed.
Elapsed: 00:00:00.04Have you done something else that would cause a deadlock?
Justin

Autonomous transaction in trigger

Hi,
Can we use commit within a database trigger? I think yes if we use autonomous transaction in that trigger.
Please confirm and if it is correct please provide an example of this.
Thanks,
Mrinmoy

user3001930 wrote:
Can we use commit within a database trigger? I think yes if we use autonomous transaction in that trigger.
Please confirm and if it is correct please provide an example of this.Yes, you can commit in an autonomous transaction within a trigger, but bear in mind that that is only committing the transcation that is autonomous, not the original sessions changes. So if you're expecting to be able to commit the data in your present transaction that has caused the trigger you are mistaken.
Perhaps the simplest way to look at an autonomous transaction is as though the database has started up a seperate session to execute some transactions, and before execution can return to the original session it must commit or rollback what it's done in that second session, however that second session cannot influence the transactions taking place in the first session.

Autonomous transaction performance

Hi,
My trigger issues a ddl, so I had to do it in an autonomous transaction to avoid the problems with commits in triggers. Is there any performace consideration doing so? Does the DDL command execute slower in a trigger in an autonomous transaction as in a normal one issued by the appliaction?
Thank you very much in advance!
torell

Oracle has been using autonomous transactions under the covers for years, so I would assume that there won't be a noticable performance penalty, if there is in fact a penalty. I'd bet dollars to doughnuts that the performance is identical.
Justin
Distributed Database Consulting, Inc.
www.ddbcinc.com

Whats the use of having pragma autonomous transaction

Hii All,
The below is the procedure developed by our predecessors.We are making use of this for writing our debug messages.
I'm aware of pragma autonomous transaction ,this allows my code to run independently of the calling program.
But here we are just using utl_File and we are neither using any DML(Inserting error messages into a table) or DDL statements in the below code.
What is real use of having pragma autonomous transaction.???This code is working in the same way even without the pragma...I dont' find any difference .
Please let me know the use of having pragma autonomous transaction in the below procedure and where it actually comes into usage.
Create or replace Procedure logmesg
p_file_name          in          varchar2,
p_mesg_text          in          varchar2,
p_dir_path          in          varchar2 default fn_get_debug_path,
p_file_ext          in          varchar2 default 'log',
p_append_flag     in          varchar2 default 'Y'
) Is
          pragma autonomous_transaction;
          l_utl_file                    utl_file.file_type;
          l_append_flag               varchar2(1);
          l_mesg_text                    varchar2(32000);
          l_file_name                    varchar2(3000);
          l_dir_path                    varchar2(32000);
          l_delimeter_occurance     number;
          l_buffer_str               varchar2(32000);
Begin
          if trim(p_dir_path) is null then
               l_dir_path     := fn_get_debug_path ;
          else
               l_dir_path := p_dir_path;
          end if;
          l_mesg_text := p_mesg_text;
          l_append_flag := nvl(p_append_flag,'Y');
          l_file_name     := p_file_name||'_'||to_char(sysdate,'ddmmyyyyhh')||'.'||p_file_ext;
          l_append_flag := Case     l_append_flag
                                   When 'Y' then 'a'
                                   When 'N' then 'w'
                               End;--l_append_flag
          Begin
               l_utl_file := utl_file.fopen(l_dir_path,l_file_name,l_append_flag);
          Exception
               When Others Then
                    l_utl_file := utl_file.fopen(l_dir_path,l_file_name,'w');
          End;
          if dbms_lob.getlength(l_mesg_text) > 32000 then
               loop
                    exit when dbms_lob.getlength(l_mesg_text) < 32000;
                    l_delimeter_occurance := dbms_lob.instr(l_mesg_text,chr(32),1,1);
                    l_buffer_str := dbms_lob.substr(l_mesg_text,l_delimeter_occurance-1);
                    utl_file.put_line(l_utl_file,l_buffer_str);
                    l_mesg_text := dbms_lob.substr(l_mesg_text,l_delimeter_occurance+1);
                    utl_file.fflush(l_utl_file);
               end loop;
          end if;
          utl_file.put_line(l_utl_file,l_mesg_text);
          utl_file.fflush(l_utl_file);
          utl_file.fclose(l_utl_file);
End logmesg;
/Here

Please let me know the use of having pragma autonomous transaction in the below procedure and where it actually comes into usage.Seems it is redundant in that procedure, and doesn't add any value, since the procedure isn't doing anything 'transactional'.
I would remove it.

Using Distributed Transaction with oracle 9i and VB

How to I get distributed transaction to work between a COM + object in VB and oracle using MSDAORA.1 driver? I keep getting the following error:
error number:
-2147168229
error description:
Cannot connect to the transaction manager or the transaction manager is unavailable.

Oracle 9i works great with VB.NET. I would recommend you to use Oracle Data Provider .NET (ODP.NET) as a database driver
http://otn.oracle.com/tech/windows/odpnet/content.html
for better performance and get full advantage of Oracle 9i features.
Regards
Jagriti
OTN Team @IDC

Migrating from non-loggin Informix to Oracle (use of transactions)

I wonder what happens when I migrate an Informix non-logging database to Oracle. Since my database doesn't use transaction (that's to say: a single DML sentence define a transaction and ttransactions using begin/commit/rolback trans are not used), applications are written with no transaction philosophy. But Oracle is ANSI-compliant and then when I execute a DML sentence, a transaction begin and it'll finish until I send commit or logout. Then, even when migration is ok, my applications will create very large transactions.

Hi Oscar,
Without actually viewing the Client application code, I can only make general assumptions..
You will have to change the client code anyway in order for it to work with Oracle e.g. Informix E/SQL -> Oracle Pro*C. The E/SQL Client code will have to be updated to reflect various changes in the DB environment; for example:
1. The use of REF CURSORS (passing them back to the client code)
2. Changes to the hardcoded Informix SQL statements to make them Oracle friendly (especially OUTER joins if you migrating to Oracle 8i)
3. Altering any E/SQL code that dynamically builds SQL statements (to make sure these SQL statements are syntactically correct in the Oracle model).
4. DB Connection methodologies.
5. Changing Informix #include files to reference equivalent Oracle #includes
6. Differences in date structs and how E/SQL and Pro*C handle dates (Oracle did not support milliseconds until 9i)
7. Exception handling.
8. Datatype changes between Informix and Oracle.
Again, there is no simple solution. A migration project that migrated the DB and Applications 'in tandem' would make it easier to remove logic from the client code and place it in the server (always a good thing) but this may not be feasable in your case.

Migrating from non-logging Informix to Oracle (use of transactions)

I wonder what happens when I migrate an Informix non-logging database to Oracle. Since my database doesn't use transaction (that's to say: a single DML sentence defines a transaction and transactions using begin/commit/rolback trans are not used), applications are written with no transaction philosophy. But Oracle is ANSI-compliant and then when I execute a DML sentence, a transaction begin and it'll finish until I send commit or logout. Then, even when migration is ok, my applications will create very large transactions.
What should I do? Is there some parameter to configure Oracle in such way it create single-DML transaction (I heard there's something like that in SQL*Plus, but I'm not sure)? Or should I rewrite applications sending commits after every sentence (The worst case, I think)?
Thanks in advance
Omar Muqoz

Hi Oscar,
Without actually viewing the Client application code, I can only make general assumptions..
You will have to change the client code anyway in order for it to work with Oracle e.g. Informix E/SQL -> Oracle Pro*C. The E/SQL Client code will have to be updated to reflect various changes in the DB environment; for example:
1. The use of REF CURSORS (passing them back to the client code)
2. Changes to the hardcoded Informix SQL statements to make them Oracle friendly (especially OUTER joins if you migrating to Oracle 8i)
3. Altering any E/SQL code that dynamically builds SQL statements (to make sure these SQL statements are syntactically correct in the Oracle model).
4. DB Connection methodologies.
5. Changing Informix #include files to reference equivalent Oracle #includes
6. Differences in date structs and how E/SQL and Pro*C handle dates (Oracle did not support milliseconds until 9i)
7. Exception handling.
8. Datatype changes between Informix and Oracle.
Again, there is no simple solution. A migration project that migrated the DB and Applications 'in tandem' would make it easier to remove logic from the client code and place it in the server (always a good thing) but this may not be feasable in your case.

Autonomous Transactions and table locks

Does a commit statement in an Autonomous Transaction block in PL/SQL release locks aquired in the master transaction block?
e.g
CREATE OR REPLACE PACKAGE test_auto_trans AS
PROCEDURE mainproc;
PROCEDURE testproc;
END test_auto_trans;
CREATE OR REPLACE PACKAGE BODY test_auto_trans AS
/*****************Main Procedure*********************/
PROCEDURE mainproc AS
BEGIN
LOCK TABLE a,b,c IN EXCLUSIVE MODE nowait;
/*some processing involving tables a,b,c here. no commit done yet*/
testproc();
/* will the locks on a,b,c still be available here? */
EXCEPTION
WHEN others THEN
dbms_output.put_line('Error');
dbms_output.put_line(sqlcode);
dbms_output.put_line(sqlerrm);
RAISE;
END mainproc;
/*****************test Procedure*********************/
PROCEDURE testproc AS
PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
/*some processing using tables a,b,c here*/
commit;
EXCEPTION
WHEN others THEN
dbms_output.put_line('Error');
dbms_output.put_line(sqlcode);
dbms_output.put_line(sqlerrm);
RAISE;
END testproc;
END test_auto_trans;
/

No transaction will release the locks held by another transaction. When you declare a stored proc to be PRAGMA AUTONOMOUS_TRANSACTION, it is essentially the same as if you logged in as the same user but in a different session.
For example, if I have two sqlplus sessions running as user a, if I do an update in session1 and a delete and commit in session 2 I can still rollback in session 1.
However, your psuedo code as posted will not work at all since the call to test_proc will block until you commit in the main proc, and since test_proc will never return, the main proc will never get to commit. It is exactly analogous to the following:
session1> SELECT * FROM t;
        ID DESCR
         1 One
         2 Two
session1> LOCK TABLE t IN EXCLUSIVE MODE nowait;
Table(s) Locked.
session1> UPDATE t SET descr = 'Un'
2 WHERE id = 1;
1 row updated.so far, this is your main proc. Now, in another session (which is equivalent to your autonomous transaction procedure), I do:
session2> UPDATE t SET descr = 'Deux'
2 WHERE id = 2;which as I type is still waiting on the commit from session 1. Therefore, I cannot get to commit the autonomous transaction which would return control to session1
HTH
John
Message was edited by:
John Spencer
Sorry, I initially forgot to answer your actual question "what about DML statements like truncate". Since TRUNCATE is actually a DDL statement I will assume that is what you meant. My initial answer covers DML statements (except SELECT which will work).
All DDL statements in Oracle go
COMMIT
DDL statement
COMMIT
since the initial commit requires a very brief exclusive lock, you will get an error like:
ORA-00054: resource busy and acquire with NOWAIT specified
Exactly as if you did:
session1> LOCK TABLE t IN EXCLUSIVE MODE nowait;
Table(s) Locked.then tried to do it again the another session
session2> LOCK TABLE t IN EXCLUSIVE MODE nowait;
LOCK TABLE t IN EXCLUSIVE MODE nowait
ERROR at line 1:
ORA-00054: resource busy and acquire with NOWAIT specified

Using Autonomous Transaction in dbms_job on Oracle 8.1.6

Similar Messages

Maybe you are looking for