Chapter 15 Logs - Recovery

The Database Book: Principles & Practice Using MySQL, Second
Edition
by Narain Gehani
Silicon Press. (c) 2011. Copying Prohibited.
Reprinted for Stephen Efange, Robert Half International

mafany27@msn.com
Reprinted with permission as a subscription benefit of Skillport,
http://skillport.books24x7.com/
All rights reserved. Reproduction and/or distribution in whole or in part in electronic,paper or

other forms without written permission is prohibited.
TheDatabaseBook:Principles&PracticeUsingMySQL,SecondEdition
Chapter 15: Logs & Recovery

Computer systems are by and large very reliable. However, they are not perfect and failures do occur occasionally because computer systems
have many components, none of which is 100% reliable. Many of us have experienced loss of hours of work because of a system crash, disk
crash, or the system freezing. It is thus prudent to periodically save data by making backup copies of documents or other data that have been
updated. For additional safety, the backups should be stored on a medium other than the disk that has the originals.
Similarly, to protect against loss of information, databases need to be backed up periodically. There are many kinds of failures that can affect
databases. For example, a database server or a disk can crash or the disk can be corrupted. In case of failure, what happens to the database
and the updates made to it? A backup copy helps a lot, but what about the updates that were made to the database after the backup copy was
made? What about partial updates that leave the database in an inconsistent state?
1 Failure Types
Database recovery is the process of recovering a consistent database from an inconsistent or unusable database with minimum loss of
information, that is, recovering a consistent database that is as close as possible to the database state at the moment of failure.
Database failures can be classified into two categories:
n
soft, and
hard or catastrophic.
A soft failure is caused by the incomplete or partial execution of a transaction that leaves a database in an inconsistent state. Some examples
of soft failures are
n
the database server or a client computer crashing because of power failure,
a database client crashing,
the database server crashing,
the network crashing,
the network getting congested enough to block interactions with the database server making it think that the client has crashed, and
application errors.
To recover a consistent database from an inconsistent one, all updates of committed transactions must be reflected in the database and all
changes made by uncommitted transactions must be taken out of the database. A transaction is said to have committed if all its updates have
been entered into the log along with an entry indicating that it committed.
Hard or catastrophic failures are ones in which the database becomes unusable. The database cannot be used because the media has been
physically damaged or because the data has been corrupted and is no longer meaningful. Some examples of catastrophic failures are
n
a disk crash,
the disk becoming corrupted because of an incorrect transaction, and
a virus infecting the database.
In such cases, recovering a database requires starting with a consistent copy of the database (if one exists) and bringing it up to date.
2 Logs
To provide protection against failure, database systems keep a record of the updates made to a database in a journal file called the
transaction log, the system log, or just the log. The log, assuming it is available and correct, can be used to recreate a consistent and current
database, that is, the log is used for database recovery. In this process, updates made by committed transactions are reflected in the
database and updates made by transactions that did not commit are undone.
To recover a database, we can start with an empty database and start applying the updates of all committed transactions (using information
from the log). However, it would be more efficient to start with a backup copy of the database than with an empty database. Alternatively, if the
database is available, but it is in an inconsistent state, then we can start with this database and apply updates of the committed transactions
that did not get to change the database and undo updates of the uncommitted transactions.
Making Updates to a Database

When a transaction updates a database, the updates are typically first made to a copy of the appropriate database items in the data buffer.
Prior to propagating these updates to disk, that is, making these updates persistent, a record of the updates is logged to disk. Specifically,
1. Updates to the database items are first made to copies of these items in the data buffer (this may first require bringing these items from
the disk to the buffer).
Page 2 / 12
ReprintedforXZCGO/mafany27@msn.com,RobertHalfInternational
SiliconPress(c)2011,CopyingProhibited.
2. Log entries corresponding to these updates are first made in memory in an area called the log buffer.
3. Contents of the log buffer are written to the log (on disk) and the buffer is flushed (emptied).
4. Data buffer contents are written to the database (on disk).
Write-Ahead Logging (WAL) Protocol

