archive log文件大小與redo log文件大小關係探究

原創 xjsunjie 2018-09-10 04:23

首先我們來看下什麼是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;


  4.    THREAD# GROUP# size

  5. ---------- ---------- ----------

  6.      1 1 50

  7.      1 2 50

  8.      2 3 50

  9.      2 4 50

  10.   --在節點1上建立測試表

  11.  SQL> create table darren(id number,item varchar2(2));

  12.  

  13.  --查看當前的歸檔情況和redo log的FRIST_CHANGE#

  14.  SQL> select thread#,name,blocks*block_size/1024/1024 "size" from v$archived_log order by 1,2;


  16.    THREAD#                             NAME                                          size

  17. ---------- ---------------------------------------------------------------------- ----------

  18.      1          +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_10.268.861729569 1.4453125

  19.      1          +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_11.270.861730475 49.9980469

  20.      1          +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_12.271.861730509 49.9980469

  21.      1          +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_13.272.861730545 49.9980469

  22.      1          +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_14.274.861730573 49.9980469

  23.      1          +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_15.275.861730601 49.9980469

  24.      1          +DATADG01/gyl/archivelog/2014_10_24/thread_1_seq_16.276.861788401 35.8242188

  25.      2          +DATADG01/gyl/archivelog/2014_10_23/thread_2_seq_2.269.861729571 2.37207031

  26.      2          +DATADG01/gyl/archivelog/2014_10_23/thread_2_seq_3.273.861730551 .008300781

  27.      2          +DATADG01/gyl/archivelog/2014_10_24/thread_2_seq_4.277.861788403 .567871094


  29.  SQL> select GROUP#,THREAD#,SEQUENCE#,STATUS,FIRST_CHANGE# from v$log order by 2;


  31.     GROUP#     THREAD#  SEQUENCE#       STATUS     FIRST_CHANGE#

  32.  ---------- ---------- ---------- ---------------- -------------

  33.      1            1        17          CURRENT        794878

  34.      2            1        16          INACTIVE       700672

  35.      3            2        5           CURRENT        794876

  36.      4            2        4           INACTIVE       517670

  37. --在節點1上進行事務，由於是測試環境，節點2上完全沒事務，是空閒實例

  38. begin

  39.   for i in 1..500000 loop

  40.    insert into darren values(1,'aa');

  41.    commit;

  42.   end loop;

  43. end;

  44.  --查看歸檔情況和redo log 的FRIST_CHANGE#

  45. SQL> select thread#,name,blocks*block_size/1024/1024 "size" from v$archived_log order by 1,2;


  47.    THREAD#                             NAME                                          size

  48. ---------- ---------------------------------------------------------------------- ----------

  49.      1       +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_10.268.861729569     1.4453125

  50.      1       +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_11.270.861730475     49.9980469

  51.      1       +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_12.271.861730509     49.9980469

  52.      1       +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_13.272.861730545     49.9980469

  53.      1       +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_14.274.861730573     49.9980469

  54.      1       +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_15.275.861730601     49.9980469

  55.      1       +DATADG01/gyl/archivelog/2014_10_24/thread_1_seq_16.276.861788401     35.8242188

  56.      1       +DATADG01/gyl/archivelog/2014_10_24/thread_1_seq_17.278.861791005     49.9980469

  57.      1       +DATADG01/gyl/archivelog/2014_10_24/thread_1_seq_18.279.861791039     49.9980469

  58.      1       +DATADG01/gyl/archivelog/2014_10_24/thread_1_seq_19.281.861791071     49.9980469

  59.      1       +DATADG01/gyl/archivelog/2014_10_24/thread_1_seq_20.282.861791091     49.9980469

  60.      1       +DATADG01/gyl/archivelog/2014_10_24/thread_1_seq_21.283.861791119     49.9980469

  61.      2       +DATADG01/gyl/archivelog/2014_10_23/thread_2_seq_2.269.861729571     2.37207031

  62.      2       +DATADG01/gyl/archivelog/2014_10_23/thread_2_seq_3.273.861730551     .008300781

  63.      2       +DATADG01/gyl/archivelog/2014_10_24/thread_2_seq_4.277.861788403     .567871094

  64.      2       +DATADG01/gyl/archivelog/2014_10_24/thread_2_seq_5.280.861791047     .791503906

  65.      2       +DATADG01/gyl/archivelog/2014_10_24/thread_2_seq_6.284.861791125     .000976563

  66.   （thread_1_seq_17至thread_1_seq_21爲insert過程中節點1產生的歸檔，大小都接近redo file大小，thread_2_seq_5和thread_2_seq_6爲節點2產生的歸檔，遠小於redo file大小）

  67.  

  68.  SQL> select GROUP#,THREAD#,SEQUENCE#,STATUS,FIRST_CHANGE# from v$log order by 2;


  70.     GROUP#      THREAD#   SEQUENCE#      STATUS      FIRST_CHANGE#

  71.    ---------- ---------- ---------- ---------------- -------------

  72.        1           1         21          ACTIVE         1206256

  73.        2           1         22          CURRENT        1308608

  74.        3           2         7           CURRENT        1338258

  75.        4           2         6           INACTIVE       1014874

  76.    （可以看到，節點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.


  7. --繼續在節點1插入數據 

  8. begin

  9.   for i in 1..500000 loop

  10.    insert into darren values(1,'aa');

  11.    commit;

  12.   end loop;

  13. end;


  15. --查看歸檔情況和redo log 的FRIST_CHANGE#

  16. SQL> select thread#,ARCHIVAL_THREAD#,name,blocks*block_size/1024/1024 "size" from v$archived_log order by 1,2;


  18.    THREAD# ARCHIVAL_THREAD#                               NAME                                        size

  19. ---------- ---------------- ---------------------------------------------------------------------- ----------

  20.     1           1            +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_10.268.861729569     1.4453125

  21.     1           1            +DATADG01/gyl/archivelog/2014_10_24/thread_1_seq_18.279.861791039     49.9980469

  22.     1           1            +DATADG01/gyl/archivelog/2014_10_24/thread_1_seq_27.291.861795885     49.9980469

  23.     1           1            +DATADG01/gyl/archivelog/2014_10_24/thread_1_seq_26.290.861795861     49.9980469

  24.     1           1            +DATADG01/gyl/archivelog/2014_10_24/thread_1_seq_25.289.861795837     49.9980469

  25.     1           1            +DATADG01/gyl/archivelog/2014_10_24/thread_1_seq_24.287.861795815     49.9980469

  26.     1           1            +DATADG01/gyl/archivelog/2014_10_24/thread_1_seq_23.286.861795789     49.9980469

  27.     1           1            +DATADG01/gyl/archivelog/2014_10_24/thread_1_seq_22.285.861795765     49.9980469

  28.     1           1            +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_11.270.861730475     49.9980469

  29.     1           1            +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_12.271.861730509     49.9980469

  30.     1           1            +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_13.272.861730545     49.9980469

  31.     1           1            +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_14.274.861730573     49.9980469

  32.     1           1            +DATADG01/gyl/archivelog/2014_10_23/thread_1_seq_15.275.861730601     49.9980469

  33.     1           1            +DATADG01/gyl/archivelog/2014_10_24/thread_1_seq_16.276.861788401     35.8242188

  34.     1           1            +DATADG01/gyl/archivelog/2014_10_24/thread_1_seq_17.278.861791005     49.9980469

  35.     1           1            +DATADG01/gyl/archivelog/2014_10_24/thread_1_seq_19.281.861791071     49.9980469

  36.     1           1            +DATADG01/gyl/archivelog/2014_10_24/thread_1_seq_20.282.861791091     49.9980469

  37.     1           1            +DATADG01/gyl/archivelog/2014_10_24/thread_1_seq_21.283.861791119     49.9980469

  38.     2           1            +DATADG01/gyl/archivelog/2014_10_24/thread_2_seq_8.292.861795895     .000488281

  39.     2           1            +DATADG01/gyl/archivelog/2014_10_24/thread_2_seq_7.288.861795827     .921386719

  40.     2           1            +DATADG01/gyl/archivelog/2014_10_24/thread_2_seq_4.277.861788403     .567871094

  41.     2           2            +DATADG01/gyl/archivelog/2014_10_24/thread_2_seq_5.280.861791047     .791503906

  42.     2           2            +DATADG01/gyl/archivelog/2014_10_23/thread_2_seq_3.273.861730551     .008300781

  43.     2           2            +DATADG01/gyl/archivelog/2014_10_24/thread_2_seq_6.284.861791125     .000976563

  44.     2           2            +DATADG01/gyl/archivelog/2014_10_23/thread_2_seq_2.269.861729571     2.37207031

  45. (注意thread_2_seq_7和thread_2_seq_8，他們的歸檔是由thread 1 執行的，參看THREAD# 和ARCHIVAL_THREAD# 列，這兩個歸檔正是在實例2關閉的時候生成的)


  47. SQL> select GROUP#,THREAD#,SEQUENCE#,STATUS,FIRST_CHANGE# from v$log order by 2;


  49.     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;


  4.     GROUP# size(M)

  5. ---------- ----------

  6.      1 50

  7.      2 50

  8.      3 50


  10. --建立測試表

  11. SQL> create table darren(id number,item varchar2(2));



  14. Table created.


  16. --查看當前歸檔的情況

  17. SQL> select SEQUENCE#,ARCHIVED,status,COMPRESSED from v$archived_log;


  19. 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


  21. --查看當前的redo size和redo wastage

  22. SQL> select name,value from v$sysstat where name in('redo size','redo wastage');


  24. NAME                                       VALUE

  25. --------------------- ------------------------------------------ ----------

  26. redo size                                 258664912

  27. redo wastage                              86181420


  29. --向測試表插入數據，產生redo記錄

  30. begin

  31.   for i in 1..500000 loop

  32.    insert into darren values(1,'aa');

  33.    commit;

  34.   end loop;

  35. end;


  37. --切換一起日誌，將insert過程中產生的redo文件全部歸檔

  38. SQL> alter system archive log current;


  40. System altered.

  41.   

  42. --查看現在的redo size和redo wastage

  43. SQL> select name,value from v$sysstat where name in('redo size','redo wastage');


  45. NAME           VALUE

  46. ---------- ------------ 

  47. redo size    512888704

  48. redo wastage 202172176


  50. --計算insert過程中產生的redo size和redo wastage

  51. SQL> select 512888704-258664912 redo from dual;


  53.       REDO

  54. ----------

  55.  254223792


  57. SQL> select 202172176-86181420 wastage from dual;


  59.    WASTAGE

  60. ----------

  61.  115990756


  63. --計算redo wastage的比例

  64. SQL> select 115990756/254223792 from dual;


  66. 115990756/254223792

  67. -------------------

  68. .456254527



  71. --查看insert 過程中產生的archive log file

  72. SQL> select SEQUENCE#,ARCHIVED,status,COMPRESSED from v$archived_log;


  74.  SEQUENCE# ARC S COM

  75. ---------- --- - ---

  76. 81 YES A NO

  77. 82 YES A NO

  78. 83 YES A NO

  79. 84 YES A NO

  80. 85 YES A NO

  81. 86 YES A NO

  82. 87 YES A NO

  83. 88 YES A NO

  84. 89 YES A NO

  85. 90 YES A NO

  86. 91 YES A NO

  87. 92 YES A NO

  88. 93 YES A NO

  89. 94 YES A NO

  90. 95 YES A NO

  91. 96 YES A NO

  92. 97 YES A NO

  93. 98 YES A NO

  94. 99 YES A NO

  95. 從91號歸檔開始爲本次insert操作產生的歸檔

  96.  --查看歸檔文件大小

  97. [oracle@oracle11g archive]$ ls -trl

  98. -rw-r----- 1 oracle oinstall 49917440 Oct 23 13:49 orcl_1_91_851966182.arc

  99. -rw-r----- 1 oracle oinstall 49257472 Oct 23 13:49 orcl_1_92_851966182.arc

  100. -rw-r----- 1 oracle oinstall 49896448 Oct 23 13:50 orcl_1_93_851966182.arc

  101. -rw-r----- 1 oracle oinstall 44149760 Oct 23 13:50 orcl_1_94_851966182.arc

  102. -rw-r----- 1 oracle oinstall 49917440 Oct 23 13:50 orcl_1_95_851966182.arc

  103. -rw-r----- 1 oracle oinstall 44199936 Oct 23 13:50 orcl_1_96_851966182.arc

  104. -rw-r----- 1 oracle oinstall 46582784 Oct 23 13:51 orcl_1_97_851966182.arc

  105. -rw-r----- 1 oracle oinstall 48513536 Oct 23 13:51 orcl_1_98_851966182.arc

  106. -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大小。
發表評論
所有評論
還沒有人評論，想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章

PostgreSQL xlog格式之checkpoint

yzs的專欄 2019-02-22 16:54:06

刪除非當前日誌組的幾點疑問解析

371690509 2019-02-22 16:21:31

MySQL InnoDB redo Log 淺析

AIOPS_DBA 2018-09-30 02:10:32

PostgreSQL xlog格式之checkpoint

yzs的專欄 2018-09-17 02:22:05

RAC中的redo和undo管理

kaka5285 2018-09-13 02:38:04

初學oracle物理存儲結構遇到的一些問題

維心主義 2018-09-12 05:23:45

DG使用中遇到的幾個錯誤

now_fly 2018-09-12 05:23:02

redo機制詳解——做好數據的第一層安保

dbguy 2018-09-12 04:59:52

redo write triggers

yanse 2018-09-12 03:34:44

redo log file的管理

abadem 2018-09-12 02:56:00

Oracle在線調整redo日誌組數及組成員

追夢沙哈拉 2018-09-12 02:39:43

MySQL各種日誌總結

thundermeng 2018-09-12 02:18:06

RMAN

無雙布袋熊 2019-02-22 18:05:07

archive記錄配置的命令

1560202 2018-09-28 02:22:43

RHEL/CentOs Mailpiler install

jianbqj 2018-09-12 04:57:20