为客户测试一个ADG场景问题,发现测试环境的日志切换频率过低,总是需要定期手工切换,这非常影响测试心情。
实际上,可以设置archive_lag_target参数强制日志切换。
比如设置:
alter system set archive_lag_target=1800;
这样即使库没任何压力,半小时也会切换一次日志。
该设置同时也适用于非常空闲的生产环境,毕竟太久时间的业务数据都在Online Redo logfile中也不好。
尤其是有cascade的DG环境,更不应该让这个时间太长,但也不要设置太短了,那样会有性能问题。
另外,借着这个参数设置的问题,顺便提示下ADG环境的问题:
1. 这类数据库参数设置,并不会通过ADG同步。
这在面试中也会经常被拿来提问,可以考察候选人的实际经验和思考方式。
----------
@primary
----------
SQL> alter system set archive_lag_target=1800;
System altered.
SQL> show parameter archive_lag_target
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
archive_lag_target integer 1800
----------
@standby
----------
SQL> show parameter archive_lag_target
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
archive_lag_target integer 0
SQL>
2. 修改业务用户密码的行为,会被同步到备库。
----------
@primary
----------
SQL> alter user test identified by 123;
User altered.
SQL> conn test/123
Connected.
----------
@standby
----------
SQL> conn test/123
Connected.
SQL> show parameter archive_lag_target
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
archive_lag_target integer 0
之所以说这个问题,经常碰到有开发人员去问DBA,某某库的备库密码不正确,主库的密码是对的,是不是ADG并不会同步密码修改的动作?
而其实除了在主库修改密码后,备库没有及时同步的情况之外,基本都是开发连错库了..
标签:target,lag,SQL,----------,日志,archive From: https://www.cnblogs.com/jyzhao/p/17400504.html