Crash and Instance Recovery

测试过程很清爽，学习了！
不过结论我还是有些疑虑的，固然gdb和类似sola下的trace等工具是能探察oracle内核每个模块中的极个别c函数的部分功能，可是往往是内核实现一个调度和去支应相应功能是，其中调动的函数过多，函数到函数跳跃很大，尽此的探察似乎很精确很多时候却是很粗旷的，往往就是一些较大功能体现的个别函数会浮出水面，而其实过程仍然可能是很复杂的！罢了不经意间说废话了。
所以过程很好，结论不能下的太急，这类的测试不过是学习积累的巩固和拓展，至于结论还真不敢说----当然鄙人愚见！

比如这段文字描述的崩溃恢复和实力恢复描述：
Two potential problems can result if an instance failure occurs:

Data blocks modified by a transaction might not be written to the datafiles at commit time and might only appear in the redo log. Therefore, the redo log contains changes that must be reapplied to the database during recovery.
After the roll forward phase, the datafiles may contain changes that had not been committed at the time of the failure. These uncommitted changes must be rolled back to ensure transactional consistency. These changes were either saved to the datafiles before the failure, or introduced during the roll forward phase.

To solve this dilemma, two separate steps are generally used by Oracle for a successful recovery of a system failure: rolling forward with the redo log (cache recovery) and rolling back with the rollback segments (transaction recovery).

 

The Redo Log and Rolling Forward

The redo log is a set of operating system files that record all changes made to any database buffer, including data, index, and rollback segments, whether the changes are committed or uncommitted. Each redo entry is a group of change vectors describing a single atomic change to the database. The redo log protects changes made to database buffers in memory that have not been written to the datafiles.

The first step of recovery from an instance or disk failure is to roll forward, or reapply all of the changes recorded in the redo log to the datafiles. Because rollback data is also recorded in the redo log, rolling forward also regenerates the corresponding rollback segments. This is called cache recovery.

Rolling forward proceeds through as many redo log files as necessary to bring the database forward in time. Rolling forward usually includes online redo log files and may include archived redo log files.

After roll forward, the data blocks contain all committed changes. They may also contain uncommitted changes that were either saved to the datafiles before the failure, or were recorded in the redo log and introduced during roll forward.

 

Rollback Segments and Rolling Back

Rollback segments record database actions that should be undone during certain database operations. In database recovery, rollback segments undo the effects of uncommitted transactions previously applied by the rolling forward phase.

After the roll forward, any changes that were not committed must be undone. After redo log files have reapplied all changes made to the database, then the corresponding rollback segments are used. Rollback segments are used to identify and undo transactions that were never committed, yet were either saved to the datafiles before the failure, or were applied to the database during the roll forward. This process is called rolling back or transaction recovery.

--
Crash and instance recovery involves the following two-step procedure:
1. Roll-forward step : During this step, formally called cache recovery, the database applies the
committed and uncommitted data in the current online redo log files to the current online
data files.
2. Rollback step : During this step, formally called transaction recovery , the database removes
the uncommitted transactions applied in the previous step, using the undo data in the undo
segments.
As you know, when the database suddenly crashes, not all the committed transactions will have
been written to disk. If your database is large, and the redo log files are also large, it can take a long
time for the roll-forward and rollback to complete. By using Oracle’s  Fast-Start Fault Recovery func-tionality, you can substantially reduce the downtime resulting from system-related outages.

---
cache recovery
 
The part of instance recovery where Oracle applies all committed and
 uncommitted changes in the redo log files to the affected data blocks.
 Also known as the rolling forward phase of instance recovery.
 
The first step of recovery from an instance or disk failure is called
 cache recovery or rolling forward, and involves reapplying all of the
 changes recorded in the redo log to the datafiles. Because rollback data
 is also recorded in the redo log, rolling forward also regenerates the
 corresponding rollback segments
 
Rolling forward proceeds through as many redo log files as necessary to
 bring the database forward in time. Rolling forward usually includes
 online redo log files (instance recovery or media recovery) and could
 include archived redo log files (media recovery only).
 
After rolling forward, the data blocks contain all committed changes.
 They could also contain uncommitted changes that were either saved to
 the datafiles before the failure, or were recorded in the redo log and
 introduced during cache recovery

你的测试中abort时，如果没有block修改在online redo中或者没有修改的block的活动时abort
那么你在mount后gdb去continue时
跟不到rolling forward involves reapplying all of the
 changes recorded in the redo log
而跟到row cache中数据字典的load过程时，此时结论不敢说了

我心血来潮时的个人愚见
是一个学习过程，个人毫无其他意思，请万无误解！

 

row cache中数据字典object的load过程不能完全看做Crash and Instance Recovery过程.

 

-----not end-----------

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/13750068/viewspace-731420/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/13750068/viewspace-731420/