DB Integrity & Transactions Part 1 IS240 – DBMS Lecture #11 – 2010-04-05 M. E. Kabay, PhD, CISSP-ISSMP Assoc. Prof. Information Assurance School of Business & Management, Norwich University mailto:mkabay@norwich.edu V: 802.479.7937 Class Notes Copyright © 2004 M. E. Kabay. All rights reserved. Page 1

Objectives Why would you need to use procedural code when SQL is so powerful? How do you use data triggers to make changes automatically? How does the DBMS ensure related changes are made together? How do you handle multiple users changing the same data at the same time? How are internal key values generated and used in updates? What is the purpose of database cursors? Copyright © 2004 M. E. Kabay. All rights reserved. Page 2

Programming Environment DBMS Tables Create code (1) Within the query system (2) In forms and reports (3) Hosted in external programs Queries (1) If ( . . ) Then SELECT . . . Else . . . UPDATE . . . End If External Program Forms & Reports (3) C++ if (. . .) { // embed SQL SELECT … } Location of procedural code. Code can usually be written in the query system, within a database form, or in an external program. When possible, code should be placed within the query system so that it cannot be by passed. (2) If (Click) Then MsgBox . . . End If Copyright © 2004 M. E. Kabay. All rights reserved. Page 3

User-Defined Function CREATE FUNCTION EstimateCosts (ListPrice Currency, ItemCategory VarChar) RETURNS Currency BEGIN IF (ItemCategory = ‘Clothing’) THEN RETURN ListPrice * 0.5 ELSE RETURN ListPrice * 0.75 END IF END User-defined function. Placing the business logic in a central location makes it easy to modify later. The function can be used in code segments or SELECT statements. Copyright © 2004 M. E. Kabay. All rights reserved. Page 4

Function to Perform Conditional Update CREATE FUNCTION IncreaseSalary (EmpID INTEGER, Amt CURRENCY) RETURNS CURRENCY BEGIN IF (Amt > 50000) THEN RETURN -1 -- error flag END UPDATE Employee SET Salary = Salary + Amt WHERE EmployeeID = EmpID; RETURN Amt Function to update the database. The input parameters are used to specify values in the SQL statement. Additional computations can be performed and the parameters modified if needed. Copyright © 2004 M. E. Kabay. All rights reserved. Page 5

Looking Up Data CREATE FUNCTION IncreaseSalary (EmpID INTEGER, Amt CURRENCY) RETURNS CURRENCY DECLARE CURRENCY MaxAmount; BEGIN SELECT MaxRaise INTO MaxAmount FROM CompanyLimits WHERE LimitName = ‘Raise’; IF (Amt > MaxAmount) THEN RETURN -1 -- error flag END UPDATE Employee SET Salary = Salary + Amt WHERE EmployeeID = EmpID; RETURN Amt; Looking up single data elements. The SELECT INTO statement can be used to return data from exactly one row in a table or query. The result is stored in a local variable (MaxAmount) that you can use in subsequent code or SQL statements. Copyright © 2004 M. E. Kabay. All rights reserved. Page 6

Data Trigger Events INSERT DELETE UPDATE BEFORE AFTER Oracle additions: Tables ALTER, CREATE, DROP User LOGOFF, LOGON Database SERVERERROR, SHUTDOWN, STARTUP Data triggers. You can set procedures to execute whenever one of these actions occurs. Row events can be triggered before or after the specified event occurs. Copyright © 2004 M. E. Kabay. All rights reserved. Page 7

Statement v. Row Triggers UPDATE Employee SET Salary = Salary + 10000 WHERE EmployeeID=442 OR EmployeeID=558 SQL After Update On table Before Update On table Triggers for overall table Update Row 442 After Update Row 442 … other rows Before Update Row 442 time Update triggers can be assigned to the overall table and fire once for the entire command, or they can be assigned to fire for each row being updated. Triggers for each row Copyright © 2004 M. E. Kabay. All rights reserved. Page 8

Data Trigger Example CREATE TRIGGER LogSalaryChanges AFTER UPDATE OF Salary ON Employee REFERENCING OLD ROW as oldrow NEW ROW AS newrow FOR EACH ROW INSERT INTO SalaryChanges (EmpID, ChangeDate, User, OldValue, NewValue) VALUES (newrow.EmployeeID, CURRENT_TIMESTAMP, CURRENT_USER, oldrow.Salary, newrow.Salary); Trigger to log the users who change an employee salary. The trigger fires any time the salary is updated, regardless of the method used to alter the data. It is a useful security tracing technique for sensitive data because it cannot be circumvented, except by the owner of the trigger. Copyright © 2004 M. E. Kabay. All rights reserved. Page 9

Canceling Data Changes in Triggers CREATE TRIGGER TestDeletePresident BEFORE DELETE ON Employee REFERENCING OLD ROW AS oldrow FOR EACH ROW WHEN (oldrow.Title = ‘President’) SIGNAL _CANNOT_DELETE_PRES; Canceling the underlying SQL command. This trigger examines the data for the employee row being deleted. The company always wants to keep data on any employee with the president title. The WHEN condition evaluates each row. The SIGNAL statement raises an error to prevent the underlying delete from executing. Copyright © 2004 M. E. Kabay. All rights reserved. Page 10

Cascading Triggers Sale(SaleID, SaleDate, …) SaleItem(SaleID, ItemID, Quantity, …) AFTER INSERT UPDATE Inventory SET QOH = QOH – newrow.Quantity Inventory(ItemID, QOH, …) AFTER UPDATE WHEN newrow.QOH < newrow.Reorder INSERT {new order} INSERT {new OrderItem} Cascading triggers. With triggers defined on multiple tables, a change in one table (SaleItem) can cascade into changes in other tables. Here, when an item is sold, quantity on hand is updated. If QOH is below the reorder point, a new order is generated and sent. Order(OrderID, OrderDate, …) OrderItem(OrderID, ItemID, Quantity, …) Copyright © 2004 M. E. Kabay. All rights reserved. Page 11

Trigger Loop Employee(EID, Salary) AFTER UPDATE IF newrow.Salary > 100000 THEN Add Bonus END BonusPaid(EID, BonusDate, Amount) AFTER UPDATE Or INSERT IF newrow.Bonus > 50000 THEN Reduce Bonus Add Options END StockOptions(EID, OptionDate, Amount, SalaryAdj) Trigger loop. Consider what happens when cascading triggers create a loop, where one trigger returns to alter a table that generated the original change. This loop would set up iterations that might converge or diverge. Even if the loop converges, it will eat up considerable resources. AFTER UPDATE Or INSERT IF newrow.Amount > 100000 THEN Reduce Salary END Copyright © 2004 M. E. Kabay. All rights reserved. Page 12

Transactions Some transactions result in multiple changes. These changes must all be completed successfully, or the group must fail. Protection for hardware and communication failures. Example: bank customer transfers money from savings account to checking account. Decrease savings balance Increase checking balance Problem if one transaction and machine crashes. Possibly: give users a chance to reverse/undo a transaction. Performance gain by executing transactions as a block. Savings Accounts Inez: 5340.92 4340.92 $1000 Checking Accounts Inez: 1424.27 Transaction 1. Subtract $1000 from savings. (machine crashes) 2. Add $1000 to Checking. (money disappears) Copyright © 2004 M. E. Kabay. All rights reserved. Page 13

Problem arises if transaction is not completed Transaction Steps Steps Savings Balance Checking Balance 0. Start 5,340.92 1,424.27 1. Subtract 1,000 4,340.92 2. Add 1,000 2,424.27 Problem arises if transaction is not completed 2. Machine crashes 1,000 is gone Transactions involve multiple changes to the database. To transfer money from a savings account to a checking account, the system must subtract money from savings and add it to the checking balance. If the machine crashes after subtracting the money but before adding it to checking, the money will be lost. Copyright © 2004 M. E. Kabay. All rights reserved. Page 14

Defining Transactions The computer needs to be told which changes must be grouped into a transaction. Turn on transaction processing. Signify a transaction start. Signify the end. Success: save all changes Failure: cancel all changes Must be set in module code Commit Rollback Copyright © 2004 M. E. Kabay. All rights reserved. Page 15

SQL Transaction Code CREATE FUNCTION TransferMoney(Amount Currency, AccountFrom Number, AccountTo Number) RETURNS NUMBER curBalance Currency; BEGIN DECLARE HANDLER FOR SQLEXCEPTION ROLLBACK; Return -2; -- flag for completion error END; START TRANSACTION; -- optional SELECT CurrentBalance INTO curBalance FROM Accounts WHERE (AccountID = AccountFrom); IF (curBalance < Amount) THEN RETURN -1; -- flag for insufficient funds END IF UPDATE Accounts SET CurrentBalance = CurrentBalance – Amount WHERE AccountID = AccountFrom; SET CurrentBalance = CurrentBalance + Amount WHERE AccountID = AccountTo; COMMIT; RETURN 0; -- flag for success Transaction to transfer money. If the system crashes before the end of the transactions (Commit), none of the changes are written to the database. On restart, the changes may all be rolled back, or the transaction restarted. Copyright © 2004 M. E. Kabay. All rights reserved. Page 16

SAVEPOINT SAVEPOINT StartOptional start commit Required elements Risky steps time Partial rollback START TRANSACTION; SELECT … UPDATE … SAVEPOINT StartOptional; If error THEN ROLLBACK TO SAVEPOINT StartOptional; END IF COMMIT; SAVEPOINT. A SAVEPOINT enables you to rollback to an intermediate point in the procedure. You can set multiple SAVEPOINTS and choose how far back you want to rollback the changes. Copyright © 2004 M. E. Kabay. All rights reserved. Page 17

Concurrent Access Concurrent Access Multiple users or processes changing the same data at the same time. Final data will be wrong! Force sequential Locking Delayed, batch updates Two processes Receive payment ($200) Place new order ($150) Initial balance $800 Result should be $800 -200 + 150 = $750 Interference result is either $600 or $950 ID Balance Jones $800 $600 $950 Customers 1) Read balance 800 2) Subtract pmt -200 4) Save new bal. 600 3) Read balance 800 5) Add order 150 6) Write balance 950 Receive Payment Place New Order Concurrent access. If two processes try to change the same data at the same time, the result will be wrong. In this example the changes made when the payment is received are overwritten when a new order is placed at the same time. Copyright © 2004 M. E. Kabay. All rights reserved. Page 18

