Oracle 10g 实例恢复Tuning

导读:




先要明白一些概念:


日志文件中的信息为了当系统出现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的自动调整。





本文转自

http://www.cnblogs.com/minbear/archive/2008/06/13/1219507.html

你可能感兴趣的:(Oracle)