丢失REDO LOG的恢复

对于Oracle数据库来说，REDO LOG 对于保证数据的完整性可恢复性起着关键的作用，因此对redo log的保护也是至关重要的，下面对REDO LOG相关的知识进行总结。
1. 原理概念
     redo log记录了数据库操作的所有事务（除了direct load和nologging操作只产生少量的redo信息），在数据库发生故障后，对数据库的恢复主要是靠redo log的信息(archive log也是redo log，只不过是备份的而已)。因此，在理论情况下，在归档模式下，只要有有效的归档日志加上有效的在线redo log就可以确保不丢失数据来恢复数据库。
    
2. redo log和archive log的产生过程
    当数据库发生事务时，会把信息记录在log buffer缓存里，当一定条件发生时由LGWR进程把信息从log buffer里写到当前的redo log组里，而日志组间又是循环交替写入的，即当当前日志组满了或发生了switch行为时，切换到下一个日志组，如果在归档模式下，此时ARCn归档进程就会备份刚写满的日志到归档目录里。
     那么在什么情况下会发生LGWR写行为呢：
     1. 每3秒一次
     2. log buffer满1/3时
     3. log buffer里的信息量达1M时
     4. 发生checkpoint时
     因此针对以上触发条件，log buffer一般设置为1～3M。

3. redo log的规划
    对redo log的规划也是很讲究的，他涉及到需要考虑的问题很多：
    1). 首先要保证不丢失redo log。因此，一个组需要建立多个成员，并镜像到不同的磁盘驱动器上。其实镜像的目的不光是保证redo log不被丢失，还平衡了I/O。
    2). 由于redo log写操作非常平凡。因此最好把redo log放到write比较快的磁盘上(RAID 5就不行，写的性能太差)，也最好和数据文件分开，可以防止I/O和等待
    3). 接下来要考虑的就是log buffer的大小了，一般来说1～3M就可以了，10M以下吧。
    4). 最后考虑的是等待事件问题。在归档模式下，在发生日志切换后会启动ARCn进程进行归档，为防止归档很慢，而事务很多写日志很快，导致LGWR和ARCn间的等待问题。可以多设置几个日志组，单个日志成员文件的大小也要适中，这个值一般和事务频率有关，一般来说设置3个组，每个成员100M就行了。

4. 日志切换
     日志有自动切换和手工切换。自动一般是写满了才发生。手工的话可以通过以下两条命令来完成：
     SQL> alter system switch logfile;
     SQL> alter system archive log current;
      具体两条命令的区别见：http://space.itpub.net/9466564/viewspace-610391

5. 管理redo log
     SQL> select group#, status, member from v$logfile;
    GROUP#  MEMBER
    ----------   ------------
         3        D:\VMWARE\ORACLE\ORADATA\ORCL\REDO03.LOG
         2        D:\VMWARE\ORACLE\ORADATA\ORCL\REDO02.LOG
         1        D:\VMWARE\ORACLE\ORADATA\ORCL\REDO01.LOG

SQL> select group#,sequence#,archived,status,first_change# from v$log;

    GROUP#  SEQUENCE# ARC STATUS           FIRST_CHANGE#
---------- ---------- --- ---------------- -------------
         1         16 NO  CURRENT                 646400
         2         15 YES INACTIVE                646395
         3         14 YES INACTIVE                646362

SQL> select sequence#,FIRST_CHANGE#,NEXT_CHANGE# from v$archived_log;

 SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
---------- ------------- ------------
         3        573951       600395
         4        600395       622729
         5        622729       636162
         6        636162       636657
         7        636657       636661
         8        636661       636664
         9        636664       646321
        10        646321       646323
        11        646323       646341
        12        646341       646356
        13        646356       646362

 SEQUENCE# FIRST_CHANGE# NEXT_CHANGE#
---------- ------------- ------------
        14        646362       646395
        15        646395       646400

13 rows selected.

SQL> select sequence#,FIRST_CHANGE#,NEXT_CHANGE#,RESETLOGS_CHANGE# from v$log_history;

 SEQUENCE# FIRST_CHANGE# NEXT_CHANGE# RESETLOGS_CHANGE#
---------- ------------- ------------ -----------------
         1        534907       568104            534907
         2        568104       573951            534907
         3        573951       600395            534907
         4        600395       622729            534907
         5        622729       636162            534907
         6        636162       636657            534907
         7        636657       636661            534907
         8        636661       636664            534907
         9        636664       646321            534907
        10        646321       646323            534907
        11        646323       646341            534907

 SEQUENCE# FIRST_CHANGE# NEXT_CHANGE# RESETLOGS_CHANGE#
---------- ------------- ------------ -----------------
        12        646341       646356            534907
        13        646356       646362            534907
        14        646362       646395            534907
        15        646395       646400            534907

15 rows selected.

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

转载于:http://blog.itpub.net/9466564/viewspace-620884/