Ask the Expert

How is recovery possible in a roll forward phase when the database instance fails?

How is recovery possible in a roll forward phase? I mean, when the instance fails, how is recovery possible? The only defined parameter is fast_start_mttr_target = 900(seconds). SMON automatically detects uncommited data (within 15 minutes), or I have to do it myself through v$instance_recovery view. Also, what columns should be considered in v$instance_recovery, that is, recovery_estimated_ios, actual_redo_blks, and so on?

    Requires Free Membership to View

    Login

Recovery is possible due to two structures in your database: the online redo logs (and potentially the archived redo logs if you restore from a backup), and the undo segments.

When an instance crashes, there will be transactions that have not yet committed or rolled back. On an instance crash, we are not concerned with any transactions that have already committed. By definition, a committed transaction has its changes written to disk, so there is nothing to recover in the case of a committed transaction, provided we are just dealing with an instance failure. So the database needs to recover uncommitted transactions. The database read the last active online redo log for the most recent transactions. It uses the information there to replay those transactions just as if the database had never crashed. When the replay of all transactions is complete, the database then rolls back the effect of those transactions since they were never committed. It is safer to assume that active transactions should be rolled back rather than committed when an instance crashes. By using these two structures, the database is able to perform instance recovery.

This was first published in October 2004

Join the conversationComment

Share
Comments

    Results

    Contribute to the conversation

    All fields are required. Comments will appear at the bottom of the article.
    Back to top