The strategy of recording database updates in the log (on disk) before modifying the database is known as the write-ahead logging (WAL)
protocol. There are two variants of the WAL protocol:
n
Deferred Update: Updates are made to the database only after the transaction has committed (by then all updates have been recorded in
the log).
Immediate Update: Updates are made to the database without waiting for the transaction to commit, but after the updates have been
recorded in the log. However, before a transaction is deemed to have committed, log records for any remaining updates made by the
transaction are inserted into the log as part of the commit operation.
To make the commit operation as small as possible (to minimize the chances of a system crash during the commit), entries in the log buffer
are moved to disk before the commit. The commit operation then consists of just updating an appropriate pointer on disk to make the records
become part of the log.
3 Log Details
Given the right tools to access and manipulate log information, logs play a very important role in ensuring consistency and durability of a
database (the C and D parts of ACID transactions).
A database log contains entries with information such as
n
Transaction id.
Action, which can be an item such as
- ABORT,
- BEGIN TRANSACTION,
- DELETE,
- END TRANSACTION,
- INSERT, or
- WRITE..
The physical location of the database item being updated, deleted, or inserted.
Operation values; for
an update, both the before (old) and after (new) values of the item being updated are recorded,
an insertion, the new value is recorded, and
a deletion, the old value is recorded.
Old values are used to undo the effects of transactions while new values are used to reflect updates made by a transaction. Some logs may
not keep old values if there is no need to undo updates as in the case of the deferred update strategy.
Logs will have multiple entries for each transaction. Logs, by default, do not record "read" components of transactions because they do not
update the database state. They are not needed for database recovery and not logging reads saves much disk space.
Some database systems can generate different types of log files, each containing information intended for different purposes, for example,
recovery, replication, or analysis.
4 Some Log Characteristics

The complete log represents the total record of the evolution of a database from day one. In practice, the complete log may not be easily
available or available at all because some or all of it may have not been archived or deleted to save storage.
Here are some characteristics of logs:
n
A log contains all the information in a database and more. It is also a temporal database, tracking the evolution of the database, who
made what updates and when, how long queries took to execute, and so forth.
A log has just too much information. Moreover, it can typically only be accessed sequentially. Consequently, it is not easy to use the log for
applications other than its primary purpose such as database recovery unless appropriate tools are available. Many tools have been
built to enable database logs to be used for proposes such as
Database Replication: Provide information to replicas so that they can synchronize with the master database.
Page 3 / 12
Database Audit: Determine how the database was used.