Concurrent Access Steps Receive Payment Balance Place New Order 1. Read balance 800 2. Subtract Pmt. -200 4. Save balance 600 800 600 950 3. Read balance 800 5. Add order 150 6. Write balance 950 Serialization. The first process locks the data so that the second process cannot even read it. Concurrent changes are prevented by forcing each process to wait for the earlier ones to be completed. Copyright © 2004 M. E. Kabay. All rights reserved. Page 19

Pessimistic Locks: Serialization One answer to concurrent access is to prevent it. When a transaction needs to alter data, it places a SERIALIZABLE lock on the data used, so no other transactions can even read the data until the first transaction is completed. SET TRANSACTION SERIALIZABLE, READ WRITE Customers Receive Payment Place New Order ID Balance Jones $800 $600 1) Read balance 800 2) Subtract pmt -200 4) Save new bal. 600 3) Read balance Receive error message that it is locked. Copyright © 2004 M. E. Kabay. All rights reserved. Page 20

SQL Pessimistic Lock CREATE FUNCTION ReceivePayment ( AccountID NUMBER, Amount Currency) RETURNS NUMBER BEGIN DECLARE HANDLER FOR SQLEXCEPTION ROLLBACK; RETURN -2; END SET TRANSACTION SERIALIZABLE, READ WRITE; UPDATE Accounts SET AccountBalance = AccountBalance - Amount WHERE AccountNumber = AccountID; COMMIT; RETURN 0; Transaction to transfer money. If the system crashes before the end of the transactions (Commit), none of the changes are written to the database. On restart, the changes may all be rolled back, or the transaction restarted. Copyright © 2004 M. E. Kabay. All rights reserved. Page 21

