Part 2_Operational Issues (Use) (2)

8/6/2019 Part 2_Operational Issues (Use) (2)

1/22

Operational Issues(Part 2)

Concurrency Controls

Recovery in databases


2/22

Concurrency control Concurrency control refers to the

coordination (or synchronization) ofexecution of multiple transactions in a multi-user database environment.

The DBMS must provide concurrency controlto prevent problems associated withconcurrent processing of transactions.

The purpose of concurrency control is toensure that data in the database is notcompromised when several transactions

access the database simultaneously. There are three problems that may occur

when concurrency control is not established,which is lost updates, uncommitted data andinconsistent retrievals.


3/22

Lost Updates

One of the problems that can arise whenmultiple users attempt to access data withoutproper concurrency control is lost updates.

To illustrate lost updates lets consider anaccount table where one of the attributes is

the customers balance. Lets assume the customers balance is $500.

Suppose if now two concurrent transactions T1and T2 attempt to update the balance at thesame time.

Lets assume T1 want to add $200 and T2wants to withdraw $100 as shown below:

Transaction Action Computation

T1 Deposit 200 Balance = 500 + 200 (Balance = 700)

T2 Withdraw 100 Balance = 700 100 (Balance = 600)


4/22

Uncommitted Data

Processing two transactions concurrently maylead to uncommitted data.

Data are not committed when two transactionsT1 and T2 are executed concurrently, and thefirst transaction (T1) is rolled back after the

second transaction (T2) has already accessedthe uncommitted data, thus violating theisolation property of transactions.

To illustrate, lets consider the following scenariowhere T1 is rolled back

Transaction Action ComputationT1 Deposit 200 Balance = 500 + 200 (Rolled back)

T2 Withdraw 100 Balance = 500 100 (Balance = $400)


5/22

Inconsistent retrieval

An inconsistent retrieval occurswhen a transaction calculatesan aggregate or summary

function (e.g., SUM) over a setof data, which the othertransactions are updating.

The inconsistency occursbecause the transaction may

read some data before theyare changed and read otherdata afterthey are changed.


6/22

Basically there are three basic approaches toconcurrency control: locking, time stamping

and versioning. Locking

In locking, if one user updates the data, allother users are denied access until theupdate is completed (or aborted).

Time Stamping In time stamping, a unique global time

stamp is assigned to each transaction. Transactions are submitted to the DBMS

based on the value of time stamps

Optimistic Approach (Versioning)

The optimistic approach is based on theassumption that most of the time thetransactions do not conflict.

This approach does not require locking ortime stamping. A transaction is executedwithout restrictions until it is committed.


7/22

Locking can take place at the

following levels: Database Level. The entire database is locked and becomes

unavailable to other users. This level may beused during backup or in batch systems. Butfor online, multi-user applications, this

approach cannot be tolerated. It is toorestrictive and will database performanceadversely.

Table Level. The entire table containing the requested

record is locked. This level may be used

when the entire table or when most of therecords need to be updated such as whenyou want to reduce the price of all items by12%. If the application requires access onlyto a single record, this level will also be veryrestrictive.


8/22

Page Level.

The operating system loads pages intomemory as and when they are needed. Apage has a fixed size such as 4K (or multiplesof it). The number of records that can fit intoa page will depend on the size of therecord. A table typically spans several

pages, and a page spans several records(rows). When a page is locked, other usersare denied access to the records in thatpage. This is currently the most widely usedlocking method in a multi-user databaseenvironment.

Row Level. Only the requested record (or row) is locked.

All other records are available to other users.Although this level gives better performance,it requires high overhead since it requires alock foreach row in the table.


9/22

Field Level.

Only the particular field (orcolumn) in a requested record islocked. This level may be

appropriate when most updatesaffect only one or two fields in arecord. For example, in a inventorycontrol applications, the quantity-on-hand field changes frequently,

but other fields (such as descriptionand bin location) are rarelyupdated. Field-level locks requireconsiderable overhead and areseldom used.


10/22

Time stamping

A time stamp has two properties: Uniqueness every transaction has a different

time stamp.

Monotonicity the time stamp values alwaysincrease.

All database operations within the sametransaction are assigned the same time stamp.

The DBMS will execute any conflictingtransactions in time stamp order, therebyensuring serializability of transactions.

In the case of conflict, one of the transactions isaborted and rescheduled with a different timestamp.

One of the disadvantages of using timestamping is that it increases the processing andmemory overhead.


11/22

Optimistic Approach (Versioning)

In this approach, each transaction movesthrough two or three phases:read, validationand write.

Read phase. In this phase, the transaction reads the data item,

performs the necessary computation, and storesthe result in a private copy (which is notaccessible to other transactions).

