alter user account unlock在备库可能无效，因备库处于read only with apply状态时拒绝所有ddl；仅当锁由failed_login_attempts触发且记录于v$ro_user_account内存视图时，该命令才生效。
ADG_REDIRECT_DML 开启后，备库仍保持只读模式，用户权限管理不能照搬主库逻辑——因为备库不写系统表，V$RO_USER_ACCOUNT 才是真实生效的锁状态来源。
为什么 ALTER USER ACCOUNT UNLOCK 在备库可能无效？
备库处于 READ ONLY WITH APPLY 状态时，所有 DDL（包括 ALTER USER ... UNLOCK）都会被拒绝，除非显式切换为读写模式（这会中断 Data Guard 同步）。但 Oracle 12c 起允许在只读备库执行 ALTER USER ... ACCOUNT UNLOCK，前提是：
• 用户被锁是因密码尝试失败（FAILED_LOGIN_ATTEMPTS 触发）；
• 锁状态记录在内存视图 V$RO_USER_ACCOUNT 中，而非数据字典；
• 当前用户有 ALTER USER 权限且连接的是备库实例本身（不是通过 DB Link 或主库代理）。
如何确认备库用户是否真被锁？
别只查 DBA_USERS.ACCOUNT_STATUS ——它反映主库状态，对备库无意义。必须查内存视图：
• 在备库执行：SELECT USERNAME, LOCK_DATE, EXPIRY_DATE FROM V$RO_USER_ACCOUNT WHERE USERNAME = 'DB_XXX';
• 若返回一行且 LOCK_DATE 非空，说明该用户在备库本地被锁；
• 若无返回，说明未触发只读账户锁定机制（比如锁由主库显式 ALTER USER ... LOCK 引起，则备库也会同步锁住，但不会出现在 V$RO_USER_ACCOUNT）；
• 注意：V$RO_USER_ACCOUNT 仅在只读数据库中填充，主库查此视图始终为空。
备库用户权限变更的实操边界
以下操作在只读备库上不可行：
• CREATE USER / DROP USER
• GRANT / REVOKE 系统权限或对象权限（因需更新数据字典）
• 修改 profile（如 ALTER PROFILE ... LIMIT FAILED_LOGIN_ATTEMPTS）
以下操作在只读备库上可行（且仅影响本地内存状态）：
• ALTER USER ... ACCOUNT UNLOCK（针对 V$RO_USER_ACCOUNT 中的锁）
• ALTER USER ... IDENTIFIED BY（重置密码，但仅对后续新连接生效；已锁用户需先 unlock）
• 通过 ADG_REDIRECT_DML 间接修改应用表数据（权限仍受主库对象授权约束）
权限同步延迟与一致性风险
主库上做的权限变更（如 GRANT SELECT ON scott.emp TO mary），会随 Redo 日志同步到备库，但存在 Apply 延迟。这意味着：
• 备库上立即执行 SELECT * FROM scott.emp 可能报 ORA-01031: insufficient privileges，即使主库已授予权限；
• 不要依赖“刚在主库授完权，就切到备库验证”——应等待 SELECT MAX(SEQUENCE#) FROM V$ARCHIVED_LOG 与主库一致，或检查 APPLY_LAG 为 0；
• 若应用要求强权限一致性，应在主库完成授权后，主动在备库执行一次 dummy 查询触发权限校验缓存刷新（如 SELECT COUNT(*) FROM DUAL），避免首次查询失败。
真正难处理的不是“怎么解锁”，而是“怎么让应用不感知主备权限差异”。V$RO_USER_ACCOUNT 的存在意味着：备库的账户安全策略是独立运行的，它既不完全继承主库，也不完全隔离——这种混合模型最容易在自动化巡检或密码策略轮换时出问题。
