Managing Data Concurrency and Consistency

7/25/2019 Managing Data Concurrency and Consistency

1/6

PART 9Data Concurrency and Consistency

Data concurrency means that many users can access data at the same time. Data

consistency means that each user sees a consistent view of data, including visiblechanges made by the users own transactions and transactions of other users.

Oracle Database oers two isolation levels, providing application developers withoperational modes that preserve consistency and provide high performance.

These isolation levels are dened in terms of three phenomena that must beprevented between concurrently executing transactions. The three preventablephenomena are

Dirty reads:a transaction reads data that has been written by anothertransaction that has not been committed yet

Fuzzy reads (nonrepeatable):a transaction rereads data it has previously

read and nds that another committed transaction has modied or deletedthe data Phantom reads:a transaction re!runs a "uery returning a set of rows that

satises a search condition and nds that another committed transaction hasinserted additional rows that satisfy the condition

Isolation Level Dirty ReadNonrepeatableRead

PhantomRead

Readuncommitted

#ossible #ossible #ossible

Read committed $ot possible #ossible #ossible

Repeatable read$ot possible$ot possible #ossible

Serializable $ot possible$ot possible $ot possible

vervie! o" Loc#in$ %echanisms%ultiuser databases use some form of data loc&ing to solve the problems associatedwith data concurrency, consistency, and integrity. Loc#s are mechanisms thatprevent destructive interaction bet!een transactions accessin$ the sameresource&

'esources include two general types of ob(ects

)ser ob(ects, such as tables and rows

*ystem ob(ects not visible to users, such as shared data in the memory anddata dictionary rows


2/6

%ultiversion 'oncurrency 'ontrolOracle provides read consistency to a "uery based on statementlevel readconsistencyand transactionlevel read consistency+to all the "ueries in atransaction.

To achieve that, Oracle uses the information maintained in its )ndo -nformation

+'ollbac& segments to provide these consistent views. The undo segmentsrollbac&segments contain the old values of data that have been changed by uncommittedor recently committed transactions.

hen the *uery read data !hich is has chan$ed !ith or !ithout commit byothers transaction+ the *uery read data "rom undo se$ments,rollbac#se$ments&

StatementLevel Read 'onsistencyOracle always enforces statement!level read consistency. /ll the data returned by asingle "uery comes from a sin$le point in time, its the time that the "ueryexecuted. *o, a "uery never sees dirty data or any of the changes made bytransactions that commit during "uery execution.

nly data committed be"ore the *uery be$an is visible to the *uery& -he*uery does not see chan$es committed a"ter statement e.ecution be$ins&

This consistency enforced to a *0102T, -$*0'T, )#D/T0 and D010T0 "uery +D%1

$ote

-f a *0102T list contains a function, then the database appliesstatement!level read consistency at the statement level for *31 runwithin the #1*31 function code, rather than at the parent *31 level. 4orexample, a function could access table whose data is changed andcommitted by another user. 4or each execution of the *0102T in the

-ransactionLevel Read 'onsistencyOracle also oers the option of enforcing transaction!level read consistency.

5hen a transaction runs in serializablemode, all data accesses re6ect the state ofthe database as of the time the transaction began. Thus, the data seen by all"ueries within the same transaction is consistent with respect to a *ingle #oint in

Time.

Transaction!level read consistency produces repeatable reads and does not exposea "uery to phantoms

racle Isolation LevelsOracle also oers the option of enforcing

IsolationLevel

Description

Read -his is the de"ault transaction isolation level&


3/6

committed 0ach "uery executed by a transaction sees only data that wascommitted before the "uery began. Oracle never reads dirty data+uncommitted data.2an experience nonrepeatable read and phantoms

Serializable *ee only those changes that were committed at the time thetransaction began, plus those changes made by the transaction

itself through -$*0'T, )#D/T0, and D010T0 statements. 'an note.perience nonrepeatable read and phantoms&)sing undo segmentsrollbac& segmentes to provide someinformation needed

Readonly *ee only those changes that were committed at the time thetransaction began and do not allow -$*0'T, )#D/T0 and D010T0statements.

Set the Isolation Levelyou can set the isolation level of a transaction by using one of these statements atthe beginning of a transaction

*0T T'/$*/2T-O$ -*O1/T-O$ 10701 '0/D 2O%%-TT0D8

*0T T'/$*/2T-O$ -*O1/T-O$ 10701 *0'-/1-9/:108*0T T'/$*/2T-O$ '0/D O$1;8

)se /1T0' *0**-O$ statement to set the transaction isolation level for allsubse"uent transactions

/1T0' *0**-O$ *0T -*O1/T-O$able

transaction began

O'/!?@ABB 2annot seriali>e access for this transaction

