zoukankan      html  css  js  c++  java

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

    最近在因归档日志暴增，使用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
  • 相关阅读:
    poj 2112
    写给学大计python的同学的查错方法
    [Win32 API学习] Edit，ListBox的用法，字体的设置
    [Win32 API] FindFirstFile()和FindNextFile()
    初探C++ win32 api——Hello world!
    [学习笔记]舞蹈链(DLX)(C++指针版)
    2020科大回归记
    SCOI2019AFO记
    [学习笔记]动态动态规划/动态DP/DDP
    BZOJ5343[CTSC2018]混合果汁（二分答案+主席树）
  • 原文地址：https://www.cnblogs.com/andy6/p/5877461.html
Copyright © 2011-2022 走看看