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

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介: 今天遇到一个奇怪的事情,使用OBSOLETE不删除归档日志,而且也不删除过期的归档的BACKUP SET 从delete obsolete的概念来看如下: The REPORT OBSOLETE and DELETE OBSOLETE com...

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

The REPORT OBSOLETE and DELETE OBSOLETE commands work in two steps:                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                              
   For each datafile for which there are full backup, datafile copy, or level 0 incremental backups, RMAN identifies the oldest full or
level 0 backup or copy that is not obsolete under the retention policy being tested. Any full backup, level 0 incremental backup, or
datafile copy of a datafile older than the one identified in this step is considered obsolete.                                                                                                                                                                                                                                                                                                                                                                          Rman Not Deleting Obsolete Archive Logs And Archive Log Backups (文档 ID 282617.1)
   Any archived logs and level 1 incremental backups that are older than the oldest non-obsolete full backup are then obsolete because
there is no full or level 0 backup to which they can be applied.                                                                                                                                                                    
可以看到所谓的冗余策略不管是天数还是副本数量,保证的都是你冗余时间或者副本最早的那一个FULL BACKUP DATABASE(FULL BACK 或者LEVEL 0增量备份)
是能够恢复的,而早于这个FULL BACKUP以前的增量备份和归档日志或者其他备份都是失效的。简单的说delete obsolete会删除已经没有用的不用于恢复的
归档日志。但是今天遇到的问题是明显的已经处于无用状态的归档任然保留,delete obsolete不能删除。

查看MOS发现问题如下:


once the datafile is identified, the file must be brought up to date with the other files. To do this, execute the following steps:

# If file is Offline:


1. Recover datafile XX:

    alter database recover datafile XX

    -- recovery will apply archives.


2. Set the Datafile Online

     alter database datafile XX online;

 

or

# If tablespace is in begin backup mode:

1. sql> alter tablespace end backup;

 

Once file is brought upto date, RMAN will not have the need to retain older archivelog files.

简单的说就是如果有数据文件处于OFFLINE 状态或者HOT BACKUP 状态,一旦重新ONLINE这个数据文件或者END BACKUP这个文件
是需要归档来进行恢复,所以是不能删除的,所以马上查看数据文件状态如下:

查询过程和处理过程
SQL> select * from dba_data_files;
 
FILE_NAME                                                ONLINE_STATUS
-------------------------------------------------------- -------------
C:\ORACLE\PRODUCT\10.2.0\ORADATA\BENDI\USERS01.DBF       ONLINE
C:\ORACLE\PRODUCT\10.2.0\ORADATA\BENDI\SYSAUX01.DBF      ONLINE
C:\ORACLE\PRODUCT\10.2.0\ORADATA\BENDI\UNDOTBS01.DBF     ONLINE
C:\ORACLE\PRODUCT\10.2.0\ORADATA\BENDI\SYSTEM01.DBF      SYSTEM
C:\ORACLE\PRODUCT\10.2.0\ORADATA\BENDI\TEST01.DBF        ONLINE
C:\ORACLE\PRODUCT\10.2.0\ORADATA\BENDI\UNTDOTBS01.DBF    ONLINE
C:\ORACLE\PRODUCT\10.2.0\ORADATA\BENDI\TESTCK.DBF        RECOVER
 
7 rows selected
 
SQL> drop tablespace testck;
 
drop tablespace testck
 
ORA-01549: tablespace not empty, use INCLUDING CONTENTS option
 
SQL> drop tablespace testck including contents and datafiles;
 
Tablespace dropped
 
SQL> select * from dba_data_files;
 
FILE_NAME                                                ONLINE_STATUS
-------------------------------------------------------- -------------
C:\ORACLE\PRODUCT\10.2.0\ORADATA\BENDI\USERS01.DBF       ONLINE
C:\ORACLE\PRODUCT\10.2.0\ORADATA\BENDI\SYSAUX01.DBF      ONLINE
C:\ORACLE\PRODUCT\10.2.0\ORADATA\BENDI\UNDOTBS01.DBF     ONLINE
C:\ORACLE\PRODUCT\10.2.0\ORADATA\BENDI\SYSTEM01.DBF      SYSTEM
C:\ORACLE\PRODUCT\10.2.0\ORADATA\BENDI\TEST01.DBF        ONLINE
C:\ORACLE\PRODUCT\10.2.0\ORADATA\BENDI\UNTDOTBS01.DBF    ONLINE
 
6 rows selected

我删除了表空间后,REPORT OBSOLETE可以正常删除过期的归档和归档备份集。


