CSC 355 Database Systems

Transactions
As we study before…
A DML statement is executed when you:
– Add new rows to a table
– Modify existing rows in a table
– Remove existing rows from a table
Transactions
A transaction can be seen as a collection of DML statements that form a
logical unit of work.
 Problem: Interruptions
●
Two SQL statements are written to transfer
money from one bank account to another…
●
…one executes, then the server crashes
– What happens to the money?
 Problem: Concurrency
●
Two users check the balance of the same bank
account…
●
…then both try to transfer money out of it
– Who gets it?
 Solution: Transactions
●
A transaction is a collection of SQL statements that
must be executed as a unit
●
A database transaction consists of one of the
following:
– DML statements that constitute one consistent change to the
data.
– One DDL statement.
– One data control language (DCL) statement.
 Transactions
●
The Transaction manager in the DBMS must
handle
– Interruptions: Logging and recovery, Buffers
– Concurrency: Concurrency control, Lock tables
Components of a DBMS

From Ullman/Widom
 Transactions in Oracle
●
Any operation that changes the database state starts an
implicit transaction in Oracle
●
Transactions can be explicitly started with a SET
TRANSACTION statement
●
Transactions end with a COMMIT statement
●
Transaction can also be ended with ROLLBACK, usually
done by system rather than user…
 Transactions: Begin and End
●
A transaction begins when the first DML SQL statement is
executed.
●
A transaction ends with one of the following events:
– A COMMIT or ROLLBACK (w/o savepoint) statement is issued.
– A DDL or DCL statement executes (automatic commit).
– The user exits from ORACLE DB utilities and tools.
●
Applications should explicitly commit or undo.
– The system crashes.
 COMMIT & ROLLBACK
Advantages
With COMMIT and ROLLBACK statements, you
can:
●
Ensure data consistency.
●
Preview data changes before making changes
permanent.
●
Group logically-related operations.
 Explicit Transaction Control

Note: You cannot COMMIT to a SAVEPOINT. SAVEPOINT is not ANSI-standard SQL.

 Rolling Back Changes to a
Savepoint
●
Create a marker in the current transaction by
using the SAVEPOINT statement.
●
Roll back to that marker by using the
ROLLBACK TO SAVEPOINT statement.
 Implicit Transactions
●
An automatic commit occurs in the following
circumstances:
– A DDL statement is issued
– A DCL statement is issued
– Normal exit from SQLDeveloper, without explicitly issuing
COMMIT or ROLLBACK statements.
●
An automatic rollback occurs when there is an
abnormal termination of SQL Developer or a system
failure.
Sample Transaction
 State of the Data
Before COMMIT or ROLLBACK
●
The previous state of the data can be recovered.
●
The current user can review the results of the DML
operations by using the SELECT statement.
●
Other users cannot view the results of the DML
statements issued by the current user.
READ CONSISTENCY (users see data as last
commit)
●
The affected rows are locked; other users cannot
change the data in the affected rows.
 State of the Data
After COMMIT
●
Data changes are saved in the database.
●
The previous state of the data is overwritten.
●
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.
 State of the Data
