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

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

1、演示环境
SQL> select * from v$version where rownum<2;

BANNER
----------------------------------------------------------------
Oracle Database 10g Release 10.2.0.3.0 - 64bit Production

SQL> select inst_id,instance_name from gv$instance; -->两节点RAC

   INST_ID INSTANCE_NAME
---------- ----------------
         1 GOBO4A
         2 GOBO4B

SQL> show parameter db_recovery   -->+REV,使用了ASM 存储方式

NAME                                 TYPE        VALUE
------------------------------------ ----------- -------------
db_recovery_file_dest                string      +REV
db_recovery_file_dest_size           big integer 1G     

SQL> select flashback_on from v$database;  -->数据库未开启闪回特性，也就是说尽管指定了闪回区，未启用闪回特性
                                           -->相应的，归档日志充满整个闪回区时，闪回区空间并不会被重用
FLASHBACK_ON
------------------
NO

2、查看及清除现有的归档日志文件
oracle@bo2dbp:~> export ORACLE_SID=+ASM1
oracle@bo2dbp:~> asmcmd
ASMCMD> cd +REV/GOBO4/ARCHIVELOG
ASMCMD> ls
2012_10_08/
....
arch_795194241_1_10.arc
arch_795194241_1_100.arc
....

oracle@bo2dbp:~> export ORACLE_SID=GOBO4A
oracle@bo2dbp:~> rman target /

Recovery Manager: Release 10.2.0.3.0 - Production on Thu Nov 29 16:23:15 2012

Copyright (c) 1982, 2005, Oracle.  All rights reserved.

connected to target database: GOBO4 (DBID=921286879)

#下面通过使用rman backup archivelog方式来删除所有的归档日志文件
RMAN> backup format '/install_source/rman_bak/arch_%d_%U'
2> archivelog all delete input;

Starting backup at 29-NOV-12
current log archived
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=1058 instance=GOBO4A devtype=DISK
channel ORA_DISK_1: starting archive log backupset
channel ORA_DISK_1: specifying archive log(s) in backup set
input archive log thread=1 sequence=139 recid=214 stamp=797450261
input archive log thread=1 sequence=140 recid=215 stamp=797450292
input archive log thread=1 sequence=141 recid=216 stamp=797450308
input archive log thread=1 sequence=142 recid=218 stamp=797450347
input archive log thread=1 sequence=143 recid=219 stamp=797450372
input archive log thread=1 sequence=144 recid=220 stamp=797450409
channel ORA_DISK_1: starting piece 1 at 29-NOV-12
channel ORA_DISK_1: finished piece 1 at 29-NOV-12
piece handle=/install_source/rman_bak/arch_GOBO4_1dnrhkn4_1_1 tag=TAG20121129T162806 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:02:15
channel ORA_DISK_1: deleting archive log(s)
archive log filename=+REV/gobo4/archivelog/arch_795194241_1_139.arc recid=214 stamp=797450261
archive log filename=+REV/gobo4/archivelog/arch_795194241_1_140.arc recid=215 stamp=797450292
archive log filename=+REV/gobo4/archivelog/arch_795194241_1_141.arc recid=216 stamp=797450308
........
piece handle=/install_source/rman_bak/arch_GOBO4_1hnrhli2_1_1 tag=TAG20121129T162806 comment=NONE
channel ORA_DISK_1: backup set complete, elapsed time: 00:00:09
channel ORA_DISK_1: deleting archive log(s)
archive log filename=+REV/gobo4/archivelog/arch_795194241_2_141.arc recid=427 stamp=800547491
archive log filename=+REV/gobo4/archivelog/arch_795194241_2_142.arc recid=429 stamp=800549193
archive log filename=+REV/gobo4/archivelog/arch_795194241_2_143.arc recid=433 stamp=800578944
archive log filename=+REV/gobo4/archivelog/arch_795194241_2_144.arc recid=437 stamp=800641679
Finished backup at 29-NOV-12