当然也有MOS文章说还有一种可能的情况就是BUG。
Bug 12412131 - Archivelog backups are not being deleted by 'DELETE OBSOLETE' (文档 ID 12412131.8)

 

 

 

 

 

 


 

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
目录
打赏
0
0
0
0
91
分享
相关文章
【赵渝强老师】Oracle的控制文件与归档日志文件
本文介绍了Oracle数据库中的控制文件和归档日志文件。控制文件记录了数据库的物理结构信息,如数据库名、数据文件和联机日志文件的位置等。为了保护数据库,通常会进行控制文件的多路复用。归档日志文件是联机重做日志文件的副本,用于记录数据库的变更历史。文章还提供了相关SQL语句,帮助查看和设置数据库的日志模式。
124 1
【赵渝强老师】Oracle的控制文件与归档日志文件
Struts 2 日志管理化身神秘魔法师,洞察应用运行乾坤,演绎奇幻篇章!
【8月更文挑战第31天】在软件开发中,了解应用运行状况至关重要。日志管理作为 Struts 2 应用的关键组件,记录着每个动作和决策,如同监控摄像头,帮助我们迅速定位问题、分析性能和使用情况,为优化提供依据。Struts 2 支持多种日志框架(如 Log4j、Logback),便于配置日志级别、格式和输出位置。通过在 Action 类中添加日志记录,我们能在开发过程中获取详细信息,及时发现并解决问题。合理配置日志不仅有助于调试,还能分析用户行为,提升应用性能和稳定性。
86 0
【数据守护者必备】SQL数据备份与恢复策略全解析:从全量到日志备份,手把手教你确保企业信息万无一失的实战技巧!
【8月更文挑战第31天】数据库是企业核心业务数据的基石,为防止硬件故障、软件错误或人为失误导致的数据丢失,制定可靠的备份与恢复策略至关重要。本文通过一个在线购物平台的案例,详细介绍了使用 SQL Server 进行全量备份、差异备份及事务日志备份的方法,并演示了如何利用 SQL Server Agent 实现自动化备份任务。此外,还提供了数据恢复的具体步骤和测试建议,确保数据安全与业务连续性。
341 0
实时计算 Flink版操作报错合集之报错“找不到对应的归档日志文件”,怎么处理
在使用实时计算Flink版过程中,可能会遇到各种错误,了解这些错误的原因及解决方法对于高效排错至关重要。针对具体问题,查看Flink的日志是关键,它们通常会提供更详细的错误信息和堆栈跟踪,有助于定位问题。此外,Flink社区文档和官方论坛也是寻求帮助的好去处。以下是一些常见的操作报错及其可能的原因与解决策略。
"揭秘!一键解锁Oracle日志清理魔法,让海量归档日志无处遁形,守护数据库健康,告别磁盘空间告急噩梦!"
【8月更文挑战第9天】随着Oracle数据库在企业应用中的普及,归档日志管理对保持数据库健康至关重要。归档日志记录所有更改,对数据恢复极为重要,但也可能迅速占用大量磁盘空间影响性能。利用Oracle提供的RMAN工具,可通过编写Shell脚本来自动清理归档日志。脚本包括设置环境变量、连接数据库、检查和删除指定时间前的日志,并记录执行情况。通过Cron作业定时运行脚本,可有效管理日志文件,确保数据库稳定运行。
177 7
关系型数据库Oracle归档日志备份
【7月更文挑战第19天】
105 5
图解MySQL【日志】——Redo Log
Redo Log(重做日志)是数据库中用于记录数据页修改的物理日志,确保事务的持久性和一致性。其主要作用包括崩溃恢复、提高性能和保证事务一致性。Redo Log 通过先写日志的方式,在内存中缓存修改操作,并在适当时候刷入磁盘,减少随机写入带来的性能损耗。WAL(Write-Ahead Logging)技术的核心思想是先将修改操作记录到日志文件中,再择机写入磁盘,从而实现高效且安全的数据持久化。Redo Log 的持久化过程涉及 Redo Log Buffer 和不同刷盘时机的控制参数(如 `innodb_flush_log_at_trx_commit`),以平衡性能与数据安全性。
27 5
图解MySQL【日志】——Redo Log
图解MySQL【日志】——Undo Log
Undo Log(回滚日志)是 MySQL 中用于实现事务原子性和一致性的关键机制。在默认的自动提交模式下,MySQL 隐式开启事务,每条增删改语句都会记录到 Undo Log 中。其主要作用包括:
26 0
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log、原理、写入过程;binlog与redolog区别、update语句的执行流程、两阶段提交、主从复制、三种日志的使用场景;查询日志、慢查询日志、错误日志等其他几类日志
102 35
MySQL日志详解——日志分类、二进制日志bin log、回滚日志undo log、重做日志redo log