11.3. Summary

Understanding the types of failures that can occur in the database is critical to deciding the type of action required to recover from the failure. We reviewed the six types of failures in a database: statement, user process, network, user errors, instance, and media.

In addition to knowing how an instance fails, you also need to know what is required to keep a database up and running: all control files, at least one member of each redo log group, and all datafiles for the SYSTEM and UNDO tablespaces. For instance failures, you want to know how long the database will take to recover. Starting with Oracle9i, you can use the initialization parameter FAST_START_MTTR_TARGET to specify the target recovery time, making it easier to meet service-level agreements.

Later in the chapter, we presented an overview of how to recover from three of the failure types: instance, user errors, and media. In the discussion on instance failures, we presented the steps required to successfully start up the database, identifying the prerequisites that must be in place for the startup phase to complete.

In many cases, users themselves can solve their errors; Flashback Query can retrieve rows that have been deleted from a table in the past, even after a COMMIT has been performed. Dropped tables are kept in a structure new to Oracle 10g called the recycle bin, which lets a user bring back the entire table as long as the space occupied by the table in the tablespace was not required for new objects. Flashback Table brings a table back to a point of time in the past without affecting other objects or users in the database; Flashback Query and Flashback Table are often used as complementary tools when many rows or even a few rows in a table have been lost or inadvertently deleted. Finally, you can access previous transactions against a table from the online and archived redo logs when the self-service recovery tools are not successful in recovering user data.

At the end of the chapter, we visited a couple of media failure scenarios and showed you how to recover from each one of these using the EM Database Control interface while minimizing downtime and preventing any loss of committed transactions.