首先我们来看下什么是archive log file，oracle 11g 的concept中是这样定义的：When you enable archiving of the online redo logs, Oracle Database copies the online redo log files to another location before they are overwritten. These copied files are referred to as archived redo log files. 那么根据这个定义，archive log file就是redo log file的拷贝，既然是拷贝，在排除压缩的情况下，两种文件的大小应该是一致的。但是我们在真实环境中看到的archive log file就是redo log file却不是一样大，真实情况是archive log file比redo log file小，极端情况下，甚至会小非常多。
     引起archive log file就是redo log file大小不一致的原因大致有如下几种：
           一、人为操作类型
                 1、SQL>alter system switch logfile;
                 2、SQL>alter system archive log current;
                 3、RMAN>backup archive log all;
                 4、RMAN>backup database plus archivelog;
           二、参数设置类型
                 archive_lag_target：日志切换的强制时间间隔，即只要到达该参数设置的时间间隔，无论redo 文件是否写满，都会进行日志切换。
           三、oracle bug类型
                 BUG 9272059、BUG 10354739、BUG 12317474、BUG 5450861、BUG 7016254
      下面对archive log file就是redo log file大小不一致的原因进行分析，首先，如果redo log file中是以空白结尾，那么，archive log file中会将末尾的空白去除，这就样就会出现archive log比redo log file小，具体小多少，就根据归档时redo log file末尾的空白大小决定。这种情形常见于前面提到的认为操作类型和参数设置类型。因为在进行强制切换日志的时候，redo log file是没有被写满的，文件的末尾必然存在空白。
      另外，日志切换并不是发生redo log file 100%满的时候，这是由于oracle的内部算法决定的，这样做的主要目的是处于性能的考虑。所以redo log file始终不会被100%的写满，在进行归档的时候，末尾的空白会被丢弃，所以就导致了archive log file小于redo log file。影响redo log切换时间的因素有：LOG_BUFFER_SIZE参数设置、系统负载、log file size、logfile 空间分配算法。
