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

最新推荐文章于 2023-11-23 16:10:24 发布

cuanlielian4510

最新推荐文章于 2023-11-23 16:10:24 发布

阅读量717

点赞数

文章标签：数据库

最近在因归档日志暴增，使用delete archivelog all貌似无法清除所有的归档日志，到底是什么原因呢？
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文件夹为空，否则，整个文件夹连同上级空目录会被删除

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/31448824/viewspace-2139499/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/31448824/viewspace-2139499/