Managing Multi-User Databases (1) IS 240 – Database Management Lecture #18 – 2004-04-20 Prof. M. E. Kabay, PhD, CISSP Norwich University [email protected].

Managing Multi-User Databases (1)

IS 240 – Database Management

Lecture #18 – 2004-04-20Prof. M. E. Kabay, PhD, CISSP

Norwich University

[email protected]

mailto:[email protected]

2 Copyright © 2004 M. E. Kabay. All rights reserved.

Topics

Database AdministrationConfiguration ControlDocumentation

Concurrency ControlAtomic TransactionsResource LockingConsistent TransactionsTransaction Isolation LevelCursor Type


Database Administration

Why might we need to administer DBs?Changing requirementsManaging employee turnoverHandling hardware & software failuresMeeting SLAs (Service Level Agreements)


Functions of the DBA

Managing DB structureControlling concurrent processingManaging processing rights & responsibilitiesDeveloping and implementing DB securityProviding for DB recoveryManaging DB performance & resourcesMaintaining the data repository


Managing DB Structure

Configuration ControlParticipate in early design and

implementationControl & manage changes to structure

Inevitable changes in requirementsPolicies on how to coordinate requests

for changeProcedures for testing and

implementing changesPrepare for unexpected

Emergency quick-response plansParticipate in business-continuity planningMaintain disaster-recovery plans


Documentation

Documentation integral component of structure maintenanceWhich changes were made when

Errors may not be visible for monthsMay need to roll back changes to

previous statusHistorical data important for trend analysisNew programmers & DBAs must be able to

understand system quickly


Concurrency Control

Atomic TransactionsResource LockingConsistent TransactionsTransaction Isolation LevelCursor Type


Multi-Step Transactions Are Fragile

Think about order-entry systemCreate order-header

Includes total of cost of line-items (details)Updated at END of detail data entry

Begin entering line-itemsEnter 3 records … have not yet finishedSystem crashes

What is the value in the order-header’s total field?


Concurrency Causes New Problems

E.g., The Lost Update Problem:User A reads inventory: finds 20 widgets.User B reads inventory: also finds 20

widgets.User A subtracts 10 widgets from 20, writes

total ____ widgets back into inventoryUser B subtracts 5 widgets from ____, writes

total ____ widgets back into inventoryBut actually, there are only ____ widgets left

in the real inventory

20 widgets

A

20 widgets

B


Atomic Transactions

We want to completeAll the steps of a transaction orNone of the steps

ATOMICGreek “a” for “not” & “tomos” for “cut”Thus “atomic” means “can not be cut.”

We mark atomic transactions with boundariesStart transactionCommit transaction

If necessary, can reverse steps takenRollback transaction

ατομος


Resource Locking

Basic Concepts of LockingLock TerminologySerializable TransactionsDeadlocksOptimistic vs Pessimistic LockingDeclaring Lock Characteristics


Basic Concepts of Locking

Locking is used in inter-process communication (IPC)

A lock is a form of semaphore (signal)Locks allow processes to

coordinate their access to resources Prevent inconsistencies

In DBMS, primarily used to serialize data accessOne process gets control of data at a time


Lock Terminology Implicit vs explicit

Automatic locks placed by DBMS: implicitProgrammatically ordered: explicit

Lock granularityLarge: database, datasetFine: records

Exclusive vs shared locksExclusive:

One process READ/WRITENo other processes allowed at all

Shared:One process has R/WOther processes can only READ


Conditional vs Unconditional Locking

Conditional lockingProcess 1 locks resource AProcess 2 locks resource A

Receives error conditionLock fails and process 2 continues

Unconditional lockingProcess 1 locks resource AProcess 2 locks resource A

Does not receive a condition reportProcess 2 waits in suspense (hangs)

until lock is granted


Serializable Transactions

Prevent transactions affecting same records from overlapping

Two-phase lockingCan accumulate locksBut once any lock is released, cannot get

more until all are releasedDefines growing phase and shrinking

phaseMore restrictive (and more common) strategy

No locks released until COMMIT or ROLLBACK


Deadlock (Deadly Embrace)

11 22

AA BB

Process 1 locks resource

A unconditionally

Process 2 locks resource

B unconditionall

y

1 locks Bunconditionall

y

1 locks Bunconditionall

y

2 locks Aunconditionall

y


Preventing Deadlocks

Deadlock is example of a race conditionWill not necessarily occurOccurs by chance when specific events

happen at specific timeAlways ensure that processes in applications

LOCK RESOURCES IN SAME ORDERUNLOCK RESOURCES IN REVERSE

ORDERApply these principles to example on

previous slide to see how they absolutely prevent deadlock


Pessimistic Locking Strategy

Assume collisions will occur and prevent conflictsLock recordsProcess transactionRelease locks

But very dangerous for performance if processing involves human interactionNot controllableOperator can leave resources locked and hang

systemOperator could go to lunch!

DO NOT LOCK AROUND HUMAN INTERVENTION!


Optimistic Locking Strategy

Assume collisions will be rare and recover if they happenRead original data recordsProcess transaction using buffersLock original data recordsCheck to see if original data have changed

If no change, commit transaction & unlock

If change, unlock & start over


Optimistic Locking (1)

ProcessProcess

Value1

Value3

Value2

Value3

Value1

DB

Data buffers

Same?

Shows events when data change while processing is being carried out

after initial READ


Optimistic Locking (2)

ProcessProcess

Value1

Value1

Value2

Value1

Value1

DB

Data buffers

Same?

Value2

Observe events whenthere is no change

in initial dataduring processing


Optimistic vs Pessimistic Strategies

Optimistic locking advantagesDoes not lock resources around human

interventionAppropriate for Web / Internet transactionsEspecially important if lock granularity is

large (e.g., entire DB or entire tables)Optimistic locking disadvantages

If specific resource is in high demand (much contention for specific records) then can cause repeated access (thrashing)

Can degrade individual and system performance


Declaring Lock Characteristics

Older programs often used specific calls to locking routinesE.g., “DBLOCK”Passed parameters to set exact type of lock

Conditional or not, granularity etc.Modern programming using DBMS uses

transaction markersBEGIN, COMMIT, ROLLBACKAllows global definition of locking strategyDBMS handles detailsCan thus change locking globally without

reprogramming


Homework

First, take a deep breath and assure yourself that you can do this.

Study pages 295-307 very carefully using SQ3R.

Prepare for Thursday’s class by using the survey-question phase of SQ3R on pages 307-325. Then actually READ those pages.

REQUIRED: By Tuesday 27th April 2003:For 40 points, complete questions 11.1

through 11.20 and include the questions with your answers


DISCUSSION

Managing Multi-User Databases (1) IS 240 – Database Management Lecture #18 – 2004-04-20 Prof. M. E. Kabay, PhD, CISSP Norwich University [email protected].

Documents

b slide

rollback slide

time slide

b b process

unconditional locking

rollback transaction

data repository slide

locks b unconditionall