CUP_COUNT值会影响logfile空间分配算法，所以，如果出现日志频繁切换且归档日志远小于redo log file的情况，请检查CUP_COUNT是否符合系统的实际情况。
       再次，如果是RAC环境，如果各节点的负载不一致，为了保证数据库的可恢复性，空闲节点会进行一些的日志切换，主要是为了增进redo 日志的FIRST_CHANGE#，空闲节点产生的归档日志大小会与redo file大小有较大差距。下面进行验证：

  1. --查看redo file大小
  2. SQL> select thread#,group#,bytes/1024/1024 "size" from v$log order by 1,2;
  3. THREAD# GROUP# size
  4. ---------- ---------- ----------
  5. 1 1 50
  6. 1 2 50
  7. 2 3 50
  8. 2 4 50
  9. --在节点1上建立测试表
  10. SQL> create table darren(id number,item varchar2(2));
  11. --查看当前的归档情况和redo log的FRIST_CHANGE#
  12. SQL> select thread#,name,blocks*block_size/1024/1024 "size" from v$archived_log order by 1,2;
  13. THREAD#                             NAME                                          size
  14. ---------- ---------------------------------------------------------------------- ----------
  15. 1          +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_10.268.861729569 1.4453125
  16. 1          +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_11.270.861730475 49.9980469
  17. 1          +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_12.271.861730509 49.9980469
  18. 1          +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_13.272.861730545 49.9980469
  19. 1          +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_14.274.861730573 49.9980469
  20. 1          +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_15.275.861730601 49.9980469
  21. 1          +DATADG01/gyl/archivelog/2014_10_24/thread_1_seq_16.276.861788401 35.8242188
  22. 2          +DATADG01/gyl/archivelog/2014_10_23/thread_2_seq_2.269.861729571 2.37207031
  23. 2          +DATADG01/gyl/archivelog/2014_10_23/thread_2_seq_3.273.861730551 .008300781
  24. 2          +DATADG01/gyl/archivelog/2014_10_24/thread_2_seq_4.277.861788403 .567871094
  25. SQL> select GROUP#,THREAD#,SEQUENCE#,STATUS,FIRST_CHANGE# from v$log order by 2;
  26. GROUP#     THREAD#  SEQUENCE#       STATUS     FIRST_CHANGE#
  27. ---------- ---------- ---------- ---------------- -------------
  28. 1            1        17          CURRENT        794878
  29. 2            1        16          INACTIVE       700672
  30. 3            2        5           CURRENT        794876
  31. 4            2        4           INACTIVE       517670
  32. --在节点1上进行事务，由于是测试环境，节点2上完全没事务，是空闲实例
  33. begin
  34. for i in 1..500000 loop
  35. insert into darren values(1,'aa');
  36. commit;
  37. end loop;
  38. end;
  39. --查看归档情况和redo log 的FRIST_CHANGE#
  40. SQL> select thread#,name,blocks*block_size/1024/1024 "size" from v$archived_log order by 1,2;
  41. THREAD#                             NAME                                          size
  42. ---------- ---------------------------------------------------------------------- ----------
  43. 1       +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_10.268.861729569     1.4453125
  44. 1       +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_11.270.861730475     49.9980469
  45. 1       +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_12.271.861730509     49.9980469
  46. 1       +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_13.272.861730545     49.9980469
  47. 1       +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_14.274.861730573     49.9980469
  48. 1       +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_15.275.861730601     49.9980469
  49. 1       +DATADG01/gyl/archivelog/2014_10_24/thread_1_seq_16.276.861788401     35.8242188
  50. 1       +DATADG01/gyl/archivelog/2014_10_24/thread_1_seq_17.278.861791005     49.9980469
  51. 1       +DATADG01/gyl/archivelog/2014_10_24/thread_1_seq_18.279.861791039     49.9980469
  52. 1       +DATADG01/gyl/archivelog/2014_10_24/thread_1_seq_19.281.861791071     49.9980469
  53. 1       +DATADG01/gyl/archivelog/2014_10_24/thread_1_seq_20.282.861791091     49.9980469
  54. 1       +DATADG01/gyl/archivelog/2014_10_24/thread_1_seq_21.283.861791119     49.9980469
  55. 2       +DATADG01/gyl/archivelog/2014_10_23/thread_2_seq_2.269.861729571     2.37207031
  56. 2       +DATADG01/gyl/archivelog/2014_10_23/thread_2_seq_3.273.861730551     .008300781
  57. 2       +DATADG01/gyl/archivelog/2014_10_24/thread_2_seq_4.277.861788403     .567871094
  58. 2       +DATADG01/gyl/archivelog/2014_10_24/thread_2_seq_5.280.861791047     .791503906
  59. 2       +DATADG01/gyl/archivelog/2014_10_24/thread_2_seq_6.284.861791125     .000976563
  60. （thread_1_seq_17至thread_1_seq_21为insert过程中节点1产生的归档，大小都接近redo file大小，thread_2_seq_5和thread_2_seq_6为节点2产生的归档，远小于redo file大小）
  61. SQL> select GROUP#,THREAD#,SEQUENCE#,STATUS,FIRST_CHANGE# from v$log order by 2;
  62. GROUP#      THREAD#   SEQUENCE#      STATUS      FIRST_CHANGE#
  63. ---------- ---------- ---------- ---------------- -------------
  64. 1           1         21          ACTIVE         1206256
  65. 2           1         22          CURRENT        1308608
  66. 3           2         7           CURRENT        1338258
  67. 4           2         6           INACTIVE       1014874
  68. （可以看到，节点2的FIRST_CHANGE#也跟进了，这里还超过了节点1的）

