如何理解Oracle归档日志比联机重做日志小很多的情况

2025-03-16 技术教程

本篇内容介绍了“如何理解Oracle归档日志比联机重做日志小很多的情况”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！

1：检查参数ARCHIVE_LAG_TARGET

ARCHIVE_LAG_TARGET参数可以设置一个时间，通过时间限制，指定数据库强制进行Log Switch进行归档。如果这个参数设置过小，有可能导致联机重做日志还没有写满就切换了，这样就有可能导致归档日志远小于联机重做日志(redo log)。

SQL>showparameterarchive_lag_target;NAMETYPEVALUE-----------------------------------------------------------------------------archive_lag_targetinteger0SQL>

如果参数archive_lag_target为0，那么可以排除这方面的因素。

2：检查是否存在人为切换redo log的可能性。

一些命令可以引起重做日志的切换，具体请见下面

SQL>altersystemarchivelogcurrent;#归档命令也会造成日志切换SQL>altersystemswitchlogfile;#直接切换日志组RMAN>backuparchivelogall;RMAN>backupdatabaseplusarchivelog;SELECTTO_CHAR(FIRST_TIME,'YYYY-MM-DDHH24:MI:SS'),BLOCKS*BLOCK_SIZE/1024/1024,COMPRESSEDFROMV$ARCHIVED_LOG;

如下案例的截图如下所示，从截图看归档日志的大小在31M左右徘徊。另外，可以看到没有启用归档日志压缩选项(其实ORACLE不支持归档日志压缩，这个后面说明)。从归档日志大小的规律可以看出，这个不是某个重做日志切换命令引起的。

3：一些Bug引起的，如下metalink文档所示：

BUG9272059-REDOLOGSWITCHAT1/8OFSIZEDUETOCMTCPU'SBUG10354739-REDOLOGSIZENOTCOMPLETLYUSEDBUG12317474-FREQUENTREDOLOGSWITCHESGENERATINGSMALLSIZEDARCHIVELOGSBUG5450861-ARCHIVELOGSAREGENERATEDWITHASMALLERSIZETHANTHEREDOLOGFILESBUG7016254-DECREASECONTROLFILEENQUEUEWAITATLOGSWITCH

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>select112.0/16fromdual;112.0/16----------7SQL>select341655552/1024/1024/7fromdual;--logbuffer341655552/1024/1024/7---------------------46.546875SQL>select200/7fromdual;--redologsize200/7----------28.5714286SQL>

当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左右大小(其中一股(strand)28.6再加上其它各股也有部分内容写入，所以归档日志的大小就是一个波动的范围)

其它各个特殊场景分析，可以参考“归档日志的大小比在线日志的大小小很多[1]”这篇文章的介绍。当然这篇文章分析过程还忽略了其它各股其实也是有部分数据的。这个需要特别注意。

如果你对这个机制不是很清楚，上面链接的这篇博客已经不可访问了，下面是我摘抄的部分内容到此，方便大家深入理解：

比如CPU的个数是64个，则会有64/16=4个strand

例1)：当log buffer的大小和redo log file的大小都是256M的时候，则每个strand都是256M/4=64M。每一个redo log file被启用时，会预先将redo log file中的大小分配出4个64M与log buffer对应，如图：

因为log buffer的大小和redo log file的大小都是256M，则redo log file没有剩余的未分配的空间了。

每个进程产生的redo会分配到log buffer上的1,2,3,4其中的某一个strand上，单个进程只能对应一个strand，这样当数据库中只有某些进程(比如极端的情况，只有某一个进程)产生的redo很多的时候，其中一个strand会快速写满，比如图中的strand 1：

写满之后LGWR会将log buffer中strand 1的内容写入到redo log file中，并且试图从redo log file中分配一个新的64M空间，发现没有了，则将所有strand中的内容写入日志，并作日志切换。

这样，可能会导致redo log file只写入了一个strand的内容，其他部分几乎是空的，则产生的archive log会只接近64M，而不是256M。当CPU_COUNT很大时，这个差值会更大。

例2)：当log buffer的大小是256M，而redo log file的大小是1G的时候，每个strand还是256M/4=64M。每一个redo log file被启用时，会预先将redo log file中的大小分配出4个64M与log buffer对应，如图：

