Chapter 19

1. Chapter 19 Transaction Management Transparencies

2. Chapter - Objectives • Function and importance of transactions. • Properties of transactions. • Concurrency Control • Meaning of serializability. • How locking can ensure serializability. • Deadlock and how it can be resolved. • How timestamping can ensure serializability. • Optimistic concurrency control. • Granularity of locking. 2

3. Chapter - Objectives • Recovery Control - Some causes of database failure. • Purpose of transaction log file. • Purpose of checkpointing. • How to recover following database failure. Additional Topics: Trigger; Stored Procedure and Package 3

4. Transactions • SQL-92 defines transaction model based on COMMIT and ROLLBACK. • Transaction is logical unit of work with one or more SQL statements guaranteed to be atomic with respect to recovery. • An SQL transaction automatically begins with a transaction-initiating SQL statement (e.g., SELECT, INSERT). Changes made by transaction are not visible to other concurrently executing transactions until transaction completes.

5. Transaction Support Transaction Action or series of actions, carried out by user or application, which accesses or changes contents of database. • Logical unit of work on the database. • Application program is series of transactions with non-database processing in between. • Transforms database from one consistent state to another, although consistency may be violated during transaction. 4

6. Transaction Support • Can have one of two outcomes: • Success - transaction commits and database reaches a new consistent state. • Failure - transaction aborts, and database must be restored to consistent state before it started. • Such a transaction is rolled back or undone. • Committed transaction cannot be aborted. • Aborted transaction that is rolled back can be restarted later. 6

7. Properties of Transactions • Four basic (ACID) properties of a transaction are: Atomicity 'All or nothing' property. Consistency Must transform database from one consistent state to another. Isolation Partial effects of incomplete transactions should not be visible to other transactions. Durability Effects of a committed transaction are permanent and must not be lost because of later failure. 7

8. Concurrency Control Process of managing simultaneous operations on the database without having them interfere with one another. • Prevents interference when two or more users are accessing database simultaneously and at least one is updating data. • Although two transactions may be correct in themselves, interleaving of operations may produce an incorrect result. 9

9. Serializability • Objective of a concurrency control protocol is to schedule transactions in such a way as to avoid any interference. • Could run transactions serially, but this limits degree of concurrency or parallelism in system. • Serializability identifies those executions of transactions guaranteed to ensure consistency. 17

10. Serializability Schedule Sequence of reads/writes by set of concurrent transactions. Serial Schedule Schedule where operations of each transaction are executed consecutively without any interleaved operations from other transactions. • No guarantee that results of all serial executions of a given set of transactions will be identical. 18

11. Serializability • In serializability, ordering of read/writes is important: (a) If two transactions only read a data item, they do not conflict and order is not important. (b) If two transactions either read or write completely separate data items, they do not conflict and order is not important. (c) If one transaction writes a data item and another reads or writes same data item, order of execution is important. 20

12. Serializability • Conflict serializable schedule orders any conflicting operations in same way as some serial execution. • Under constrained write rule (transaction updates data item based on its old value, which is first read), use precedence graph to test for serializability. 22

13. Recoverability • Serializability identifies schedules that maintain database consistency, assuming no transaction fails. • Could also examine recoverability of transactions within schedule. • If transaction fails, atomicity requires effects of transaction to be undone. • Durability states that once transaction commits, its changes cannot be undone (without running another, compensating, transaction). 29

14. Concurrency Control Techniques • Two basic concurrency control techniques: • Locking • Timestamping • Both are conservative approaches: delay transactions in case they conflict with other transactions. • Optimistic methods assume conflict is rare and only check for conflicts at commit. 31

15. Locking Transaction uses locks to deny access to other transactions and so prevent incorrect updates. • Most widely used approach to ensure serializability. • Generally, a transaction must claim a read (shared) or write (exclusive) lock on a data item before read or write. • Lock prevents another transaction from modifying item or even reading it, in the case of a write lock. 32

16. Locking - Basic Rules • If transaction has read lock on item, can read but not update item. • If transaction has write lock on item, can both read and update item. • Reads cannot conflict, so more than one transaction can hold read locks simultaneously on same item. • Write lock gives transaction exclusive access to that item. 33

17. Locking - Basic Rules • Some systems allow transaction to upgrade read lock to a write lock, or downgrade write lock to a read lock. 34

