必须先开启resource_limit才能使idle_time生效；idle_time是profile参数，单位为分钟，仅对inactive会话生效，依赖resource_limit=true且用户绑定含idle_time的profile，否则设置无效。
必须先开启 resource_limit 才能让 IDLE_TIME 生效
IDLE_TIME 是 Profile 的一个资源限制参数，但它不是“设了就立刻管用”。Oracle 默认关闭资源限制功能，resource_limit 参数值为 FALSE 时，所有 Profile 中的 IDLE_TIME、CONNECT_TIME 等设置全部被忽略。
检查当前状态：SELECT name, value FROM gv$parameter WHERE name = 'resource_limit';
如果返回 FALSE，必须先执行：ALTER SYSTEM SET RESOURCE_LIMIT = TRUE;
注意：
- 这个操作影响整个实例，无需重启，但只对新建立的会话生效
- 已存在的空闲会话不会被 retroactively 断开
- RAC 环境下需在所有节点确认该参数已启用（gv$parameter 视图可查）
IDLE_TIME 单位是分钟，且只作用于 INACTIVE 状态会话
IDLE_TIME 控制的是“用户连接后不发任何 SQL、不提交、不 rollback”的空闲窗口。它不计算正在执行 SQL 的时间，也不计算等待锁或 I/O 的时间——只看 v$session.status 是否为 INACTIVE，且 v$session.last_call_et 超过设定阈值。
常见误判场景：
- 应用端启用了连接池（如 HikariCP、Druid），连接长期复用但实际无业务请求 → 符合 IDLE_TIME 触发条件
- PL/SQL Developer 或 Toad 等工具保持连接但未执行语句 → 同样会被断开
- 会话处于 ACTIVE 状态（哪怕卡在 long-running query）→ IDLE_TIME 完全不介入
设置示例：CREATE PROFILE app_noidle LIMIT IDLE_TIME UNLIMITED;ALTER PROFILE DEFAULT LIMIT IDLE_TIME 30;ALTER USER app_user PROFILE app_noidle;
注意：
- IDLE_TIME 值为 0 表示“不限制”，不是“立即断开”
- 设为 1 分钟并不等于“1 分钟整”后断开，实际触发时机依赖 PMON 清理周期（通常几秒到几十秒延迟）
- 断开后会话状态变为 KILLED，但进程残留直到下次尝试通信才真正释放（这点容易被监控脚本误报）
别和 SQLNET.EXPIRE_TIME 混用，它们解决的问题完全不同
SQLNET.EXPIRE_TIME（写在 $ORACLE_HOME/network/admin/sqlnet.ora）是网络层保活机制：它定期向客户端发探测包，用于发现“客户端已崩溃/断网但 TCP 连接未正常关闭”的僵死连接。而 IDLE_TIME 是数据库服务端逻辑控制：客户端还连着、TCP 正常，只是人或应用没干活。
典型冲突场景：
- 防火墙设置了 900 秒空闲超时
- 你配了 SQLNET.EXPIRE_TIME=600，但 Oracle 实际探测间隔可能达 1200 秒（文档明确说明最大偏差为 2×EXPIRE_TIME）
- 结果防火墙先干掉连接，Oracle 还在等下一次探测 → 客户端收到 ORA-03113 / ORA-03135
建议做法：
- 如果你真需要防僵死连接，优先调操作系统 tcp_keepalive 参数（Linux：/proc/sys/net/ipv4/tcp_keepalive_time）
- SQLNET.EXPIRE_TIME 只在无法控制网络设备时作为兜底，且应设为小于防火墙超时值（比如防火墙 900 秒，这里设 300）
- IDLE_TIME 和 SQLNET.EXPIRE_TIME 可共存，但目标不同，不要指望它们数值一致就能“严丝合缝”
修改后要验证真实效果，不能只看 profile 定义
很多人改完 profile 就以为万事大吉，结果几天后还是被反馈“连接突然断了”。根本原因是没验证实际会话行为。
验证步骤：
- 创建测试用户并分配新 profile：CREATE USER test_idle IDENTIFIED BY pwd; ALTER USER test_idle PROFILE app_noidle;
- 用该用户登录，执行 SELECT * FROM DUAL; 后不再操作
- 查看会话状态：SELECT sid, serial#, status, last_call_et, username FROM v$session WHERE username = 'TEST_IDLE';
- 等待超过 IDLE_TIME 设置值后，再查 —— 若仍为 INACTIVE 且 last_call_et 持续增长，说明没生效（大概率 resource_limit 没开或 profile 没正确绑定）
关键提醒：
- dba_profiles 显示的是 profile 定义，不是当前会话实际生效值
- 用 v$session.profile 列可确认该会话是否真的加载了预期 profile
- 修改 profile 后，已有会话不会自动更新限制，必须重新连接才能应用新规则