5hen seriali>able transaction fails with the 2annot *eriali>e /ccess 0rror, theapplication can ta&e any of several actions

2ommit the wor& executed to that point


4/6

0xecute additional +but dierent statements +perhaps after rolling bac& to asavepoint established earlier in the transaction

)ndo the entire transaction

'omparison o" Read 'ommitted and Serializable Isolation (Loc#'ontention)both read committed and seriali>able isolation levels provide a high degree ofconsistency and concurrency.

This section includes the following topics

Transaction set consistency

'ow!level loc&ing

'eferential integrity

Distributed transactions

/n operation +"uery or transaction is transaction set consistent if all its readsreturn data written by the same set of committed transactions.

/n operation is not set consistent if some reads re6ect the changes of one set oftransaction and other reads re6ect changes made by other transactions.

/n operation that is not transaction set consistent in eect sees the database in astate that re6ects no single set of committed transactions.

racle provides transactions e.ecutin$ in read committed mode !ithtransaction set consistency "or each statement& Serializable modeprovides transaction set consistency "or each transaction&

Ro!level Loc#in$both read committed and serializable transactions use ro!level loc#in$+and both !ill !ait i" they try to chan$e a ro! updated by an uncommittedconcurrent transaction&

The second transaction that tries to update a given row waits for the othertransaction to commit or undo and release its loc&. -f that other transaction rollsbac&, the waiting transaction, regardless of its isolation mode, can proceed tochange the previously loc&ed row as if the other transaction had not existed.

Cowever, if the other bloc&ing transaction commits and release its loc&s, a readcommitted transaction proceeds with its intended update. / seriali>able transaction

will fails with the error 'annot Serialize /ccess 0rror, because the othertransaction has committed a change that was made since the seriali>abletransaction began.

Re"erential Inte$rity:ecause oracle does not use read loc&s in either read!consistent or seriali>abletransactions, data read by one transaction can be overwritten by another.


5/6

$ote

;ou can use both read committed and seriali>able transaction isolationlevels with Oracle '/2.

Distributed -ransactionsin a distributed database environment, a given transaction updates data in multiplephysical database protected by two!phase commit to ensure all nodes or noncommit. -n this environment, all servers, whether oracle or non!oracle, thatparticipate in a seriali>able transaction are re*uired to support serializableisolation mode. -f not, it will raise an error.

The transaction can undo and retry only when the remote server does supportseriali>able transactions. -n contrast, read committed transactions can performdistributed transactions with servers that do not support seriali>able transactions.

$ote Transaction containing D%1 statements with sub"ueries should use

seriali>able isolation to guarantee consistent read.

1o! racle Database Loc#s Data1oc&s are mechanisms that prevent destructive interaction between transactionsaccessing the same resource. Oracle automatically obtains necessary loc&s whenexecuting *31 statements.racle loc#in$ is "ully automatic and re*uires nouser action+ so the database users never need to loc# any resourcee.plicitly&

%odes o" Loc#in$Oracle uses two modes of loc&ing in a multiuser database:

Loc#in$%ode

Description

0.clusiveloc#

#revents the associated resource from being shared. This loc&mode is obtained to modify data. The rst transaction to loc& aresource exclusively is the only transaction that can alter theresource until the exclusive loc& is released

Share loc# /llows the associated resource to be shared. %ultiple users

reading data can share the data, holding share loc&s to preventconcurrent access by a writer. *everal transactions can ac"uireshare loc&s on the same resource

Deadloc#sDeadloc&s can occur when two or more users are waiting for data loc&ed by eachother. Deadloc&s prevent some transactions from continuing to wor&.


6/6

Oracle automatically detects deadloc& situations and resolves them by rolling bac&one of the statements involved in the deadloc&, thereby releasing one set of thecon6icting row loc&s. The statement rolled bac& is the one belonging to thetransaction that detects the deadloc&.

$ote

-n distributed transactions, local deadloc&s are detected by analy>ingwait data, and global deadloc&s are detected by a time out. Onedetected, nondistributed and distributed deadloc&s are handled by the

/void Deadloc#sDeadloc&s can usually be avoided if transactions accessing the same table loc&those tables in the same order, either through implicit or explicit loc&s.

-ypes o" Loc#sOracle loc&s fall into one of three general categories shown below

Loc# DescriptionD%L loc#s (dataloc#s)

D%1 loc&s protect data, for example table loc&s loc&entire tables, row loc&s loc& selected rows

DDL loc#s (dictionaryloc#s)

DD1 loc&s protect the structure of schema ob(ects, forexample the denitions of tables and views

Internal loc#s and

latches

-nternal loc&s and latches protect internal database

structures such as datales. -nternal loc&s and latchesare entirely automatic

Documents

Managing Data Concurrency and Consistency