archive log檔案大小與redo log檔案大小關係探究

bitifi發表於2016-04-27
Hive
     首先我們來看下什麼是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大小。







來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/28258625/viewspace-1688115/，如需轉載，請註明出處，否則將追究法律責任。

相關文章