这时，redo log file中还有1G-256M=768M剩余的未分配的空间。

如果strand 1写满之后，LGWR会将log buffer中strand 1的内容写入到redo log file中，并且试图从redo log file中分配一个新的64M空间，然后不断往下写。图片

直到redo log file中再没有可分配空间了，则将所有strand中的内容写入日志，并作日志切换。

例3)：当log buffer的大小是256M，而redo log file的大小是100M的时候，每个strand还是256M/4=64M。但是redo log file中的空间会按strand的个数平均分配，也就是每块100M/4=25M。

这样，当每个strand中的内容写到25M的时候，就会日志切换，而不是64M。相当于log buffer中的一部分空间被浪费了。

5：检查是否开启归档日志压缩

此功能的目的是在归档传输到远程或者归档存储到磁盘之前进行压缩，以便减少归档日志传输的时间和占用的磁盘空间。可以使用下面脚本检查。

SELECTNAME,ARCHIVELOG_COMPRESSIONFROMV$DATABASE;SELECTTO_CHAR(FIRST_TIME,'YYYY-MM-DDHH24:MI:SS'),BLOCKS*BLOCK_SIZE/1024/1024,COMPRESSEDFROMV$ARCHIVED_LOG;SQL>SELECTNAME,2ARCHIVELOG_COMPRESSION3FROMV$DATABASE;NAMEARCHIVEL-----------------GSPPDISABLED

起初，估计很多人都会被这个所迷惑，其实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)

