Lecture 5. MS SQL. Transactions
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Lecture 5. MS SQL. Transactions

  • 337 views
Uploaded on

My lecture notes, composed from different open sources from Internet. If you have copyright claims just tell me to remove.

My lecture notes, composed from different open sources from Internet. If you have copyright claims just tell me to remove.

More in: Education , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
337
On Slideshare
337
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
8
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Database Development in SQL ServerLecture 5Transactions
  • 2. TransactionsA transaction is a sequence of database operations with thefollowing properties (ACID):● Atomic: Operations of a transaction are executed all-or-nothing,and are never left “half-done”● Consistency:Assume all database constraints are satisfied atthe start of a transaction, they should remain satisfied at the endof the transaction● Isolation: Transactions must behave as if they were executed incomplete isolation from each other● Durability: If the DBMS crashes after a transaction commits, alleffects of the transaction must remain in the database whenDBMS comes back up
  • 3. Behaviour● A transaction is automatically started when a user executes anSQL statement● Subsequent statements in the same session are executed aspart of this transaction– Statements see changes made by earlier ones in the sametransaction– Statements in other concurrently running transactions do not● COMMIT command commits the transaction– Its effects are made final and visible to subsequenttransactions● ROLLBACK command aborts the transaction– Its effects are undone
  • 4. Fine prints● Schema operations (e.g., CREATE TABLE)implicitly commit the current transaction– Because it is often difficult to undo a schemaoperation● Many DBMS support an AUTOCOMMITfeature, which automatically commits everysingle statement– You can it on/off through the API (e.g., JDBC)
  • 5. Atomicity● Partial effects of a transaction must be undone when– User explicitly aborts the transaction using ROLLBACK● E.g., application asks for user confirmation in the last step and issuesCOMMIT or ROLLBACK depending on the response– The DBMS crashes before a transaction commits● Partial effects of a modification statement must be undonewhen any constraint is violated– However, only this statement is rolled back; the transactioncontinues● How is atomicity achieved?– Logging (to support undo)
  • 6. Durability● Effects of committed transactions must surviveDBMS crashes● How is durability achieved?– Forcing all changes to disk at the end of everytransaction?● Too expensive: DBMS manipulates data in memory– Logging (to support redo)
  • 7. Consistency● Consistency of the database is guaranteed byconstraints and triggers declared in thedatabase and/or transactions themselves– Whenever inconsistency arises, abort thestatement or transaction, or (with deferredconstraint checking or application-enforcedconstraints) fix the inconsistency within thetransaction
  • 8. Isolation● Transactions must appear to be executed in a serialschedule (with no interleaving operations)● For performance, DBMS executes transactions using aserializable schedule– In this schedule, operations from different transactions caninterleave and execute concurrently– But the schedule is guaranteed to produce the same effectsas a serial schedule● How is isolation achieved?– Locking, multi-version concurrency control, etc.
  • 9. SQL isolation levels● Strongest isolation level: SERIALIZABLE– Complete isolation– SQL default (not always)● Weaker isolation levels: REPEATABLE READ,READ COMMITTED, READ UNCOMMITTED– Increase performance by eliminating overheadand allowing higher degrees of concurrency– Trade-off: sometimes you get the “wrong” answer
  • 10. READ UNCOMMITTED● Can read “dirty” data– A data item is dirty if it is written by an uncommitted transaction● Problem: What if the transaction that wrote the dirty dataeventually aborts?● Example: wrong average– -- T1: -- T2:UPDATE StudentSET GPA = 3.0WHERE SID = 142; SELECT AVG(GPA)FROM Student;ROLLBACK;COMMIT;
  • 11. READ COMMITTED● No dirty reads but non-repeatable reads possible– Reading the same data item twice can produce different results● Example: different averages– -- T1: -- T2:SELECT AVG(GPA)FROM Student;UPDATE StudentSET GPA = 3.0WHERE SID = 142;COMMIT;SELECT AVG(GPA)FROM Student;COMMIT;
  • 12. REPEATABLE READ● Reads are repeatable, but may see phantoms● Example: different average (still!)– -- T1: -- T2:SELECT AVG(GPA)FROM Student;INSERT INTO StudentVALUES(789, ‘Nelson’, 10, 1.0);COMMIT;SELECT AVG(GPA)FROM Student;COMMIT;
  • 13. Summary of SQL isolation levelsSyntax: At the beginning of a transactionSET TRANSACTION ISOLATION LEVELisolation_level;Dirty reads Non-repeatable reads PhantomsREAD UNCOMMITTEDREAD COMMITTED ImpossibleREPEATABLE READ Impossible ImpossibleSERIALIZABLE Impossible Impossible Impossible
  • 14. ANSI isolation levels are lock-based● READ UNCOMMITTED– Short-duration locks: lock, access, release immediately● READ COMMITTED– Long-duration write lock: do not release write locks until commit● REPEATABLE READ– Long-duration locks on all data items accessed● SERIALIZABLE– Lock ranges to prevent insertion as well
  • 15. An isolation level not based onlocksSnapshot isolation●Based on multiversion concurrency control●Available in Oracle, PostgreSQL, MS SQL Server, etc.●How it works– Transaction X performs its operations on a private snapshot of thedatabase taken at the start of X– X can commit only if it does not write any data that has been alsowritten by a transaction committed after the start of X●Avoids all ANSI anomalies●But is NOT equivalent to SERIALIZABLE because of write skewanomaly
  • 16. Bottom line● Group reads and dependent writes into atransaction in your applications– E.g., enrolling a class, booking a ticket● Anything less than SERIALABLE is potentiallyvery dangerous– Use only when performance is critical– READ ONLY makes weaker isolation levels a bitsafer