Database Reference
In-Depth Information
Timestamping
An alternative to two-phase locking is timestamping. With timestamping, the DBMS assigns to each database
update the unique time when the update started; this time is called a timestamp. In addition, every database
row includes the timestamp associated with the last update to the row. The DBMS processes updates to the
database in timestamp order. If two users try to change the same row at the same time, the DBMS processes
the change that has the earlier timestamp. The other transaction will be restarted and assigned a new time-
stamp value.
Timestamping avoids the need to lock rows in the database and eliminates the processing time needed to
apply and release locks and to detect and resolve deadlocks. On the other hand, additional disk and memory
space are required to store the timestamp values; in addition, the DBMS uses extra processing time to update
the timestamp values.
One might naturally ask at this point whether the ability to have concurrent update is worth the com-
plexity that it adds to the DBMS. In some cases, the answer is no. Concurrent update may be far from a
necessity. In most cases, however, concurrent update is necessary to the productivity of the users of the sys-
tem. In these cases, implementation of locking, timestamping, or some other strategy is essential to the
proper performance of the system.
242
RECOVER DATA
A DBMS must provide methods to recover a database in the event the database is damaged in any way. A
database can be damaged or destroyed in many ways. Users can enter data that is incorrect, transactions that
are updating the database can end abnormally during an update, a hardware problem can occur, and so on.
After any such event has occurred, the database might contain invalid or inconsistent data. It may even be
totally destroyed.
Obviously, a situation in which data has been damaged or destroyed must not be allowed to go uncor-
rected. The database must be returned to a correct state. Recovery is the process of returning the database
to a state that is known to be correct from a state known to be incorrect; in performing such a process, you
say that you recover the database. In situations where indexes or other physical structures in the database
have been damaged but the data has not, many DBMSs provide a feature that you can use to repair the data-
base automatically to recover it.
To address cases in which the data in a database has been damaged, the simplest approach to recovery
involves periodically making a copy of the database (called a backup or a save). If a problem occurs, the
database is recovered by copying this backup copy over it. In effect, the damage is undone by returning the
database to the state it was in when the last backup was made.
Unfortunately, other activity besides that which caused the destruction also is undone. Suppose the data-
base is backed up at 10:00 p.m. and users begin updating it at 8:00 a.m. the next day. Further suppose that at
11:30 a.m., something happens that destroys the database. If the previous night
s backup is used to recover the
database, the entire database is returned to the state it was in at 10:00 p.m. All updates made in the morning
are lost, not just the update or updates that were in progress at the time the problem occurred. Thus, during
the final part of the recovery process, users would have to redo all the work they had done since 8:00 a.m.
'
Journaling
As you might expect, enterprise DBMSs provide sophisticated features to avoid the costly and time-consuming
process of having users redo their work. These features include journaling, which involves maintaining a
journal or log of all updates to the database. The log is a separate file from the database; thus, the log is still
available if a catastrophe destroys the database.
Several types of information are typically kept in the log for each transaction. This information includes
the transaction ID and the date and time of each individual update. The log also includes a record of what the
data in the row looked like in the database before the update (called a before image) and a record of what the
data in the row looked like in the database after the update (called an after image). In addition, the log con-
tains an entry to indicate the start of a transaction and the successful completion (commit) of a transaction.
To illustrate the use of a log by a DBMS, consider the four sample transactions shown in Figure 7-10.
Three transactions—1, 3, and 4—require a single update to the database. The second transaction, which is
Ryan's order transaction for Brookings Direct, requires seven updates to the database.
