必须用sysdba权限账号（如sys或system）解锁，普通用户执行会报ora-01031错误；需先查dba_users或v$ro_user_account确认锁定状态，再执行alter user ... account unlock；反复锁定须调failed_login_attempts参数；adg备库须本地登录单独解锁。
必须用具备 SYSDBA 权限的账号（如 sys 或 system）才能解锁，普通用户执行 ALTER USER ... ACCOUNT UNLOCK 会直接报 ORA-01031: insufficient privileges 错误。
查清当前用户状态和锁定来源
先确认是不是真被锁，以及锁在哪——Oracle 19c 的主备集群、RAC 和只读备库行为不同，不能只看 dba_users.account_status：
- 在主库执行：
SELECT username, account_status, lock_date FROM dba_users WHERE username = 'SCOTT';，若返回LOCKED(TIMED)或EXPIRED & LOCKED(TIMED)，说明是密码失败触发的自动锁定 - 在 ADG 只读备库上，
dba_users永远显示OPEN，得查内存视图：SELECT * FROM v$ro_user_account WHERE username = 'SCOTT';，有记录即表示该备库已锁 - 如果是 RAC 环境，还要排除节点间 GES 同步延迟导致的“看似已解锁但连接仍拒”的假象，建议在所有节点都执行一次解锁
用 SQL 命令解锁并验证是否生效
命令本身简单，但细节决定成败：
- 语法必须严格：
ALTER USER SCOTT ACCOUNT UNLOCK;——ACCOUNT UNLOCK是固定词组，中间不能加下划线、空格或换行 - 如果同时要重置密码（比如原密码已遗忘），合并执行更安全：
ALTER USER SCOTT IDENTIFIED BY newpass ACCOUNT UNLOCK; - 解锁后必须立刻验证：
SELECT username, account_status FROM dba_users WHERE username = 'SCOTT';，确保返回OPEN；在备库还要补查v$ro_user_account是否已清空 - 注意大小写：Oracle 19c 默认用户名全大写，
'scott'和'SCOTT'是两个不同用户
为什么刚解锁又马上被锁？重点调 profile 里的 FAILED_LOGIN_ATTEMPTS
反复被锁不是解锁失败，而是防护机制还在运行。根本原因是 profile 中的失败次数限制没改：
- 先查用户用的 profile：
SELECT username, profile FROM dba_users WHERE username = 'SCOTT'; - 再查该 profile 的限制：
SELECT resource_name, limit FROM dba_profiles WHERE profile = 'DEFAULT' AND resource_name = 'FAILED_LOGIN_ATTEMPTS';，默认值通常是10 - 临时放开（适合测试/运维）：
ALTER PROFILE DEFAULT LIMIT FAILED_LOGIN_ATTEMPTS UNLIMITED; - 若需保留一定防护，建议设为
30或50：ALTER PROFILE DEFAULT LIMIT FAILED_LOGIN_ATTEMPTS 30; - 注意：
FAILED_LOGIN_ATTEMPTS修改立即生效，无需重启数据库，但会影响所有使用该 profile 的用户
备库用户被锁不能只靠主库操作
ADG 只读备库的锁定状态独立于主库，主库解锁对备库完全无效：
- Oracle 12c+ 才支持在备库上直接执行
ALTER USER ... ACCOUNT UNLOCK，19c 支持，但必须连到备库实例本身执行 - 不能通过主库的 DBLINK 或远程连接去操作备库的用户锁定状态
- 如果应用直连备库，且备库用户被锁，必须登录备库服务器，用
sqlplus / as sysdba连本地实例再解锁 - 备库解锁后，仍需检查
v$ro_user_account是否为空，这是唯一可信的状态源
真正容易被忽略的是备库的 v$ro_user_account 视图和 RAC 下多节点 GES 状态不一致的问题——很多 DBA 解锁完主库就以为万事大吉，结果应用连备库或某节点时照样报 ORA-28000，根源就在这里。
