Oracle Transaction
Oracle Transaction
1. What Is a Transaction?
2. How To Start a New Transaction?
3. How To End the Current Transaction?
4. How To Create a Test Table for Transaction Testing?
5. How To Commit the Current Transaction?
6. How To Rollback the Current Transaction?
7. What Happens to the Current Transaction If a DDL Statement Is Executed?
8. What Happens to the Current Transaction If the Session Is Ended?
9. What Happens to the Current Transaction If the Session Is Killed?
10. How Does Oracle Handle Read Consistency?
11. What Is a READ WRITE Transaction?
12. What Is a READ ONLY Transaction?
13. How To Set a Transaction To Be READ ONLY?
14. What Are the Restrictions in a READ ONLY Transaction?
15. What Are the General Rules on Data Consistency?
16. What Are Transaction Isolation Levels Supported by Oracle?
17. What Is a Data Lock?
18. How Data Locks Are Respected?
19. How To Experiment a Data Lock?
20. How To View Existing Locks on the Database?
21. What Is a Dead Lock?
22. How Oracle Handles Dead Locks?
What Is a Transaction?
A transaction is a logical unit of work requested by a user to be applied to the database objects.
Oracle server introduces the transaction concept to allow users to group one or more SQL
statements into a single transaction, so that the effects of all the SQL statements in a transaction
can be either all committed (applied to the database) or all rolled back (undone from the
database).
There is no SQL statement to explicitly start a new transaction. Oracle server implicitly starts a
new transaction with the following two conditions:
The first executable statement of a new user session will automatically start a new
transaction.
The first executable statement after a previous transaction has been ended will
automatically start a new transaction.
Running the COMMIT statement will explicitly end the current transaction.
Running the ROLLBACK statement will explicitly end the current transaction.
Running any DDL statement will implicitly end the current transaction.
Disconnecting a user session will implicitly end the current transaction.
Killing a user session will implicitly end the current transaction.
If you want to practice DML statements, you should create a testing table as shown in the script
below:
You should keep this table for to practice other tutorial exercises presented in this collection.
If you have used some DML statements updated some data objects, and you want to have the
updates to be permanently recorded in the database, you can use the COMMIT statement. It will
make all the database changes made in the current transaction become permanent and end the
current transaction. The following tutorial exercise shows you how to use COMMIT statements:
SQL> COMMIT;
Commit complete.
If you have used some DML statements updated some data objects, you find a problem with
those updates, and you don't want those updates to be permanently recorded in the database, you
can use the ROLLBACK statement. It will remove all the database changes made in the current
transaction and end the current transaction. The following tutorial exercise shows you how to use
ROLLBACK statements:
SQL> ROLLBACK;
Rollback complete.
As you can see, the two new records inserted into the table were removed by the ROLLBACK
statement.
If a DDL statement is executed, the current transaction will be committed and ended. All the
database changes made in the current transaction will become permanent. This is called an
implicit commit by a DDL statement. The following tutorial exercise shows you that the
CREATE TABLE statement forced the current transaction to be committed and ended. The
subsequent ROLLBACK statement has no effects on the closed transaction.
SQL> ROLLBACK;
Rollback complete.
If a session is ended, the current transaction in that session will be committed and ended. All the
database changes made in the current transaction will become permanent. This is called an
implicit commit when session is ended. The following tutorial exercise shows you that the
"disconnect" command forces the current transaction to be committed and ended. When the
session is reconnected, you can see the changes made by the UPDATE statements.
SQL> disconnect
SQL> connect HR/fyicenter
Keep the "HR" SQL*Plus window as is, and open another window to run another instance of
SQL*Plus.
As you can see, two records were rolled back as the session got killed by another session.
Oracle supports two options for you on how to maintain read consistency:
READ WRITE (the default option), also called statement-level read consistency.
READ ONLY, also called transaction-level read consistency.
A READ WRITE transaction is a transaction in which the read consistency is set at the statement
level. In a READ WRITE transaction, a logical snapshot of the database is created at the
beginning of the execution of each statement and released at the end of the execution. This
guaranties that all reads within a single statement get consistent data from the database.
For example, if you have a query statement that takes 10 minutes to be executed, a snapshot of
the database will be created for this statement for 10 minutes. If a subquery is used in this
statement, it will get the consistent data no matter when it gets executed within this 10 minutes.
In another word, data changes made during this 10 minutes by other users will not impact the
execution of this query statement.
A READ ONLY transaction is a transaction in which the read consistency is set at the
transaction level. In a READ ONLY transaction, a logical snapshot of the database is created at
the beginning of the transaction and released at the end of the transaction. This guaranties that all
reads in all statements within this transaction get consistent data from the database.
For example, if you have a transaction with many statements that takes 10 hours to be executed,
a snapshot of the database will be created for this transaction for 10 hours. If a query statement is
executed at the beginning of the transaction and at the end of the transaction, it will return the
same result guarantied. In another word, data changes made during this 10 hours by other users
will not impact the execution of statements within this transaction.
Oracle Tutorials - Set a READ ONLY Transaction
If you want a transaction to be set as READ ONLY, you need to the transaction with the SET
TRANSACTION READ ONLY statement. Note that a DML statement will start the transaction
automatically. So you have to issue the SET TRANSACTION statement before any DML
statements. The tutorial exercise below shows you a good example of READ ONLY transaction:
Keep the "HR" SQL*Plus window as is, and open another window to run another instance of
SQL*Plus.
SQL> COMMIT;
Commit complete.
SQL> COMMIT;
Commit complete.
SQL> SELECT * FROM fyi_links;
ID URL NOTES COUNTS CREATED
------- ---------------- ---------- ---------- ---------
101 FYICENTER.COM 07-MAY-06
110 CENTERFYI.COM 07-MAY-06
As you can see that two records were deleted from another session after the HR session started
the READ ONLY transaction. The deleted records was not impacting any query statements until
the transaction was ended with the COMMIT statement.
READ COMMITTED (the default option). If the transaction contains DML that requires
row locks held by another transaction, then the DML statement waits until the row locks
are released.
SERIALIZABLE. If a serializable transaction contains data manipulation language
(DML) that attempts to update any resource that may have been updated in a transaction
uncommitted at the start of the serializable transaction, then the DML statement fails.
A data lock is logical flag the Oracle server is placed on data objects to give an exclusive right to
a transaction. Statements in other transactions needs to respect data locks based on certain rules.
Rules on data locks are:
(session 1)
SQL> connect HR/fyicenter
(session 2)
SQL> connect HR/fyicenter
SQL> COMMIT;
(lock on row id=101 released)
(ready to run UPDATE)
1 row updated.
SQL> COMMIT;
As can see from the pervious tutorial exercise, performance of the second session is greatly
affected by the data lock created on the database. To maintain a good performance level for all
sessions, you need to monitor the number of data locks on the database, and how long do they
last.
Oracle maintains current existing data locks in a Dynamic Performance View called V$LOCK
with columns like:
The following tutorial exercise shows you how to view existing locks on the database:
(session 1)
SQL> connect HR/fyicenter
Now keep those two sessions as is. You need to open a third window to connect to the database
as SYSTEM to view all current locks:
(session 3)
SQL> connect SYSTEM/password
SQL> select sid, username from v$session
2 where username='HR';
SID USERNAME
---------- ------------------------------
23 HR
39 HR
Line #1 and #2 represent the lock resulted from the UPDATE statement in session #1 on
row id=110.
Line #3 and #4 represent the lock resulted from the INSERT statement in session #2 on
row id=112.
Line #5 represents a request of lock resulted from the UPDATE statement in session #2
on row id=110, which is blocked by the lock from line #1 and #2.
A dead lock is phenomenon happens between two transactions with each of them holding a lock
that blocks the other transaction as shown in the following diagram:
(transaction 1) (transaction 2)
update row X to create lock 1
update row Y to create lock 2
update row X
(blocked by lock 1)
update row Y
(blocked by lock 2)
Oracle server automatically detects dead locks. When a dead lock is detected, Oracle server will
select a victim transaction, and fail its statement that is blocked in the dead lock to break the
dead lock. The tutorial exercise below shows you an example of statements failed by Oracle
server because of dead locks:
(session 1)
SQL> connect HR/fyicenter
ORA-00060: deadlock
detected while waiting
for resource
(statement failed)