1. Transaction Processing

2. Objectives After completing this lesson, you should be able to do the following: –Define transactions effectively for an application

3. Transactions –A transaction consists of a collection of DML statements that form a logical unit of work for the application (i.e. all operations must be completed or none completed so data remains in a consistent state for application) –Example: in processing a transfer of money between bank accounts both the withdrawal of money from one account and the deposit of money into another account must be performed; cannot have first action recorded in database without the second action

4. Database Transactions May be implicit or explicit Explicit: –consist of a set of DML (INSERT UPDATE, DELETE) statements that make one consistent change to the data –Controlled by using the COMMIT, SAVEPOINT, and ROLLBACK statements Implicit: automatically performed by DBMS: –A DDL (CREATE, ALTER, DROP) statement –A DCL (GRANT, REVOKE) statement

5. Database Transactions –Transaction begins when the first executable SQL statement is executed –Transaction ends with one of the following events: COMMIT or ROLLBACK issued DDL or DCL statement executes (automatic commit) User exits System crashes –After one transaction ends a new transaction starts automatically with the next SQL statement

6. Advantages of using Transactions –Ensures data consistency –Groups logically related operations into one unit –Allows preview of data changes before making changes permanent

7. DELETE Controlling Transactions Transaction Savepoint A ROLLBACK to Savepoint B DELETE Savepoint B COMMIT INSERT UPDATE ROLLBACK to Savepoint A INSERTUPDATE INSERT ROLLBACK INSERT Control transactions by using COMMIT, SAVEPOINT, and ROLLBACK statements (note: SAVEPOINT is not standard SQL)

8. – Automatic commit occurs under the following circumstances: DDL statement is issued DCL statement is issued Normal exit from SQL*Plus, without explicitly issuing COMMIT or ROLLBACK –Automatic rollback occurs under an abnormal termination of SQL*Plus or a system failure. Implicit Transaction Processing

9. State of Data Before COMMIT or ROLLBACK –State of data at end of last explicit or implicit transaction can be recovered. –Current user (i.e. issued changes to data) can review the current state of data changed by DML operations by using the SELECT statement. –Other users cannot see results of DML statements by the current user –Changed rows are locked; other users cannot change the data within the affected rows

10. State of Data After COMMIT –Data changes made permanent in database –Previous state of data is permanently lost –All users can view the results –Locks on the affected rows are released; those rows are available for other users to manipulate –All savepoints are erased

11. Committing Data UPDATEemployees SET department_id = 90 WHEREemp_no = 103; 1 row updated. UPDATEemployees SET department_id = 90 WHEREemp_no = 103; 1 row updated. Make changes to data using DML: COMMIT; Commit complete. Commit these changes (i.e. make changes to data permanent):

12. Discards all pending changes by using the ROLLBACK statement: –State of data at time of last commit or implicit transaction is restored (i.e current data changes undone) –Locks on affected rows released DELETE FROMemployees; 20 rows deleted. ROLLBACK; Rollback complete. State of Data After ROLLBACK - delete undone; employees table still contains 20 rows of data

13. Rolling Back Changes to a Marker –Create a marker in a current transaction by using the SAVEPOINT statement. –Roll back to that marker by using the ROLLBACK TO SAVEPOINT statement. SQL> UPDATE... SQL> SAVEPOINT update_done; Savepoint created. SQL> INSERT... SQL> ROLLBACK TO update_done; Rollback complete.

14. Statement-Level Rollback –If a single DML statement fails during execution, only that statement is rolled back. –The Oracle Server implements an implicit savepoint. –All other changes are retained. –The user should terminate transactions explicitly by executing a COMMIT or ROLLBACK statement.

15. Read Consistency –Read consistency guarantees a consistent view of the data at all times. –Changes made by one user do not conflict with changes made by another user. –Read consistency ensures that on the same data: Readers do not wait for writers Writers do not wait for readers

16. Implementation of Read Consistency UPDATE employees SET sal = 2000 WHERE ename = 'SCOTT'; 'SCOTT'; Data blocks Rollback segments changed and unchanged data before change “old” data User A User B Read consistent image SELECT * FROM employees;

17. Locking Oracle locks: –Prevent destructive interaction between concurrent transactions –Require no user action –Automatically use the lowest level of restrictiveness –Are held for the duration of the transaction –Have two basic modes: Exclusive Share

18. Summary Description Makes all pending changes permanent Allows a rollback to the savepoint marker Discards all pending data changes Statement COMMIT SAVEPOINT ROLLBACK

19. Lab Overview –Inserting rows into the tables –Updating and deleting rows in the table –Controlling transactions