oracle 重做日志（Redo LogBuffer）

oracle redo

一、Oracle的重做日志基本概念及原理

重做日志文件 redo log file 通常也称为日志文件，它是保证数据库安全和数据库备份与恢复的文件，是数据库安全和恢复的最基本的保障。管理员可以根据日志文集和数据库备份文件，将崩溃的数据库恢复到最近一次记录日志时的状态。所以在日常工作当中，管理员维护重做日志文件也是十分必要的。

1、概述

重做日志文件用于记录事务操作所引起的数据的变化，包括回滚段事务表、回滚块、数据块上的事务槽、数据行的变化等，当执行DDL、DML操作时，有LGWR进程将日志缓冲区中与事务相关的重做记录写入到重做日志文件中。当丢失或损坏数据库中的数据时，Oracle会根据redo文件中的记录 恢复丢失的数据。

1.1史记讲解法来理解日志记录的原理

buffercache里面有一堆的buffer，假设在buffercache上站着一个人，它能够看到buffercache里面所有的buffer，而且这个人眼睛特别快，对buffercache来讲大量的sql语句执行，在一个时间其中的某个buffercache中的块被改了，下一个时间另外一个buffercache中的块被改了，时间差了几毫秒，就是说在短时间内，大量的buffer被修改了，然后这个人就拿着一个本在记录，严格按照时间来记录buffer的一个改变过程，机上在这个时间点哪个buffer发生什么样的改变。也就是说这个人，以极快的速度严格的按照时间顺序来记录buffer的一个改变过程，这些日志会记录到logbuffer里面去，最后logbuffer会通过LGWR这个进程写到磁盘上的redolog里面去。

也就是说，我们的日志记录的是BUFFER的改变，并且按照时间顺序记录的，所以说日志里面记录的就是buffer里严格的按照时间顺序记录的buffer的整个改变过程。日志记录的是buffer的改变，日志是以buffer为单位来记录的，一个块的改变至少记录一条日志，安装改变的时间顺序来记录的。

1.2、日志记录方式

Oracle要记录这个buffer的改变：

一记录buffer地址也就是磁盘中数据块的地址
二时间点哪个时间改变的
三对这个数据块做了什么改变。

比如我们执行了一个delete的语句，删除了一万行，这一万行在一千个块``````里，这时我们大体粗略的认为产生了一千条日志，因为针对每一个块都产生一条日志。

1.3、时间日志产生的过程

oracle实例连接很多客户端会话，每一个会话都分到一个小块内存PAG，客户会话Oracle用server process处理，每个server process都会产生一个PAG，都有可能修改buffercache中的一个buffer，server process``````会将磁盘block块读到buffer里面去，会从内存buffer里面读到CPU里面去，也会修改buffer数据，所有的这些访问都是server process来做的，当然脏数据块写会的时候是使用的DBWR进程。server process每修改一次buffer的时候它会自己产生日志，先写到自己的PGA里面去，当写到一定程度的时候，它再从PGA写到logbuffer里面去，第二个serverprocess也一样。当修改某个buffer的时候它也会产生日志，也会从PGA写到logbuffer里面去。

实际的日志产生的过程：

serverprocess修改buffer产生日志写到自己的PGA里面去，在某些触发的条件下，会把日志写到logbuffer里面去，最终又通过进程LGWR写到磁盘的redolog里面去。

2 Oracle中的事务

Oracle有一个原则，所有已提交事务Oracle保证不会丢失，一个事务是由一条和多条增删改数据组成一个事务，就是一条或多条DML语句。关系型数据库的标准语言为结构化查询语言（STRUCTURED QUERY LANGUAGE），最多可分为六个类型：

数据查询语言（DQL:data query language）:如select语句

数据操作语言（DML:data manipulation language）:如Insert update delete 等

数据定义语言（DDL:data definition language）:如create dop alter等

数据控制语言（DCL:data control language）:如grant revoke deny等语句

事务处理语言（TPL:transaction process language）:如begin transaction commit rollback savepoint等语句

指针控制语言（CCL:cursor control language）:如declare sursor、fetch into、update where current等语句

事务和Oracle的一致性关系非常紧密，很多人就是因为在事务这个概念上没有注意。最后导致数据库的数据被损坏。在实际中事务很简单，事务就是由一条或多条增删改语句组成，比如，登陆数据库以后，开始一条delete语句，一个事务开始了，然后commit一个事务就结束了，commit以后再输入一条增伤语句的时候，一个事务又开始了，我们可以这么认为一个事务的开始和结束是在两个commit之间。

