idle_time生效必须同时满足resource_limit=true且用户被分配含idle_time的profile；仅改profile或仅开resource_limit均无效，需先确认并启用resource_limit开关，再配置profile并重新登录生效。
IDLE_TIME 生效必须同时满足两个硬性条件：resource_limit=TRUE 且用户被分配了含 IDLE_TIME 的 profile。只改 profile 或只开 resource_limit 都不会生效。
确认 resource_limit 是否已启用
这是最常被忽略的前置开关。IDLE_TIME 在 resource_limit=FALSE 时完全不生效，哪怕 profile 里写了 1 分钟也无效。
- 查当前值：
SELECT name, value FROM v$parameter WHERE name = 'resource_limit'，返回FALSE就得先开 - 临时开启（对新会话立即生效）：
ALTER SYSTEM SET resource_limit = TRUE - 永久生效（写入 spfile，重启后仍有效）：
ALTER SYSTEM SET resource_limit = TRUE SCOPE=SPFILE - 已有会话不受影响，需重新登录才能受 IDLE_TIME 约束
设置 IDLE_TIME 的三种方式及适用场景
IDLE_TIME 单位是分钟，0 表示禁用（不推荐），UNLIMITED 表示不限制（生产环境严禁）。
- 改默认 profile（影响所有未显式指定 profile 的用户）：
ALTER PROFILE DEFAULT LIMIT IDLE_TIME 15 - 新建专用 profile 并赋给特定用户（推荐）：
CREATE PROFILE app_user LIMIT IDLE_TIME 10→ALTER USER scott PROFILE app_user - 临时测试可用
ALTER SESSION SET CURRENT_SCHEMA = ...切换 profile，但无法绕过 resource_limit 开关 - IDLE_TIME 从最后一次 SQL 执行或网络交互开始计时，不是登录时间；执行
SELECT 1 FROM DUAL就能重置计时器
为什么改了 IDLE_TIME 还不生效？常见干扰项
真正生效前，要排除多个“超时”机制的干扰，它们优先级不同、作用域不同。
-
SQLNET.EXPIRE_TIME（在$ORACLE_HOME/network/admin/sqlnet.ora中）：服务端定期发探测包，单位分钟，设为 10 表示每 10 分钟探一次。它不直接断连接，但配合防火墙可能引发ORA-12170或假死 - 应用层连接池（如 HikariCP、Druid）的
idleTimeout配置优先级高于数据库侧，会先于 IDLE_TIME 把连接回收，掩盖真实问题 -
CONNECT_TIME是总连接时长上限（从登录开始计），和空闲无关；误设会导致用户刚连上几分钟就被踢 - Oracle Cloud EPM、Responsys 等 SaaS 服务的空闲超时是独立控制的，跟底层 DB 的 IDLE_TIME 无关
验证是否真的生效
别只信命令返回 “Profile created”，要实测。用目标用户登录后，等超过设定时间再执行语句，看是否报 ORA-02396。
- 用目标用户登录：
sqlplus scott/tiger@orcl - 执行一次查询：
SELECT SYSDATE FROM DUAL - 等待 > IDLE_TIME 分钟（比如设了 10 分钟就等 11 分钟），再执行
SELECT * FROM DUAL - 若返回
ORA-02396: exceeded maximum idle time, please reconnect，说明生效；否则继续排查 resource_limit 和 profile 绑定
最容易被忽略的是：IDLE_TIME 不作用于后台作业（如 DBMS_JOB、DBMS_SCHEDULER）、也不影响通过 dblink 发起的远程会话；这些场景需要单独配置或监控。
