文章详情

登录

短信预约-IT技能 免费直播动态提醒

选择考试省份

  • 北京
  • 上海
  • 天津
  • 重庆
  • 河北
  • 山东
  • 辽宁
  • 黑龙江
  • 吉林
  • 甘肃
  • 青海
  • 河南
  • 江苏
  • 湖北
  • 湖南
  • 江西
  • 浙江
  • 广东
  • 云南
  • 福建
  • 海南
  • 山西
  • 四川
  • 陕西
  • 贵州
  • 安徽
  • 广西
  • 内蒙
  • 西藏
  • 新疆
  • 宁夏
  • 兵团

请输入下面的图形验证码

提交验证

短信预约提醒成功

Oracle归档日志比联机重做日志小很多的情况总结

2024-12-03 10:56

关注

本文转载自微信公众号「DBA闲思杂想录」，作者潇湘隐者 。转载本文请联系DBA闲思杂想录公众号。

Oracle归档日志比联机重做日志小很多，出现这种情况的原因有很多，我们可以从下面这几方面着手检查，一一排除确认。

1：检查参数ARCHIVE_LAG_TARGET

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

  1. SQL> show parameter archive_lag_target; 
  2.  
  3. NAME                                 TYPE        VALUE 
  4. ------------------------------------ ----------- ------------------------------ 
  5. archive_lag_target                   integer     0 
  6. SQL>  

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

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

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

  1. SQL> alter system archive log current; #归档命令也会造成日志切换 
  2.  
  3. SQL> alter system switch logfile;      #直接切换日志组 
  4.  
  5. RMAN> backup archivelog all; 
  6.  
  7. RMAN> backup database plus archivelog; 
  8.  
  9.  
  10. SELECT TO_CHAR(FIRST_TIME, 'YYYY-MM-DD HH24:MI:SS'),  
  11.        BLOCKS * BLOCK_SIZE / 1024 / 1024,  
  12.        COMPRESSED  
  13. FROM   V$ARCHIVED_LOG;  

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

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

  1. BUG 9272059 - REDO LOG SWITCH AT 1/8 OF SIZE DUE TO CMT CPU'S 
  2. BUG 10354739 - REDOLOGSIZE NOT COMPLETLY USED 
  3. BUG 12317474 - FREQUENT REDO LOG SWITCHES GENERATING SMALL SIZED ARCHIVELOGS  
  4. BUG 5450861 - ARCHIVE LOGS ARE GENERATED WITH A SMALLER SIZE THAN THE REDO LOG FILES 
  5. 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部分

  1. SQL>  select 112.0/16 from dual; 
  2.  
  3.   112.0/16 
  4. ---------- 
  5.          7 
  6.  
  7. SQL>  select 341655552/1024/1024/7 from dual;   --log buffer 
  8.  
  9. 341655552/1024/1024/7 
  10. --------------------- 
  11.             46.546875 
  12.  
  13. SQL> select 200/7 from dual;   --redo log size 
  14.  
  15.      200/7 
  16. ---------- 
  17. 28.5714286 
  18.  
  19. 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左右大小(其中一股(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：检查是否开启归档日志压缩

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

  1. SELECT NAME, 
  2.  ARCHIVELOG_COMPRESSION  
  3. FROM V$DATABASE; 
  4.  
  5.  
  6. SELECT TO_CHAR(FIRST_TIME, 'YYYY-MM-DD HH24:MI:SS'),  
  7.        BLOCKS * BLOCK_SIZE / 1024 / 1024,  
  8.        COMPRESSED  
  9. FROM   V$ARCHIVED_LOG;  
  10.  
  11.  
  12.  
  13. SQL> SELECT NAME, 
  14.   2         ARCHIVELOG_COMPRESSION 
  15.   3  FROM V$DATABASE; 
  16.  
  17. NAME      ARCHIVEL 
  18. --------- -------- 
  19. 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)

  1. There are 2 possible causes for this : 
  2.  
  3. 1. Documented and designed behaviour due to explicit forcing an archive creation before the redolog file is full 
  4. SQL> alter system switch logfile; 
  5. SQL> alter system archive log current; 
  6. RMAN> backup archivelog all; 
  7. RMAN> backup database plus archivelog; 
  8. 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. 
  9.  
  10. >2. Undocumented, but designed behaviour : 
  11. BUG 9272059 - REDO LOG SWITCH AT 1/8 OF SIZE DUE TO CMT CPU'S 
  12. BUG 10354739 - REDOLOGSIZE NOT COMPLETLY USED 
  13. BUG 12317474 - FREQUENT REDO LOG SWITCHES GENERATING SMALL SIZED ARCHIVELOGS  
  14. BUG 5450861 - ARCHIVE LOGS ARE GENERATED WITH A SMALLER SIZE THAN THE REDO LOG FILES 
  15. BUG 7016254 - DECREASE CONTROL FILE ENQUEUE WAIT AT LOG SWITCH 
  16.  
  17. Explanation : 
  18. As per Bug: 5450861 (closed as 'Not a Bug'): 
  19. * The archive logs do not have to be even in size. This was decided a very long time ago, 
  20. when blank padding the archive logs was stopped, for a very good reason - in order to save disk space. 
  21. * The log switch does not occur when a redo log file is 100% full. There is an internal algorithm 
  22. that determines the log switch moment. This also has a very good reason - doing the log switch 
  23. at the last moment could incur performance problems (for various reasons, out of the scope of this note). 
  24. As a result, after the log switch occurs, the archivers are copying only the actual information from the 
  25. redo log files. Since the redo logs are not 100% full after the log switch and the archive logs are 
  26. not blank padded after the copy operation has finished, this results in uneven, smaller files than 
  27. the original redo log files. 
  28. There are a number of factors which combine to determine the log 
  29. switch frequency. These are the most relevant factors in this case: 
  30.  
  31. a) RDBMS parameter LOG_BUFFER_SIZE 
  32. If this is not explicitly set by the DBA then we use a default; 
  33. at instance startup the RDBMS  calculates the number of shared redo 
  34. strands as ncpus/16, and the size of each strand is 128Kb * ncpus 
  35. (where ncpus is the number of CPUs in the system). The log buffer 
  36. size is the number of stands multiplied by the strand size. 
  37. The calculated or specified size is rounded up to a multiple of the granule size  
  38. of a memory segment in the SGA. For 11.2 if 
  39. SGA size >= 128GB then granule size is 512MB 
  40. 64GB <= SGA size < 128GB then granule size is 256MB 
  41. 32GB <= SGA size < 64GB then granule size is 128MB 
  42. 16GB <= SGA size < 32GB then granule size is 64MB 
  43. 8GB <= SGA size < 16GB then granule size is 32MB 
  44. 1GB <= SGA size < 8GB then granule size is 16MB 
  45. SGA size < 1GB then granule size is 4MB 
  46. There are some minimums and maximums enforced. 
  47.  
  48. b) System load 
  49. Initially only one redo strand is used, ie the number of "active" 
  50. redo strands is 1, and all the processes copy their redo into 
  51. that one strand. When/if there is contention for that strand then 
  52. the number of active redo strands is raised to 2. As contention 
  53. for the active strands increases, the number of active strands 
  54. increases. The maxmum possible number of active redo strands is 
  55. the number of strands initially allocated in the log buffer. 
  56. (This feature is called "dynamic strands", and there is a hidden 
  57. parameter to disable it which then allows processes to use all 
  58. the strands from the outset). 
  59.  
  60.  
  61. c) Log file size 
  62. This is the logfile size decided by the DBA when the logfiles are created. 
  63.  
  64. d) The logfile space reservation algorithm 
  65. When the RDBMS switches into a new online redo logfile, all the 
  66. log buffer redo strand memory is "mapped" to the logfile space. 
  67. If the logfile is larger than the log buffer then each strand 
  68. will map/reserve its strand size worth of logfile space, and the 
  69. remaining logfile space (the "log residue") is still available. 
  70. If the logfile is smaller than the log buffer, then the whole 
  71. logfile space is divided/mapped/reserved equally among all the 
  72. strands, and there is no unreserved space (ie no log residue). 
  73. When any process fills a strand such that all the reserved 
  74. underlying logfile space for that strand is used, AND there is 
  75. no log residue, then a log switch is scheduled. 
  76.  
  77. Example : 128 CPU's so the RDBMS allocates a 
  78. log_buffer of size 128Mb containing 8 shared strands of size 16Mb. 
  79. It may be a bit larger than 128Mb as it rounds up to an SGA granule boundary. 
  80. The logfiles are 100Mb, so when the RDBMS switches into a 
  81. new online redo logfile each strand reserves 100Mb/8 = 25600 blocks 
  82. and there is no log residue. If there is low system load, only one 
  83. of the redo strands will be active/used and when 25600 blocks of 
  84. that strand are filled then a log switch will be scheduled - the created 
  85. archive logs have a size around 25600 blocks. 
  86.  
  87. With everything else staying the same (128 cpu's and low load), 
  88. using a larger logfile would not really reduce the amount of 
  89. unfilled space when the log switches are requested, but it would 
  90. make that unfilled space less significant as a percentage of the 
  91. total logfile space, eg 
  92.  
  93. - with a 100Mb logfile, the log switch happens with 7 x 16Mb 
  94. logfile space unfilled (ie the logfile is 10% full when the 
  95. log switch is requested) 
  96.  
  97. - with a 1Gb logfile, the log switch would happen with 7 x 16Mb 
  98. logfile space unfilled (ie the logfile is 90% full when the 
  99. log switch is requested) 
  100. With a high CPU_COUNT, a low load and a redo log file size smaller than  
  101. the redolog buffer, you may see small archived log files because of log switches 
  102. at about 1/8 of the size of the define log file size. 
  103. This is because CPU_COUNT defines the number of redo strands (ncpus/16). 
  104. With a low load only a single strand may be used. With redo log file size smaller 
  105. than the redolog buffer, the log file space is divided over the available strands. 
  106. When for instance only a single active strand is used, a log switch can already occur 
  107. when that strand is filled. 

参考资料

[1]

链接已经无效: http://www.ctonote.com/oracle/3236/

 

来源：DBA闲思杂想录内容投诉

免责声明：

① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的，并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据，供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。

② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341

软考中级精品资料免费领

  • 历年真题答案解析
  • 备考技巧名师总结
  • 高频考点精准押题

  • 2024年上半年信息系统项目管理师第二批次真题及答案解析（完整版）

    难度     813人已做
    查看

  • 【考后总结】2024年5月26日信息系统项目管理师第2批次考情分析

    难度     354人已做
    查看

  • 【考后总结】2024年5月25日信息系统项目管理师第1批次考情分析

    难度     318人已做
    查看

  • 2024年上半年软考高项第一、二批次真题考点汇总（完整版）

    难度     435人已做
    查看

  • 2024年上半年系统架构设计师考试综合知识真题

    难度     224人已做
    查看

相关文章

发现更多好内容

猜你喜欢

AI推送时光机

Oracle归档日志比联机重做日志小很多的情况总结

后端开发Oracle日志2024-12-03

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

后端开发2024-04-02
位置：首页-资讯-后端开发
咦！没有更多了？去看看其它编程学习网 内容吧
首页课程
资料下载问答资讯