Using SAVEPOINT
The SAVEPOINT names and marks the present point in the processing of a transaction. Used with the ROLLBACK TO statement, the savepoints undo parts of a transaction rather than the entire transaction. In the illustration below, you mark a savepoint before doing an insert. When the INSERT statement tries to store a duplicate value in the empno column, the predefined exception DUP_VAL_ON_INDEX is raised. In that situation, you roll back to the savepoint, undoing merely the insert.
DECLARE
emp_id emp.empno%TYPE;
BEGIN
UPDATE emp SET ... WHERE empno = emp_id;
DELETE FROM emp WHERE ...
...
SAVEPOINT do_insert;
INSERT INTO emp VALUES (emp_id, ...);
EXCEPTION
WHEN DUP_VAL_ON_INDEX THEN
ROLLBACK TO do_insert;
END;
If you roll back to a savepoint, any savepoints marked after the savepoint are erasing. Though, the savepoint to which you roll back is not erasing. For illustration, if you mark five savepoints, and then roll back to the third, only the fourth and the fifth are erase. A simple rollback or commit erases all savepoints.
When you mark a savepoint within a recursive subprogram, the new instances of the
SAVEPOINT statements are executed at each level in the recursive fall. Though, you can only roll back to the nearly all recently marked savepoint.
The Savepoint names are undeclared identifiers and can be reused within the transaction. This moves the savepoint from its old position to the persent point in the transaction. And hence, the rollback to the savepoint affects only the present part of your transaction. An illustration is as shown:
BEGIN
...
SAVEPOINT my_point;
UPDATE emp SET ... WHERE empno = emp_id;
...
SAVEPOINT my_point; -- move my_point to current point
INSERT INTO emp VALUES (emp_id, ...);
EXCEPTION
WHEN OTHERS THEN
ROLLBACK TO my_point;
END;
The number of active savepoints per session is limitless. An active savepoint is the one marked as the last commit or rollback.