（2010-07-14）Oracle实例恢复详解

   又有一段时间没接触Oracle了，也就是没有天天都保证一个小时以上的Oracle学习时间，惭愧，意志力不够。

   感觉Oracle的学习真的是一个比较长期的过程，在其中的学习过程中会经历沮丧，恐惧，甚至受挫感，我想这就是我这整整一年oracle的学习体会吧。然而oracle的学习也是一个柳暗花明的过程，在一段坚持不懈的学习过程后会在不经意间发现自己慢慢的进步了，只是自己的这些进步被当初的受挫感而击败吧。总之我会坚持oracle+linux的学习的，我不会放弃的。既然坚持了一年了，那就再继续坚持吧。

    好了，温故而知新，现在开始oracle备份和恢复的专项研究吧，或许我会从oracle的备份与还原学习中又一次体会到oracle的博大精深吧。首先是oracle的实例恢复：

   

 

先要明白一些概念：

日志文件中的信息为了当系统出现failure时，保证事务可以恢复。当用户事务完成发出commit时，总是先等待LGWR进程将事务所需的redo信息写到日志文件（之前可能在redo buffer中）后，才会收到commit complete信息。

DBWR进程总是比LGWR进程写的速度慢（DBWR进程是随机写，LGWR进程是顺序写，随机写比顺序写要慢）

当DBWR进程要将缓存区中的信息写入到数据文件时，会先通知LGWR进程将事务相关的redo信息写入到日志文件。

SCN可以理解为一个标签，ORACLE对数据库中的每个操作都打上一个标签。这个标签是顺序增加的。永远不会归0（除非数据库重建）

CHECKPOINT是ORACLE为了记录哪些数据已经被写入到数据文件中。

CHECKPOINT的作用就是要保证当checkpoint发生时，这个checkpoint SCN之前的数据都要由DBWR写入到数据文件中，而在DBWR写之前，又会触发LGWR进程将相关的redo信息写入到日志文件中。这样，checkpoint完成后，发生instance failure时就不再需要恢复这个checkpoint SCN前的信息.

理解实例恢复的相关信息：

Instance Recovery所需要的信息，就是最近一次checkpoint之后到日志文件结尾的这些redo信息。
因为checkpoint之前的数据都已经一致性地写入到数据文件中了，而之后的数据可能有一部分已经写进数据文件，而有一部分没有写进数据文件。

Instance Recovery所需要的时间，将数据文件 从最近一次checkpoint开始，恢复到控制文件中记录的这个数据文件的最后一个SCN值为止，应用这两者之间redo信息的时间就是instance recovery所要花费的时间。

实例恢复的调整：

由上面的信息可以总结出，实例恢复最关键的问题的就是最近一次CHECKPOINT发生的时间，以及CHECKPOINT发生的频率。只有确认了最近一次CHECKPOIN发生的时间点，才能确定恢复所需的redo信息，以及恢复所要花费的时间。

对于instance recovery花费时间的调优，就是对参数FAST_START_MTTR_TARGE的调整，单位“秒”，最大值为3600秒。

也就是说FAST_START_MTTR_TARGET这个参数的设置会直接影响到checkpoint发生的频率。

FAST_START_MTTR_TARGE所设置的时间就是用户希望数据库用在instance recovery的时间。也就是从应用最近一次checkpoint到日志信息最后这两个点之间redo信息所要花费的时间。

MTTR设置的时间过小的话，会造成系统checkpoint过于频繁，而发生checkpoint时就要DBWR，LGWR等进程写数据文件，产生物理IO，久而久之，数据库性能会越来越慢；
MTTR设置的时间过大的话，当实例失败时，instance recover所花费的时间就会过长。

从10g开始，数据库可以实现自动调整，如果FAST_START_MTTR_TARGET=0时，可以从alert里面看到如下信息：
MTTR advisory is disabled because FAST_START_MTTR_TARGET is not set
此时，数据库会根据负载自动调整checkpoint发生的频率。

如果要严格要求instance recovery时间的话，就设置FAST_START_MTTR_TARGET参数，如果不是那么严格的话，建议用10g的自动调整。