#再次查看依然有很多归档日志文件存在，而且都是10月23日之前的
ASMCMD> pwd
+REV/GOBO4/ARCHIVELOG
ASMCMD> ls
2012_09_30/
2012_10_09/
2012_10_10/
2012_10_11/
2012_10_12/
2012_10_13/
2012_10_14/
2012_10_15/
2012_10_16/
2012_10_17/
2012_10_18/
2012_10_22/
2012_10_23/
arch_795194241_1_100.arc
arch_795194241_1_101.arc
arch_795194241_1_102.arc
............

#再次删除日志文件，来个更狠的命令，直接delete所有的archivelog，最近新增的一个archivelog被删除
RMAN> delete noprompt archivelog all;

released channel: ORA_DISK_1
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=1081 instance=GOBO4A devtype=DISK

List of Archived Log Copies
Key     Thrd Seq     S Low Time  Name
------- ---- ------- - --------- ----
453     1    294     A 29-NOV-12 +REV/gobo4/archivelog/arch_795194241_1_294.arc
deleted archive log
archive log filename=+REV/gobo4/archivelog/arch_795194241_1_294.arc recid=453 stamp=800662185
Deleted 1 objects

# 上面输出的结果只有一个归档日志被删除，何以故？
# 这个我们的分析一下delete noprompt archivelog all以及备份归档日志时使用的 delete input
# 回顾一下Oracle控制文件以及Oracle RMAN的的备份恢复的原理。
# 我们知道，Oracle 控制文件里边记录了数据库的名字，id,创建的时间戳....一大堆的信息，当然也有不可少的归档信息以及备份信息。
# 如果不知道控制文件有什么？ 那就参考:Oracle 控制文件，文章尾部有给出链接。

# 其次，Oracle RMAN的备份恢复的所有信息都依赖于两个东东，要么是控制文件，要么是恢复目录(catalog)。
# 因为所有的备份与恢复信息都会依据备份是的方式存储到这两个位置。
# 理所当然的是，对这两个东东里的备份集，镜像副本，归档日志，等等所有能备份的对象的任意操作，首先会参考这些对象的记录的信息。
# 其次是当被记录的对象发生变化时做相应的更新。

3、深度分析无法清除的原因
#先来看看gv$archived_log，如果是单实例使用v$archived_log
#从下面的查询可知，又有两个新的归档日志产生，一个从第一个instance产生，一个从第二个instance产生。
SQL> select name,status,count(*) from gv$archived_log group by name,status;

NAME                                               S   COUNT(*)
-------------------------------------------------- - ----------
                                                   D        444
+REV/gobo4/archivelog/arch_795194241_1_295.arc     A          2
+REV/gobo4/archivelog/arch_795194241_2_150.arc     A          2

# 从上面的查询可知，当前的两个节点其归档日志只有2个，其余的444个其名字都是NULL值。
# 看看关于视图v$archived_log中NAME列的解释
# Archived log file name. If set to NULL, either the log file was cleared before it was archived or an RMAN backup command
#  with the "delete input" option was executed to back up archivelog all (RMAN> backup archivelog all delete input;). 

# 上面的这段话表明当前的这些日志文件要么被手动清除，要么被rman的delete input选项清除。
# 其次status列的D字段也表明了这些个名字为空的归档日志已经被Deleted.也就是说有444个归档日志已经被删除了。

# 再次尝试删除归档日志，尾数为295和150的归档日志也被删除
RMAN> delete noprompt archivelog all;

released channel: ORA_DISK_1
allocated channel: ORA_DISK_1
channel ORA_DISK_1: sid=1081 instance=GOBO4A devtype=DISK

List of Archived Log Copies
Key     Thrd Seq     S Low Time  Name
------- ---- ------- - --------- ----
454     1    295     A 29-NOV-12 +REV/gobo4/archivelog/arch_795194241_1_295.arc
455     2    150     A 29-NOV-12 +REV/gobo4/archivelog/arch_795194241_2_150.arc
deleted archive log
archive log filename=+REV/gobo4/archivelog/arch_795194241_1_295.arc recid=454 stamp=800712037
deleted archive log
archive log filename=+REV/gobo4/archivelog/arch_795194241_2_150.arc recid=455 stamp=800712038
Deleted 2 objects

# 查询gv$archived_log视图，表明所有现有的archivelog都已经被删除
SQL> select name,status,count(*) from gv$archived_log group by name,status;