Performance Analysis: Determine transaction execution time, bottlenecks, and so on.
n
The log is typically not accessible to normal users; access is reserved for DBAs and system administrators.
A log can be "viewed" as an append only table. Also, only the database system is allowed to append rows to the log.
Like the database, the log is kept on disk for durability:
To ensure that at least one of the database or the log survives a disk crash or corruption, it is prudent to keep them on separate disks.
If the disk on which the log resides crashes or is corrupted, then a backup copy of the database should be made immediately.
Log files require a lot of storage. Consequently, they should be archived periodically this is typically done in conjunction with backups.
When a log is archived, the log is truncated (emptied).
5 Database Recovery
I will now discuss different types of database recovery. I will discuss recovery from both soft and catastrophic failures.
Automatic Recovery
Most database systems, when restarted, check to see if the database server was shut down normally. If not, they assume that the database is
potentially inconsistent or not current. An automatic recovery process is initiated to bring the database to a consistent and current state that
corresponds with the information stored in the log. For example, here is a sample of what the MySQL database server mysqld prints when it
is restarted after an abnormal termination:
C: > mysqld
InnoDB: Database was not shut down normally.
InnoDB: Starting recovery from log files...
InnoDB: Starting log scan based on checkpoint at
log sequence number 0 14674032
InnoDB: Doing recovery: scanned up to log sequence
number 0 14839521
number 0 14905056
number 0 21555224
InnoDB: 1 uncommitted transaction(s) which must be
rolled back
InnoDB: Starting rollback of uncommitted transactions
InnoDB: Rolling back transaction number 26745
InnoDB: Rolling back of transaction number 26745
completed
InnoDB: Rollback of uncommitted transactions completed
InnoDB: Starting an apply batch of log records to the
database
InnoDB: Apply batch completed
InnoDB: Started
mysqld: ready for connections
After going through the recovery process, the MySQL database server (with the InnoDB storage engine) is ready to accept requests from a
client. Note that InnoDB uses the immediate update variant of the WAL protocol for database updates.
Recovery Strategy
The database recovery strategy used depends upon the nature of the failure and whether the database is using the deferred or the immediate
update variant of the WAL protocol. For example, in case of a
n
soft failure, the log is used to bring the database to a consistent and current state. Updates made by committed transactions are applied
to the database (redo of committed transactions). In addition, if the immediate update strategy is being used, then updates made by
uncommitted transactions are undone (undo of uncommitted transactions).
catastrophic failure, the latest usable backup copy of the database is used as a starting point. The log is used to take the database to a
current and consistent state. This may not be possible if the log is also affected by the failure.
When recovering a database, the database recovery system needs to know which transactions have been applied to the database. Then it
need apply only the updates of the remaining committed transactions and undo updates of the uncommitted transactions.
Page 4 / 12
Backups
In case of a catastrophic failure, the log can be used to recover the database by starting with an empty database and then applying all the
updates made by the committed transactions as recorded in the log. The complete log, starting from day one, can be massive, containing a
large number of entries. It may be much larger than the database itself. Processing such a log to recover the database will therefore require
much time.
Consequently, to make the database recovery process faster and more efficient, databases are backed up periodically, that is, a copy of the
database is stored periodically. The latest backup copy is used as the starting point for database recovery. The log entries needed to recreate
the database need only reflect updates made after the backup was made.
The more recent the backup copy, the less time it will take to recover a consistent and up-to-date version of the database. Consequently,
backups should be made often. However, the frequency of making backups needs to be balanced with the time it takes to create a backup
and the amount of storage required for the backup.
Like databases, logs should also be backed up just in case they become unusable or inaccessible as a result of a catastrophic failure.
Typically, logs are also backed up along with the databases. When a backup copy of a log is made, the log is truncated (logging starts afresh
with an empty file). Otherwise, logs will get massive even though the database itself may not be massive.
Backups should typically be kept on another disk or medium that is different from the disks with the database and the log. For additional
safety, backups should be stored in different geographical locations.
There are two kinds of database backups: offline or cold backups and online or hot backups.
Offline or Cold Backup
An offline (cold) backup is a backup made after taking the database offline, that is, stopping all database updates (existing transactions may
be allowed to complete). Note that making an offline backup can be disruptive to the operation of a business. An offline backup reflects a
consistent view of the database state at a moment in time.
Online or Hot Backup
An online (hot) backup is a backup made while transactions are updating the database. Unlike a cold backup, a hot backup will not disrupt the
operation of a business even though it may slow the performance of the database a bit.
Unlike a cold backup, a hot backup may not reflect a consistent state of the database because updates made by a transaction may not make it
to the backup copy. For example, suppose that transaction T1 updates two tables, Orders and OrderInfo. T1 arrives during a hot backup
after table Orders has been backed up. T1 goes ahead and updates Orders and OrderInfo. Table OrderInfo is backed up after it is
updated by T1. The backup copy now contains some, but not all, of T1's updates those made to table OrderInfo, but not those made to
table Orders.
The backup copy represents an approximation of the database as it changed while the backup was being made. Nevertheless, with the
information in the log, a consistent and current version of the database can be created using the backup copy.
Recovery Operations
Three major operations are involved in database recovery:
n
redo,
undo, and
checkpoint.
Redo Operation
A redo operation reapplies an update to the database made by a transaction as recorded in the log (the "redo" nomenclature is a bit of a
misnomer some updates may have been applied before but others will be applied for the first time). Log entries for transaction updates
contain the new values of items. These values are used to update the database. Redo operations are used to ensure that the updates made
by committed transactions are reflected in the database. When recovering from a failure, updates made by committed transactions are
applied in the forward log direction.
The database system does not guarantee a specific commit order for simultaneously executing transactions. It only guarantees that the order
in which the transactions commit will lead to a consistent database. Different transaction commit orders may lead to different but consistent
databases there is no guarantee that they will lead to the same database. Consequently, to ensure that we recover a consistent database
that matches the database had there been no failure, transaction updates recorded in the log must be applied to the database in the commit
order as noted in the log.
Undo Operation
An undo operation undoes an update made by a transaction. Undo operations are used to reverse database updates made by transactions
that did not commit (such updates happen if the database system is using the immediate update strategy). Transactions may not commit
Page 5 / 12
because they were aborted or because of failures such as a server crash. Updates made by transactions that did not commit make a
database inconsistent. By undoing the updates of these transactions, an inconsistent database can be brought to a consistent state. To
reverse a database update, the corresponding log entry needs to contain the original value. The undo operations are applied in the reverse of
the order in which the updates were made.
Speeding up RecoveryCheckpoints
To recover a database, the database recovery system scans the complete log to apply updates made by committed transactions and undo
updates made by uncommitted transactions. However, if the database recovery system can determine which transactions had committed and
had their updates applied to the database, then it can skip the part of the log corresponding to these transactions.
To speed up database recovery, database systems use checkpoints to tell the database recovery system how much of the log it needs to
examine. Database systems periodically force all updates of committed transactions to be written to the database (on disk), that is, they
periodically checkpoint the database. A checkpoint entry is then written to the log. The database recovery system can now start at the most
recent checkpoint because updates of transactions that committed before the checkpoint are guaranteed to have been applied to the
database.
Checkpoint entries can also be used to record additional information to help the database recovery system, for example, a list of the active
(uncommitted) transactions at checkpoint time.
Recovery Steps
We now discuss steps taken to recover a database from failure.
Soft Failure
Immediate Update Wal Protocol
To recover a database, the database recovery system takes these actions:
1. The most recent checkpoint is located in the log by scanning the log backwards.
2. While scanning backwards, lists of committed and uncommitted transactions are built. These are the transactions that updated the
database after the checkpoint.
3. To the list of uncommitted transactions are added uncommitted transactions specified in the checkpoint log entry[42] but which are not in
the list of uncommitted transactions.
4. Starting from the checkpoint entry, the log is forward scanned while applying updates of the committed transactions to the database.
5. The log is backward scanned while undoing updates that might have been made to the database by the uncommitted transactions.
The end result is a database that is both consistent and current.
Deferred Update Wal Protocol
Database recovery is similar to when the database system is using the immediate update WAL protocol, except that now there is no need to
worry about uncommitted transactions.
Catastrophic Failure
Recovering from a catastrophic failure typically involves starting with a backup copy. There are two scenarios depending upon whether or not
the database was taken offline to make the backup (i.e., whether the backup is cold or hot).
Starting with a Cold Backup Copy
The backup copy represents a consistent snapshot of the database at the time it was made. But it is likely to be not current because of the
transactions that appeared after the backup was made. To recover a current version of the database, the backup copy is used as the starting
point. All updates made by all committed transactions in the log after the backup was made are then applied to the backup copy.
Starting with a Hot Backup Copy
A hot backup copy is a fuzzy (inconsistent) snapshot of the database. It is inconsistent because, while the backup was being performed,
transactions were allowed to update the database. There is no guarantee that all the updates made by these transactions were included in the
backup copy.
To bring such a backup copy to a consistent and current state, updates made by transactions that committed after the backup was started
must be applied to the database and those made by transactions that did not commit must be undone.
To recover the database, the recovery system takes these actions:
1. Scans the log backwards to the most recent checkpoint before the start of the backup.
2. Starting from this checkpoint the recovery steps are the same as in the case of recovery from soft failure when the immediate update
WAL protocol is used.
Page 6 / 12
[42]We
assume that a checkpoint entry specifies the transactions that were active at checkpoint time.
6 Database Recovery Example

