归档日志比在线日志小很多

To BottomTo Bottom

In this Document

Symptoms
 Changes
 Cause
 Solution
 References

This document is being delivered to you via Oracle Support's Rapid Visibility (RaV) process and therefore has not been subject to an independent technical review.

APPLIES TO:

Oracle Database - Enterprise Edition - Version 11.2.0.1 and later
Information in this document applies to any platform.

SYMPTOMS

The created archived redologs are (significant) smaller than the related online redologfile.

CHANGES

Bug 7016254 is included in 11.2 and makes a major change comparted or prior version in the 'log switch code' in kcrfwnf().
This document is based on the 11.2 behaviour. 

CAUSE

There are 2 possible causes for this :

1. Documented and designed behaviour due to explicit forcing an archive creation before the redolog file is full

    • SQL> alter system switch logfile;
    • SQL> alter system archive log current;
    • RMAN> backup archivelog all;
    • RMAN> backup database plus archivelog;
    • ARCHIVE_LAG_TARGET : limits the amount of data that can be lost and effectively increases the availability of the standby database by forcing a log switch after the specified amount of time elapses. you can see this aswell in RAC with an idle/low-load instance.

2. Undocumented, but designed behaviour :

    • BUG 9272059 - REDO LOG SWITCH AT 1/8 OF SIZE DUE TO CMT CPU'S
    • BUG 10354739 - REDOLOGSIZE NOT COMPLETLY USED
    • BUG 12317474 - FREQUENT REDO LOG SWITCHES GENERATING SMALL SIZED ARCHIVELOGS 
    • BUG 5450861 - ARCHIVE LOGS ARE GENERATED WITH A SMALLER SIZE THAN THE REDO LOG FILES
    • BUG 7016254 - DECREASE CONTROL FILE ENQUEUE WAIT AT LOG SWITCH

Explanation :

As per Bug: 5450861 (closed as 'Not a Bug'):

* The archive logs do not have to be even in size. This was decided a very long time ago,
when blank padding the archive logs was stopped, for a very good reason - in order to save disk space.

* The log switch does not occur when a redo log file is 100% full. There is an internal algorithm
that determines the log switch moment. This also has a very good reason - doing the log switch
at the last moment could incur performance problems (for various reasons, out of the scope of this note).
As a result, after the log switch occurs, the archivers are copying only the actual information from the
redo log files. Since the redo logs are not 100% full after the log switch and the archive logs are
not blank padded after the copy operation has finished, this results in uneven, smaller files than
the original redo log files.

There are a number of factors which combine to determine the log
switch frequency. These are the most relevant factors in this case:


a) RDBMS parameter LOG_BUFFER_SIZE

If this is not explicitly set by the DBA then we use a default;
at instance startup the RDBMS  calculates the number of shared redo
strands as ncpus/16, and the size of each strand is 128Kb * ncpus
(where ncpus is the number of CPUs in the system). The log buffer
size is the number of stands multiplied by the strand size.
The calculated or specified size is rounded up to a multiple of the granule size 
of a memory segment in the SGA. For 11.2 if
SGA size >= 128GB then granule size is 512MB
64GB <= SGA size < 128GB then granule size is 256MB
32GB <= SGA size < 64GB then granule size is 128MB
16GB <= SGA size < 32GB then granule size is 64MB
8GB <= SGA size < 16GB then granule size is 32MB
1GB <= SGA size < 8GB then granule size is 16MB
SGA size < 1GB then granule size is 4MB
There are some minimums and maximums enforced.


b) System load

Initially only one redo strand is used, ie the number of "active"
redo strands is 1, and all the processes copy their redo into
that one strand. When/if there is contention for that strand then
the number of active redo strands is raised to 2. As contention
for the active strands increases, the number of active strands
increases. The maxmum possible number of active redo strands is
the number of strands initially allocated in the log buffer.
(This feature is called "dynamic strands", and there is a hidden
parameter to disable it which then allows processes to use all
the strands from the outset).


c) Log file size

This is the logfile size decided by the DBA when the logfiles are created.


d) The logfile space reservation algorithm

When the RDBMS switches into a new online redo logfile, all the
log buffer redo strand memory is "mapped" to the logfile space.
If the logfile is larger than the log buffer then each strand
will map/reserve its strand size worth of logfile space, and the
remaining logfile space (the "log residue") is still available.
If the logfile is smaller than the log buffer, then the whole
logfile space is divided/mapped/reserved equally among all the
strands, and there is no unreserved space (ie no log residue).
When any process fills a strand such that all the reserved
underlying logfile space for that strand is used, AND there is
no log residue, then a log switch is scheduled.