18. Two-Phase Locking (2PL) Transaction follows 2PL protocol if all locking operations precede first unlock operation in the transaction. • Two phases for transaction: • Growing phase - acquires all locks but cannot release any locks. • Shrinking phase - releases locks but cannot acquire any new locks. 38

19. Cascading Rollback • If every transaction in a schedule follows 2PL, schedule is serializable. • However, problems can occur with interpretation of when locks can be released. 42

20. Deadlock • Only one way to break deadlock: abort one or more of the transactions. • Deadlock should be transparent to user, so DBMS should restart transaction(s). • Two general techniques for handling deadlock: • Deadlock prevention. • Deadlock detection and recovery. 46

21. Timestamping • Transactions ordered globally so that older transactions, transactions with smaller timestamps, get priority in the event of conflict. • Conflict is resolved by rolling back and restarting transaction. • No locks so no deadlock. 51

22. Timestamping Timestamp A unique identifier created by DBMS that indicates relative starting time of a transaction. • Can be generated by using system clock at time transaction started, or by incrementing a logical counter every time a new transaction starts. 52

23. Database Recovery Process of restoring database to a correct state in the event of a failure. • Need for Recovery Control • Two types of storage: volatile (main memory) and nonvolatile. • Volatile storage does not survive system crashes. • Stable storage represents information that has been replicated in several nonvolatile storage media with independent failure modes. 68

24. Types of failures • System crashes, resulting in loss of main memory. • Media failures, resulting in loss of parts of secondary storage. • Application software errors. • Natural physical disasters. • Carelessness or unintentional destruction of data or facilities. • Sabotage. 69

25. Transactions and Recovery • Transactions represent basic unit of recovery. • Recovery manager responsible for atomicity and durability. • If failure occurs between commit and database buffers being flushed to secondary storage then, to ensure durability, recovery manager has to redo (rollforward) transaction's updates. 70

26. Transactions and Recovery • If transaction had not committed at failure time, recovery manager has to undo (rollback) any effects of that transaction for atomicity. • Partial undo - only one transaction has to be undone. • Global undo - all transactions have to be undone. 71

27. Recovery Facilities • DBMS should provide following facilities to assist with recovery: • Backup mechanism, which makes periodic backup copies of database. • Logging facilities, which keep track of current state of transactions and database changes. 73

28. Recovery Facilities • Checkpoint facility, which enables updates to database in progress to be made permanent. • Recovery manager, which allows DBMS to restore the database to a consistent state following a failure. 74

29. Log File • Contains information about all updates to database: • Transaction records. • Checkpoint records. • Often used for other purposes (for example, auditing). 75

30. Log File • Transaction records contain: • Transaction identifier. • Type of log record, (transaction start, insert, update, delete, abort, commit). • Identifier of data item affected by database action (insert, delete, and update operations). • Before-image of data item. • After-image of data item. • Log management information. 76

31. Log File • Log file may be duplexed or triplexed. • Log file sometimes split into two separate random-access files. • Potential bottleneck; critical in determining overall performance. 78

32. Checkpointing Checkpoint Point of synchronization between database and log file. All buffers are force-written to secondary storage. • Checkpoint record is created containing identifiers of all active transactions. • When failure occurs, redo all transactions that committed since the checkpoint and undo all transactions active at time of crash. 79

33. Transaction Sample • create trigger tD_patient on patient for DELETE as • /* DELETE trigger on patient */ • begin • declare @errno int, • @errmsg varchar(255) • /* ERwin Builtin Sun Nov 04 11:57:56 2001 */ • /* patient assigned bed ON PARENT DELETE SET NULL */ • update bed • set • bed.patient_id = NULL • from bed,deleted • where • bed.patient_id = deleted.patient_id • return • error: • raiserror @errno @errmsg • rollback transaction • end

34. Triggers; Stored Procedures; Packages • Triggers are created in a schema with the DDL “create trigger” command. Triggers define a action to be taken whenever an SQL statement affects a table and, equally significant, at a specified time or state within the SQL statement’s life cycle. An INSERT, UPDATE, or DELETE command may affect a table. The SQL statement’s life cycle has four states: a before and after SQL statement and a before and after row state. Therefore, we have three types of triggers-insert, update, and delete-that may fire at four different times within a SQL command’s life, yielding 12 possible triggers.

