為什么歸檔日志的大小比在線日志的大小小很多

有些用戶會(huì)對(duì)于歸檔日志的大小比在線日志小感到疑惑，對(duì)于這種情況：

首先請(qǐng)檢查您的歸檔日志文件是否壓縮：
SELECT to_char(first_time,'yyyy-mm-dd hh34:mi:ss'),blocks*block_size/1024/1024,compressed from v$archived_log;

如果未壓縮，那么這個(gè)問(wèn)題可能和您的CPU個(gè)數(shù)有關(guān)。
請(qǐng)查看您的CPU個(gè)數(shù)：
show parameter CPU_COUNT

歸檔日志的大小是真實(shí)的在線日志文件的使用量，也就是在線日志文件切換前其中寫(xiě)入的內(nèi)容的大小。
但是為了更好的并行減少?zèng)_突，oracle會(huì)按每16個(gè)CPU分一股(strand),每一股獨(dú)立從redo buffer以及redo log中分配一塊空間，當(dāng)這一塊redo buffer用完，會(huì)寫(xiě)入redo log并且繼續(xù)從redo log中分配相同大小的空間，如果無(wú)法分配空閑空間就會(huì)進(jìn)行日志切換，而不管其他strand是否寫(xiě)完。
下面舉例子來(lái)說(shuō)明這個(gè)算法：
比如CPU的個(gè)數(shù)是64個(gè)，則會(huì)有64/16=4個(gè)strand
例1)當(dāng)log buffer的大小和redo log file的大小都是256M的時(shí)候，則每個(gè)strand都是256M/4=64M。
每一個(gè)redo log file被啟用時(shí)，會(huì)預(yù)先將redo log file中的大小分配出4個(gè)64M與log buffer對(duì)應(yīng)，如圖：

因?yàn)閘og buffer的大小和redo log file的大小都是256M，則redo log file沒(méi)有剩余的未分配的空間了。

每個(gè)進(jìn)程產(chǎn)生的redo會(huì)分配到log buffer上的1,2,3,4其中的某一個(gè)strand上，單個(gè)進(jìn)程只能對(duì)應(yīng)一個(gè)strand，
這樣當(dāng)數(shù)據(jù)庫(kù)中只有某些進(jìn)程（比如極端的情況，只有某一個(gè)進(jìn)程）產(chǎn)生的redo很多的時(shí)候，其中一個(gè)strand會(huì)快速寫(xiě)滿，比如圖中的strand 1：

寫(xiě)滿之后LGWR會(huì)將log buffer中strand 1的內(nèi)容寫(xiě)入到redo log file中，并且試圖從redo log file中分配一個(gè)新的64M空間，發(fā)現(xiàn)沒(méi)有了，則將所有strand中的內(nèi)容寫(xiě)入日志，并作日志切換。

這樣，可能會(huì)導(dǎo)致redo log file只寫(xiě)入了一個(gè)strand的內(nèi)容，其他部分幾乎是空的，則產(chǎn)生的archive log會(huì)只接近64M，而不是256M。
當(dāng)CPU_COUNT很大時(shí)，這個(gè)差值會(huì)更大。

例2)當(dāng)log buffer的大小是256M，而redo log file的大小是1G的時(shí)候，每個(gè)strand還是256M/4=64M。
每一個(gè)redo log file被啟用時(shí)，會(huì)預(yù)先將redo log file中的大小分配出4個(gè)64M與log buffer對(duì)應(yīng)，如圖：

這時(shí)，redo log file中還有1G-256M=768M剩余的未分配的空間。 如果strand 1寫(xiě)滿之后，LGWR會(huì)將log buffer中strand 1的內(nèi)容寫(xiě)入到redo log file中，并且試圖從redo log file中分配一個(gè)新的64M空間，然后不斷往下寫(xiě)。

創(chuàng)新互聯(lián)建站基于10多年網(wǎng)站建設(shè)行業(yè)經(jīng)驗(yàn)，一直致力于為中小型企業(yè)提供信息化解決方案，創(chuàng)新互聯(lián)建站做到開(kāi)放、開(kāi)源，讓企業(yè)所有核心數(shù)據(jù)掌握到企業(yè)手里，打破行業(yè)亂象，讓企業(yè)被網(wǎng)絡(luò)公司掌控的局面不再發(fā)生；美工設(shè)計(jì)部，產(chǎn)品/程序研發(fā)部，營(yíng)銷策劃部，售后客服部。一切服務(wù)為企業(yè)量身定制，專注為您！

直到redo log file中再?zèng)]有可分配空間了，則將所有strand中的內(nèi)容寫(xiě)入日志，并作日志切換。

例3)當(dāng)log buffer的大小是256M，而redo log file的大小是100M的時(shí)候，每個(gè)strand還是256M/4=64M。
但是redo log file中的空間會(huì)按strand的個(gè)數(shù)平均分配，也就是每塊100M/4=25M。

這樣，當(dāng)每個(gè)strand中的內(nèi)容寫(xiě)到25M的時(shí)候，就會(huì)日志切換，而不是64M。相當(dāng)于log buffer中的一部分空間被浪費(fèi)了。

請(qǐng)參考以下文檔：
1.Archive Logs Are Created With Smaller, Uneven Size Than The Original Redo Logs. Why? (Doc ID 388627.1)
With a high CPU_COUNT, a low load and a redo log file size smaller than the redolog buffer, you may 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.

<==高 CPU_COUNT和低workload(實(shí)際上數(shù)據(jù)庫(kù)不一定不繁忙，只是在產(chǎn)生redo的進(jìn)程很少的情況下）會(huì)導(dǎo)致 Archive Log比redo log小很多，而且日志頻繁切換。

2.Archived redolog is (significant) smaller than the redologfile. (Doc ID 1356604.1)
The logfile space reservation algorithm
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.

<==log strand 和 log switch的算法在這個(gè)note中講的更明白。

出自：甲骨文中國(guó)

當(dāng)前標(biāo)題：為什么歸檔日志的大小比在線日志的大小小很多
文章路徑：http://www.jbt999.com/article22/gsedjc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供App開(kāi)發(fā)、Google、網(wǎng)站內(nèi)鏈、自適應(yīng)網(wǎng)站、外貿(mào)建站、移動(dòng)網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：[email protected]。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)