Example : 128 CPU's so the RDBMS allocates a
log_buffer of size 128Mb containing 8 shared strands of size 16Mb.
It may be a bit larger than 128Mb as it rounds up to an SGA granule boundary.
The logfiles are 100Mb, so when the RDBMS switches into a
new online redo logfile each strand reserves 100Mb/8 = 25600 blocks
and there is no log residue. If there is low system load, only one
of the redo strands will be active/used and when 25600 blocks of
that strand are filled then a log switch will be scheduled - the created
archive logs have a size around 25600 blocks.

With everything else staying the same (128 cpu's and low load),
using a larger logfile would not really reduce the amount of
unfilled space when the log switches are requested, but it would
make that unfilled space less significant as a percentage of the
total logfile space, eg

- with a 100Mb logfile, the log switch happens with 7 x 16Mb
logfile space unfilled (ie the logfile is 10% full when the
log switch is requested)

- with a 1Gb logfile, the log switch would happen with 7 x 16Mb
logfile space unfilled (ie the logfile is 90% full when the
log switch is requested)

With a high CPU_COUNT, a low load and a redo log file size smaller than 
the redolog buffer, you may see small archived log files because of log switches
at about 1/8 of the size of the define log file size.
This is because CPU_COUNT defines the number of redo strands (ncpus/16).
With a low load only a single strand may be used. With redo log file size smaller
than the redolog buffer, the log file space is divided over the available strands.
When for instance only a single active strand is used, a log switch can already occur
when that strand is filled.

SOLUTION

Check if the above is matching the behaviour you are seeing, then it is expected behaviour.

If the behaviour is different than open a Service Request to Oracle Support for futher analysis

<think>嗯,用户询问的是Oracle RMAN归档日志的删除策略配置。这个问题很专业,用户应该是DBA或运维人员,需要精确控制归档日志空间。从提问方式看,用户对RMAN有基础了解,但可能被复杂的保留策略选项搞混了。归档日志管理确实是备份恢复的核心环节。我记得RMAN主要提供两种保留策略:基于恢复窗口(RECOVERYWINDOW)和基于冗余副本(REDUNDANCY)。用户需要根据实际业务需求选择——前者适合有明确RPO要求的场景,后者则更简单直接。 具体到配置命令,关键点在于CONFIGURE ARCHIVELOG DELETIONPOLICY和CROSSCHECK命令的配合使用。这里要特别注意:如果用户启用了DataGuard,删除策略必须考虑备用库的日志应用状态,否则可能导致备用库中断。这个坑很多DBA都踩过。空间计算方面需要提醒用户:恢复窗口策略实际需要的空间可能远大于窗口天数*每日日志量,因为如果某个备份保留期内没有新备份,对应的日志会一直保留。最好用V$RECOVERY_AREA_USAGE视图监控。用户可能还会遇到ORA-00257错误,这通常是归档日志撑满闪回区导致的。除了设置保留策略,还应该建议用户定期执行DELETEOBSOLETE命令,并考虑归档路径使用ASM或非闪回区目录。 最后生成的三个问题都紧扣操作实践:第一条针对策略选择的关键考量点,第二条解决用户配置后可能遇到的典型报错,第三条则是日常维护动作。这样应该能覆盖用户后续可能遇到的衍生问题。</think>## Oracle RMAN 归档日志删除策略配置指南 ### 1. 核心删除策略类型 Oracle RMAN 提供两种主要的归档日志删除策略: * **基于恢复窗口 (RECOVERY WINDOW)** 定义数据库可恢复到**过去多长时间**的状态。 语法:`CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF <天数> DAYS;` 示例:`CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;` * **规则**:RMAN 保留所有**保证能将数据库恢复到最近7天内任意时间点**所必需的归档日志和备份。 * **基于冗余副本 (REDUNDANCY)** 定义每种备份文件**至少保留多少个副本**。 语法:`CONFIGURE RETENTION POLICY TO REDUNDANCY <副本数>;` 示例:`CONFIGURE RETENTION POLICY TO REDUNDANCY 2;` * **规则**:RMAN 保留至少2份完整的备份集及其所需的归档日志。超过数量的旧副本会被标记为可删除。 ### 2. 归档日志删除策略 (ARCHIVELOG DELETION POLICY) 此策略**专门控制归档日志的删除**,需在配置核心保留策略后设置: * **基本语法** ```sql CONFIGURE ARCHIVELOG DELETION POLICY TO ...; ``` * **常用策略选项** * **应用后删除 (APPLIED ON STANDBY)** 适用于 Data Guard 环境。归档日志在**所有配置的备用数据库**上应用后才允许删除。 ```sql CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY; ``` * **备份后删除 (BACKED UP \<次数\> TIMES TO DEVICE TYPE \<设备类型\>)** 归档日志被备份到指定设备类型达到指定次数后允许删除。 ```sql CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 2 TIMES TO DISK; ``` * **无 (NONE - 默认)** 仅遵循核心保留策略 (`RECOVERY WINDOW` 或 `REDUNDANCY`)。归档日志在**不再被任何备份需要时**才可删除。 ```sql CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; -- 默认值 ``` * **已切换 (SHIPPED TO ALL STANDBY)** 归档日志已传输到所有备用库(但不一定应用)后允许删除。 ### 3. 执行删除的关键步骤 配置策略后,**不会自动删除**归档日志。需手动执行命令: 1. **标记过期文件 (Obsolete)** 根据保留策略确定哪些归档日志/备份已不再需要: ```sql REPORT OBSOLETE; -- 查看哪些文件将被标记为过期 DELETE OBSOLETE; -- 删除标记为过期的文件 ``` 2. **删除不再需要的归档日志** 使用 `DELETE` 命令删除符合删除策略的归档日志: ```sql DELETE ARCHIVELOG ALL; -- 删除所有符合删除策略的归档日志 DELETE ARCHIVELOG UNTIL TIME 'SYSDATE-3'; -- 删除3天前的归档日志(需符合策略) DELETE ARCHIVELOG ALL BACKED UP 2 TIMES TO DEVICE TYPE DISK; -- 删除已备份2次到磁盘的日志 ``` 3. **交叉检查 (推荐)** 确保 RMAN 仓库记录与磁盘/磁带上的物理文件一致: ```sql CROSSCHECK ARCHIVELOG ALL; -- 检查所有归档日志 DELETE EXPIRED ARCHIVELOG ALL; -- 删除仓库中有记录但物理文件已丢失的归档日志信息 ``` ### 4. 最佳实践与注意事项 * **策略选择**: * 优先使用 `RECOVERY WINDOW` 满足 RPO (恢复点目标)[^1]。 * `REDUNDANCY` 更简单,但需确保副本数足够覆盖所需恢复时间。 * `ARCHIVELOG DELETION POLICY` 通常配置为 `APPLIED ON ALL STANDBY` (有DG时) 或 `BACKED UP ...` (无DG时)。 * **执行频率**: 结合备份作业,在备份成功后执行 `DELETE OBSOLETE` 和 `DELETE ARCHIVELOG ...`。可封装在备份脚本中。 * **空间监控**: 定期检查归档目标目录 (`LOG_ARCHIVE_DEST_n`) 或快速恢复区 (`DB_RECOVERY_FILE_DEST`) 的使用情况,避免空间耗尽导致数据库挂起[^2]。 * **Data Guard 环境**: 务必使用 `APPLIED ON [ALL] STANDBY` 策略,防止主库删除备用库尚未应用的日志,导致复制中断。 * **备份验证**: 删除策略依赖备份的有效性。定期 `VALIDATE` 备份集。 * **谨慎使用 `DELETE FORCE`**: `DELETE ... FORCE` 会跳过策略检查直接删除物理文件,可能导致恢复失败。仅在紧急清理且明确后果时使用。 ### 5. 配置示例 **目标**:设置7天恢复窗口,归档日志在备份到磁盘2次后删除。 ```sql RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS; RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 2 TIMES TO DISK; -- 在备份脚本中执行: RMAN> BACKUP ARCHIVELOG ALL DELETE INPUT; -- 备份并删除符合策略的输入日志 RMAN> DELETE OBSOLETE; ``` **目标**:Data Guard 环境,归档日志在所有备库应用后删除。 ```sql RMAN> CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS; RMAN> CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY; -- 定期执行: RMAN> DELETE ARCHIVELOG ALL; ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值