oracle学习笔记 logbuffer相关设置



oracle学习笔记  logbuffer相关设置

前面讲了oracle日志的工作机制
我们看一下logbuffer大小该如何设置呢

一）对软硬件的选择

从你第一次使用计算机开始，你就会一直碰到对软硬件选择的问题
每个人都一样
在你选择的时候别人也在选择，而且在相互影响

对个人来说最好要相信一个可靠的来源
你可以相信一句话，相信一个人，相信一个原理，也可以找到一个真理再去相信它
但你最终做的选择还是你自己的决定
也都是从自己的角度出发想对自己有好处，得到自己想要的

但在你得到一个物体后，可能和你想的并不一样，你不想要的也会随之而来

不用担心自己不知道做的选择对不对，
在整体的计算机世界每样软硬件的结果最终历史会给出一个最后的选择

二）LGWR的触发条件

还是oracle实例结构
buffercache、dbf和logbuffer、日志文件

看一下系统中的进程
[oracle@redhat4 ~]$ ps -ef|grep ora
结果中有这么一行
oracle   11913     1  0 02:26 ?        00:00:02 ora_lgwr_jiagulun
就是LGWR进程

这个进程负责把日志从内存logbuffer中写到磁盘redolog中

LGWR有触发机制
在下列情况下会把buffer中的数据写回磁盘

1、用户提交
commit的时候一定会触发LGWR把日志写回磁盘

2、有1/3重做日志缓冲区未被写入磁盘
比如说现在logbuffer是3M
当我的redolog达到1M的时候就会触发LGWR往磁盘写

3、有大于1M的重做日志缓冲区未被写入磁盘
也就是从某种意义上来讲LGWR负担不是很重的话
我的logbuffer中的日志一般不会超过1M

4、每隔3秒钟会触发LGWR

5、DBWR需要写入的数据的SCN大于LGWR记录的SCN，DBWR触发LGWR写入
这个个最重要
前四个很容易理解第五个这个非常关键

前面讲过DBWR的触发机制，它和LGWR之间一般的情况下没什么关系
DBWR触发DBWR的，LGWR触发LGWR的，各写各的东西

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

对oracle来讲日志总是先于buffer写到磁盘上
就是 Write-Ahead-Log 日志写入优先
也是和oracle的一致性有关系

如下面这种情况
假设在事务提交时，
还没有把日志写入redolog，而直接使用DBWR向磁盘写脏buffer
这时突然掉电，
结果dbf没有写完，redolog中也没有日志
而写了一半的dbf块块中的数据就是错误的
想恢复，没有redolog没法做到
这样这个数据库最终产生错误，数据库就不一致了，
而且无法恢复到这次操作前的状态

如果提交以写入了redolog结束
写入redolog时掉电，那么事务没有提交成功这时不影响一致性
日志写完了内存脏块在写入磁盘时掉电
修改的数据已被写入了日志，这时就可以恢复

三）LOG优化建议

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

OLTP，联机事务处理（Online Transaction Processing）系统
是传统的关系型数据库的主要应用
表示事务性非常高的系统，以小的事务以及小的查询为主
数据量少，DML频繁，并行事务处理多，但是一般都很短
使用一般用途或事务处理模板
OLAP，联机分析处理（Online Analytical Processing）系统
是数据仓库系统的主要应用，
支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果
数据量大，DML少
使用数据仓库模板

正常的数据库一般都是OLTP

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

redolog放到存储上
对硬盘来讲有一个参数叫IOPS(Input/Output Operations Per Second)，
即每秒进行读写（I/O）操作的次数
多用于OLTP数据库、小文件存储等场合，衡量磁盘随机访问的性能

logbuffer写到redolog用LGWR进程

整体来讲硬盘有sata硬盘、sas硬盘、fc硬盘、还有一种硬盘叫固态盘
对IOPS来讲从sata到sas到fc到ssd依次增加
ssd硬盘它的iops会达到几十万
当然不同的固态盘它的IOPS、它的性能差距是非常大的，它跟硬盘不一样
富士通的硬盘和希捷的硬盘都是sas硬盘它的性能差不多
但是固态盘我们测得性能差距很大

LGWR的特点是在写日志时

第一非常频繁，也就是写的次数很多，IOPS很多，每秒的I/O次数很高
要求磁盘IOPS必须很高

第二它每次写的量比较小

第三它是顺序写
一个磁盘文件LGWR从logbuffer中顺序往redolog磁盘文件里写

前面讲的raid5、raid6甚至包括raid10、raid01它们都是条带化
一块数据被条带的分布到多个硬盘上，可以并发
条带在这里没有意义
redolog不要放到raid5 raid6上因为它们的写性能很差
当然可以放到raid10和raid01上
最好是放到固态盘上
现在很多存储里面可以有一部分固态盘同时还有一部分硬盘

