小编点评

**问题一：** alter system set archive_lag_target=1800; **建议：** * 由于日志切换频率过低，建议将 archive_lag_target 设置为 0 或 1分钟。 * 为了减少对 ADG 环境的影响，可以设置 archive_lag_target 为 1 或 5分钟，但要根据实际情况进行调整。 **问题二：** * alter user test identified by 123; **建议：** * 在修改业务用户密码的行为之前，请确保备库中已更新密码。 * 确保开发人员在修改主库密码后，立即同步密码修改到备库。

正文

为客户测试一个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并不会同步密码修改的动作？

而其实除了在主库修改密码后，备库没有及时同步的情况之外，基本都是开发连错库了..