必须先启用resource_limit参数，再修改DEFAULT profile的IDLE_TIME为1800秒，仅对新会话生效；验证需结合DBA_USERS、DBA_PROFILES查询及实际空闲超时测试。
直接改 DEFAULT profile 的 IDLE_TIME 即可，但必须确保 resource_limit 已启用，否则设置完全不生效。
确认 resource_limit 是否已开启
Oracle 的 profile 限制（包括 IDLE_TIME）默认是关闭的。不先打开它，任何 ALTER PROFILE 都只是写进数据字典，不会触发实际断连。
- 执行
SHOW PARAMETER resource_limit，如果返回FALSE，必须先运行：ALTER SYSTEM SET resource_limit = TRUE; - 该命令需
SYS或SYSTEM权限，且对所有会话立即生效（无需重启实例） - 注意：修改后只影响新建立的会话；已存在的空闲会话仍按旧规则判断
设置用户空闲 30 分钟断开
30 分钟 = 1800 秒，这是 IDLE_TIME 的单位（秒），不是分钟。
- 若想让所有用
DEFAULTprofile 的用户都受控，运行：ALTER PROFILE DEFAULT LIMIT IDLE_TIME 1800; - 若只想控制特定用户（如
app_user），更推荐新建 profile：CREATE PROFILE app_idle_30 LIMIT IDLE_TIME 1800;，再绑定：ALTER USER app_user PROFILE app_idle_30; -
IDLE_TIME仅统计「连续无任何数据库交互」的时间，执行 SQL、提交事务、甚至SELECT 1 FROM DUAL都会重置计时器
验证设置是否真正起作用
别只查 DBA_PROFILES —— 那只能看到配置值，看不到是否被激活。
- 查 profile 是否被用户使用：
SELECT username, profile FROM dba_users WHERE username = 'YOUR_USER'; - 查该 profile 下的
IDLE_TIME实际值：SELECT resource_name, limit FROM dba_profiles WHERE profile = 'DEFAULT' AND resource_name = 'IDLE_TIME'; - 最可靠验证方式：用该用户登录，保持 SQL*Plus 空闲超过 30 分钟，再敲
SELECT * FROM DUAL;—— 若报ORA-02396: 超出最大空闲时间, 请重新连接，说明生效
容易被忽略的关键点
IDLE_TIME 是数据库服务端行为，和客户端工具（PL/SQL Developer、SQL Developer）、JDBC 连接池、应用层心跳无关。它不会提前预警，也不会自动续期 —— 一到时间就硬断，且断开后会话状态变成 SNIPED，由 PMON 清理资源。如果你的应用依赖长连接，又不能接受突然中断，那这个机制本身就不适合你，得考虑在应用层加心跳或改用连接池保活。