NAME                                               S   COUNT(*)
-------------------------------------------------- - ----------
                                                   D        448
# 在asmcmd命令下也无法找到我们刚刚删除的归档日志文件
ASMCMD> pwd
+REV/GOBO4/ARCHIVELOG
ASMCMD> ls -l arch_795194241_1_295.arc
asmcmd: entry 'arch_795194241_1_295.arc' does not exist in directory '+REV/GOBO4/ARCHIVELOG/'
ASMCMD> ls -l arch_795194241_2_150.arc
asmcmd: entry 'arch_795194241_2_150.arc' does not exist in directory '+REV/GOBO4/ARCHIVELOG/'

# 在A节点上再次切换一次
SQL> alter system switch logfile;

System altered.

SQL> select inst_id,name,count(*) from gv$archived_log group by inst_id,name;

   INST_ID NAME                                                 COUNT(*)
---------- -------------------------------------------------- ----------
         2                                                           223
         1 +REV/gobo4/archivelog/arch_795194241_1_296.arc              1
         2 +REV/gobo4/archivelog/arch_795194241_1_296.arc              1
         1                                                           223

--上面的查询可以看到当前的一个归档日志arch_795194241_1_296.arc基于Inst_id为1的有1个，而基于Inst_id为2的也有一个

--而直接查询v$archived_log时只有1个当前的归档日志，实际上arch_795194241_1_296.arc文件是由第一个instance产生的。
--数字296之前的1即可以表明为第一个instance产生的。

SQL> select name from v$archived_log where name='+REV/gobo4/archivelog/arch_795194241_1_296.arc';

NAME
--------------------------------------------------
+REV/gobo4/archivelog/arch_795194241_1_296.arc

# 关于这个地方个人认为这个应该是用于做恢复时用的。
# RAC数据库在恢复时，无论多个少节点，只有所有的归档日志的集合才能完成地表述数据库的变迁。
# 此时，无论从哪个节点上看，或者说做无论从哪个节点恢复，都可以看到该归档日志。
# 而具体是哪个instance产生则由'%t'重做线程编号来判断。

#下面再来看看控制文件

SQL> select * from gv$controlfile_record_section where type='ARCHIVED LOG';

   INST_ID TYPE                         RECORD_SIZE RECORDS_TOTAL RECORDS_USED FIRST_INDEX LAST_INDEX LAST_RECID
---------- ---------------------------- ----------- ------------- ------------ ----------- ---------- ----------
         1 ARCHIVED LOG                         584           224          224         149        148        456
         2 ARCHIVED LOG                         584           224          224         149        148        456

# RECORDS_TOTAL：Number of records allocated for the section
# 列RECORDS_TOTAL表明为当前TYPE分配的可存储的总数，在两个instance上都为224条
# 从最近一次切换日志的查询结果可知，被删除的有223条，新增的一条为arch_795194241_1_296.arc，总条数为224条。
# 如果下次日志切换再增加一条往哪里放呢？那些已经超出缺省保留期的归档日志被覆盖，即被重用。
# 用户在控制文件中保存ARCHIVED LOG部分的保留时间由谁来决定呢，参数control_file_record_keep_time，缺省为7天
# 这意味着7天前的归档日志和备份信息可能在控制文件中已经不存在了

SQL> show parameter control_file_record_keep_time 

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
control_file_record_keep_time        integer     7

SQL> select count (*) from v$archived_log;

  COUNT(*)
----------
       224

# Author : Robinson
# Blog : http://blog.csdn.net/robinson_0612
SQL> alter session set nls_date_format='yyyymmdd hh24:mi:ss';

Session altered.

# 下面的查询正好表明为什么2012_10_23和之前的日志为什么没有被删除
# 因为20121023 18:04:53之后的归档日志已经被覆盖了，所以使用delete archivelog all时是根本无法清除之前的日志的，无能为力阿。
# 对于rman下的delete archivelog all方式不会删除控制文件中对应的归档日志信息，但在控制文件中设置delete状态，
# 即v$archived_log视图的status列为deleted

