TRANSACTIONS REDO AND UNDO DATABASE TABLES

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



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



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



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


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


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


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


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


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


Atomicity

dbms_output.put_line( 'I fired and updated ' ||

sql%rowcount || ' rows' );

end;

Trigger created.

11


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


Atomicity

insert into t values (1);

I fired and updated 1 rows

1 row created.

insert into t values(-1);


insert into t values(-1)

*

ERROR at line 1:

ORA-02290: check constraint (OPS$TKYTE.SYS_C0018095) violated

select * from t2;

CNT

----------

1

13


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


Atomicity

if we run that stored procedure:

begin

p;

end;



begin

*

ERROR at line 1:

15


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


Atomicity

Oracle treated the stored procedure call as an atomic

statement

17


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


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


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


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


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


Durability

Asynchronous commits are applicable only to

batch-oriented applications, those that are

automatically restartable upon failure.

23


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


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


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


Redo and Undo

Undo, unlike redo, is stored internally in the

database in a special set of segments known as

undo segments.

27


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


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


Database Tables

Index clustered tables

30


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


Database Tables

Hash clustered tables:

32


Documents

TRANSACTIONS REDO AND UNDO DATABASE TABLES