Managing Data Concurrency

Data Concurrency & Consistency

Data Concurrency, which ensures that users can access data at the same time• Data Consistency, which ensures that each

user sees a consistent view of the data, including visible changes made by the user's own transactions and committed transactions of other users

Transaction & ACID

• Atomicity

• Consistency

• Isolation

• Durability

Atomicity

• All parts of a transaction are performed or none of them are.

• There are no partial transactions. • For example, if a transaction starts updating

100 rows, but the system fails after 20 updates, then the database rolls back the changes to these 20 rows.

Consistency

• The results of a query must be consistent with the state of the database at the time the query started.

• The transaction takes the database from one consistent state to another consistent state.

• The principle of consistency• requires that the database ensure that changed values are

not seen by the query• For example, in a banking transaction that debits a savings

account and credits a checking account, a failure must not cause the database to credit only one account, which would lead to inconsistent data

Isolation

• An incomplete (that is, uncommitted) transaction must be invisible to the rest of the world.

• The effect of a transaction is not visible to other transactions until the transaction is committed.

• only the one session that is executing the transaction is allowed to see the changes:

• all other sessions must see the unchanged data, not the new values.

For example, one user updating the HR.employees table does not see the uncommitted changes to employees made concurrently by another user. Thus, it appears to users as if transactions are executing serially.

Durability

• Once a transaction completes, it must be impossible for the database to lose it

• Changes made by committed transactions are permanent. A

• The instant the transaction completes, it must be broadcast to the world, and the database must guarantee that the change is never lost: a relational database is not allowed to lose data.

• After a transaction completes, the database ensures through its recovery mechanisms that changes from the transaction are not lost.

Basic DML

• Basic DML Statements– SELECT – INSERT– UPDATE– DELETE

• SELECT– Oracle reads block from Data File to DBBC– Fetch rows from UNDO if necessary

Execution of SELECT

Execution of SELECT

• Step 1 is the transmission of the SELECT statement from the user process to the server process. The server will search the database buffer cache to find if the necessary blocks are already in memory, and if they are, proceed to Step 4.

• If they are not, Step 2 is to locate the blocks in the datafiles• Step 3 is to copy them into the database buffer cache.• Step 4 transfers the data to the server process, where there

may be some further processing before • Step 5 returns the result of the query to the user process.

Executing an UPDATE

• For any DML operation, it is necessary to work on both data blocks and undo blocks, and also to generate redo

• the A, C, and I of the ACID test require generation of undo; the D requires generation of redo

• At 1st step, required blocks must be in DB cache.

• Also an empty block of UNDO segment.

Executing an UPDATE

• Locks are applied on affected rows• Redo is generated• Generation of REDO is applied both on data and

undo block– Row id and new value of the column(s) are written to

the log buffer– Old value to the undo block– If column is part of index than index changes are also

recorded• Updates are carried out in buffer cache

Executing an UPDATE

• During update is applied until the data is saved/committed :– Queries of other users to the data that is under

change will be redirected to UNDO segment– Only the session that is doing update can see the

change data

Executing an INSERT/DELETE

• Conceptually INSERT/DELETE are managed in same fashion

• A crucial difference between INSERT & DELETE is the amount of UNDO data.

• During INSERT only RowID of the new row is saved in undo block

• During DELETE whole row is copied in uno block.

COMMIT, ROLLBACK, SAVEPOINT

• Remember that if anything goes wrong, rollback of transactions in progress is completely automatic and is carried out by background processes.

• PMON will detect that there is a problem with the session, and roll back the transaction.

• If the server is rebooted while the database is in use, then on startup SMON will detect the problem and initiate a rollback of all active transactions

• DDL cannot be rolled back

Commit

• When you say COMMIT, all that happens physically is that LGWR flushes the log buffer to disk.

• DBWn does absolutely nothing.

Locking

• Locks prevent others session from updating data locked by some session

• Exclusive– The lock is held until the transaction is complete– If one row is updating, only that row will be locked rest of the

data will be available for change– Only one session can take exclusive lock at a time.

• Shared– Can be taken by many session at a time– Prevents another session from changing the table definition

with a DDL statement

Enqueue Mechanism

• Session will wait if the lock requested is already with another session

• Several sessions may be waiting for the lock of same row or object

• Oracle maintain a queue of requests according to the order of the request

• This is called enqueue mechanism

Locking

• SELECT FOR UPDATE– Select rows and lock them in exclusive mode

• SELECT FOR UPDATE WAIT 10

• SELECT FOR UPDATE NOWAIT

Lock Contention

• Session requests an object or row and cannot get it because of exclusive lock

• Deadlock is on form of Lock Contention• DBA is not responsible to prevent the lock

contention• Application program must control lock

contention

Causes of Lock Contention

• Long running transactions• Poorly written batch processes• SELECT FOR UPDATE• OR-0060 Error• Commit, Rollback or Kill sessions

Killing a User Session

Select sid, serial#, username from v$sessionWhere sid in (select BLOCKING SESSION from V$session);Alter system kill session ‘ ‘ immediate;

PL/SQL• PL/SQL is Oracle’s 3GL that runs within the oracle database• Provides procedural constructs like

– IF THEN– FOR WHILE

• Anonymous– Ad hoc code

• Stored – Stored in database in data dictionary– Procedure– Function– Package– Trigger

Anonymous

declare increase number :=10;beginupdate emp set salary=salary *(100+increase)/100;commit;end;/The above code will increase the salary of employee according to the values of increase variable.

Stored

create procedure sal_rise(increase number) asbeginupdate emp set salary=salary *(100+increase)/100;commit;end;Execcute sal_rise(10);The above code will increase the salary of employee according to the values of increase variable.

PL/SQL Objects

• Procedure• Function• Package• Trigger

Procedure

• A piece of code which optional accepts arguments and perform some task.

• Arguments can be IN OUT, IN-OUT– IN parameter used to pass data to procedure– Out parameter used to send out data from

procedure– Arguments can be IN-OUT

Procedure

• Example• CREATE TABLE tbl_int (c1 number);• CREATE OR REPLACE PROCEDURE ins_val (v1 in

number) as begin• For i in 1..v1 loop• Insert into tbl_int values (v1);• end loop;• End ins_val;• /

Function

• Similar to procedure but does not have OUT arguments

• Function returns a value with RETURN statement

• EXECUTE statement is not used to invoke a FUNCTION

Function

• Create or replace function even_odd (v1 number) return varchar2

• as begin• if mod (v1,2) =0 then• return ‘even’;• else• return ‘odd’;• end if;• end even_odd;

Package

• A package is used to group related procedures and functions

• A package has– Specification– Body

Package Example

create or replace package numbers as function odd_even(v1 number) return varchar2;procedure ins_ints(v1 in number);end numbers; /

Triggers

• Database triggers are a special category of PL/SQL object, in that they cannot be invoked manually.

• A trigger runs (or “fires”) automatically, when a particular action is carried out, or a certain situation arises; this is the triggering event.

Example

• create or replace trigger old_emp• before delete on emp• for each row• begin• pro_old_emp(:old.employee_id);• end;