Serialization Effects Receive Payment Balance Place New Order 1. Read balance 800 2. Subtract Pmt. -200 4. Save balance 600 800 600 750 3. Read balance Error: Blocked 3. Read balance 600 4. Add order 150 5. Write balance 750 Copyright © 2004 M. E. Kabay. All rights reserved. Page 22

Transaction to Transfer Money CREATE FUNCTION ReceivePayment ( AccountID NUMBER, Amount Currency) RETURNS NUMBER BEGIN DECLARE HANDLER FOR SQLEXCEPTION ROLLBACK; RETURN -2; END SET TRANSACTION SERIALIZABLE, READ WRITE; UPDATE Accounts SET AccountBalance = AccountBalance - Amount WHERE AccountNumber = AccountID; COMMIT; RETURN 0; Copyright © 2004 M. E. Kabay. All rights reserved. Page 23

Deadlock 1) Lock Data A 3) Wait for Data B Deadlock Two (or more) processes have placed locks on data and are waiting for the other’s data. Many solutions Random wait time Global lock manager Two-phase commit - messages Data A Data B 2) Lock Data B 4) Wait for Data A Copyright © 2004 M. E. Kabay. All rights reserved. Page 24

Deadlock Sequence Process 1 Data A Data B Process2 Lock Data A 3. Wait for Data B Locked by 1 Locked by 2 2. Lock Data B 4. Wait for Data A Deadlock. Process 1 has locked Data A and is waiting for Data B. Process 2 has locked Data B and is waiting for Data A. To solve the problem, one of the processes has to back down and release its lock. Copyright © 2004 M. E. Kabay. All rights reserved. Page 25

