ORACLE歸檔日誌比聯機重做日誌小很多的情況
前幾天一網友在群裡反饋他遇到歸檔日誌比聯機重做日誌（redo log）小很多的情況，個人第一次遇到這種情況，非常感興趣，於是在一番交流溝通後，終於弄清楚了情況，順便將這方面的資料整理於此！也是一個總結、學習過程！
歸檔日誌比聯機重做日誌小很多，出現這種情況的原因有很多，我們可以從下面這幾方面著手檢查，一一排除確認。
1：檢查引數ARCHIVE_LAG_TARGET
ARCHIVE_LAG_TARGET引數可以設定一個時間，通過時間限制，指定資料庫強制進行Log Switch進行歸檔。 如果這個引數設定過小，有可能導致聯機重做日誌還沒有寫滿就切換了，這樣就有可能導致歸檔日誌遠小於重做日誌。
SQL> show parameter archive_lag_target;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
archive_lag_target integer 0
SQL>
該網友反饋引數archive_lag_target為0，那麼也可以排除這方面的因素。
2：檢查是否存在人為切換redo log的可能性。
一些命令可以引起重做日誌的切換，具體請見下面
SQL> alter system archive log current; #歸檔命令也會造成日誌切換
SQL> alter system switch logfile; #直接切換日誌組
RMAN> backup archivelog all;
RMAN> backup database plus archivelog;
SELECT TO_CHAR(FIRST_TIME, 'YYYY-MM-DD HH24:MI:SS'),
BLOCKS * BLOCK_SIZE / 1024 / 1024,
COMPRESSED
FROM V$ARCHIVED_LOG;
該網友QQ提供的截圖如下所示，從截圖看歸檔日誌的大小在31M左右徘徊。另外，可以看到沒有啟用歸檔日誌壓縮選項（其實ORACLE不支援歸檔日誌壓縮，這個後面說明）。從歸檔日誌大小的規律可以看出，這個不是某個重做日誌切換命令引起的。
3：一些Bug引起的，如下metalink文件所示：
o BUG 9272059 - REDO LOG SWITCH AT 1/8 OF SIZE DUE TO CMT CPU'S
o BUG 10354739 - REDOLOGSIZE NOT COMPLETLY USED
o BUG 12317474 - FREQUENT REDO LOG SWITCHES GENERATING SMALL SIZED ARCHIVELOGS
o BUG 5450861 - ARCHIVE LOGS ARE GENERATED WITH A SMALLER SIZE THAN THE REDO LOG FILES
o BUG 7016254 - DECREASE CONTROL FILE ENQUEUE WAIT AT LOG SWITCH
4： 跟CPU個數CPU_COUNT以及log_buffer、redo log size有關。
歸檔日誌的大小是真實的線上日誌檔案的使用量，也就是線上日誌檔案切換前其中寫入的內容的大小。為了更好的並行減少衝突，提高併發，減少redo allocation latch的等待，ORACLE會將redo buffer分成若干小的buffer，每份小的buffer叫strand。按每16個CPU分一股(strand),每一股獨立從redo buffer以及redo log中分配一塊空間，當這一塊redo buffer用完，會寫入redo log並且繼續從redo log中分配相同大小的空間，如果無法分配空閒空間就會進行日誌切換，而不管其他strand是否寫完。
如上所示CPU_COUNT為112，那麼 112/16=7 ,那麼redo buffer和 redo log 都可以分成7部分
SQL> select 112.0/16 from dual;
112.0/16
----------
7
SQL> select 341655552/1024/1024/7 from dual; --log buffer
341655552/1024/1024/7
---------------------
46.546875
SQL> select 200/7 from dual; --redo log size
200/7
----------
28.5714286
SQL>
當log buffer的大小是325.828125M(341655552)，分成7股（strand）的話，每個strand還是325.828125M/7=46.546875M。而redo log的大小是200M的時候，redo log中的空間會按strand的個數平均分配，也就是每塊200M/7=28.5714286M。
這樣，當每個strand中的內容寫到28M多左右的時候，就會日誌切換，而不是46M。相當於log buffer中的一部分空間被浪費了。所以你看到的歸檔日誌基本是30M左右大小（其中一股28.6再加上其它各股也有部分內容，所以歸檔日誌的大小就是一個波動的範圍）
其它各個特殊場景分析，可以參考歸檔日誌的大小比線上日誌的大小小很多這篇文章的介紹。如下所示，當然這篇文章分析過程還忽略了其它各股其實也是有部分資料的。這個需要特別注意。
5： 檢查是否開啟歸檔日誌壓縮
此功能的目的是在歸檔傳輸到遠端或者歸檔儲存到磁碟之前進行壓縮，以便減少歸檔傳輸的時間和佔用的磁碟空間。可以使用下面指令碼檢查。
SELECT NAME,
ARCHIVELOG_COMPRESSION
FROM V$DATABASE;
SELECT TO_CHAR(FIRST_TIME, 'YYYY-MM-DD HH24:MI:SS'),
BLOCKS * BLOCK_SIZE / 1024 / 1024,
COMPRESSED
FROM V$ARCHIVED_LOG;
SQL> SELECT NAME,
2 ARCHIVELOG_COMPRESSION
3 FROM V$DATABASE;
NAME ARCHIVEL
--------- --------
GSPP DISABLED
起初，估計很多人都會被這個所迷惑，估計也認同這種說法，其實ORACLE 10g 、 11g都是不支援歸檔日誌壓縮的，也沒有明確的官方文件說明，其實歸檔日誌壓縮本來是ORACLE 10g計劃引入的新特性，不幸的是這個計劃放棄了，而且ORACLE 11g也不支援。所以其實這種說法是不靠譜的，所以對應這種原因，你完全可以忽略這個，之所以也寫到這裡，是因為網上很多文章都介紹了這種可能性，而且很多人都沒有認真分辨、查證！
Archive compression was a planned new feature for 10G, but unfortunately it was withdrawn and it is still
not available in 11g .This feature is expected in future releases
最後大家可以去metalink上看看Archived redolog is (significant) smaller than the redologfile. (文件 ID 1356604.1)這篇文章，官方文件不愧是官方文件，最全面的闡述了歸檔日誌比重做日誌小的原因。下面擷取部分內容展示如下：
Archived redolog is (significant) smaller than the redologfile. (文件 ID 1356604.1)
There are 2 possible causes for this :
1. Documented and designed behaviour due to explicit forcing an archive creation before the redolog file is full
o SQL> alter system switch logfile;
o SQL> alter system archive log current;
o RMAN> backup archivelog all;
o RMAN> backup database plus archivelog;
o ARCHIVE_LAG_TARGET : limits the amount of data that can be lost and effectively increases the availability of the standby database by forcing a log switch after the specified amount of time elapses. you can see this aswell in RAC with an idle/low-load instance.
2. Undocumented, but designed behaviour :
o BUG 9272059 - REDO LOG SWITCH AT 1/8 OF SIZE DUE TO CMT CPU'S
o BUG 10354739 - REDOLOGSIZE NOT COMPLETLY USED
o BUG 12317474 - FREQUENT REDO LOG SWITCHES GENERATING SMALL SIZED ARCHIVELOGS
o BUG 5450861 - ARCHIVE LOGS ARE GENERATED WITH A SMALLER SIZE THAN THE REDO LOG FILES
o BUG 7016254 - DECREASE CONTROL FILE ENQUEUE WAIT AT LOG SWITCH
Explanation :
As per Bug: 5450861 (closed as 'Not a Bug'):
* The archive logs do not have to be even in size. This was decided a very long time ago,
when blank padding the archive logs was stopped, for a very good reason - in order to save disk space.
* The log switch does not occur when a redo log file is 100% full. There is an internal algorithm
that determines the log switch moment. This also has a very good reason - doing the log switch
at the last moment could incur performance problems (for various reasons, out of the scope of this note).
As a result, after the log switch occurs, the archivers are copying only the actual information from the
redo log files. Since the redo logs are not 100% full after the log switch and the archive logs are
not blank padded after the copy operation has finished, this results in uneven, smaller files than
the original redo log files.
There are a number of factors which combine to determine the log
switch frequency. These are the most relevant factors in this case:
a) RDBMS parameter LOG_BUFFER_SIZE
If this is not explicitly set by the DBA then we use a default;
at instance startup the RDBMS calculates the number of shared redo
strands as ncpus/16, and the size of each strand is 128Kb * ncpus
(where ncpus is the number of CPUs in the system). The log buffer
size is the number of stands multiplied by the strand size.
The calculated or specified size is rounded up to a multiple of the granule size
of a memory segment in the SGA. For 11.2 if
SGA size >= 128GB then granule size is 512MB
64GB <= SGA size < 128GB then granule size is 256MB
32GB <= SGA size < 64GB then granule size is 128MB
16GB <= SGA size < 32GB then granule size is 64MB
8GB <= SGA size < 16GB then granule size is 32MB
1GB <= SGA size < 8GB then granule size is 16MB
SGA size < 1GB then granule size is 4MB
There are some minimums and maximums enforced.
b) System load
Initially only one redo strand is used, ie the number of "active"
redo strands is 1, and all the processes copy their redo into
that one strand. When/if there is contention for that strand then
the number of active redo strands is raised to 2. As contention
for the active strands increases, the number of active strands
increases. The maxmum possible number of active redo strands is
the number of strands initially allocated in the log buffer.
(This feature is called "dynamic strands", and there is a hidden
parameter to disable it which then allows processes to use all
the strands from the outset).
c) Log file size
This is the logfile size decided by the DBA when the logfiles are created.
d) The logfile space reservation algorithm
When the RDBMS switches into a new online redo logfile, all the
log buffer redo strand memory is "mapped" to the logfile space.
If the logfile is larger than the log buffer then each strand
will map/reserve its strand size worth of logfile space, and the
remaining logfile space (the "log residue") is still available.
If the logfile is smaller than the log buffer, then the whole
logfile space is divided/mapped/reserved equally among all the
strands, and there is no unreserved space (ie no log residue).
When any process fills a strand such that all the reserved
underlying logfile space for that strand is used, AND there is
no log residue, then a log switch is scheduled.
Example : 128 CPU's so the RDBMS allocates a
log_buffer of size 128Mb containing 8 shared strands of size 16Mb.
It may be a bit larger than 128Mb as it rounds up to an SGA granule boundary.
The logfiles are 100Mb, so when the RDBMS switches into a
new online redo logfile each strand reserves 100Mb/8 = 25600 blocks
and there is no log residue. If there is low system load, only one
of the redo strands will be active/used and when 25600 blocks of
that strand are filled then a log switch will be scheduled - the created
archive logs have a size around 25600 blocks.
With everything else staying the same (128 cpu's and low load),
using a larger logfile would not really reduce the amount of
unfilled space when the log switches are requested, but it would
make that unfilled space less significant as a percentage of the
total logfile space, eg
- with a 100Mb logfile, the log switch happens with 7 x 16Mb
logfile space unfilled (ie the logfile is 10% full when the
log switch is requested)
- with a 1Gb logfile, the log switch would happen with 7 x 16Mb
logfile space unfilled (ie the logfile is 90% full when the
log switch is requested)
With a high CPU_COUNT, a low load and a redo log file size smaller than
the redolog buffer, you may see small archived log files because of log switches
at about 1/8 of the size of the define log file size.
This is because CPU_COUNT defines the number of redo strands (ncpus/16).
With a low load only a single strand may be used. With redo log file size smaller
than the redolog buffer, the log file space is divided over the available strands.
When for instance only a single active strand is used, a log switch can already occur
when that strand is filled.
參考資料：
https://oracleblog.org/study-note/archive-size-is-much-smaller-than-redo-size/
http://www.ctonote.com/oracle/3236/