35. Trigger (Alternatively a trigger could be used to enforce some constraints). CREATE TRIGGER staff_nit_handlng_not_much ON property_for_rent FOR INSERT, UPDATE AS IF ((SELECT COUNT(*) FROM property_for_rent p WHERE p.sno = INSERTED.sno > 10) BEGIN PRINT “staff member already managing 10 properties” ROLLBACK TRANSACTION END;

36. More On Triggers CREATE OR REPLACE TRIGGER usage_bir* BEFORE INSERT ON usage FOR INSERT, UPDATE DECLARE logon_error exception FOR each ROW BEGIN number_of_days = SYSTEM DATE (JULIAN DAY) - LOGONDATE (JULIAN DAY) IF (number_of_days => 90) THEN RAISE LOGON_ERROR (-20000 ‘password expired’) END IF END;

37. More On Triggers • The three-letter suffix defines the type of trigger. The first letter will be b or a for before or after. The second letter will be I, U, or D for INSERT, UPDATE, or DELETE. The third letter will be r or s for row or statement. • If we move ‘for each row’, then the trigger will be a statement-level trigger.

38. More On Triggers • When combining the different types of triggering actions, there are twelve possible combinations: BEFORE INSERT row BEFORE INSERT statement AFETR INSERT row AFETR INSERT statement BEFORE UPDATE row -----

39. Triggers Example Create or Replace Trigger EMP_BIR Before Insert in EMP For Each Row Begin if (:New.Salary > 10,000) then Raise_Application_error (-20200 ‘Salary Cap Exceeded’) End if; End; Note: BIR (Before; Insert; Row) The name :new.salary correlates to the new value to be inserted in the EMP table’s salary column.

40. Stored Procedure and Package • PL/SQL procedure language--SQL extends SQL by adding constructs found in other procedural languages, such as 1. variables and types 2. Control structures such as IF-THEN-ELSE statements and loops 3. Procedures and functions • Stored procedure – groups of SQL and PL/SQL statements • Package – group of procedures, functions and SQL statements grouped together into a single unit. (procedure and function)

41. Stored Procedures • Oracle stored procedures are written in Oracle’s PL/SQL procedural language, an extension of the ANSI SQL/92 Standard. • Stored Procedures accept arguments and may be encapsulated within a PL/SQL package. • Stored procedures are created in the database with the data definition language (DDL) “create procedure” command, which compiles and enters the procedure in the database. • These stored procedures may be invoked from an interactive Oracle SQL/PLUS session, a Pro*C program, or Oracle database triggers and other stored procedures.

42. Stored Procedures • decalre • salary number(7,2); • commission number(7,2); • comm_missing exception; -- declare exception • begin • select sal, comm into salary, commission from emp • where empno = :emp_id;' • if commission is null then • raise exception; -- raise exception • else • :bonus : = (salary * 0.05) + (commission * 0.15); • end if; • exception --- begin exception handler • when comm_missing then • --- process error • end;

43. Package Example Create or Replace Package Emp_table_pkg as Procedure Initialize_table; Procedure Insert_Unique_Emp (ID in Number); Function More_emp_ids return Boolean; Function Next_emp_id return number; End package Emp_table_pkg; Create or Replace Package body Emp_table_pkg as ------- End Emp_table_pkg ;

44. Managing Transactions in MTS Components • Every instance of a component under MTS control has an associated context object which holds information about the requested object and serves as the object’s communication link to MTS. MTS manages transactions through this context object. • To obtain a reference to this object within a Visual Basic MTS component, call the GetObjectContext method:   Dim ObjContext as ObjectContext Set ObjContext = GetObjectContext ()

45. Managing Transactions in MTS Components • To provide component-based transactions, MTS must manage state information about every single instance of all components under its control. It does so by intercepting the instantiation of a component and creating a sibling object at the creation time of the original object. This second object is known as a context object and its job is to maintain information about the context of the newly created object. Some of the information in a context object includes:       --Transaction participation       ---Thread of execution information --Security information, such as the component’s creator

46. Managing Transactions in MTS Components • You must build all MTS components as in-process COM DLL’s, also called ActiveX DLLs. • Logically group your components into packages for process isolation and performance. • Use existing data access APIs ADO (Active Data Objects) RDO (Remote Data Objects) DAO (Data Access Objects) to access data.

47. Final Words • Transform data into information by understanding the process • Transform information into decisions with knowledge • Transform decisions into results with actions