如果你的redolog确实是因为IOPS非常高导致LGWR工作负担很大、写的很慢，
产生一堆问题，这个问题很难解决的话
非常简单但可能涉及到硬件投资了
去买一批固态盘把你的redolog写进去
当然这个固态盘空间很小就可以不需要太大
大约有一个G以内可能就够了

这些知识如果以前对计算机比较熟应该能懂，基本就够用了

四）logbuffer设多大

9i以前，一般是3M
3M就够了，这里大小不是问题

在10g中ORACLE会自动调整它的值，他遵循这样一个原则，
'Fixed SGA Size'+ 'Redo Buffers'是granule size的整数倍
这是从oracle9开始出现的新特性

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-bit Windows平台sga大于1G时参数默认值为8M

这个参数调整并不是任意的，还受到sga总量的限制，
如果sga不够，即使调整参数也不会生效，只能调整到系统能够认到的最大值

可以使用
alter system set "_ksmg_granule_size"=16777216 scope=spfile;
调整它的值，重启数据库生效

在手动调整后还是要再由oracle决定大小，最终有可能的值有4M、8M、16M

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

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                        4194304 No
说明Granule Size的大小是4M

SGA空间再大一些，Granule Size还会大一些
也可能8M也可能16M

如Granule Size当前是4M，想给SGA分配空间
比如说我们给它分配161M
但oracle不会给它分配161M
它会用4对161给它取整
要不就是160，要不就是164

粒度其实就是为了防止分内存的时候很多内存被分成小块
oracle内存分配最好4M为单位
防止小碎片的产生

2）Redo Buffers的大小

原则：'Fixed SGA Size'+ 'Redo Buffers'是granule size 的整数倍

在上面语句的查询结果中
Fixed SGA Size                      1219016 No

Fixed SGA Size的大小是1M

Redo Buffers要不就是3M要不就是7M
3M的话加上上面Fixed SGA Size的大小1M就是4M
是Granule Size的整数倍
7M的话加上上面Fixed SGA Size的1M最后是8M
也是Granule Size的整数倍
一般Fixed SGA Size和Redo Buffers的和是granule size的最小的整数倍

结果中
Redo Buffers                        7168000 No
这里因为Redo Buffers取3M太小了所以使用了7M

如果现在granule是16M的话
如果Fixed SGA Size的大小是1M
Redo Buffers的大小就可以是15M

默认是这么来取的，它取的值一般都够
因为redo buffer空间往往不是问题

五）oracle SQL Developer

oracle SQL Developer是一个图形化的客户端工具
它可以连接和管理oracle的数据库

启动后建立连接才能使用
连接名自己取
用户名使用自己想使用的用户
主机名我使用了oracle所在虚拟机的ip：192.168.3.47
建立的连接使用oracle的监听端口，一般端口号为1521
SID为要连接的当前实例名，我这里是建立数据库时取得实例名jiagulun

连接上以后可以看到oracle数据库中的对象
在 'Data Miner连接' 窗口都列出来了
连接用户可见的所有的用户的所有对象如表视图索引等都可以找到
对这些对象的操作，只能在所连接的用户有权限才能进行

在对应连接的 'SQL工作表' 窗口中工作表标签页内可以执行sql语句
执行时弹出 '查询结果' 窗口显示二维的表结构的结果

还有相关的类似的一些工具，比如pl/sql developer、toad（蟾蜍）等
它们在界面上可能更友好一些
老师不建议用那些工具，它们是要花钱的，
下载的多是破解版的，往往版本比较低
oracle版本高使用了一个管理它的工具版本低
就可能把oracle搞坏
或者说oracle一些新的性能，新的一些功能你发现不了

对oracle的sql developer你可以下到最新版的因为它是免费的
虽然界面没那么很友好，但是也很好用
特别是在右上角的一个下拉列表框
有oracle的最经典的论坛网站，当然都是英文的
学oracle的话他们是最经典的，特别是AskTom

如果oracle出现什么错误什么问题
在这里如选中asktom查询，
它就自动跳到asktom网站上去找到相关的一些文章展示给你

比如在这里选择metalink
再输入问题的描述，如4031
一回车
在 '消息-日志' 窗口它就会给出一个网址
并且软件会自动在默认浏览器打开这个网页
查询使用网站metalink或asktom里面相关的4031的错误就会给列出来
直接看就ok了，非常有帮助

在这里还有oracle的在线官方文档10G的11G的9的
还有OTN的一个论坛
这都非常好，要慢慢习惯去用