Optimistic Locks Assume that collisions are rare Improved performance, fewer resources Allow all code to read any data (no locks) When code tries to write a new value Lock the records Check to see if the existing value is different from the one you were given earlier If it is different, someone changed the database before you finished, so it is a collision--raise an error and unlock Try again Copyright © 2004 M. E. Kabay. All rights reserved. Page 26

Optimistic Locks for Simple Update (1) Read the balance and save it (e.g., to initial-value_buffer) (2) Prepare the new computed value (3) Write the new value to a buffer (e.g., new-value_buffer) (4) LOCK the resources involved (5) Check for errors by comparing the initial-value_buffer to the currentvalue in the database (5a) If initial-value_buffer <> currentvalue, UNLOCK and go back to step (1). (5b) If initial-value_buffer = currentvalue then write new-value_buffer into currentvalue and UNLOCK Optimistic locking process. The steps assume that concurrency problems will not arise. If another transaction does change the data before this transaction finishes, the code receives an error message and must restart. Copyright © 2004 M. E. Kabay. All rights reserved. Page 27

Optimistic Locks with SQL CREATE FUNCTION ReceivePayment ( AccountID NUMBER, Amount Currency) RETURNS NUMBER oldAmount Currency; testEnd Boolean = FALSE; BEGIN DO UNTIL testEnd = TRUE SELECT Amount INTO oldAmount WHERE AccountNumber = AccountID; … UPDATE Accounts SET AccountBalance = AccountBalance - Amount WHERE AccountNumber = AccountID AND Amount = oldAmount; COMMIT; IF SQLCODE = 0 and nrows > 0 THEN testEnd = TRUE; RETURN 0; END IF -- keep a counter to avoid infinite loops END This is the comparison of current value vs old value Optimistic concurrency with SQL. Keep the starting value within memory and then only do the update if that value is unchanged. If another transaction changed the data before this one completes, go back and get the new value and start over. Copyright © 2004 M. E. Kabay. All rights reserved. Page 28

DISCUSSION Copyright © 2004 M. E. Kabay. All rights reserved. Page 29