SQL> select min (FIRST_TIME), min (COMPLETION_TIME), max (FIRST_TIME), max (COMPLETION_TIME) from
  2  v$archived_log;

MIN(FIRST_TIME)   MIN(COMPLETION_TI MAX(FIRST_TIME)   MAX(COMPLETION_TI
----------------- ----------------- ----------------- -----------------
20121023 18:03:12 20121023 18:04:53 20121130 12:00:26 20121130 12:14:51

SQL> select min (FIRST_TIME), min (COMPLETION_TIME), max (FIRST_TIME), max (COMPLETION_TIME) from
  2  gv$archived_log;

MIN(FIRST_TIME)   MIN(COMPLETION_TI MAX(FIRST_TIME)   MAX(COMPLETION_TI
----------------- ----------------- ----------------- -----------------
20121023 18:03:12 20121023 18:04:53 20121130 12:00:26 20121130 12:14:51   

# 既然这般，如何是好啊？
# 那就直接在asmcmd命令行下删除吧。一顿狂删 rm -rf 2012_09_30/
# 莫急，莫急，一不小心删完了，我晕，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文件夹为空，否则，整个文件夹连同上级空目录会被删除

本文涉及到的一些参考文章:
    Oracle 控制文件(CONTROLFILE)    Oracle 归档日志    参数CONTROL_FILE_RECORD_KEEP_TIME和MAXLOGHISOTRY    使用 ASMCMD 工具管理ASM目录及文件    ORA-00254/ORA-15173 Archive_log Directory On Asm Being Deleted

 

更多参考:

有关Oracle RAC请参考
     使用crs_setperm修改RAC资源的所有者及权限     使用crs_profile管理RAC资源配置文件     RAC 数据库的启动与关闭     再说 Oracle RAC services     Services in Oracle Database 10g     Migrate datbase from single instance to Oracle RAC     Oracle RAC 连接到指定实例     Oracle RAC 负载均衡测试(结合服务器端与客户端)     Oracle RAC 服务器端连接负载均衡(Load Balance)     Oracle RAC 客户端连接负载均衡(Load Balance)     ORACLE RAC 下非缺省端口监听配置(listener.ora tnsnames.ora)
     ORACLE RAC 监听配置 (listener.ora tnsnames.ora)     配置 RAC 负载均衡与故障转移     CRS-1006 , CRS-0215 故障一例 
     基于Linux (RHEL 5.5) 安装Oracle 10g RAC
     使用 runcluvfy 校验Oracle RAC安装环境

有关Oracle 网络配置相关基础以及概念性的问题请参考：
     配置非默认端口的动态服务注册
     配置sqlnet.ora限制IP访问Oracle     Oracle 监听器日志配置与管理
     设置 Oracle 监听器密码(LISTENER)     配置ORACLE 客户端连接到数据库

有关基于用户管理的备份和备份恢复的概念请参考
     Oracle 冷备份     Oracle 热备份     Oracle 备份恢复概念     Oracle 实例恢复     Oracle 基于用户管理恢复的处理     SYSTEM 表空间管理及备份恢复     SYSAUX表空间管理及恢复     Oracle 基于备份控制文件的恢复(unsing backup controlfile)

有关RMAN的备份恢复与管理请参考
     RMAN 概述及其体系结构     RMAN 配置、监控与管理     RMAN 备份详解     RMAN 还原与恢复     RMAN catalog 的创建和使用     基于catalog 创建RMAN存储脚本     基于catalog 的RMAN 备份与恢复     RMAN 备份路径困惑     使用RMAN实现异机备份恢复(WIN平台)     使用RMAN迁移文件系统数据库到ASM     linux 下RMAN备份shell脚本     使用RMAN迁移数据库到异机

有关ORACLE体系结构请参考
     Oracle 表空间与数据文件     Oracle 密码文件     Oracle 参数文件     Oracle 联机重做日志文件(ONLINE LOG FILE)     Oracle 控制文件(CONTROLFILE)     Oracle 归档日志     Oracle 回滚(ROLLBACK)和撤销(UNDO)     Oracle 数据库实例启动关闭过程     Oracle 10g SGA 的自动化管理     Oracle 实例和Oracle数据库(Oracle体系结构) 

时间： 2024-11-03 21:51:53

delete archivelog all 无法彻底删除归档日志？的相关文章

解决delete archivelog all无法彻底删除归档日志的问题

最近在因归档日志暴增,使用delete archivelog all貌似无法清除所有的归档日志,到底是什么原因呢? 1.演示环境 SQL> select * from v$version where rownum<2; BANNER ---------------------------------------------------------------- Oracle Database 10g Release 10.2.0.3.0 - 64bit Production SQL> s

DELETE OBSOLETE不删除归档日志以及归档的备份集

今天遇到一个奇怪的事情,使用OBSOLETE不删除归档日志,而且也不删除过期的归档的BACKUP SET 从delete obsolete的概念来看如下: The REPORT OBSOLETE and DELETE OBSOLETE commands work in two steps:                                                                                                         

【Oracle】 rman 删除归档日志的命令

   因为数据仓库上asm的磁盘空间不足,需要删除早期的归档日志,查看资料有以下两种方式: delete archivelog until time 'sysdate-N'; delete archivelog all completed before 'sysdate-N'; 这两个命令的差别在哪里呢? 使用list 命令来查看一下究竟... RMAN>  list archivelog until time 'sysdate-1'; using target database control

Linux怎么自动删除归档日志文件？Linux自动删除归档日志文件的教程

1.日志删除策略 自动删除7天前的归档日志与备份文件. 2.调度计划 0 0 * * * nohup sh /db2backup/script/auto_rm_logs.sh & 3.日志删除脚本 auto_rm_logs.sh #!/bin/sh #------------------------------------- # rm db2 archive log file and *.tgz files @hury # create @2016-12-13 # script name:aut

Oracle RMAN 清除归档日志

      在开发环境及UAT环境经常碰到需要清除归档日志的情形,对于这个问题方法有很多.可以直接使用rm方式清除归档日志,也可以使用find命令来查找符合条件的记录来清除归档日志,或者直接写个shell脚本来搞定.这样在DEV或者UAT还可以,但是在Prod环境还是建议使用RMAN提供的命令来搞定比较妥当.因为rm,find方式删除了实际的归档日志也释放了空间,但对应的存储在控制文件中的归档信息并没有彻底清除.依旧占用着一些空间未能及时清除而需要控制文件通过age out方式来释放空间.本文描

delete archivelog all无法清除归档日志解决方法_oracle

最近在因归档日志暴增,使用delete archivelog all貌似无法清除所有的归档日志,到底是什么原因呢? 1.演示环境 复制代码 代码如下: SQL> select * from v$version where rownum<2; BANNER ---------------------------------------------------------------- Oracle Database 10g Release 10.2.0.3.0 - 64bit Productio

rman 还原归档日志(restore archivelog)

     听说过还原(restore)数据库,表空间及数据库文件,使用归档日志恢复(recover)数据库,表空间,数据库文件.咦,还有还原归档日志这一说法呢?没错,可能我们忽略了还原归档日志这一个过程,原因是还原归档日志通常情况下是oracle在recover时自动完成的.大多数情况下我们是先还原数据库,恢复数据库,打开数据库.实际上在恢复数据库之前有一个动作,那就是还原归档日志,也就是将日志文件还原到缺省的归档位置,如果我们在备份归档日志时使用了delete [all] input子句的话.

归档日志物理删除后闪回恢复区空间未释放

连接数据库进去提示ora-00257:archiver error.Connect internal only,until freed. 登录服务器,操作系统验证,登录好久登录不进去 无奈,把oracle服务重启了下,终于登录进去了 查询v$archived_log 里面有2条归档日志记录,但是在磁盘上怎么找都找不到 select * from V$FLASH_RECOVERY_AREA_USAGE;--显示归档日志占用闪回恢复区有98% select sum(percent_space_use

oracle中升级到12.1.0.2之后rman无法删除已经归档日志

客户一个数据库,架构是2地3中心,本地有primary和standby,远程还有一个standby. primary的rman archivelog deletion policy是ship to all standby 同城standby的rman archivelog deletion policy是backup 1 time,备份在同城standby上进行. 远程standby的rman archivelog deletion policy是applied on all standby.