After COMMIT - Example
-- Make the changes
DELETE FROM employees WHERE employee_id= 99999;
>> 1 rows deleted.
INSERT INTO departments
VALUES (290, 'Corporate Tax', NULL, 1700
>> 1 rows deleted.
-- Commit the changes
COMMIT;
●
A row is deleted from the employees table, and
●
A new row is inserted in the DEPARTMENTS table.
●
Changes are saved by using the COMMIT statement.
●
Before commit, no other user session can see the changes!
 State of the Data
After ROLLBACK
Discard all pending changes by using the
ROLLBACK statement:
●
Data changes are undone.
●
Previous state of the data is restored.
●
Locks on the affected rows are released.
 State of the Data
After ROLLBACK - Example
DELETE FROM test;
>> 25,000 rows deleted.
ROLLBACK;
>> Rollback complete.
DELETE FROM test WHERE id = 100;
>> 1 rows deleted.
SELECT * FROM test WHERE id = 100;
>> No rows selected.
COMMIT;
>> Commit complete.
●
When trying to delete one record from test, all data rows are deleted
by mistake
●
The error can be fixed by rolling back and executing the proper query
 Rollback Scope Level
●
If a single DML statement fails during execution, only that
statement is rolled back automatically.
●
Within a block or transaction, the rollback reaches until a
specified savepoint or last executed commit.
●
The user should terminate transactions explicitly by executing a
COMMIT or ROLLBACK statement.
●
The Oracle server issues an implicit commit before and after
any DDL or DCL statement.
 Transactions
●
A transaction...
●
Main issues: concurrency and interruptions
●
TCL commands: rollback, commit, etc.
●
Implicit transactions.
●
State of the Data.
●
Scope of the ROLLBACK command.
 Two more examples
●
Transaction Control
●
Rollback to Savepoint Example

From: Transactions (oracle.com)

 Read Consistency
●
Read consistency guarantees a consistent view
of the data at all times.
●
Changes made by one user do not conflict with
the changes made by another user.
●
Users access data in two ways:
Reading operations (SELECT)
Writing operations (INSERT, DELETE, UPDATE)
 Read Consistency
Read consistency ensures that, on the same data:
– Readers do not wait for writers
– Writers do not wait for readers
– Writers wait for writers

The purpose of read consistency is to ensure that

each user sees data as it existed at the last
commit, before a DML operation started.
 Transactions in Oracle
The basic transaction control commands are:

●
COMMIT, makes changes permanent
●
ROLLBACK, undoes changes
●
SAVEPOINT, which marks a savepoint in a
transaction
 Transactions
●
A transaction is a collection of SQL statements that
must be executed as a unit
●
Transactions have ACID properties:
– Atomicity
– Consistency
– Isolation
– Durability
 ACID Properties
●
A transaction should satisfy the following
properties:
– Atomicity: Executes completely or not at all
– Consistency: Satisfies all database constraints
– Isolation: Executes “separately” from others
– Durability: Once executed, results are permanent
 ACID Properties
●
Another way to look at these properties:
– Atomicity: Entire transaction takes places at once or it does not
happen at all
– Consistency: State of database consistent before and after
transaction
– Isolation: Multiple transactions happen independently with no
interference
– Durability: No data lost even if the system fails
 Atomicity
●
Transaction operations are kept in a local store, not applied
to the database immediately
– Transaction can see its own changes, others can’t
●
When a transaction is completed, COMMIT applies changes
to the shared database in their entirety (“executes
completely…”)
●
ROLLBACK during a transaction undoes any partial results
(“…or not at all”)
 Consistency
●
Constraints can be “deferred”, so that they are
only checked when a transaction commits, not
for each individual statement
– Add DEFERRABLE INITIALLY DEFERRED to the
constraint definition
– If a constraint is violated when you COMMIT, a
ROLLBACK of the entire transaction is done!
Data is consistent!
 Durability
●
After COMMIT, the changes applied to the
shared database are permanent, and cannot be
rolled back later.
Data is persistent!
 Isolation
●
DBMS maintains “separation” among
transactions that access data concurrently
– Various levels of isolation
– Tradeoffs between performance and data integrity
 Isolation Levels
●
SERIALIZABLE: Transactions must appear to run
serially – cannot read any changes from others
●
REPEATABLE READ: Can read committed changes that
only add data
●
READ COMMITTED: Can read all committed changes
●
READ UNCOMMITTED: Can read all changes,
committed and not committed
 Transactions in Oracle
●
SET TRANSACTION statement can specify
ISOLATION LEVEL
– READ COMMITTED (default)
– SERIALIZABLE
– Oracle does not support REPEATABLE READ and READ
UNCOMMITTED
●
COMMIT or ROLLBACK ends transaction
 Midterm Exam Information
●
Exam Wednesday, February 5th

●
Logistics
– In-person section, in-person in CDM 222

– 1 hour

– Online section schedule with OL Exam on D2L

– Closed book, no electronic devices

– You may use one 8.5”x11” sheet of original, handwritten notes for the exam (both sides)

– No typed, printed, or photocopied notes permitted

●
Everything cover in class and D2L material

●
Ullman/Widom Sections 1.1-1.3, 2.1-2.3, 4.1, 6.1-6.5, 7.1-7.3

●
Short answer questions, multiple choice, writing and/or evaluating SQL DDL/DML code and queries, etc.