现在的位置: 首页 > 综合 > 正文

实例恢复instance failure and recovry

2013年10月10日 ⁄ 综合 ⁄ 共 2672字 ⁄ 字号 评论关闭

 

预备知识

对数据库进行修改的时候,服务进程先将要修改的数据块读入数据库高速缓冲区database buffer cache,然后在日志缓冲区中写入即将应用于数据块的变化(包括应用于数据块的变化和撤销块undo的变化)。如果是更新列,新值(应用于表数据块的变化)和旧值(应用于撤销块的变化)都会被写入日志缓冲区redo log buffer。生成重做日志后,就可以在database buffer cache内完成更新操作了:使用变化后的列更新表数据块,未变化的列被写入撤销段数据块。从此刻到提交update操作,所有查询都会被重定向至撤销段,即隔离性isolation。

 

COMMIT后,会将日志缓冲区redo log buffer的内容写入重做日志文件online redo log files。被写入重做日志文件的重做流 包含了被提交的事务以及未被提交的事务。而与DBWn无关

 

服务器进程在内存中工作,在数据高速缓冲区内更新数据块和撤销段,然后DBWn根据LRU算法将数据高速缓冲区的内容写入数据文件。其中可能包含用于已提交事务和未提交事务的数据文件的数据块或撤销块。

the server processes work in the memory: they update blocks of data and undo segments in the database buffer cache, not on disk. then DBWn will write the changed block down to the datafiles according the algorithm that DBWn uses.

 

 

instance failure and reasons

instance failure is a disorderly shutdown of the instance , popularly referred as a crash.

this could be caused by a power cut, by switching off or rebooting the server machine, or by any number of critical hardware problems. In some circumstances one of the Oracle backuground processes may fail; this will also trigger an immediate instance failure. 
just the same as issuing the SHUTDOWN ABORT command.

 

即在发生instance failure的时候,可能 已提交事务的未被写入数据文件,而未提交事务被写入数据文件。此时数据库发生讹误。

我们知道重做日志总是先于数据的,所以在重做日志中已经保存有对数据文件的修改(数据块和撤销块)。

 

在roll forward完成之前,数据库不能被打开,用户无法连接到数据库。

instance recovery

as the ACID says, it may never lose a committed transaction and never show an uncommitted transaction.

and when instance failure hanppens, Oracle will start the instance recovery automaticly when you start it.

 

roll forward

it will use the contents of the online logfiles to
rebuild the database buffer cache to the state it was in before the crash.

this
phase of recovery, calls the roll forward 前滚, reinstates(恢复原来状态) all changes: changes to data blocks and changes to
undo blocks, for both committed and uncommitted transactions. the appropriate block is loaded from the datafiles into the database buffer cache, and the change is applied. then the block is written back to disk. 即根据数据文件和重做日志文件的SCN(?),将相应的(最大的一直状态的数据文件)数据文件读取到数据库高速缓冲区,并将此SCN之后的日志文件应用于读取的数据文件上,还原到崩溃之前的数据高速缓冲区的状态。

 

 

rollback phase

once the roll forward is complete, it is as though the crash had never occured.

then Oracle will roll back the uncommitted transactions
in the database automatically. but it happens after the database has been opened for use. 
if a user connects and hits some data that needs to be rolled back but hasn't yet been, the server will roll back the changes with undo segment.

 

the process of instance recovry

when you issue STARTUP command, first it read the parameter file,build the instance in memory分配内存启动后台进程; then it reads the controlfile when the database transitions to mount mode. 

then in the transition to open mode, SMON checks the
file headers of all the datafiles and online redo logfiles. At this point, if there had been an instance failure, it is apparent(obvious) the file headers are all out of sync. so SMON goes into the instance recovery routine,
and the database is only actually opened after the roll forward phase has completed.


抱歉!评论已关闭.