码迷，mamicode.com
首页 > 其他好文 > 详细

delete archivelog all 无法彻底删除归档日志？

时间：2016-09-16 22:50:43      阅读：227      评论：0      收藏：0      [点我收藏+]

标签：

最近在因归档日志暴增，使用delete archivelog all貌似无法清除所有的归档日志，到底是什么原因呢？

[python] view plain copy
 
 print?
  1. 1、演示环境  
  2. SQL> select * from v$version where rownum<2;  
  3.   
  4. BANNER  
  5. ----------------------------------------------------------------  
  6. Oracle Database 10g Release 10.2.0.3.0 - 64bit Production  
  7.   
  8. SQL> select inst_id,instance_name from gv$instance; -->两节点RAC  
  9.   
  10.    INST_ID INSTANCE_NAME  
  11. ---------- ----------------  
  12.          1 GOBO4A  
  13.          2 GOBO4B  
  14.   
  15. SQL> show parameter db_recovery   -->+REV,使用了ASM 存储方式  
  16.   
  17. NAME                                 TYPE        VALUE  
  18. ------------------------------------ ----------- -------------  
  19. db_recovery_file_dest                string      +REV  
  20. db_recovery_file_dest_size           big integer 1G       
  21.   
  22. SQL> select flashback_on from v$database;  -->数据库未开启闪回特性，也就是说尽管指定了闪回区，未启用闪回特性  
  23.                                            -->相应的，归档日志充满整个闪回区时，闪回区空间并不会被重用  
  24. FLASHBACK_ON  
  25. ------------------  
  26. NO  
  27.   
  28. 2、查看及清除现有的归档日志文件      
  29. oracle@bo2dbp:~> export ORACLE_SID=+ASM1  
  30. oracle@bo2dbp:~> asmcmd  
  31. ASMCMD> cd +REV/GOBO4/ARCHIVELOG  
  32. ASMCMD> ls  
  33. 2012_10_08/  
  34. ....  
  35. arch_795194241_1_10.arc  
  36. arch_795194241_1_100.arc  
  37. ....  
  38.   
  39. oracle@bo2dbp:~> export ORACLE_SID=GOBO4A  
  40. oracle@bo2dbp:~> rman target /  
  41.   
  42. Recovery Manager: Release 10.2.0.3.0 - Production on Thu Nov 29 16:23:15 2012  
  43.   
  44. Copyright (c) 1982, 2005, Oracle.  All rights reserved.  
  45.   
  46. connected to target database: GOBO4 (DBID=921286879)  
  47.   
  48. #下面通过使用rman backup archivelog方式来删除所有的归档日志文件  
  49. RMAN> backup format ‘/install_source/rman_bak/arch_%d_%U‘  
  50. 2> archivelog all delete input;  
  51.   
  52. Starting backup at 29-NOV-12  
  53. current log archived  
  54. using target database control file instead of recovery catalog  
  55. allocated channel: ORA_DISK_1  
  56. channel ORA_DISK_1: sid=1058 instance=GOBO4A devtype=DISK  
  57. channel ORA_DISK_1: starting archive log backupset  
  58. channel ORA_DISK_1: specifying archive log(s) in backup set  
  59. input archive log thread=1 sequence=139 recid=214 stamp=797450261  
  60. input archive log thread=1 sequence=140 recid=215 stamp=797450292  
  61. input archive log thread=1 sequence=141 recid=216 stamp=797450308  
  62. input archive log thread=1 sequence=142 recid=218 stamp=797450347  
  63. input archive log thread=1 sequence=143 recid=219 stamp=797450372  
  64. input archive log thread=1 sequence=144 recid=220 stamp=797450409  
  65. channel ORA_DISK_1: starting piece 1 at 29-NOV-12  
  66. channel ORA_DISK_1: finished piece 1 at 29-NOV-12  
  67. piece handle=/install_source/rman_bak/arch_GOBO4_1dnrhkn4_1_1 tag=TAG20121129T162806 comment=NONE  
  68. channel ORA_DISK_1: backup set complete, elapsed time: 00:02:15  
  69. channel ORA_DISK_1: deleting archive log(s)  
  70. archive log filename=+REV/gobo4/archivelog/arch_795194241_1_139.arc recid=214 stamp=797450261  
  71. archive log filename=+REV/gobo4/archivelog/arch_795194241_1_140.arc recid=215 stamp=797450292  
  72. archive log filename=+REV/gobo4/archivelog/arch_795194241_1_141.arc recid=216 stamp=797450308  
  73. ........  
  74. piece handle=/install_source/rman_bak/arch_GOBO4_1hnrhli2_1_1 tag=TAG20121129T162806 comment=NONE  
  75. channel ORA_DISK_1: backup set complete, elapsed time: 00:00:09  
  76. channel ORA_DISK_1: deleting archive log(s)  
  77. archive log filename=+REV/gobo4/archivelog/arch_795194241_2_141.arc recid=427 stamp=800547491  
  78. archive log filename=+REV/gobo4/archivelog/arch_795194241_2_142.arc recid=429 stamp=800549193  
  79. archive log filename=+REV/gobo4/archivelog/arch_795194241_2_143.arc recid=433 stamp=800578944  
  80. archive log filename=+REV/gobo4/archivelog/arch_795194241_2_144.arc recid=437 stamp=800641679  
  81. Finished backup at 29-NOV-12  
  82.   
  83. #再次查看依然有很多归档日志文件存在，而且都是10月23日之前的  
  84. ASMCMD> pwd  
  85. +REV/GOBO4/ARCHIVELOG  
  86. ASMCMD> ls  
  87. 2012_09_30/  
  88. 2012_10_09/  
  89. 2012_10_10/  
  90. 2012_10_11/  
  91. 2012_10_12/  
  92. 2012_10_13/  
  93. 2012_10_14/  
  94. 2012_10_15/  
  95. 2012_10_16/  
  96. 2012_10_17/  
  97. 2012_10_18/  
  98. 2012_10_22/  
  99. 2012_10_23/  
  100. arch_795194241_1_100.arc  
  101. arch_795194241_1_101.arc  
  102. arch_795194241_1_102.arc  
  103. ............  
  104.   
  105. #再次删除日志文件，来个更狠的命令，直接delete所有的archivelog，最近新增的一个archivelog被删除  
  106. RMAN> delete noprompt archivelog all;  
  107.   
  108. released channel: ORA_DISK_1  
  109. allocated channel: ORA_DISK_1  
  110. channel ORA_DISK_1: sid=1081 instance=GOBO4A devtype=DISK  
  111.   
  112. List of Archived Log Copies  
  113. Key     Thrd Seq     S Low Time  Name  
  114. ------- ---- ------- - --------- ----  
  115. 453     1    294     A 29-NOV-12 +REV/gobo4/archivelog/arch_795194241_1_294.arc  
  116. deleted archive log  
  117. archive log filename=+REV/gobo4/archivelog/arch_795194241_1_294.arc recid=453 stamp=800662185  
  118. Deleted 1 objects  
  119.   
  120. # 上面输出的结果只有一个归档日志被删除，何以故？  
  121. # 这个我们的分析一下delete noprompt archivelog all以及备份归档日志时使用的 delete input  
  122. # 回顾一下Oracle控制文件以及Oracle RMAN的的备份恢复的原理。  
  123. # 我们知道，Oracle 控制文件里边记录了数据库的名字，id,创建的时间戳....一大堆的信息，当然也有不可少的归档信息以及备份信息。  
  124. # 如果不知道控制文件有什么？ 那就参考:Oracle 控制文件，文章尾部有给出链接。  
  125.   
  126. # 其次，Oracle RMAN的备份恢复的所有信息都依赖于两个东东，要么是控制文件，要么是恢复目录(catalog)。  
  127. # 因为所有的备份与恢复信息都会依据备份是的方式存储到这两个位置。  
  128. # 理所当然的是，对这两个东东里的备份集，镜像副本，归档日志，等等所有能备份的对象的任意操作，首先会参考这些对象的记录的信息。  
  129. # 其次是当被记录的对象发生变化时做相应的更新。  
  130.   
  131. 3、深度分析无法清除的原因  
  132. #先来看看gv$archived_log，如果是单实例使用v$archived_log  
  133. #从下面的查询可知，又有两个新的归档日志产生，一个从第一个instance产生，一个从第二个instance产生。  
  134. SQL> select name,status,count(*) from gv$archived_log group by name,status;  
  135.   
  136. NAME                                               S   COUNT(*)  
  137. -------------------------------------------------- - ----------  
  138.                                                    D        444  
  139. +REV/gobo4/archivelog/arch_795194241_1_295.arc     A          2  
  140. +REV/gobo4/archivelog/arch_795194241_2_150.arc     A          2  
  141.   
  142. # 从上面的查询可知，当前的两个节点其归档日志只有2个，其余的444个其名字都是NULL值。  
  143. # 看看关于视图v$archived_log中NAME列的解释  
  144. # Archived log file name. If set to NULL, either the log file was cleared before it was archived or an RMAN backup command  
  145. #  with the "delete input" option was executed to back up archivelog all (RMAN> backup archivelog all delete input;).   
  146.   
  147. # 上面的这段话表明当前的这些日志文件要么被手动清除，要么被rman的delete input选项清除。  
  148. # 其次status列的D字段也表明了这些个名字为空的归档日志已经被Deleted.也就是说有444个归档日志已经被删除了。  
  149.   
  150. # 再次尝试删除归档日志，尾数为295和150的归档日志也被删除  
  151. RMAN> delete noprompt archivelog all;  
  152.   
  153. released channel: ORA_DISK_1  
  154. allocated channel: ORA_DISK_1  
  155. channel ORA_DISK_1: sid=1081 instance=GOBO4A devtype=DISK  
  156.   
  157. List of Archived Log Copies  
  158. Key     Thrd Seq     S Low Time  Name  
  159. ------- ---- ------- - --------- ----  
  160. 454     1    295     A 29-NOV-12 +REV/gobo4/archivelog/arch_795194241_1_295.arc  
  161. 455     2    150     A 29-NOV-12 +REV/gobo4/archivelog/arch_795194241_2_150.arc  
  162. deleted archive log  
  163. archive log filename=+REV/gobo4/archivelog/arch_795194241_1_295.arc recid=454 stamp=800712037  
  164. deleted archive log  
  165. archive log filename=+REV/gobo4/archivelog/arch_795194241_2_150.arc recid=455 stamp=800712038  
  166. Deleted 2 objects  
  167.   
  168. # 查询gv$archived_log视图，表明所有现有的archivelog都已经被删除  
  169. SQL> select name,status,count(*) from gv$archived_log group by name,status;  
  170.   
  171. NAME                                               S   COUNT(*)  
  172. -------------------------------------------------- - ----------  
  173.                                                    D        448  
  174. # 在asmcmd命令下也无法找到我们刚刚删除的归档日志文件  
  175. ASMCMD> pwd  
  176. +REV/GOBO4/ARCHIVELOG  
  177. ASMCMD> ls -l arch_795194241_1_295.arc  
  178. asmcmd: entry ‘arch_795194241_1_295.arc‘ does not exist in directory ‘+REV/GOBO4/ARCHIVELOG/‘  
  179. ASMCMD> ls -l arch_795194241_2_150.arc  
  180. asmcmd: entry ‘arch_795194241_2_150.arc‘ does not exist in directory ‘+REV/GOBO4/ARCHIVELOG/‘  
  181.   
  182. # 在A节点上再次切换一次  
  183. SQL> alter system switch logfile;  
  184.   
  185. System altered.  
  186.   
  187. SQL> select inst_id,name,count(*) from gv$archived_log group by inst_id,name;  
  188.   
  189.    INST_ID NAME                                                 COUNT(*)  
  190. ---------- -------------------------------------------------- ----------  
  191.          2                                                           223  
  192.          1 +REV/gobo4/archivelog/arch_795194241_1_296.arc              1  
  193.          2 +REV/gobo4/archivelog/arch_795194241_1_296.arc              1  
  194.          1                                                           223  
  195.            
  196. --上面的查询可以看到当前的一个归档日志arch_795194241_1_296.arc基于Inst_id为1的有1个，而基于Inst_id为2的也有一个  
  197.   
  198. --而直接查询v$archived_log时只有1个当前的归档日志，实际上arch_795194241_1_296.arc文件是由第一个instance产生的。  
  199. --数字296之前的1即可以表明为第一个instance产生的。  
  200.   
  201. SQL> select name from v$archived_log where name=‘+REV/gobo4/archivelog/arch_795194241_1_296.arc‘;  
  202.   
  203. NAME  
  204. --------------------------------------------------  
  205. +REV/gobo4/archivelog/arch_795194241_1_296.arc  
  206.   
  207. # 关于这个地方个人认为这个应该是用于做恢复时用的。  
  208. # RAC数据库在恢复时，无论多个少节点，只有所有的归档日志的集合才能完成地表述数据库的变迁。  
  209. # 此时，无论从哪个节点上看，或者说做无论从哪个节点恢复，都可以看到该归档日志。  
  210. # 而具体是哪个instance产生则由‘%t‘重做线程编号来判断。  
  211.   
  212. #下面再来看看控制文件  
  213.   
  214. SQL> select * from gv$controlfile_record_section where type=‘ARCHIVED LOG‘;  
  215.   
  216.    INST_ID TYPE                         RECORD_SIZE RECORDS_TOTAL RECORDS_USED FIRST_INDEX LAST_INDEX LAST_RECID  
  217. ---------- ---------------------------- ----------- ------------- ------------ ----------- ---------- ----------  
  218.          1 ARCHIVED LOG                         584           224          224         149        148        456  
  219.          2 ARCHIVED LOG                         584           224          224         149        148        456  
  220.   
  221. # RECORDS_TOTAL：Number of records allocated for the section  
  222. # 列RECORDS_TOTAL表明为当前TYPE分配的可存储的总数，在两个instance上都为224条  
  223. # 从最近一次切换日志的查询结果可知，被删除的有223条，新增的一条为arch_795194241_1_296.arc，总条数为224条。  
  224. # 如果下次日志切换再增加一条往哪里放呢？那些已经超出缺省保留期的归档日志被覆盖，即被重用。  
  225. # 用户在控制文件中保存ARCHIVED LOG部分的保留时间由谁来决定呢，参数control_file_record_keep_time，缺省为7天  
  226. # 这意味着7天前的归档日志和备份信息可能在控制文件中已经不存在了  
  227.   
  228. SQL> show parameter control_file_record_keep_time   
  229.   
  230. NAME                                 TYPE        VALUE  
  231. ------------------------------------ ----------- ------------------------------  
  232. control_file_record_keep_time        integer     7  
  233.   
  234. SQL> select count (*) from v$archived_log;  
  235.   
  236.   COUNT(*)  
  237. ----------  
  238.        224  
  239.   
  240. # Author : Robinson  
  241. # Blog : http://blog.csdn.net/robinson_0612  
  242. SQL> alter session set nls_date_format=‘yyyymmdd hh24:mi:ss‘;  
  243.   
  244. Session altered.  
  245.   
  246. # 下面的查询正好表明为什么2012_10_23和之前的日志为什么没有被删除  
  247. # 因为20121023 18:04:53之后的归档日志已经被覆盖了，所以使用delete archivelog all时是根本无法清除之前的日志的，无能为力阿。  
  248. # 对于rman下的delete archivelog all方式不会删除控制文件中对应的归档日志信息，但在控制文件中设置delete状态，  
  249. # 即v$archived_log视图的status列为deleted  
  250.   
  251. SQL> select min (FIRST_TIME), min (COMPLETION_TIME), max (FIRST_TIME), max (COMPLETION_TIME) from  
  252.   2  v$archived_log;  
  253.   
  254. MIN(FIRST_TIME)   MIN(COMPLETION_TI MAX(FIRST_TIME)   MAX(COMPLETION_TI  
  255. ----------------- ----------------- ----------------- -----------------  
  256. 20121023 18:03:12 20121023 18:04:53 20121130 12:00:26 20121130 12:14:51  
  257.   
  258. SQL> select min (FIRST_TIME), min (COMPLETION_TIME), max (FIRST_TIME), max (COMPLETION_TIME) from  
  259.   2  gv$archived_log;  
  260.   
  261. MIN(FIRST_TIME)   MIN(COMPLETION_TI MAX(FIRST_TIME)   MAX(COMPLETION_TI  
  262. ----------------- ----------------- ----------------- -----------------  
  263. 20121023 18:03:12 20121023 18:04:53 20121130 12:00:26 20121130 12:14:51     
  264.   
  265. # 既然这般，如何是好啊？  
  266. # 那就直接在asmcmd命令行下删除吧。一顿狂删 rm -rf 2012_09_30/   
  267. # 莫急，莫急，一不小心删完了，我晕，ORA-00254/ORA-15173 Archive_log Directory On Asm Being Deleted 在等候阿。         

 

小结
a、delete archivelog all将会毫无保留的删除所有的归档日志(在控制文件中有相应记录的)
b、归档日志的信息被记录在控制文件之中，其生存期和可保留的总数也受到控制文件创建初以及参数control_file_record_keep_time限制
c、对于那些已经在控制文件中被覆盖的归档日志，该方式不起作用，使用backup archivelog all delete input同样不起作用
d、注意backup archivelog all时delete input与delete all input有些差异，前者删除仅仅被备份过的归档日志，而后者则对于多个归档位置
  下的所有归档日志全部删除。
e、视图v$archived_log或gv$archived_log提供了归档日志的相关详细信息
f、建议备份归档日志后再删除。注，RAC+ASM下切不可使得archivedlog文件夹为空，否则，整个文件夹连同上级空目录会被删除

转：http://blog.csdn.net/leshami/article/details/8245736#comments

delete archivelog all 无法彻底删除归档日志？

标签：

原文地址：http://www.cnblogs.com/andy6/p/5877461.html
踩
(0)
赞
(0)
   
举报
评论 一句话评论（0）
登录后才能评论！
分享档案
更多>
2021年07月29日 (22)
2021年07月28日 (40)
2021年07月27日 (32)
2021年07月26日 (79)
2021年07月23日 (29)
2021年07月22日 (30)
2021年07月21日 (42)
2021年07月20日 (16)
2021年07月19日 (90)
2021年07月16日 (35)
周排行
mamicode.com排行更多图片
更多
友情链接
兰亭集智   国之画   百度统计   站长统计   阿里云   chrome插件   新版天听网
关于我们 - 联系我们 - 留言反馈
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码！