Does the after Update trigger will kick off if there is a rollback?
Scenario: Lets say we update a table A and the trigger on table A kicks off and updates another table B with the details. If there is a rollback issued on table A due to some processing error, will the trigger cause the table B to rollback the change?
Yes, it will.
Triggers work in scope of the DML statement's transaction (either started by you explicitly or by the DML statement itself implicitly)
When this transaction is rolled back, all changes made by the triggers are also rolled back.
However, if you put
PRAGMA autonomous_transaction
into the trigger definition, the trigger will start its own transaction which you should commit before the trigger completes.
Just a note - if you define AFTER UPDATE statement level trigger (without FOR EACH ROW clause) it will not fire if DML statement on the table fails and is rolled back.
Related
What happens if, after updating the table, trigger fails for any reason in Oracle11g. Will original update rollback? If not, how to enforce performing rollback in case of failure.
As should be in any DB, Statements are atomic in Oracle. Transaction won't be completed, and any DML action occured during transaction process will be rolledback.
If a trigger is already in function what will be the effect if i will replace a small part of it ,so many records are getting inserted in table A continuously in which the trigger is applied.
Trigger X is running in table A,
total records are getting insterted per minute are 1000
If i have replaced the trigger what will be the Impact of It for those service who are accesing the table.
Thanks in advance
A CREATE TRIGGER DDL should have no impact on your running DML transactions. Exclusive locks are not required on the table in order to add the trigger.
A CREATE OR REPLACE DDL is slightly different. It has to change an existing object. If the trigger is actively firing, the new trigger will try to lock the trigger object in the library cache before altering it. No impact on the table.
I generally observe that triggers execute immediately.
If you have tested your trigger, you should have no issues. If the trigger is correct, it will go into effect, and the impact shall be according to the logic that you've written in the trigger. The act of creating the trigger is not of concern, but the correctness of the trigger code is. So test it well.
Any transactions underway at the time you create the trigger will finish without firing the trigger.
Any future transactions will fire the trigger.
I dropped a table and tried to rollback, but to no use. Will it ever work like this or am I playing wrong here?
As from most of the comments I am clear that DDL statements cannot be undone by rollback but only by FLASHBACK.
I tried undoing
DELETE FROM STUDENT;
It still it can't be undone:
My order of execution was
INSERT,
DELETE FROM ,
ROLLBACK.
I don't believe rollback will undo schema changes.
ROLLBACK without a savepoint qualifier will roll back the entire current transaction.
For DDL statements, there is no current transaction to rollback. The DDL statement implicitly generates a COMMIT before the statement starts and after it completes. So if you issue a ROLLBACK following a DROP, no work has been done in the current transaction so there is nothing to roll back.
For DML statements, you'll roll back the entire current transaction. If you do
INSERT
DELETE
ROLLBACK
your transaction begins when you execute the INSERT operation. So when you issue the ROLLBACK, you are rolling back both the INSERT and the DELETE so you're back to having no data in the table (assuming you started with no data). If you COMMIT after the INSERT then the next transaction would begin with the DELETE and your ROLLBACK will only roll back the DELETE operation. Alternately, you can declare a savepoint after the INSERT and roll back to the savepoint
SQL> create table foo( col1 number );
Table created.
SQL> insert into foo values( 1 );
1 row created.
SQL> savepoint after_insert;
Savepoint created.
SQL> delete from foo;
1 row deleted.
SQL> rollback to savepoint after_insert;
Rollback complete.
SQL> select * from foo;
COL1
----------
1
Rollback does not undo schema changes, but to undo drop table operations you can check:
http://docs.oracle.com/cd/B19306_01/backup.102/b14192/flashptr004.htm
From the documentation:
Oracle Database implicitly commits the current transaction before and after every DDL statement.
This means that you cannot ROLLBACK a DDL statement (that is, a schema change).
Rollback will never undo Data Definition commands such as drop table alter table etc.
Dropping a table changes the structure of the database (using DDL statements like CREATE, DROP, ...).
COMMIT and ROLLBACK only work on the data which is exchanged with the database using DML statements (like INSERT, UPDATE, ...).
So, no it will never work like this.
To rollback ddl changes you need to use Flashback.
Rollback:
Discard all pending changes by using the ROLLBACK statement. Following a ROLLBACK statement:
Data changes are undone.
The previous state of the data is restored.
The locks on the affected rows are released.
Example
While attempting to remove a record from the TEST table, you can accidentally empty the table. You can correct the mistake, reissue the proper statement, and make the data change permanent.
DELETE FROM test;
25,000 rows deleted.
ROLLBACK;
Rollback complete.
DELETE FROM test
WHERE id = 100;
1 row deleted.
SELECT *
FROM test
WHERE id = 100;
No rows selected.
COMMIT;
Commit complete
After giving commit we can't rollback.
I have an Oracle trigger which is calling a stored procedure that has PRAGMA AUTONOMOUS_TRANSACTION defined. The values that are passed from the trigger have been committed already but it appears that the values are not available in the stored procedure? I'm not positive of this since the ability to debug/log/commit is difficult and the timing of the output is confusing me a bit. I'd like to know if it's expected that any passed values are simply available in the stored procedure regardless of the AUTONOMOUS_TRANSACTION?
Thanks
Values passed in to a stored procedure as parameters will always be available to the stored procedure. It doesn't matter whether the procedure is declared using an autonomous transaction.
Code running in an autonomous transaction cannot see changes made by the calling transaction. 9 times out of 10, when people are describing problems seeing the data they expect, this is the source of the problem.
If your stored procedure is doing anything other than writing something to a log table, I would be exceptionally cautious about using autonomous transactions. If you are using autonomous transactions for anything other than logging, you are almost certainly using them incorrectly. And you are probably introducing a whole host of bugs related to race conditions and transactional integrity.
"The trigger logic is conditionally
updating Table B which calls the
stored procedure to select from the
values on Table A so that Table B can
be updated with a calculated value. "
Perhaps Table B really ought to be a Materialized View derived from Table A? We can build a lot of complexity into the WHERE clauses of the queries which populate MViews. Find out more.
If you have a row level trigger on table_x, then that trigger can be fired multiple times by the same statement as different rows are impacted by that statement.
The order in which those rows are impacted is indeterminate. As such, the state of table_x is indeterminate during the execution of a row level trigger. This is why the MUTATING TABLE exception is raised.
An autonomous transaction 'cheats' by looking at the committed state of the table (ie excluding all changes made by that statement, and other statements in the transaction).
If you want a stored procedure to look at the state of table_x in response to activity on that table, then it needs to be done after all the rows changes have been made (ie in a statement level trigger, not a row level trigger).
The design pattern for this is often to set a flag (package level variable) in a row level trigger, check the flag in an AFTER statement level trigger, and if necessary action it and reset it.
Could in Oracle DDL (create/alter) be transactional like they are in MS SQL (started from 2005)?
DDL is not transactional in Oracle. From the 11.2 doc:
Oracle Database implicitly commits the current transaction before and after every DDL statement.
No. In Oracle DDL statements themselves are not transactional.
Running a DDL statement will implicitly commit any open transaction for that session before starting the actual work.
In addition some statements, like an alter table statement, may fail if another session has an open transaction on the object being modified or one of its dependencies. You can set a ddl_lock_timeout to specify how long you want Oracle to wait for the object to become available.
See DDL Statements for a summary of types of DDL statements and information about their behaviour regarding locks and transactions.
Oracle Database implicitly commits the current transaction before and after every DDL statement.
Just discovered this, so needs more investigation, but Oracle's create schema authorization at least allows to bundle several DDL statements in a single transaction, thus avoiding several commits, and guarantees no side-effects, i.e. a rollback, if any one of the DDL statement fails.
It is unclear whether the rollback applies to the wrapped DDL statements only, as-if the create schema started a save-point, or the outer transaction with possibly some prior DML statement.
You still cannot avoid the commit after the last wrapped DDL statement complete successfully though.