No matter whether your database is operating in ARCHIVELOG or NOARCHIVELOG mode, you must minimize downtime when you perform routine backup or recovery. A NOARCHIVELOG database usually has more downtime because it relies on the capability of its hardware. The speed of backup and recovery depends on how fast your hard disk can read and write the files. However, an ARCHIVELOG database's downtime is reduced through
appropriate recovery strategies. This module investigates the various methods that can be used to minimize database downtime when a recovery is required. After completing this module, you will be able to:
- List the methods for minimizing database downtime
- Start a database with missing datafiles and perform a recovery
- Describe a parallel recovery
- Reconstruct a lost or corrupted control file
- Recover a read-only tablespace
- Describe recovery issues related to read-only tablespaces
If the company database were to fail during an outage, how long would it take until the business was negatively affected?
Generally, this question can be answered by management. If all data is entered manually by data entry, the downtime could be relatively long without hurting the business operations. The business could potentially operate normally by generating orders or forms that could be entered into the database later. This type of situation could have minimal effect on the business.
On the other hand, a financial institution that sends and receives data electronically 24 hours a day cannot afford to be down for any time at all without impairing the business operation. The electronic transactions will be rendered unusable until the database has recovered.
After you determine how long the business could survive without a database, you can figure out the average amount of time the database could be down if it were to fail by using the (MTTR) mean time to recovery.
Recovery time depends on the read log files
- time data blocks and
- the processing time required to recover.
However, the DBA can set restrictions based on the recovery time of several seconds by setting individual parameters. LOG_CHECKPOINT_TIMEOUT limits the number of seconds between the last checkpoint and the recent redo record.
But his recovery time limit set for it are not accurate enough. The MTTR is an average time it takes to recover from certain types of failure.
You should record each type of failure that is tested so that you can then determine an average recovery time.
The MTTR can help determine
mean recovery times for different failure scenarios. You can document these times during your testing cycles. The next lesson explains different methods for minimizing database downtime.