六）redolog的组成

oracle初始安装时redolog一般有三组

在sql developer中执行
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个即有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为组3的日志文件

可以看到GROUP#有三个即有三个组，
每个组对应有一个成员MEMBER，三个组每个组有一个成员

可以每个组两个成员，这两个成员就完全相等
就是互相备份的关系

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')

有了这几个命令就可以对日志的整个体系结构进行变化了

这些命令相关的文件，老师都会放到网上
我们到论坛www.jiagulun.com上去找去下载就可以了

七）控制日志切换时间

有一次一个学生找老师
说项老师很奇怪啊
我们用户给我们提出了一个需求
用户说你给我维护数据库可以丢数据
因为丢数据是没有办法的
但丢的数据不能超过十分钟
他说很奇怪怎么保证丢的数据不能超过十分钟

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

REDO LOG切换的时间应该尽可能的不低于10-20 分钟
我们的建议是10-20分钟之间
这个地方是它控制数据丢失的问题

logbuffer对应redolog
写的时候先写第一个redolog
写满以后再写第二个
第一个写满了以后写第二个的时候叫切换
我们尽量的控制一个日志文件
从开始写到写满的时间控制在10-20分钟以内

根据当前日志的产生速度我们可以调整它的大小
让一个日志文件写满后产生切换的时间控制在10-20分钟以内

1）调整日志大小

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

比如现在我正在使用第二组
可把第三组改成20M大小
第三组下面写的时候就用20M了
在往第三组写的时候
再把第二组改成20M

可以一次新建立三个日志组并建立新组成员为新大小
然后删除原来的三组

也可以只在原三组操作
删除当前未使用的组再建组名相同的新组并建立新组成员大小为新大小
然后切换当前日志
删除剩下的那个组并建新同名组和建新组成员为新大小

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说明日志处于非归档模式

用命令看一下当前归档模式

SQL> 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

有一行
Database log mode              No Archive Mode
说明是非归档模式

也可以使用
SQL> SELECT log_mode FROM v$database;

LOG_MODE
------------
NOARCHIVELOG

也是非归档模式

下面修改归档模式，需要重启数据库

1、一致性关闭数据库

SQL> shutdown immediate;
Database closed.
Database dismounted.
ORACLE instance shut down.

2、启动到mount阶段

SQL> startup mount;
ORACLE instance started.

Total System Global Area  285212672 bytes
Fixed Size                  1219016 bytes
Variable Size              96470584 bytes
Database Buffers          180355072 bytes
Redo Buffers                7168000 bytes
Database mounted.

3、切换归档模式
可以
切换到自动归档模式
ALTER DATABASE ARCHIVELOG;
切换为手工归档模式
ALTER DATABASE ARCHIVELOG MANUAL;
切换到非归档模式
alter database noarchivelog;
这三种都要在这一步完成，open状态的数据库无法完成

这里切换到自动归档模式
SQL> ALTER DATABASE ARCHIVELOG;

Database altered.

4、数据库切换到open阶段

SQL> ALTER DATABASE OPEN;

Database altered.

这样数据库进入到了归档模式

SQL> SELECT log_mode FROM v$database;

LOG_MODE
------------
ARCHIVELOG

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

每个数据成员为50M

日志组成员情况
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、删除重建日志组及成员

SQL> alter database drop logfile group 1;

Database altered.

目前的组情况

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
文件还存在所以要先在操作系统把这个文件删除

[oracle@redhat4 ~]$ mv  /u01/app/oracle/oradata/jiagulun/redo01.log /tmp

建新组和成员
SQL> alter database add logfile group 1 ('/u01/app/oracle/oradata/jiagulun/redo01.log') size 100M;

Database altered.

成功

再看一下组情况
SQL> select GROUP#  ,BYTES/1024/1024 size_M,STATUS,ARCHIVED from v$log;

    GROUP#     SIZE_M STATUS           ARC
---------- ---------- ---------------- ---
         1        100 UNUSED           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

同样修改第二组
SQL> alter database drop logfile group 2;
[oracle@redhat4 ~]$ mv  /u01/app/oracle/oradata/jiagulun/redo02.log /tmp
SQL> alter database add logfile group 2 ('/u01/app/oracle/oradata/jiagulun/redo02.log') size 100M;

这时的组情况和组成员的情况
SQL> select GROUP#  ,BYTES/1024/1024 size_M,STATUS,ARCHIVED from v$log;

    GROUP#     SIZE_M STATUS           ARC
---------- ---------- ---------------- ---
         1        100 UNUSED           YES
         2        100 UNUSED           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