2.2、事务提交方法

2.2.1、假设提交是将修改的数据写到磁盘上

一个事务提交，将该事务所修改的块写到磁盘上，然后才是提交成功，就如客户端上我们操作很多dml语句后，执行COMMIT后，要过很久光标才返回。在提交一个事务的时候，如果这个事务修改了大量的块，commit的话，如果需要把脏数据块写到磁盘上，DBWR需要将这些大量的脏数据写到磁盘，需要消耗大量的IO，很耗时，用户等待commit完成需要很长时间，这样的话会感觉数据块很慢，所以说commit后，Oracle将该事务涉及的所有脏数据都写到磁盘上是不现实的。

2.2.2、事务的提交实际方法

一条事务开始以后，进行了DML操作以后，在修改的过程会产生很多的日志，这些日志在这个会话的PGA里面产生，产生以后会批量的快速的写到logbuffer里面去，logbuffer因为有空间限制、时间限制等，LGWR会相对较快的把日志写到redolog里面去。

会话serverprocess修改块的过程中产生很多日志，日志写到logbuffer，logbuffer由后台进程LGWR写到磁盘上，整个过程产生的日志都在logbuffer里面，logbuffer也会往redolog里写。Oracle在commit的时候，一提交Oracle就会触发LGWR把logbuffer的日志写到磁盘。

日志写的好处：

1、logbuffer写到redolog，在一个时间点只往一个redolog文件写入，每一个redoLog在磁盘上都是一块连续的空间，所以日志写的时候，寻道的次数会很少，而且是顺序写，脏数据写的时候磁盘位置很多时候是离散的。

2、当事务提交，Oracle只需触发LGWR把剩余的日志写到磁盘上就可以了。。

3、日志记录了数据块的所有的改变，一个数据快改变了，和磁盘上就不一样了，提交的时候没有把buffercache里的脏数据写到DBF，但是把脏块的修改记录以日志的形式记录下来，如果以后数据库崩溃了，之前已提交未写到磁盘上的脏数据可以通过日志前滚再次写到磁盘上。

快速提交

以上两点已经阐述了为什么会快速的把日志写到redolog中了，当会话进行COMMIT时，Oracle只是把logbuffer中的日志快速的写到redolog中，并没有实际把buffer写会磁盘，所以说对用户来讲，commit速度快，就认为Oracle很快，一旦光标返回就可以做下一件事。

3、日志和计算机缓存

缓存在很多软件上进行应用，对于计算机而言，有读缓存有写缓存。计算机中，读缓存是吧数据块调到内存中，读的时候可以到缓存里面去找，CPU去读这个块，只能读这个块，如果CPU要修改这个块，不能直接在内存修改，要修改需要直接修改磁盘上的，修改磁盘会产生IO，读缓存只对读有意义对写性能很低下，它只是能提高读的性能对写没有性能提高。Oracle因为实现了日志机制，修改了一个buffer块产生logbuffer日志马上写会磁盘redolog，commit以后一直保证写，commit就成功了。

在Oracle里面，Oracle的各种buffercache实现了写缓存，对写的块和对产生的日志写会磁盘进行缓存，所以对Oracle来讲实现了写缓存，日志写缓存的实现是通过日志的buffercache也就是logbuffer，它不仅仅对读有意义，对写也有意义。Oracle的buffercache不仅能提高读性能，还能提高性能。在整个计算机里面，Oracle数据库里面能够提高写缓存的只有两个地方，还有一个就是存储上的BUFFER，Oracle数据库很多都是建在各类型的存储上，存储上有buffer，buffer上有电池，也就是存储的buffer支持写缓存，存储中的单个硬盘本身也有缓存，只支持读缓存。

