Download resource lock

SI 654
Database Application Design
Winter 2004
Dragomir R. Radev
1
© 2002 by Prentice Hall
Database Processing
Eighth Edition
Managing
Multi-User
Databases
2
Chapter 11
David M. Kroenke
© 2002 by Prentice Hall
Multi-User Databases
• Serving the needs of multiple users
and multiple applications adds
complexity in…
– design,
– development, and
– migration (future updates)
3
© 2002 by Prentice Hall
Multi-User Database Issues
include…
• Interdependency
– Changes required by one user may
impact others
• Concurrency
– People or applications may try to
update the same information at the
same time
4
© 2002 by Prentice Hall
Multi-User Database Issues
include… (continued)
• Record Retention
– When information should be
discarded
• Backup/Recovery
– How to protect yourself from losing
critical information
5
© 2002 by Prentice Hall
Common Multi-User DBMS
• Windows 2000
– Access 2000
– SQL Server
– ORACLE
6
• UNIX
– ORACLE
– Sybase
– Informix
© 2002 by Prentice Hall
Role of the Database
Administrator
• Organizations typically hire a
database administrator (DBA) to
handle the issues and complexities
associated with multi-user databases.
• A DBA facilitates the development
and use of one or more databases.
7
© 2002 by Prentice Hall
Data Administrator versus
Database Administrator
• Data Administrator
– Handle the
database functions
and responsibilities
for the entire
organization.
– Data administrator
responsibilities are
discussed in
Chapter 17.
8
• Database
Administrator (DBA)
– Handle the
functions
associated with a
specific database,
including those
applications served
by the database.
– This chapter
describes the
responsibilities of
the DBA.
© 2002 by Prentice Hall
The Characteristics of a
DBA
• Technical
– The DBA is responsible for the
performance and maintenance of one or
more databases.
• Diplomatic
– The DBA must coordinate the efforts,
requirements, and sometimes conflicting
goals of various user groups to develop
community-wide solutions.
9
© 2002 by Prentice Hall
Technical Skills of the DBA
• Managing the database structure
• Controlling concurrent processing
• Managing processing rights and
responsibilities
• Developing database security
• Providing database recovery
• Managing the database management system
(DBMS)
• Maintaining the data repository
10
© 2002 by Prentice Hall
Managing the Database
Structure
• Managing the database structure
includes configuration control and
documentation regarding:
– The allocation of space
– Table creation
– Indices creation
– Storage procedures
– Trigger creation
11
© 2002 by Prentice Hall
Configuration Control
• The database configuration must reflect changes
in organizational and user requirements
• Structural changes to the database often effect
most, if not all, applications and users
• Sometimes configuration changes have
unanticipated consequences
• Consequently, broad perspectives, careful analysis,
and effective communication are essential. As
well, the DBA must be prepared to debug and
repair unforeseen issues.
12
© 2002 by Prentice Hall
The Need for
Documentation
• When altering a databases structure,
unanticipated issues are inevitable
• In recording the specific changes, dates,
and times, it is easier to determine the
root cause of issues and to resolve the
issues
• When historical data is restored, it must
be reformatted with all the changes in the
database structure since the data was
originally saved.
13
© 2002 by Prentice Hall
Documentation
• All structural changes must be carefully
documented with the following:
– Reason for change
– Who made the changes
– Specifically what was changed
– How and when the changes were
implemented
– How were the changes tested and what
were the results
14
© 2002 by Prentice Hall
Documentation Aids
• Version Control and Computer Assisted
Software Engineering (CASE) tools
automate and/or manage many tedious
documentation tasks.
• Printing the data dictionaries after
structural changes also helps eliminate
many tedious documentation tasks
15
© 2002 by Prentice Hall
Controlling Concurrency
Processing
• Concurrency control ensures that one
user’s actions do not adversely impact
another user’s actions
• At the core of concurrency is accessibility.
In one extreme, data becomes inaccessible
once a user touches the data. This ensures
that data that is being considered for
update is not shown. In the other
extreme, data is always readable. The
data is even readable when it is locked for
update.
16
© 2002 by Prentice Hall
Aspects of Concurrency
Control
• Rollback/Commit: Ensuring all actions
are successful before posting to the
database
• Multitasking: Simultaneously serving
multiple users
• Lost Updates: When one user’s action
overwrites another user’s request
17
© 2002 by Prentice Hall
Rollback/Commit
• A database operation typically involves
several transactions. These transactions
are atomic and are sometimes called logical
units of work (LUW).
• Before an operation is committed to the
database, all LUWs must be successfully
completed. If one or more LUW is
unsuccessful, a rollback is performed and
no changes are saved to the database.
18
© 2002 by Prentice Hall
Lost Update Problem
• If two or more users are attempting
to update the same piece of data at
the same time, it is possible that one
update may overwrite another update.
• Resource locking scenarios are
designed to address this problem
19
© 2002 by Prentice Hall
Resource Locking
• A resource lock prevents a user from
reading and/or writing to a piece of
data
• The size of the piece of data (e.g.,
database, table, field) is termed the
lock granularity
20
© 2002 by Prentice Hall
Types of Resource Locks
• Implicit versus
Explicit
– Implicit locks are
issued automatically
by the DBMS based
on an activity
– Explicit locks are
issued by users
requesting exclusive
rights to the data
21
• Exclusive versus
Shared
– An exclusive lock
lock prevents
others from reading
or updating the
data
– A shared lock allows
others to read, but
not update the data
© 2002 by Prentice Hall
Two-Phased Resource
Locking
• Two-phased locking, whereby locks
are obtained as they are needed
– A growing phase, whereby the
transaction continues to request
additional locks
– A shrinking phase, whereby the
transaction begins to release the
locks
22
© 2002 by Prentice Hall
Deadlocks
• As a transaction begins to lock
resources, it may have to wait for a
particular resource to be released by
another transaction. On occasions,
two transactions maybe indefinitely
waiting on one another to release
resources. This condition is known as
a deadlock or a deadly embrace.
23
© 2002 by Prentice Hall
Avoiding Deadlocks
• Strategy 1:
– Wait until all resources are available,
then lock them all before beginning
• Strategy 2:
– Establish and use clear locking
orders/sequences
• Strategy 3:
– Once detected, the DBMS will rollback
one transaction
24
© 2002 by Prentice Hall
Resource Locking Strategies
• Optimistic Locking
– Read data
– Process transaction
– Issue update
– Look for conflict
– If conflict
occurred, rollback
and repeat or else
commit
25
• Pessimistic Locking
– Lock required
resources
– Read data
– Process
transaction
– Issue update
– Release locks
© 2002 by Prentice Hall
Consistent Transactions
• Consistent transactions are often
referred to by the acronym ACID
– Atomic
– Consistent
– Isolated
– Durable
26
© 2002 by Prentice Hall
ACID: Atomic
• A transaction consists of a series of
steps. Each step must be successful
for the transaction to be saved.
• This ensures that the transaction
completes everything it intended to
do before saving the changes.
27
© 2002 by Prentice Hall
ACID: Consistent
• No other transactions are permitted
on the records until the current
transaction finishes
• This ensures that the transaction
integrity has statement level
consistence among all records
28
© 2002 by Prentice Hall
ACID: Isolation
• Within multi-user environments, different
transactions may be operating on the same
data. As such, the sequencing of
uncommitted updates, rollbacks, and
commits continuously change the data
content.
• The 1992 ANSI SQL standards define
four isolation levels and specify respective
issues.
29
© 2002 by Prentice Hall
Summary of Isolation Levels
30
© 2002 by Prentice Hall
ACID: Durable
• Durable transactions are saved to the
data permanently
• Interim calculations, views, and subqueries are temporal rather than
durable; that is to say that these
temporal results are not saved
31
© 2002 by Prentice Hall
Set-at-a-Time Versus
Row-at-a-Time
• SQL statements act as filters for
the entire data set.
• A cursor may be defined within a SQL
statement to point to a particular
record.
• Several types of cursors have been
defined. The cursor type defines how
the cursor behaves.
32
© 2002 by Prentice Hall
Types of Cursors
33
© 2002 by Prentice Hall
Database Security
• Database security strives to ensure…
– Only authorized users perform
authorized activities at authorized
times
34
© 2002 by Prentice Hall
Managing Processing Rights
and Responsibilities
• Processing rights define who is
permitted to do what, when
• The individuals performing these
activities have full responsibility for
the implications of their actions
• Individuals are identified by a
username and a password
35
© 2002 by Prentice Hall
Granting of Processing
Rights
• Database users are known as an individual
and as a member of one or more role
• Access and processing rights/privileges
may be granted to an individual and/or a
role
• Users possess the compilation of rights
granted to the individual and all the roles
for which they are members
36
© 2002 by Prentice Hall
Granting Privileges
37
© 2002 by Prentice Hall
Providing Database Recovery
• Common causes of database failures…
– Hardware failures
– Programming bugs
– Human errors/mistakes
– Malicious actions
• Since these issues are impossible to
completely avoid, recovery
procedures are essential
38
© 2002 by Prentice Hall
Database Recovery
Characteristics
• Continuing business operations (Fallback procedures/Continuity planning)
• Restore from backup
• Replay database activities since
backup was originally made
39
© 2002 by Prentice Hall
Fall-back Procedures/
Continuity Planning
• The business will continue to operate even
when the database is inaccessible
• The fall-back procedure defines how the
organization will continue operations
• Careful attention must be paid to…
– saving essential data
– continuing to provide quality service
40
© 2002 by Prentice Hall
Restoring from Backup
• In the event that the system must be
rebuilt or reloaded, the database is
restored from the last full backup.
• Since it is inevitable that activities
occurred since the last full backup
was made, subsequent activities must
be replayed/restored.
41
© 2002 by Prentice Hall
Recovery via Reprocessing
• This is a brunt-force technique.
• Simply re-type all activities since the
backup was performed.
• This procedure is costly because of the
effort involved in re-entering the data.
• This procedure is risky in that human error
is likely and in that paper record-keeping
may not be accurate.
42
© 2002 by Prentice Hall
Recovery via
Rollback/Rollforward
• Most database management systems
provide a mechanism to record
activities into a log file.
43
© 2002 by Prentice Hall
Rollforward
• Activities recorded in the log files may be
replayed. In doing so, all activities are reapplied to the database.
• This procedure is used to resynchronize
restored database data.
• This procedure is termed a Rollforward.
44
© 2002 by Prentice Hall
Rollback
• Since log files save activities in
sequence order, it is possible to undo
activities in reserve order that they
were originally executed.
• This is performed to correct/undo
erroneous or malicious transaction(s).
• This procedure is known as a Rollback.
45
© 2002 by Prentice Hall
Managing the Database
Management System (DBMS)
• In addition to controlling and maintaining
the users and the data, the DBA must also
maintain and monitor the DBMS itself.
– Performance statistics (performance
tuning/optimizing)
– System and data integrity
– Establishing, configuring, and maintaining
database features and utilities
46
© 2002 by Prentice Hall
Maintaining the Data
Repository
• The data repository contains metadata.
Metadata is data about data.
• The data repository specifies the name,
type, size, format, structure, definitions,
and relationships among the data. They
also contain the details about applications,
users, add-on products, etc.
47
© 2002 by Prentice Hall
Types of Data Repositories
• Active data
repository
– The development
and management
tools
automatically
maintain and
upkeep the
metadata.
48
• Passive data
repository
– People manually
maintain and
upkeep the
metadata
© 2002 by Prentice Hall