I will now illustrate database recovery following a server crash. For this example, I will assume that the database system uses the deferred
update WAL protocol implying that the database will not contain any updates made by uncommitted transactions. When the server is brought
back online, the database is "usable" but it is in an inconsistent state. A consistent version of the database will be recovered by applying, from
the log, updates of committed transactions.
Consider the tables Orders and OrderInfo of the Everest Books database:
Orders
OrderId
CustomerId
OrderDate
ShipDate
Shipping
SalesTax
2004-03-31
2004-03-31
4.99
0.00
2004-04-01
2004-04-02
5.99
0.00
2004-04-01
2004-04-02
3.99
0.00
2004-04-02
2004-04-02
6.99
0.00
Orderinfo
OrderId
ISBN
Qty
Price
929306279
29.95
929306260
49.95
439357624
16.95
670031844
34.95
929306279
29.95
929306260
49.95
439357624
16.95
670031844
34.95
Four transactions, T1, T2, T3, and T4, all of them placing orders for the book White Mughals, arrive at the database server soon after which it
crashes:
n
T1 generates an order for one copy of the book White Mughals for the customer with id 2.
T2 generates an order for one copy of the book White Mughals for the customer with id 3.
T3 changes the order for the customer with id 2 (generated by transaction T1) from one copy to two copies of White Moguls (the shipping
charge is also changed from $3.99 to $4.99).
T4 generates an order for one copy of the book White Moguls for the customer with id 1.
When the server crashes, it has completed execution or is in the middle of executing these transactions:
n
T1 has committed and its updates have been propagated to the database (that is, to the disk).
T2 has committed, but its updates, which are in the data buffer, did not make it to the database.
T3 has committed, but its updates, which are in the data buffer, did not make it to the database.
T4, whose updates are in the data buffer, does not get a chance to commit.
Committing means that all the updates made by a transaction have been entered into the log along with an entry indicating that the transaction
committed. But this does not mean that the updates were written to database.
Specifically, only transaction T1's updates (related customer id is 2 and order id is 5) to the Orders table are reflected in the database (row
shown in gray):
Orders (Just Before Server Crash)
OrderId
CustomerId
OrderDate
ShipDate
Shipping
SalesTax
2004-03-31
2004-03-31
4.99
0.06
2004-04-01
2004-04-02
5.99
0.00
2004-04-01
2004-04-02
3.99
0.00
Page 7 / 12
2004-04-02
2004-04-02
6.99
0.00
2004-05-03
2004-05-03
3.99
0.00
Updates made by transactions T2, T3, and T4 (related customer ids are 3, 2, and 1, respectively) to the data buffer copy of the Orders table
did not get propagated to the database:
Updates To Orders (In The Data Buffer)
OrderId
CustomerId
OrderDate
ShipDate
Shipping
SalesTax
2004-05-03
2004-05-03
3.99
0.00
2004-05-03
2004-05-03
4.99
0.00
2004-05-03
2004-05-03
3.99
0.00
Only transaction T1's updates to the OrderInfo table are reflected in the database (row shown in gray):
Orderinfo (Just Before Server Crash)
OrderId
ISBN
Qty
Price
929306279
29.95
929306260
49.95
439357624
16.95
670031844
34.95
929306279
29.95
929306260
49.95
439357624
16.95
670031844
34.95
670031844
34.95
However, as in case of the Orders table, updates made by transactions T2, T3, and T4 (related order ids are 6, 5, and 7, respectively) to the
copy of the OrderInfo table in the data buffer did not propagate to the database:
Updates To Orderinfo (In The Data Buffer)
OrderId
ISBN
Qty
Price
670031844
34.95
670031844
34.95
670031844
34.95
When the system crashes, the log looks like this:

Log At System Crash Time
Trans Id
Action
Item Updated
Before Value / Other Info
After Value
T1
BEGIN TRANS
T1
INSERT
Orders
<5,2,2004-05-03,2004-05-03, 3.99,0.00>
T1
INSERT
OrderInfo
<5,0670031844,1,34.95>
T1
COMMIT
T2
BEGIN TRANS
T2
INSERT
CHECK POINT
Orders
<6,3,2004-05-03,2004-05-03, 3.99,0.00>
T2 is active
<6,0670031844,1,34.95>
T2
INSERT
T2
COMMIT
T3
BEGIN TRANS
T3
WRITE
T3
WRITE
T3
COMMIT
OrderInfo
<5,0670031844,1,34.95>
OrderInfo
<5,0670031844,2, 34.95>
<5,2,2004-05-03,2004-05-03, 3.99,0.00>
Orders
<5,2,2004-05-03, 2004-05-03, 4.99,0.00>
Page 8 / 12
T4
BEGIN TRANS
T4
INSERT
<7,1,2004-05-03,2004-05-03, 3.99,0.00>
Orders
The log entries for each of the four transactions are shown contiguously for ease of reading. However, in general, they may be interleaved.
Updates made by transactions T2 and T3 will appear in the recovered database because these transactions committed before the server
crashed. Some updates made by transaction T4 were recorded in the log, but T4 did not get to commit. Consequently, none of its updates will
appear in the recovered database.
Updates made by transaction T1 were already in the database at the time of the crash. Note that T1's updates will be updated by transaction
T3.
To restore the database to a consistent and current state, the log is scanned backward to the most recent checkpoint and while doing so, a list
of transactions that committed after the checkpoint is built. Then the log is scanned forward and updates made by the committed transactions
are applied to the database.
Here are the tables Orders and OrderInfo after database recovery:
Orders (After Recovery)
OrderId
CustomerId
OrderDate
ShipDate
Shipping
SalesTax
2004-03-31
2004-03-31
4.99
0.06
2004-04-01
2004-04-02
5.99
0.00
2004-04-01
2004-04-02
3.99
0.00
2004-04-02
2004-04-02
6.99
0.00
2004-05-03
2004-05-03
4.99
0.00
2004-05-03
2004-05-03
3.99
0.00
Orderinfo (After Recovery)