在整个Oracle的运行环境中，buffercache提供写缓存，文件系统也有缓存，只支持读缓存，不能写缓存。一般内存和磁盘的数据交换都要经过文件系统，内存的数据在从磁盘读取时要经过文件系统的读缓存，内存的数据在向磁盘写入时也要经过文件系统但此时文件系统不提供缓存，当然Oracle的存储体系实际工作中很少建在文件系统上，这样读写也不经过操作系统的文件系统了，Oracle读数据，先从磁盘到存储的buffer然后到文件系统的buffer再到buffercache。Oracle写数据时，redolog在存储上，LGWR写的时候会绕过文件系统的缓存，即绕过文件系统中的cache，这个cache只能缓存读，直接将日志写到存储的缓存里面，然后存储会控制在适当的时候写到磁盘里面去，存储的写缓存通过电池来实现的，为了保证数据不丢失要使用电池，当commit时，实际上数据库使用LGWR只是把数据从logbuffer写到存储的cache里，到底有没有写到磁盘上，数据库并不知道。如果存储出问题，电池没电了，这时数据就会丢失了，这时候redolog也可能损坏，这个需要注意。

commit提交以后，保证我这个事务所修改的所有的数据块对应的日志都已经写到redolog里面去了，数据库突然崩溃了，就是buffer里面的脏块没有了，数据库下次启动以后，就可以使用这些redolog把那些丢失的脏块再重新构造出来，就是能够将数据库恢复到崩溃前的那个时刻，也就是不会出现数据丢失。Oracle数据库数据恢复有实例恢复INSTANCE RECOVERY和介质恢复MEDIA RECOVERY，上面就是说的实例恢复。

实例恢复是Oracle实例出现失败后，Oracle自动进行的恢复，数据库出现实例故障，如断电、后台进程故障、或使用abort命令终止实例，在启动数据库时就会发现实例故障，此时就需要实例恢复，实例恢复是数据库自动进行的，可以将数据库恢复到故障之前的事务一致性状态。它可以确保buffer cache中的数据不会丢失，只用到redolog，不使用归档。

介质恢复主要用于介质故障引起数据库文件的破坏时使用，当存档数据库的介质出现故障时所做的恢复，介质故障时当一个文件、文件的一部分或磁盘不能读写时出现的故障，文件错误一般指意外的错误导致文件被删除或意外事务导致文件的不一致，这些状态下的数据库都是不一致的，需要DBA手工进行数据库的恢复。介质恢复用在丢失或损坏数据文件或控制文件的情形，将还原的数据文件恢复成当前数据文件，还能恢复数据文件异常脱机时没有来得及做检查点操作丢失的变更，介质恢复使用归档日志和联机日志，但必须由命令显示调用，即手工进行。

Oracle是通过日志保证已经提交的数据不会丢失，同时实现快速提交。

4、LGWR的触发条件

a、用户提交

b、有1/3重做日志缓冲区未写入磁盘

c、有大于1M的重做日志缓冲区未被写入磁盘

d、每隔3秒

e、DBWR需要写入的数据的SCN大于LGWR记录的SCN，DBWR触发LGWR写入

Oracle有这么一个机制，一个buffer脏了，Oracle保证这个buffer在写到磁盘以前，这个buffer变脏所做的操作对应的日志一定是写到磁盘了，就是DBWR被触发了，它要将40个脏块写到磁盘上，这个时候Oracle保证40个脏块所对应的日志已经写到磁盘上了，如果没有就写到磁盘就先触发LGWR写到磁盘，然后DBWR再往磁盘上写。对于Oracle来讲日志总是先于buffer写到磁盘上，日志写入优先机制。

5、log优化建议

数据库按进行的大多数数据处理情况可分为两种应用类型：

OLTP，联机事务处理（online transaction processing）系统是传统的关系型数据库的主要应用，表示事务性非常高的系统，并行事务处理多，但是一般都很短，使用一般用途活事务处理模板。

OLAP，联机分析处理（online analytical process）系统是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果，数据量大，DML少，使用数据仓库模板。正常的数据库一般都是OLTP。

在OLTP系统上，redo log文件的写操作主要是小型的，比较频繁，一般的写大小在几K，而每秒钟产生的写IO次数会达到几十次，数百次神指上千次。因为redo log文件适合存在于IOPS较高的转速较快的磁盘上。另外由于redo log文件的写入是串行的，因为对于redo log文件所做的底层条带化处理，对于redo log写性能的提升是十分有限的。

redolog放到存储上，对硬盘来讲有一个参数较IOPS(input/output operations per sccond)，每秒进行读写IO操作的次数，多用于OLTP数据库、小文件存储等场合，衡量磁盘随机访问的性能。整体来讲硬盘有stat盘，sas盘，fc盘，还有固态盘，对IOPS来讲从stat到sas到fs到ssd一次增加，ssd硬盘它的iops会达到几十万，当然不同的固态硬盘的IOPS性能差距是非常大的，它跟硬盘不一样，富士通的硬盘和希捷的硬盘都是sas盘他们的性能差不多，但是固态盘性能差距较大。