Validation phase. In this phase, the transaction is validated to make

sure that the changes made do not violatedatabase consistency and integrity requirements.

If the transaction passes the validation test, thetransaction moves to the write phase. If not, thechanges are discarded and the transaction isrestarted.

Write phase. This phase commits the changes to the database,

i.e., the changes are updated.


12/22

Data recovery and back-up

Recovery from transaction failuresusually means that the database isrestored to some state from the pastso that a correct state close to thetime of failure can bereconstructed from that past state.

To do this, the system must keepinformation about changes to data

items during transaction executionoutside the database.

This information is typically kept inthe system log.


13/22

Four most common types of errors are abortedtransactions, incorrect data, system failure

and database destruction, which are: Aborted transaction.

A transaction normally requires a sequenceof processing steps such as reading,computing and writing.

The transaction may be aborted at any ofthese steps and this may result in errors.

To correct these errors, the system mustrollback by undoing the steps for thattransaction.

If files had been updated, the system mustundo the steps so that the data in the files areresorted to their former state.


14/22

Incorrect data. This refers to updating a database correctly

but with incorrect data. This type of error is more difficult to detectuntil someone notices and reports the error.

Furthermore, some time may have elapsedbefore the error is actually detected. Usersmay have actually used or transmitted theincorrect data and this can be a problem.

If the errors are few, they may be correctedwith compensating transactions.

System failure. This may occur anytime due to any number

of reasons (e.g., power failure, disk crash). To recover from this failure, the system is rolled

back to the most recent checkpoint, andthen restarted using the after-images for alltransactions that were processed after thatcheckpoint.


15/22

Database destruction.

Parts of a database or even an entiredatabase may be destroyed or

become corrupted (e.g., due to diskcrash or virus).

In this case the database itself mustbe restored. This usually accomplishby using backup copies.

That means organizations mustalways make backup copies of alltheir critical files.


16/22

There are several approaches one can use torecovery from system failures:

Backup Facilities The backup facility in a DBMS provide periodical

copies of portion of or the entire database.

The frequency of the backup will depend on theneeds of the application.

Critical applications may need to be backed upevery 10 minutes while less critical applicationsmay only need to be backed up every hour orevery day.

It is also not necessary to backup the entiredatabase each time; only the affected or

modified parts of database need to be backedup.

Making copies of the entire database frequentlywill affect system performance. The backup copyis used to restore the database in the event ofhardware failure, catastrophic loss, or damage.


17/22

Journalizing Facilities

This facility is used to store the audit trailsof transactions and database changes.

The information in these journals can beused to restore or reconstruct the systemshould there be a system failure.

Recovery Manager This facility in the DBMS restores the

database correctly after a failure hasoccurred, after that it permits normal

processing to resume. The recovery manager uses the log fileand backup copies to restore thedatabase.


18/22

Checkpoint Facilities When the DBMS runs this facility, it

will refuse to accept any newtransactions, however it willcomplete and update all current

transactions as well as update andsynchronize all the relevant filesand journals.

When the DBMS does this, it is saidto be in a quite state. Afterperforming the checkpointoperations, it writes a checkpoint

record to a log file. This record contains all the

information necessary to restart thesystem.


19/22

Recovery & Restart Procedures

Restore/Rerun. This technique involves

reprocessing all the transactions(up to the point of failure) using the

most recent backup copy. This procedure is simple and easyto implement.

The down side is that it may take along time to reprocess all theaffected transactions.

Another disadvantage is that whilethe system is recovering the data,it may not be available to processnew transactions.


20/22

Transaction Integrity

A transaction normally requires a sequence ofprocessing steps such as reading, computingand writing.

A transaction may get aborted at any of thesesteps and this can cause the data to be

compromised. The processing steps may have modified someof the values and this may cause databaseinconsistency.

To have modified some of the values and thismay cause database inconsistency. To avoidsuch errors, the DBMS should only commit atransaction (i.e., update the files) after it hasbeen processed successfully.

Aborted transactions are not committed to thedatabase (i.e., the database is not updated).

To implement this correctly, the DBMS mustdefine the transaction boundary the logical

beginning and ending of a transaction.


21/22

Backward recovery.

In this technique, the DBMS annuls allthe unwanted changes to the

database and then reverts to theprevious state.

That is, it undoes the changes madeto the database by the abortedtransaction.

The before-images are used torestore the database to the correctstate


22/22

Database(withchanges)

Before

images

Database(withoutchanges)

DBMS

Database(withchanges)

After

images

Database(withoutchanges)

DBMS

(a) Rollback

(b) Rollforward

Documents

Part 2_Operational Issues (Use) (2)