OrderId
ISBN
Qty
Price
929306279
29.95
929306260
49.95
439357624
16.95
670031844
34.95
929306279
29.95
929306260
49.95
439357624
16.95
670031844
34.95
670031844
34.95
670031844
34.95
After database recovery, tables Orders and OrderInfo will be different from what they were before the crash. This is because during the
recovery process, unapplied updates to these tables, as determined from the log, will be applied. After the recovery process, other tables in
the database will be same as they were at the time of the crash because they were not affected by these updates.
7 MySQL
MySQL provides facilities for creating several different types of log files:
Log
Type
What Information Does It Contain?
query
Contains information about the connections established between the client and the server, and all queries including read queries. Entries are made in
the order in which connections and queries are received. This log cannot be used for recovery because it does not contain information about the
transaction commit order.
binary
Contains information about statements that update the database. It is used for recovery and for replication. The binary log also contains information
about how long queries take to execute. But it does not contain information about read queries. Entries are logged in order of transaction execution.
slow
query
Contains information about queries that took long to execute or did not use an index.
The slow query log contains information about queries that are candidates for optimization. This information could be extracted from the query
log, but this log can be massive. Moreover, all the information needed for optimization may not be there because, to save space, the query log
is emptied when it is archived and typically this happens periodically.
Page 9 / 12
8 Exercises
1. Compare the deferred and immediate database update variants of the WAL protocols by listing the advantages of each.
2. If the log contains all the information in a database and more, why bother having a database? Why not just build and use tools that
manipulate the log and retrieve data from it?
3. List five different types of information that can be extracted from the log but not from the database.
4. Suppose we have a 50 MB database that grows in size to 100 MB over one year. Over this period, it is modified by about 2000
transactions per hour on the average. Each transaction generates log entries totaling about 100 bytes. What will be the size of the log
after one year? What should have been done to the log over this period?
5. In the database recovery example of Section 6 (page 299), we assumed that the database system used the deferred update WAL
protocol, that is, only updates of committed transactions could appear in the database. In this exercise, we will assume that the database
system uses the immediate update strategy, that is, updates made by transactions appear in the database after they have been entered
in the log (the transactions need not have committed).
To refresh your memory, this example involves updates to the tables Orders and OrderInfo:
Orders
OrderId
CustomerId
OrderDate
ShipDate
Shipping
SalesTax
2004-03-31
2004-03-31
4.99
0.00
2004-04-01
2004-04-02
5.99
0.00
2004-04-01
2004-04-02
3.99
0.00
2004-04-02
2004-04-02
6.99
0.00
OrderInfo
OrderId
ISBN
Qty
Price
929306279
29.95
929306260
49.95
439357624
16.95
670031844
34.95
929306279
29.95
929306260
49.95
439357624
16.95
670031844
34.95
Four transactions, T1, T2, T2, and T4 modify the database they arrive at the database server and soon after which it crashes:
n
T3 updates the order for the customer with id 2 (generated by transaction T1) to make the order be for two copies of White Moguls (the
shipping charge is also changed from $3.99 to $4.99).
When the server crashes, it has completed execution or is in the middle of executing these transactions:
n
T1 has committed and its updates have been propagated to the database.
T2 has committed and its updates have been propagated to the database.
T3's updates are partially propagated to the database (its update of OrderInfo reflecting an order for two copies of White Moguls is in
the database but not its update of Orders to reflect a higher shipping price of $4.99). Note that T3 updates the row in OrderInfo
inserted by T1.
T4 does not get a chance to commit, but its updates have been propagated to the database.
Here are the two tables Orders and OrderInfo as they appeared just before the server crash (rows updated by the above transactions are
show in gray):
Orders (Just Before Server Crash)
Page 10 / 12
OrderId
CustomerId
OrderDate
ShipDate
Shipping
SalesTax
2004-03-31
2004-03-31
4.99
0.06
2004-04-01
2004-04-02
5.99
0.00
2004-04-01
2004-04-02
3.99
0.00
2004-04-02
2004-04-02
6.99
0.00
2004-05-03
2004-05-03
3.99
0.00
2004-05-03
2004-05-03
3.99
0.00
2004-05-03
2004-05-03
3.99
0.00
Orderinfo (Just Before Server Crash)