LGWR的特点是在写日志时：第一非常频繁，写的次数很多，每秒的IO次数很高，要求磁盘的IOPS必须很高；二每次写的量比较小；三它是顺序写，一个磁盘文件LGWR从logbuffer中顺序望redolog磁盘文件里写。

raid5raid6甚至包括raid10、raid01都是条带化，一块数据被条带的分布到多个硬盘上，可以并发，条带在这里没有意义，redolog不要放在raid5raid6上，因为他们的写性能很差，当然可以放到raid10和raid01上，最好放到固态盘上，现在狠多存储里面可以有一部分固态盘，同时还有一部分硬盘。如果redolog确实是因为IOPS非常高导致LGWR工作负担很大、写的很慢，产生一堆问题，这个问题很难解决的话，非常简答但涉及到硬件投资，采购固态硬盘，把你的redolog写进去，固态盘不需要很大，一个G就够了。

6、logbuffer设置多大

9i以前一般是3M，在10G以后Oracle会自动调整他的大小，它遵循这样一个原则，fixed sga size + redo buffers 是granule size的整数倍。

6.1、粒度

Oracle把它的sga和pga内存给它分成一个叫granule（粒度）的东西，这个粒度大小是Oracle自动去调整的，大小由一个隐含参数_ksmg_granule_size决定，最终分配的内存量都是这个参数的整数倍，sga组件buffer cache shared pool等都是按granule的整数倍来分配和释放的。

在Oracle9i中，sga<128M时，粒度值是4M，否则粒度依平台不同值可能为8M或16M，

在10G中这个参数的大小一般遵循如下原则：

sga_max_size <=1024m then _ksmg_granule_size=4m

sga_max_size >=1024m then _ksmg_granule_size=16m

另外在32位windows平台sga大于1G时参数默认值为8M

这个参数调整并不是任意的，还收到sga总量的限制，如果sga不够，即使调整参数也不会生效，只能调整到系统能够认到的最大值，可以使用alter system set “_ksmg_granule_size”=16777216 scope =spfile;调整它的值，重启数据库生效，在手动调整后还是要再由Oracle决定大小，最终又可能的值有4M 8M 16M。

执行一个sql语句看下粒度多大：

select * from v$sgainfo where name in ( ‘Fixed SGA Size’,‘Redo Buffers’,‘Granule Size’);

NAME BYTES RES

---

Fixed SGA Size 1219016 No

Redo Buffers 7168000 No

Granule Size 4194304 No

如granule size是4M，想给sga分配空间，比如我们给他分配161m，但是Oracle不会给它分配161的，它会用4对161取整，要不就是160要不就是164。粒度起始就是为了防止内存被分成小块，Oracle内存分配最好4M，防止小碎片的产生。

6.2、redo buffer的大小

原则：fixed sga size + redo buffers 是granule size的整数倍

在上面语句的查询结果中fixed sga size 1219016 no,fixed sga size的大小就是1m，redo buffer要不就是3M要不就是7M,一般fixed sga size和redo buffers的和是granule size的最小的整数倍。

7、redo log的组成

Oracle初始安装时redolog一般有三组，

select * from v$log;

GROUP# THREAD# SEQUENCE# BYTES MEMBERS ARCHIVED STATUS FIRST_CHANGE# FIRST_TIME

 1       1        35     52428800       1 NO   INACTIVE   1174677  20-10月-16

 2       1        36     52428800       1 NO   CURRENT   1185401  21-10月-16

 3        1        34     52428800       1 NO   INACTIVE   1161958  19-10月-16

group有3个就是有三个日志组，membets都是1表示每个日志组有一个成员。

select * from v$logfile;

GROUP# STATUS TYPE MEMBER IS_RECOVERY_DEST_FILE

 3 (null) ONLINE /u01/app/oracle/oradata/jiagulun/redo03.log NO

 2 (null) ONLINE /u01/app/oracle/oradata/jiagulun/redo02.log NO

 1 (null) ONLINE /u01/app/oracle/oradata/jiagulun/redo01.log NO

