在生产环境中，数据库管理员经常会遇到各种各样的错误和挑战。比如备库端备份完归档日志后无法删除这些日志，并且一直报RMAN-08120错误。通过分析和排查，深入了解这个问题，并探讨备库架构的选择。
环境介绍
首先，让了解一下案例的环境。数据库架构相对简单，使用了GRID单机+ADG（Active Data Guard）架构，数据库版本是11.2.0.4，且已经应用了最新的PSU（Patch Set Update）。
分析过程
- 报错现象
RMAN-08120错误，指出归档日志无法删除。在备份脚本日志中，发现了一系列相同的错误，其中包含了归档日志的文件名和序列号。通常，RMAN-08120错误表示归档日志尚未在备库端应用，这可能是由于以下原因引起的：
- 归档日志尚未传递到备库端，可能由于传输中的错误。
- 备库端尚未应用这些日志。
- 部署了OGG（Oracle GoldenGate）的IE（Integrated Extract）进程，但尚未抽取这些日志。
- DG同步状态
为了进一步排查，查询了Data Guard（DG）同步状态，发现状态正常，没有延迟。这表明问题可能不是由DG同步引起的。
- 归档日志是否存在
通过RMAN查询，确认了归档日志实际存在，排除了数据不一致的情况。
- 归档日志生产记录
进一步的分析显示，归档日志序列号之间存在巨大的差距，而无法删除的日志序列号范围从1到100。这暗示了备库曾经在一段时间内充当了主库的角色。通过查询归档日志的详细信息，发现这些无法删除的归档日志是在备库切换到快照模式后生成的，导致它们无法删除。
故障原因
在进一步了解备库的情况后，确定了问题的根本原因。备库曾经切换到快照模式，这导致了生成的归档日志无法被删除。问题可能是由于BUG或某个隐藏参数控制引起的。为解决问题，采取了强制删除归档日志的方法。
解决方案
问题的解决方案非常简单，通过RMAN执行以下命令删除归档日志：
RMAN> delete force archivelog until time 'sysdate-3';
这个命令会强制删除在当前时间前3天之前的所有归档日志。
总结及建议
这个案例提供了一些有关备库架构选择的有益思考。虽然单机+ADG架构相对简单，但它可能不适用于所有场景，尤其在对高可用性有严格要求的情况下。备库架构的选择应该根据业务需求、硬件环境、技术能力和其他因素来进行综合考虑。在某些情况下，ADG+容灾自动切换等机制可以弥补高可用性的不足，但在需要更快速、无感知的故障