Thereare2possiblecausesforthis:1.DocumentedanddesignedbehaviourduetoexplicitforcinganarchivecreationbeforetheredologfileisfullSQL>altersystemswitchlogfile;SQL>altersystemarchivelogcurrent;RMAN>backuparchivelogall;RMAN>backupdatabaseplusarchivelog;ARCHIVE_LAG_TARGET:limitstheamountofdatathatcanbelostandeffectivelyincreasestheavailabilityofthestandbydatabasebyforcingalogswitchafterthespecifiedamountoftimeelapses.youcanseethisaswellinRACwithanidle/low-loadinstance.>2.Undocumented,butdesignedbehaviour:BUG9272059-REDOLOGSWITCHAT1/8OFSIZEDUETOCMTCPU'SBUG10354739-REDOLOGSIZENOTCOMPLETLYUSEDBUG12317474-FREQUENTREDOLOGSWITCHESGENERATINGSMALLSIZEDARCHIVELOGSBUG5450861-ARCHIVELOGSAREGENERATEDWITHASMALLERSIZETHANTHEREDOLOGFILESBUG7016254-DECREASECONTROLFILEENQUEUEWAITATLOGSWITCHExplanation:AsperBug:5450861(closedas'NotaBug'):*Thearchivelogsdonothavetobeeveninsize.Thiswasdecidedaverylongtimeago,whenblankpaddingthearchivelogswasstopped,foraverygoodreason-inordertosavediskspace.*Thelogswitchdoesnotoccurwhenaredologfileis100%full.Thereisaninternalalgorithmthatdeterminesthelogswitchmoment.Thisalsohasaverygoodreason-doingthelogswitchatthelastmomentcouldincurperformanceproblems(forvariousreasons,outofthescopeofthisnote).Asaresult,afterthelogswitchoccurs,thearchiversarecopyingonlytheactualinformationfromtheredologfiles.Sincetheredologsarenot100%fullafterthelogswitchandthearchivelogsarenotblankpaddedafterthecopyoperationhasfinished,thisresultsinuneven,smallerfilesthantheoriginalredologfiles.Thereareanumberoffactorswhichcombinetodeterminethelogswitchfrequency.Thesearethemostrelevantfactorsinthiscase:a)RDBMSparameterLOG_BUFFER_SIZEIfthisisnotexplicitlysetbytheDBAthenweuseadefault;atinstancestartuptheRDBMScalculatesthenumberofsharedredostrandsasncpus/16,andthesizeofeachstrandis128Kb*ncpus(wherencpusisthenumberofCPUsinthesystem).Thelogbuffersizeisthenumberofstandsmultipliedbythestrandsize.ThecalculatedorspecifiedsizeisroundeduptoamultipleofthegranulesizeofamemorysegmentintheSGA.For11.2ifSGAsize>=128GBthengranulesizeis512MB64GB<=SGAsize<128GBthengranulesizeis256MB32GB<=SGAsize<64GBthengranulesizeis128MB16GB<=SGAsize<32GBthengranulesizeis64MB8GB<=SGAsize<16GBthengranulesizeis32MB1GB<=SGAsize<8GBthengranulesizeis16MBSGAsize<1GBthengranulesizeis4MBTherearesomeminimumsandmaximumsenforced.b)SystemloadInitiallyonlyoneredostrandisused,iethenumberof"active"redostrandsis1,andalltheprocessescopytheirredointothatonestrand.When/ifthereiscontentionforthatstrandthenthenumberofactiveredostrandsisraisedto2.Ascontentionfortheactivestrandsincreases,thenumberofactivestrandsincreases.Themaxmumpossiblenumberofactiveredostrandsisthenumberofstrandsinitiallyallocatedinthelogbuffer.(Thisfeatureiscalled"dynamicstrands",andthereisahiddenparametertodisableitwhichthenallowsprocessestouseallthestrandsfromtheoutset).c)LogfilesizeThisisthelogfilesizedecidedbytheDBAwhenthelogfilesarecreated.d)ThelogfilespacereservationalgorithmWhentheRDBMSswitchesintoanewonlineredologfile,allthelogbufferredostrandmemoryis"mapped"tothelogfilespace.Ifthelogfileislargerthanthelogbuffertheneachstrandwillmap/reserveitsstrandsizeworthoflogfilespace,andtheremaininglogfilespace(the"logresidue")isstillavailable.Ifthelogfileissmallerthanthelogbuffer,thenthewholelogfilespaceisdivided/mapped/reservedequallyamongallthestrands,andthereisnounreservedspace(ienologresidue).Whenanyprocessfillsastrandsuchthatallthereservedunderlyinglogfilespaceforthatstrandisused,ANDthereisnologresidue,thenalogswitchisscheduled.Example:128CPU'ssotheRDBMSallocatesalog_bufferofsize128Mbcontaining8sharedstrandsofsize16Mb.Itmaybeabitlargerthan128MbasitroundsuptoanSGAgranuleboundary.Thelogfilesare100Mb,sowhentheRDBMSswitchesintoanewonlineredologfileeachstrandreserves100Mb/8=25600blocksandthereisnologresidue.Ifthereislowsystemload,onlyoneoftheredostrandswillbeactive/usedandwhen25600blocksofthatstrandarefilledthenalogswitchwillbescheduled-thecreatedarchivelogshaveasizearound25600blocks.Witheverythingelsestayingthesame(128cpu'sandlowload),usingalargerlogfilewouldnotreallyreducetheamountofunfilledspacewhenthelogswitchesarerequested,butitwouldmakethatunfilledspacelesssignificantasapercentageofthetotallogfilespace,eg-witha100Mblogfile,thelogswitchhappenswith7x16Mblogfilespaceunfilled(iethelogfileis10%fullwhenthelogswitchisrequested)-witha1Gblogfile,thelogswitchwouldhappenwith7x16Mblogfilespaceunfilled(iethelogfileis90%fullwhenthelogswitchisrequested)WithahighCPU_COUNT,alowloadandaredologfilesizesmallerthantheredologbuffer,youmayseesmallarchivedlogfilesbecauseoflogswitchesatabout1/8ofthesizeofthedefinelogfilesize.ThisisbecauseCPU_COUNTdefinesthenumberofredostrands(ncpus/16).Withalowloadonlyasinglestrandmaybeused.Withredologfilesizesmallerthantheredologbuffer,thelogfilespaceisdividedovertheavailablestrands.Whenforinstanceonlyasingleactivestrandisused,alogswitchcanalreadyoccurwhenthatstrandisfilled.

“如何理解Oracle归档日志比联机重做日志小很多的情况”的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注亿速云网站，小编将为大家输出更多高质量的实用文章！