再考虑一种极端情况，如果节点2已经down了，那么，节点2的归档将会由节点1进行代为执行，同样会推进节点2的redo log的FIRST_CHANGE#，继续上面的实验：

  1. --关闭节点2
  2. SQL> shutdown immediate
  3. Database closed.
  4. Database dismounted.
  5. ORACLE instance shut down.
  6. --继续在节点1插入数据
  7. begin
  8. for i in 1..500000 loop
  9. insert into darren values(1,'aa');
  10. commit;
  11. end loop;
  12. end;
  13. --查看归档情况和redo log 的FRIST_CHANGE#
  14. SQL> select thread#,ARCHIVAL_THREAD#,name,blocks*block_size/1024/1024 "size" from v$archived_log order by 1,2;
  15. THREAD# ARCHIVAL_THREAD#                               NAME                                        size
  16. ---------- ---------------- ---------------------------------------------------------------------- ----------
  17. 1           1            +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_10.268.861729569     1.4453125
  18. 1           1            +DATADG01/gyl/archivelog/2014_10_24/thread_1_seq_18.279.861791039     49.9980469
  19. 1           1            +DATADG01/gyl/archivelog/2014_10_24/thread_1_seq_27.291.861795885     49.9980469
  20. 1           1            +DATADG01/gyl/archivelog/2014_10_24/thread_1_seq_26.290.861795861     49.9980469
  21. 1           1            +DATADG01/gyl/archivelog/2014_10_24/thread_1_seq_25.289.861795837     49.9980469
  22. 1           1            +DATADG01/gyl/archivelog/2014_10_24/thread_1_seq_24.287.861795815     49.9980469
  23. 1           1            +DATADG01/gyl/archivelog/2014_10_24/thread_1_seq_23.286.861795789     49.9980469
  24. 1           1            +DATADG01/gyl/archivelog/2014_10_24/thread_1_seq_22.285.861795765     49.9980469
  25. 1           1            +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_11.270.861730475     49.9980469
  26. 1           1            +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_12.271.861730509     49.9980469
  27. 1           1            +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_13.272.861730545     49.9980469
  28. 1           1            +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_14.274.861730573     49.9980469
  29. 1           1            +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_15.275.861730601     49.9980469
  30. 1           1            +DATADG01/gyl/archivelog/2014_10_24/thread_1_seq_16.276.861788401     35.8242188
  31. 1           1            +DATADG01/gyl/archivelog/2014_10_24/thread_1_seq_17.278.861791005     49.9980469
  32. 1           1            +DATADG01/gyl/archivelog/2014_10_24/thread_1_seq_19.281.861791071     49.9980469
  33. 1           1            +DATADG01/gyl/archivelog/2014_10_24/thread_1_seq_20.282.861791091     49.9980469
  34. 1           1            +DATADG01/gyl/archivelog/2014_10_24/thread_1_seq_21.283.861791119     49.9980469
  35. 2           1            +DATADG01/gyl/archivelog/2014_10_24/thread_2_seq_8.292.861795895     .000488281
  36. 2           1            +DATADG01/gyl/archivelog/2014_10_24/thread_2_seq_7.288.861795827     .921386719
  37. 2           1            +DATADG01/gyl/archivelog/2014_10_24/thread_2_seq_4.277.861788403     .567871094
  38. 2           2            +DATADG01/gyl/archivelog/2014_10_24/thread_2_seq_5.280.861791047     .791503906
  39. 2           2            +DATADG01/gyl/archivelog/2014_10_23/thread_2_seq_3.273.861730551     .008300781
  40. 2           2            +DATADG01/gyl/archivelog/2014_10_24/thread_2_seq_6.284.861791125     .000976563
  41. 2           2            +DATADG01/gyl/archivelog/2014_10_23/thread_2_seq_2.269.861729571     2.37207031
  42. (注意thread_2_seq_7和thread_2_seq_8，他们的归档是由thread 1 执行的，参看THREAD# 和ARCHIVAL_THREAD# 列，这两个归档正是在实例2关闭的时候生成的)
  43. SQL> select GROUP#,THREAD#,SEQUENCE#,STATUS,FIRST_CHANGE# from v$log order by 2;
  44. GROUP#     THREAD#  SEQUENCE#        STATUS     FIRST_CHANGE#
      ---------- ---------- ---------- ---------------- -------------
          1           1         27           ACTIVE         1831962
          2           1         28           CURRENT        1935906
          3           2         9            CURRENT        1955175
          4           2         8            INACTIVE       1690602

由于redo wastage的存在，redo log file中间也会存在空白，那这部分空白会不会被丢弃呢？首先看下什么是redo wastage，简单的说就是LGWR进程在写redo log file的时候是按操作系统的标准块为单位进行写入的，具体块的大小，可以使用下述语句进行查询：

  1. select max(l.lebsz) log_block_size_kccle
  2. from sys.x$kccle l
  3. where l.inst_id = userenv('Instance');

假设标准块大小为512字节，在一次写入操作中一共要写入1036字节数据，那么就需要3个标准块，尽管第三个块没有被写满，但是SGA中redo log写入的指针会跳转到下面一个块，这里的第三个块剩下的空间就被浪费了，这就是 redo wastage。减少这种情况的方法就是减少commit次数。
                                               
     下面通过实验观察redo wastage造成的空白会不会在归档的时候被丢弃：

  1. --查看redo file大小
  2. SQL> select group#,bytes/1024/1024 \"size(M)\" from v$log;
  3. GROUP# size(M)
  4. ---------- ----------
  5. 1 50
  6. 2 50
  7. 3 50
  8. --建立测试表
  9. SQL> create table darren(id number,item varchar2(2));
  10. Table created.
  11. --查看当前归档的情况
  12. SQL> select SEQUENCE#,ARCHIVED,status,COMPRESSED from v$archived_log;
  13. SEQUENCE#  ARC S COM
    ---------- --- - ---
       81      YES A NO
       82      YES A NO
       83      YES A NO
       84      YES A NO
       85      YES A NO
       86      YES A NO
       87      YES A NO
       88      YES A NO
       89      YES A NO
       90      YES A NO
  14. --查看当前的redo size和redo wastage
  15. SQL> select name,value from v$sysstat where name in('redo size','redo wastage');
  16. NAME                                       VALUE
  17. --------------------- ------------------------------------------ ----------
  18. redo size                                 258664912
  19. redo wastage                              86181420
  20. --向测试表插入数据，产生redo记录
  21. begin
  22. for i in 1..500000 loop
  23. insert into darren values(1,'aa');
  24. commit;
  25. end loop;
  26. end;
  27. --切换一起日志，将insert过程中产生的redo文件全部归档
  28. SQL> alter system archive log current;
  29. System altered.
  30. --查看现在的redo size和redo wastage
  31. SQL> select name,value from v$sysstat where name in('redo size','redo wastage');
  32. NAME           VALUE
  33. ---------- ------------
  34. redo size    512888704
  35. redo wastage 202172176
  36. --计算insert过程中产生的redo size和redo wastage
  37. SQL> select 512888704-258664912 redo from dual;
  38. REDO
  39. ----------
  40. 254223792
  41. SQL> select 202172176-86181420 wastage from dual;
  42. WASTAGE
  43. ----------
  44. 115990756
  45. --计算redo wastage的比例
  46. SQL> select 115990756/254223792 from dual;
  47. 115990756/254223792
  48. -------------------
  49. .456254527
  50. --查看insert 过程中产生的archive log file
  51. SQL> select SEQUENCE#,ARCHIVED,status,COMPRESSED from v$archived_log;
  52. SEQUENCE# ARC S COM
  53. ---------- --- - ---
  54. 81 YES A NO
  55. 82 YES A NO
  56. 83 YES A NO
  57. 84 YES A NO
  58. 85 YES A NO
  59. 86 YES A NO
  60. 87 YES A NO
  61. 88 YES A NO
  62. 89 YES A NO
  63. 90 YES A NO
  64. 91 YES A NO
  65. 92 YES A NO
  66. 93 YES A NO
  67. 94 YES A NO
  68. 95 YES A NO
  69. 96 YES A NO
  70. 97 YES A NO
  71. 98 YES A NO
  72. 99 YES A NO
  73. 从91号归档开始为本次insert操作产生的归档
  74. --查看归档文件大小
  75. [oracle@oracle11g archive]$ ls -trl
  76. -rw-r----- 1 oracle oinstall 49917440 Oct 23 13:49 orcl_1_91_851966182.arc
  77. -rw-r----- 1 oracle oinstall 49257472 Oct 23 13:49 orcl_1_92_851966182.arc
  78. -rw-r----- 1 oracle oinstall 49896448 Oct 23 13:50 orcl_1_93_851966182.arc
  79. -rw-r----- 1 oracle oinstall 44149760 Oct 23 13:50 orcl_1_94_851966182.arc
  80. -rw-r----- 1 oracle oinstall 49917440 Oct 23 13:50 orcl_1_95_851966182.arc
  81. -rw-r----- 1 oracle oinstall 44199936 Oct 23 13:50 orcl_1_96_851966182.arc
  82. -rw-r----- 1 oracle oinstall 46582784 Oct 23 13:51 orcl_1_97_851966182.arc
  83. -rw-r----- 1 oracle oinstall 48513536 Oct 23 13:51 orcl_1_98_851966182.arc
  84. -rw-r----- 1 oracle oinstall    13312 Oct 23 13:51 orcl_1_99_851966182.arc

根据实验数据显示，redo wastage的比例约为46%，redo log大小为50M，忽略文件末尾的空白影响，如果归档时丢弃redo wastage产生的日志文件中间的空白，那么，归档文件的大小约为50*1024*1024*46%=24117248字节。从实验数据看，归档日志都远大于 24117248字节（不考虑99号日志，该日志为手动切换产生）。
     结论：归档时不会丢弃由于redo wastage产生的redo log file中间的空白。
    另外再说明一点，由于某些BUG的存在，会出现redo log切换非常频繁，产生的归档都远小于redo log file的大小，所以，在观察到redo log切换频繁的时候，要关注下归档日志的大小，如归归档日志远小于redo log file大小，这时造成redo log频繁切换的原因可能不是大量的事务，这时要综合考虑， 不要贸然加大redo log file大小。

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

archive log文件大小与redo log文件大小关系探究相关推荐

  1. undo log mysql_MySQL的redo log与undo log

    1.Redo log.Undo log存放位置 首先,我们先要知道InnoDBredo log.undo log存放位置.InnoDB的事务日志是指Redo log,简称log,存放在日志文件ib_l ...

  2. MySQL redo log 重做日志 原理 Oracle Redo Log 机制 小结

    MySQL-重做日志 redo log -原理 [redo log buffer][redo log file]-原理 目录: 1.重做日志写入过程图 2.相关知识点汇总图 3.redo_log_bu ...

  3. 老白理解的REDO LOG

    理解REDO LOG(1) 介质恢复和实例恢复的基本概念 REDO LOG是Oracle为确保已经提交的事务不会丢失而建立的一个机制.实际上REDO LOG的存在是为两种场景准备的,一种我们称之为实例 ...

  4. 必须了解的MySQL三大日志：binlog、redo log和undo log

    点击上方"方志朋",选择"设为星标" 回复"666"获取新整理的面试文章 作者: 六点半起床 juejin.im/post/68602522 ...

  5. 浅谈Oracle Online redo log

    Oracle online redo log是Oracle数据库中核心文件之一.在数据库操作中,只要有任何的数据块变化,都会生成相应的redo entry.redo entry首先保存在log buf ...

  6. Redo Log 和Checkpoint not complete

    首先我们来看下 alertSID.log 日志: Mon Nov 30 17:31:54 2009 Thread 1 advanced to log sequence 14214 (LGWR swit ...

  7. 新特性速递 | InnoDB redo log archiving(归档)

     导读 MySQL 8.0.17开始支持的redo log归档能干嘛用呢,好吃吗 今天,MySQL 8.0.17发布了,看了下release note,发现果真如之前预期的那样,恢复了redo lo ...

  8. 必须了解的mysql三大日志-binlog、redo log和undo log

    来源:https://juejin.im/post/6860252224930070536 日志是 mysql 数据库的重要组成部分,记录着数据库运行期间各种状态信息.mysql日志主要包括错误日志. ...

  9. 一文聊透binlog、redo log、undo log

    今日推荐 Web登录很简单?开玩笑!知乎热问:国家何时整治程序员的高薪现象?太可怕了!注解+反射优雅的实现Excel导入导出(通用版)Fluent Mybatis 牛逼!Nginx 常用配置清单这玩意 ...

最新文章

  1. 月份加日期前面用on还是in_表示时间或地点：in，on，at 的使用
  2. 最简单的设置按钮的鼠标悬停效果
  3. java对import语句_Java的import语句 - 不积跬步，无以至千里 - 51Testing软件测试网 51Testing软件测试网-软件测试人的精神家园...
  4. linux ubuntu 安装jdk
  5. 【Qt开发经验】Qt信号槽连接不成功问题原因汇总
  6. linux下录屏与截屏软件kazam
  7. Serializing - 序列化 综述 – To be continued.
  8. CSU 2151 集训难度（线段树）
  9. python在电脑下载-Windows下下载及安装numpy、pandas及简单应用
  10. 二十五、K8s系统强化1- 系统安全与apparmor
  11. Asp.net Boilerplate之AbpSession扩展
  12. 大学计算机课是绩点课吗,选修课是什么意思 选修课成绩算入绩点吗
  13. 洛谷 P4218 [CTSC2010]珠宝商 后缀自动机+点分治
  14. java读取txt文件乱码解决方案
  15. JAVA超全笔试/面试考试题.(500问)--第三章面试题全面收录
  16. 乌镇发布六大榜单，解读大数据产业全景 !（附2018中国大数据产业地图、企业榜单）...
  17. VSCode、notepa++列选择（垂直选中）快捷键方法
  18. ios手游退款有风险吗？
  19. Ajax参数对照及Success内容
  20. 免费分享我的匿名邮件群发系统，可匿名发送: 163 126 139 gmail qq 21cn 263 及各类企业级邮件

热门文章

  1. 生活在Emacs中（转）
  2. “合”而不同，持“智”以恒，幂律智能2022产品升级发布会全程回顾！
  3. Installshield 12 安装包制作工具
  4. 基与Vue的emoji表情使用 --- emoji-vue的使用和bug修改
  5. 台达编码器型号含义_台达编码器选型.doc
  6. 【解决】word如何删除页眉上的一道横线
  7. 荣耀笔记本可以JAVA_荣耀笔记本装Win10系统攻略，一文教你快速入门
  8. 微信小程序BackgroundAudioManager播放m3u8格式音频
  9. 真实评测 i7 12700k和i9 12900k选哪个好
  10. 工业设计如何从零开始学手绘