transactions redo and undo database tables
TRANSCRIPT
TRANSACTIONS – REDO AND
UNDO – DATABASE TABLES
Prepared By: L. Huyam Al-Amro
LECTURE 10
What is a Transaction?
A transaction is a logical, atomic unit of work that
contains one or more SQL statements.
A transaction groups SQL statements so that they
are either all committed, which means they are
applied to the database, or all rolled back, which
means they are undone from the database.
Oracle Database assigns every transaction a unique
identifier called a transaction ID.
2
Prepared By: L. Huyam Al-Amro
What is a Transaction?
the main purpose of transactions: they take the
database from one consistent state to the next.
When you commit work in the database, you are
assured that either all of your changes, or none of
them, have been saved.
Oracle transactions can provide consistent data
every time, under highly concurrent data access
conditions.
3
Prepared By: L. Huyam Al-Amro
What is a Transaction?
All Oracle transactions comply with the basic
properties of a database transaction, known as
ACID properties. ACID is an acronym for the
following:
Atomicity: Either all of a transaction happens or none
of it happens.
Consistency: A transaction takes the database from
one consistent state to the next.
4
Prepared By: L. Huyam Al-Amro
What is a Transaction?
Isolation: The effects of a transaction may not be
visible to other transactions until the transaction has
committed.
Durability: Once the transaction is committed, it is
permanent.
5
Prepared By: L. Huyam Al-Amro
Transaction Control Statements
The various transaction control statements available to
us:
COMMIT: To use this statement’s simplest form, you
just issue COMMIT. A COMMIT ends your transaction
and makes any changes permanent (durable).
ROLLBACK: To use this statement’s simplest form,
you just issue ROLLBACK. A rollback ends your
transaction and undoes any uncommitted changes.
6
Prepared By: L. Huyam Al-Amro
Transaction Control Statements
SAVEPOINT: A SAVEPOINT allows you to create a
marked point within a transaction. You may have
multiple SAVEPOINTs within a single transaction.
7
Prepared By: L. Huyam Al-Amro
Atomicity
Statement-Level Atomicity
Consider the following example, where an INSERT or
DELETE on table T fires a trigger that adjusts the CNT
column in table T2 appropriately:
8
Prepared By: L. Huyam Al-Amro
Atomicity
create table t2 ( cnt int );
Table created.
insert into t2 values ( 0 );
1 row created.
commit;
Commit complete.
create table t ( x int check ( x>0 ) );
Table created.
9
Prepared By: L. Huyam Al-Amro
Atomicity
create trigger t_trigger
before insert or delete on t for each row
begin
if ( inserting ) then
update t2 set cnt = cnt +1;
else
update t2 set cnt = cnt -1;
end if;
10
Prepared By: L. Huyam Al-Amro
Atomicity
dbms_output.put_line( 'I fired and updated ' ||
sql%rowcount || ' rows' );
end;
Trigger created.
11
Prepared By: L. Huyam Al-Amro
Atomicity
We don’t want the CNT column in T2 to be
incremented if a row is not actually inserted into T.
Fortunately in Oracle, the original statement from
the client—INSERT INTO T, in this case—either
entirely succeeds or entirely fails. This statement is
atomic. We can confirm this, as follows:
12
Prepared By: L. Huyam Al-Amro
Atomicity
insert into t values (1);
I fired and updated 1 rows
1 row created.
insert into t values(-1);
I fired and updated 1 rows
insert into t values(-1)
*
ERROR at line 1:
ORA-02290: check constraint (OPS$TKYTE.SYS_C0018095) violated
select * from t2;
CNT
----------
1
13
Prepared By: L. Huyam Al-Amro
Atomicity
Procedure-Level Atomicity
Consider the same previous example, with the following procedure P:
create or replace procedure p
as
begin
insert into t values ( 1 );
insert into t values (-1 );
end;
Procedure created.
14
Prepared By: L. Huyam Al-Amro
Atomicity
if we run that stored procedure:
begin
p;
end;
I fired and updated 1 rows
I fired and updated 1 rows
begin
*
ERROR at line 1:
15
Prepared By: L. Huyam Al-Amro
Atomicity
ERROR at line 1:
ORA-02290: check constraint (OPS$TKYTE.SYS_C0018095) violated
ORA-06512: at "OPS$TKYTE.P", line 5
ORA-06512: at line 2
select * from t;
no rows selected
select * from t2;
CNT
----------
0
16
Prepared By: L. Huyam Al-Amro
Atomicity
Oracle treated the stored procedure call as an atomic
statement
17
Prepared By: L. Huyam Al-Amro
Atomicity
Transaction-Level Atomicity
The entire goal of a transaction, a set of SQL
statements executed together as a unit of work, is to
take the database from one consistent state to
another consistent state.
To accomplish this goal, transactions are atomic as
well—the entire set of successful work performed
by a transaction is either entirely committed and
made permanent or rolled back and undone.
18
Prepared By: L. Huyam Al-Amro
Atomicity
Upon receipt of “success” from the database after
committing a transaction, you know that all of the
work performed by the transaction has been made
persistent.
19
Prepared By: L. Huyam Al-Amro
Durability
Normally, a COMMIT is a synchronous process: your
application invokes COMMIT and then your
application waits for the entire COMMIT processing
to be complete.
When a transaction is committed, its changes are
permanent—you can rely on those changes being in
the database even if the database crashed the
instant after the commit completed.
20
Prepared By: L. Huyam Al-Amro
Durability
Since the commit may take measurable timebecause it involves a physical write to the redo logfiles stored on disk, you may have the commitperformed in the background, without waiting for it.
Starting with Oracle Database 10g Release 2 andabove, you may add a WRITE clause to yourCOMMIT statements.
The WRITE clause allows the commit to either WAITfor the redo you generated to be written to disk(the default) or NOWAIT for the redo to be written.
21
Prepared By: L. Huyam Al-Amro
Durability
If you make the COMMIT asynchronous by using
COMMIT WRITE NOWAIT, you remove the need to
wait for that physical I/O in the client application.
That comes with the side-effect that your commit is
no longer assured to be durable.
So, any application that does interact with a person,
that reports to the person “commit complete,” should
use the synchronous commit.
22
Prepared By: L. Huyam Al-Amro
Durability
Asynchronous commits are applicable only to
batch-oriented applications, those that are
automatically restartable upon failure.
23
Prepared By: L. Huyam Al-Amro
Redo and Undo
The two most important pieces of data in an Oracle
database: redo and undo.
Redo is the information Oracle records in online (and
archived) redo log files in order to “replay” your
transaction in the event of a failure.
Undo is the information Oracle records in the undo
segments in order to “reverse, or roll back”, your
transaction.
24
Prepared By: L. Huyam Al-Amro
Redo and Undo
What Is Redo?
Redo log files are crucial to the Oracle database.
These are the transaction logs for the database.
Oracle maintains two types of redo log files: online
and archived.
They are used for recovery purposes; their purpose in
life is to be used in the event of an instance or
media failure. (This topic has been covered in Lecture-7)
25
Prepared By: L. Huyam Al-Amro
Redo and Undo
What Is Undo?
Undo information is generated by the database as
you make modifications to data so that the data
can be put back the way it was before the
modifications took place.
Whereas redo is used to replay a transaction in the
event of failure—to recover the transaction—undo
is used to reverse the effects of a statement or set
of statements.
26
Prepared By: L. Huyam Al-Amro
Redo and Undo
Undo, unlike redo, is stored internally in the
database in a special set of segments known as
undo segments.
27
Prepared By: L. Huyam Al-Amro
Database Tables
Types of Tables
There are nine major types of tables in Oracle, wewill list four of them as follows:
Oracle Heap organized tables: These are normal,standard database tables. Data is managed in aheap-like fashion. As data is added, the first freespace found in the segment that can fit the data willbe used. As data is removed from the table, itallows space to become available for reuse bysubsequent INSERTs and UPDATEs.
28
Prepared By: L. Huyam Al-Amro
Database Tables
Index organized tables (IOTs) : These tables are
stored in an index structure. This imposes physical
order on the rows themselves. The data is stored in
sorted order, according to the primary key.
Index clustered tables: Clusters are groups of one or
more tables, physically stored on the same database
blocks, with all rows that share a common cluster key
value being stored physically near each other.
29
Prepared By: L. Huyam Al-Amro
Database Tables
Index clustered tables
30
Prepared By: L. Huyam Al-Amro
Database Tables
Hash clustered tables: These tables are similar to
index clustered tables, but with one main exception:
the cluster key index is replaced with a hash
function.
- The hash cluster hashes the key of a row using a
function to arrive at the database block the data
should be on.
31
Prepared By: L. Huyam Al-Amro
Database Tables
Hash clustered tables:
32
Prepared By: L. Huyam Al-Amro