OrderId
ISBN
Qty
Price
929306279
29.95
929306260
49.95
439357624
16.95
670031844
34.95
929306279
29.95
929306260
49.95
439357624
16.95
670031844
34.95
670031844
34.95
670031844
34.95
670031844
34.95
Database recovery this time will require both a redo and an undo of updates to the database. Specifically, it will require a redo of the
committed transactions after the checkpoint, that is, transactions T2 and T3, and an undo of the updates made by transaction T4.
The following log is different from the one shown in Section 6 (page 299) because the entries of transactions T3 and T4 are interleaved (see
shaded area):
Log File
Trans Id
Action
Item Updated
Before Value / Other Info
After Value
T1
BEGIN TRANS
T1
INSERT
Orders
<5,2,2004-05-03, 2004-05-03,3.99,0.00>
T1
INSERT
OrderInfo
<5,0670031844,1,34.95>
T1
COMMIT
T2
BEGIN TRANS
T2
INSERT
CHECK POINT
Orders
<6,3,2004-05-03, 2004-05-03,3.99,0.00>
T2 is active
<6,0670031844,1,34.95>
T2
INSERT
T2
COMMIT
T3
BEGIN TRANS
T3
WRITE
T4
BEGIN TRANS
T3
WRITE
T4
T3
OrderInfo
<7,1,2004-05-03, 2004-05-03,3.99,0.00>
Orders
<5,0670031844,2,34.95>
<5,2,2004-05-03, 2004-05-03,3.99,0.00>
Orders
INSERT
COMMIT
<5,0670031844,1,34.95>
OrderInfo
<5,2,2004-05-03, 2004-05-03,4.99,0.00>
Go through the database recovery process, explaining step-by-step how the database will be brought back to a consistent and current state.
Show the final version of the tables Orders and OrderInfo after database recovery.
6. Assume that a backup copy of the database was made after taking the database offline. The tables have the values
Page 11 / 12
Orders (Backup Copy)

OrderId
CustomerId
OrderDate
ShipDate
Shipping
SalesTax
2004-03-31
2004-03-31
4.99
0.06
2004-04-01
2004-04-02
5.99
0.00
2004-04-01
2004-04-02
3.99
0.00
2004-04-02
2004-04-02
6.99
0.00
Orderinfo (Backup Copy)

OrderId
ISBN
Qty
Price
929306279
29.95
929306260
49.95
439357624
16.95
670031844
34.95
929306279
29.95
929306260
49.95
439357624
16.95
670031844
34.95
The log as shown in Exercise 5 is what the log looks at some moment after the making of the backup copy. Explain, step by step, how the
database would be recovered from a disk crash and show what the database would look like after recovery.
Page 12 / 12

Chapter 15 Logs - Recovery

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Chapter 15 Logs - Recovery

Diunggah oleh

Hak Cipta:

Format Tersedia

The Database Book: Principles & Practice Using MySQL, Second

Reprinted for Stephen Efange, Robert Half International

All rights reserved. Reproduction and/or distribution in whole or in part in electronic,paper or

Chapter 15: Logs & Recovery

the database server or a client computer crashing because of power failure,

a database client crashing,

the database server crashing,

the network crashing,

the disk becoming corrupted because of an incorrect transaction, and

a virus infecting the database.

Making Updates to a Database

Write-Ahead Logging (WAL) Protocol

4 Some Log Characteristics

Database Audit: Determine how the database was used.

Like the database, the log is kept on disk for durability:

6 Database Recovery Example

When the system crashes, the log looks like this:

Before Value / Other Info

<5,2,2004-05-03, 2004-05-03, 4.99,0.00>

Orderinfo (After Recovery)

What Information Does It Contain?

Orderinfo (Just Before Server Crash)

Before Value / Other Info

Orders (Backup Copy)

Orderinfo (Backup Copy)

Anda mungkin juga menyukai