GROUP#为组号，MEMBER为组的成员，如/u01/app/oracle/oradata/jiagulun/redo03.log，可以每个组两个成员，这两个成员完全相等，就是互相备份的关系。redolog重要性比dbf都要重要，dbf可以丢，但是redolog千万不能丢失。比如我有四个组，每个组两个成员，一个组其中的一个成员放到一个磁盘上另外一个成员放到另外一个磁盘上，一个磁盘坏了还有另外一个成员，这叫冗余。

我们经常需要对日志进行一些改变，这和数据库备份恢复有关，备份恢复就是涉及一个体系性的方案，来解决Oracle的数据丢失的问题，将我们数据丢失的损失减少到最少。关于日志如何添加删除如下：

添加日志组：

alter database add logfile group 5 ‘/opt/oracle/oradata/dbtest/redo05_1.log’ size 10M;

给日志组添加成员：

alter database add logfile member ‘’/opt/oracle/oradata/dbtest/redo04_3.log’ to group 4;

删除日志组：

alter database drop logfile group 5;

删除组成员：

alter database drop logfile (‘’/opt/oracle/oradata/dbtest/redo05_1.log’,‘’/opt/oracle/oradata/dbtest/redo05_2.log’);

8、控制日志切换时间

有次一个学生找老师，说用户给我们提出一个需求，维护数据库可以丢数据，因为丢数据是没有办法的，但丢的额数据不能超过十分钟，怎么才能保证丢的数据不能超过十分钟。

其实这是很简单的一个问题，也是在备份恢复里面重点讲的一个东西，你只要知道Oracle的体系结构原理很容易设计出来，我们可以把数据库控制在用户提出的需求范围之内。

redolog切换的时间应该尽可能的不低于10-20分钟，建议是10-20分钟之间，这个地方是他控制数据丢失的问题。logbuffer对应redolog，写的时候先写第一个redolog，写满以后再写第二个，第一个写满了写第二个的时候叫切换，我们尽量控制写一个日志文件，从开始写到写满的时间在10-20分钟之内。根据当前日志的产生的速度我们可以调整它的大小，来控制这个时间。

8.1、调整日志大小

Oracle中redolog日志的大小是不能直接改变的，只能先删除原日志文件，然后建立新大小的文件。

例如现在蒸菜使用第二组，可把第三组改成20M，当切换写第三组的时候，再把第二组改成20M；

可以依次新建立三个日志组分配新的大小，然后删除原来的日志组；

也可以在原三组操作，删除当前未使用的组，再建立组名想的新组分配新的大小，然后切换当前日志，删除剩下的那个组，创建新的同名组成员及大小。

8.2、调整日志大小的实际例子

a)进入归档模式

因为控制日志切换时间是为了保存住日志，所以让redolog日志归档才有意义，在非归档模式虽然也有日志切换，但是切换后都扔掉了，再控制切换时间就没有意义了。

SQL> select GROUP# ,BYTES/1024/1024 size_M,STATUS,ARCHIVED from v$log;

GROUP#     SIZE_M STATUS           ARC

---

     1         50 INACTIVE         NO

     2         50 INACTIVE         NO

     3         50 CURRENT          NO

arc列都为no说明日志处于非归档模式，用命令看下当前归档模式，

archive log list;

Database log mode No Archive Mode --数据库日志模式目前非归档

Automatic archival Disabled --自动存档 未启用

Archive destination USE_DB_RECOVERY_FILE_DEST --归档终点

Oldest online log sequence 35 --最早的联机日志序列

Current log sequence 37 --当前的日志序列

也可以使用select log_mode from v$database;修改归档模式，需要重启数据库。

先关闭数据库，shutdown immediate;

再启动到mount状态，startup mount再切换至归档模式，

alter database archivelog --切换到自动归档模式

alter database archivelog manual --切换到手动归档模式

alter database noarchivelog --切换到非归档模式

最后再打开数据库，alter database open;

b)修改日志组成员大小

–1、查看当前日志组成员

SQL> select GROUP# ,BYTES/1024/1024 size_M,STATUS,ARCHIVED from v$log;

GROUP#     SIZE_M STATUS           ARC

---

     1         50 INACTIVE         YES

     2         50 INACTIVE         YES

     3         50 CURRENT          NO

SQL> select member from v$logfile;

MEMBER

---

/u01/app/oracle/oradata/jiagulun/redo03.log

/u01/app/oracle/oradata/jiagulun/redo02.log

/u01/app/oracle/oradata/jiagulun/redo01.log

