- Transactions
- Transaction Logging
- Database Recovery Concepts
- Performing a Crash Recovery Operation
- Backup and Recovery
- Backing Up a Database with Split Mirroring
- Practice Questions
- Answers
This chapter is from the book
This chapter is from the book
This chapter is from the book
Performing a Crash Recovery Operation
Earlier, we saw that whenever transaction processing is interrupted by an unexpected event (such as a power failure), the database the transaction was interacting with at the time is placed in an inconsistent state. Such a database will remain in an inconsistent state and will be unusable until a crash recovery operation returns it to some point of consistency. (An inconsistent database will notify users and applications that it is unusable via a return code and error message that is generated each time an attempt to establish a connection to it is made.)
So just how is a crash recovery operation initiated? One way is by executing the RESTART command from the DB2 Command Line Processor (CLP). The basic syntax for this command is:
RESTART [DATABASE | DB] [DatabaseName] <USER [UserName] <USING [Password]>> <DROP PENDING TABLESPACES ( [TS_Name], ... )> <WRITE RESUME>
where:
|
DatabaseName |
Identifies the name assigned to the database that is to be returned to a consistent and usable state. |
|
UserName |
Identifies the name assigned to a specific user whose authority the crash recovery operation is to be performed under. |
|
Password |
Identifies the password that corresponds to the name of the user that the crash recovery operation is to be performed under. |
|
TS_Name |
Identifies the name assigned to one or more tablespaces that are to be disabled and placed in "Drop Pending" mode if errors are encountered while trying to return them to a consistent state. |
Thus, if you wanted to perform a crash recovery operation on an inconsistent database named SAMPLE, you could do so by executing a RESTART command that looks something like this:
RESTART DATABASE SAMPLE
Note
If all database I/O was suspended (using the SET WRITE command) at the time a crash occurred, I/O must be resumed (using the WRITE RESUME option of the RESTART command) as part of the crash recovery process. (We'll look at the SET WRITE command a little later.)
You can also initiate a crash recovery operation for a particular database by selecting the Restart action from the Databases menu found in the Control Center. Figure 7-7 shows the Control Center menu items that must be selected in order to perform a crash recovery operation on an unusable database.
)
Figure 7-7. Initiating a crash recovery operation from the Control Center.
It is also possible to configure a database in such a way that crash recovery will automatically be performed, if necessary, when an application or user attempts to establish a connection to it. This is done by assigning the value ON to the autorestart database configuration parameter. (The DB2 Database Manager checks the state of a database the first time an attempt to establish a connection to the database is made and if it determines that the database is in an inconsistent state, it executes the RESTART command automatically if the autorestart database configuration parameter is set to ON.)
Note
Any user can restart an inconsistent database; no authorization checking is performed.
It is important to note that if a crash recovery operation is performed on a recoverable database (i.e., a database that has been configured to support forward recovery operations) and an error occurs during the recovery process that is attributable to an individual tablespace, that tablespace will be taken offline, and will no longer be accessible until it is repaired. This has no effect on crash recovery itself and upon completion of the crash recovery operation, all other tablespaces in the database will be accessible and connections to the database can be established—provided the tablespace that is taken offline is not the tablespace that contains the system catalogs. If the tablespace containing the system catalogs is taken offline, it must be repaired before any connections to the database will be permitted.
A Word about Soft Checkpoints
It was mentioned earlier that crash recovery is performed by using information stored in the transaction log files to roll back all incomplete transactions found and complete any committed transactions that were still in memory (but had not yet been externalized to storage) when the transaction failure occurred. As you might imagine, if the transaction log files for a database are large, it could take quite a while to scan the entire log and check for corresponding rows in the database. However, it's usually not necessary to scan the entire log since records recorded at the beginning of a log file are usually associated with transactions that have been completed and have already been externalized to the database. Furthermore, if these records can be skipped, the amount of time required to recover a crashed database can be greatly reduced.
That's where a mechanism known as the soft checkpoint comes in. The DB2 Database Manager uses a log control file to determine which records from a specific log file need to be applied to the database. This log control file is written to disk periodically, and the frequency at which this file is updated is determined by the value of the softmax database configuration parameter. Once the log control file is updated the soft checkpoint information stored in it establishes where in a transaction log file crash recovery should begin; all records in a log file that precede the soft checkpoint are assumed to be associated with transactions that have already been written to the database and are ignored.