FAILED_LOGIN_ATTEMPTS 和 PASSWORD_LOCK_TIME 必须配对设置在同一条 ALTER PROFILE 语句中，否则账户可能永久锁定；PASSWORD_LOCK_TIME 单位为天，设为1/24表示锁定1小时，未设置时默认为UNLIMITED（永久锁定）。
FAILED_LOGIN_ATTEMPTS 和 PASSWORD_LOCK_TIME 必须配对设置
只设 failed_login_attempts 不设 password_lock_time，账户会被锁定但永远不解锁——这是生产环境最常踩的坑。oracle 默认 password_lock_time 是 0（即永久锁定），不是“1小时”或“1天”。
-
FAILED_LOGIN_ATTEMPTS控制失败几次后触发锁定，值为5或10较常见 -
PASSWORD_LOCK_TIME单位是“天”，设为1/24表示锁定 1 小时，1/1440表示锁定 1 分钟 - 若设
PASSWORD_LOCK_TIME为UNLIMITED，需 DBA 手动执行ALTER USER ... ACCOUNT UNLOCK才能恢复 - 修改后立即生效，不影响已登录会话，但新登录尝试即按新规校验
别直接改 DEFAULT PROFILE，优先建专用 profile
直接在 DEFAULT profile 上改 FAILED_LOGIN_ATTEMPTS，等于给所有未显式指定 profile 的用户（包括 SYS、SYSTEM、DBSNMP）统一上锁——某次误操作导致监控账号被锁，Zabbix 告警全丢。
- 新建 profile 更安全：
CREATE PROFILE app_login_limit LIMIT FAILED_LOGIN_ATTEMPTS 5 PASSWORD_LOCK_TIME 1/24; - 分配前确认用户当前 profile：
SELECT username, profile FROM dba_users WHERE username = 'APP_USER'; - 绑定命令：
ALTER USER app_user PROFILE app_login_limit; - 注意：profile 名称区分大小写，且不能超过 30 字符
验证是否真生效：查 dba_users.account_status 和登录行为
光看 dba_profiles 里的 limit 值没用，必须验证实际登录时的行为。很多 DBA 改完就以为好了，结果攻击者仍在暴力扫。
- 测试前先清空测试账号的锁定状态：
ALTER USER testuser ACCOUNT UNLOCK; - 故意输错密码 5 次（用 sqlplus 或 JDBC），观察第 6 次是否报
ORA-01017: invalid username/password后再连是否报ORA-28000: the account is locked - 查状态：
SELECT username, account_status, lock_date FROM dba_users WHERE username = 'TESTUSER';——LOCKED或LOCKED(TIMED)才算成功 - 注意：
lock_date字段有值，且account_status显示LOCKED(TIMED)，说明PASSWORD_LOCK_TIME生效；若为LOCKED（无 TIMED），说明PASSWORD_LOCK_TIME是 0 或未设
监听器层面也要堵住暴力入口
数据库层的 FAILED_LOGIN_ATTEMPTS 只拦 SQL 登录，拦不住绕过数据库直连监听器的扫描。去年某客户被扫出 200+ 个弱密码账户，源头是监听器暴露在公网。
- 编辑
$ORACLE_HOME/network/admin/listener.ora，启用节点验证：VALID_NODE_CHECKING_REGISTRATION_LISTENER = ON - 限制可注册 IP：
REGISTRATION_INVITED_NODES_LISTENER = (localhost,192.168.10.0/24) - 重启监听器：
lsnrctl reload（无需重启数据库实例） - 验证是否生效：
lsnrctl status输出中应含Security: ON和Valid Node Checking: ON