从结果分析当前正在使用第三组，并且第一第二组处于非活动状态，所以下面删除第一第二组并重新建第一第二组并建立新大小的成员，因为Oracle每个实例的日志组最少不能少于两个，所以一二组不能同时删除，系统不让都删了只剩下第三组，需要一次的删除并且重建。

–2、删除重建日志组成员

删除并重建第一组日志

alter database drop logfile group 1;

SQL> select GROUP# ,BYTES/1024/1024 size_M,STATUS,ARCHIVED from v$log;

GROUP#     SIZE_M STATUS           ARC

---

     2         50 INACTIVE         YES

     3         50 CURRENT          NO

SQL> select member from v$logfile;

MEMBER

---

/u01/app/oracle/oradata/jiagulun/redo03.log

/u01/app/oracle/oradata/jiagulun/redo02.log

这时在操作系统中，/u01/app/oracle/oradata/jiagulun/redo01.log文件还存在，所以需要手动删除，mv /u01/app/oracle/oradata/jiagulun/redo01.log /tmp

建新组和成员

alter database add logfile group 1 (‘/u01/app/oracle/oradata/jiagulun/redo01.log’) size 100M;

用语句再次查看情况

select GROUP# ,BYTES/1024/1024 size_M,STATUS,ARCHIVED from v$log;

select member from v$logfile;

注意只有当日志组为unused（或Inactive）时才能删除，如果不是该状态的，需要切换日志组，alter system switch logfile;同样的操作删除并重建第二组日志。

重建第三组日志，需要先切换日志组，将其状态变成Inactive，再进行上述操作删除添加。

大小都是100M的日志组修改成功，修改系统检查点不能改变组的unused状态，需要切换日志后才会进入使用状态，数据库重启不会切换日志，但是active状态会变成Inactive状态，这里的status状态跟是否归档没有关系，active是指活动的非当前日志，在实例恢复时会被用到。active状态意味着，checkpoint尚未完成，因此该日志文件不能被覆盖，Inactive是非活动日志，在实例恢复时不再需要但在介质恢复时可能需要。

如果此redolog文件在Oracle进行实例恢复时有用它就是active，在需要进行实例恢复时没有用了，就是变成Inactive状态，一般可理解为如果此日志记录的信息所对应的buffer脏还没有写入磁盘它的状态就是active，如果此日志所记录的所有改变对应的所有buffer块已经没有了脏块，此日志就转换为Inactive状态。

–3、查看切换时间

select to_char(FIRST_TIME,‘yyyy-mm-dd hh24:mi:ss’) f_time,SEQUENCE# from v$log_history;

–4、archive_lag_target参数

上面的方法控制日志的切换，如不手工切换，最终都是在日志写满后自动的切换，想做到20分钟切换一次，需要根据实例的负载情况计算出日志在要求时间内产生多少，然后把redolog设置成相应的大小，在日志写满后进行切换，如果实例出现一次往往日志产生的数据量会发生变化，这样会造成日志切换并归档时间长短的变动，就很难保证在20分钟就会归档保存日志。

但是一个参数可以强制进行日志切换，ARCHIVE_LAG_TRAGET参数可以设置一个时间，通过时间限制，指定数据库强制进行日志切换，进行归档。日志切换后再自动归档模式下马上就会自动进行归档，若自动归档没打开，日志切换后就不归档当前重做日志。

SQL> show parameter archive_lag_target;

NAME TYPE VALUE

---

archive_lag_target integer 0

值为0表示禁用基于时间的日志切换功能，修改参数如下：

alter system set archive_lag_target=1200;设置日志切换时间为20分钟

查看当前数据库记录的归档日志信息：

sleect name ,completion_time from v$archived_log where name is not null;

非归档模式、手动归档模式和自动归档模式此参数都会使redolog自动切换，但手动模式切换后并不自动归档，归档需要手动完成，在手动归档模式下自动切换日志后若没有进行及时手动归档，当已归档日志用完后，Oracle实例就会停止自动切换而被挂起，等待可使用的redolog，并且手动切换日志也会无法执行等待可用日志文件，这是只能感觉给数据库日志进行手动归档，否则数据库只能读而不能写。

非归档模式下参数也有效会自动切换日志也可手动切换，但这种模式不要求日志必须归档，所以即使所有的日志都没有归档它仍然会不停的切换，不要求有已经归档的可用redolog文件，不会造成阻塞，自动模式在切换后会自动进行归档。