今天,回顾下之前遇到的一个参数的问题【archive_lag_target】

该参数的作用是强制数据库在某个时间间隔达成的时候执行日志切换(log switch)
它的单位是秒,因此:
如果,你设置成1800,表示1800/60=30分钟

该参数的工作原理是:
如果设置了该参数,那么该参数将会定期(你设置的值)去检查当前的重做日志
1. 当前的重做日志是否包含重做记录?如果包含,则切换日志
2. 当前重做日志是几秒前被创建的(自创建以来过去了n秒)?当前日志的归档时间(归档需要m秒)?
—-> 如果n+m的时间超过了archive_lag_target的值,则切换日志

该参数的规则如下:
0,表示禁用
60 ~ 7200,为合理的取值范围,即:
通常会设置为1分钟强制切换日志,或者2小时强制切换日志

但是出于性能考虑:
1. 频繁的日志切换会带来性能问题,如果开了归档模式,频繁的日志切换,也会带来存储的压力
2. 因为归档文件是用于数据库恢复的,因此日志切换的频率的设计,在DG架构中也需要考虑:
——–> 网络承载的数据传输的压力
——–> 备库能够接受的重做数据丢失的边界

当正常的日志切换比强制日志切换的间隔更频繁,archive_lag_target的设置就很尴尬了,形同虚设
但是在日志切换不频繁,且不规律的场景中,强制日志切换就很有用了:
1. 让日志切换的频率规范
2. 保证灾难发生的时候,重做数据的丢失在可控的边界之中

一般设置为:三十分钟到一个小时之间,也就是:1800 ~ 3600

此外,特别【需要注意】的是,如果在ORACLE RAC架构中启用该参数,则每个节点都需要启用,并且必须设置成同样的值。

下面通过设置前后的日志变化,展示该参数的用法:

在DG架构中,该参数需要在主库端设置。

先看看当前归档日志产生的频率

可以看到,日志产生的时间间隔并不规律。

这里为了演示效果,将改参数设为:5分钟

为了看到效果,我们让数据库生成一些大的数据:

然后再看看:

可以看到,现在,日志已经每隔五分钟生成一次。

——————————————————————————
Done。

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

隐藏
变装