oracle用户空闲自动断开依赖resource_limit=true且用户profile含idle_time；idle_time以分钟计，0禁用、unlimited不限制；常见失效原因包括sqlnet.expire_time干扰、应用连接池超时优先级更高及后台作业不受限。
oracle 用户空闲自动断开，本质是靠 idle_time 限制生效的，但必须满足两个前提：数据库启用了资源限制（resource_limit=true），且该用户被分配了含 idle_time 的 profile。
确认 resource_limit 是否已启用
不开启这个参数，profile 里的 IDLE_TIME 完全不生效。直接查：
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 单位是分钟，值为 0 表示禁用（不推荐），UNLIMITED 表示不限制（生产环境严禁）。
- 修改默认 profile：
ALTER PROFILE DEFAULT LIMIT IDLE_TIME 15;—— 影响所有未显式指定 profile 的用户 - 新建专用 profile 并赋给用户：
CREATE PROFILE app_user LIMIT IDLE_TIME 10;→ALTER USER scott PROFILE app_user; - 临时测试可改当前 session 所属 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 或连接假死 -
CONNECT_TIME是总连接时长上限（从登录开始计），和空闲无关；误设会导致用户刚连上几分钟就被踢 - 应用层连接池（如 HikariCP、Druid）自身也有 idle timeout 配置，优先级高于数据库侧，容易掩盖真实问题
- Oracle Cloud EPM 或 Responsys 等 SaaS 服务的空闲超时是独立控制的，和底层 DB 的
IDLE_TIME无关，得走对应平台的 REST API 或管理界面
验证是否真的生效
别只信命令返回 “Profile created”，要实测：
- 用目标用户登录：
sqlplus scott/tiger@orcl - 执行一次查询：
SELECT SYSDATE FROM DUAL; - 等待超过设定的
IDLE_TIME分钟（比如设了 2 分钟，就等 130 秒以上） - 再执行任意语句：
SELECT * FROM DUAL;—— 若报ORA-02396: 超出最大空闲时间, 请重新连接，说明生效
真正容易被忽略的是：IDLE_TIME 对后台作业（如 DBMS_SCHEDULER job）、长时间运行的 PL/SQL 块、或正在执行大查询的会话不触发中断；它只管“完全无交互”的空闲状态。所以压测或批处理场景下，这个值不能只看登录后静默时间，得结合业务实际交互节奏来定。