这时只剩下第三组了
因为它正在使用无法删除所以要先手动切换一下日志
SQL> alter system switch logfile;

System altered.

切换后的组情况
SQL> select GROUP#  ,BYTES/1024/1024 size_M,STATUS,ARCHIVED from v$log;

    GROUP#     SIZE_M STATUS           ARC
---------- ---------- ---------------- ---
         1        100 CURRENT          NO
         2        100 UNUSED           YES
         3         50 ACTIVE           YES

第三组处于ACTIVE状态仍然无法删除
这时可以再次切换日志
也可以切换一次检查点

SQL> alter system checkpoint;

System altered.

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

    GROUP#     SIZE_M STATUS           ARC
---------- ---------- ---------------- ---
         1        100 CURRENT          NO
         2        100 UNUSED           YES
         3         50 INACTIVE         YES

第三组目前为INACTIVE可以删除了
切换检查点可以使所有ACTIVE状态变为INACTIVE
多次执行日志切换也可以达到目的，但有时须多次才能做到

依次执行
SQL> alter database drop logfile group 3;
[oracle@redhat4 ~]$ mv  /u01/app/oracle/oradata/jiagulun/redo03.log /tmp
SQL> alter database add logfile group 3 ('/u01/app/oracle/oradata/jiagulun/redo03.log') size 100M;

再看一下组情况

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

    GROUP#     SIZE_M STATUS           ARC
---------- ---------- ---------------- ---
         1        100 CURRENT          NO
         2        100 UNUSED           YES
         3        100 UNUSED           YES

大小都是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;

执行结果较多只列出一部分
F_TIME               SEQUENCE#
2016-04-11 13:40:01          1
2016-04-11 13:41:27          2
2016-04-11 13:41:36          3
2016-05-13 08:33:47          4
2016-05-14 08:15:22          5
.
.
.
2016-10-19 10:25:59         34
2016-10-20 07:01:19         35

SEQUENCE#列是日志的编号
两行的时间差就是发生两次切换间隔的时间
从一号切开始到二号切开始用了1分半钟
从二号切开始到三号开始切换可能是手工切的速度非常快

这里只是实验环境没有负载而且经常关机所以切换时间有些不符合逻辑，不必细究
虽然关机不会造成日志的切换但关机后库不使用了一个日志写满的时间就会出奇的长
正常的情况在生产高峰期的时候，应该控制在十分钟左右

使用一些命令可以手工的去切

ALTER SYSTEM ARCHIVE LOG CURRENT;
为归档命令也会造成日志切换
或
alter system switch logfile;
直接切换日志组

我们执行
SQL> alter system switch logfile;

System altered.

再看归档的日志的切换
SQL> select to_char(FIRST_TIME,'yyyy-mm-dd hh24:mi:ss') f_time,SEQUENCE# from v$log_history;

F_TIME               SEQUENCE#
------------------- ----------
2016-04-11 13:40:01          1
2016-04-11 13:41:27          2
2016-04-11 13:41:36          3
2016-05-13 08:33:47          4
2016-05-14 08:15:22          5
.
.
.
2016-10-19 10:25:59         34
2016-10-20 07:01:19         35
2016-10-21 08:29:09         36

36 rows selected.

比刚才多了一行
就是当前用的redolog不管写没写满把它强行的关了，让它写下一个

4）ARCHIVE_LAG_TARGET参数

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

但有一个参数可以强制进行日志切换
ARCHIVE_LAG_TARGET参数可以设置一个时间，
通过时间限制，指定数据库强制进行日志切换（Log Switch），进行归档

日志切换后在自动归档模式下马上就会自动进行归档
若自动归档没有打开，日志切换后就不归档当前重做日志

SQL> show parameter archive_lag_target;

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
archive_lag_target                   integer     0

值为0表示表示禁用基于时间的日志切换功能

修改此参数
alter system set archive_lag_target=1800;
设置日志切换时间为30分钟。
我的系统中当前日志归档的系统目录为：
/u01/app/oracle/flash_recovery_area/JIAGULUN/archivelog/
在下一级有对应日期的子目录，其下可以找到一个日期中归档的所有日志

查看归档日志的文件名和归档完成时间的命令
alter session set nls_date_format='yyyy-mm-dd hh24:mi:ss';

select name,COMPLETION_TIME from v$archived_log where name is not null;

非归档模式、手动归档模式和自动归档模式此参数都会造成redolog的自动切换

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

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

自动模式在切换后会自动进行归档

八）小结

这是我们给大家讲的日志的知识
REDO LOG切换的时间应该尽可能的不低于10-20 分钟
关于归档的知识放到备份恢复里面去讲

2016年11月1日

                                                                                                             文字：韵筝