ora-03113 是 max_idle_time 主动终止会话的典型表现，当数据库未崩溃（alert.log 无异常、无 trace 文件）且会话长期 inactive、last_call_et 超过设定阈值时可确认；该参数自 oracle 12.2 起支持，仅对 open pdb 生效，优先级高于 idle_time，不触发审计或触发器。
ORA-03113 是 MAX_IDLE_TIME 触发的典型表现
看到客户端报 ORA-03113: end-of-file on communication channel，且没有对应数据库崩溃痕迹（alert.log 无异常、trace 文件未生成），大概率是 MAX_IDLE_TIME 主动终止了会话。它和 ORA-02396（来自 IDLE_TIME）不同：前者由数据库内核强制断链，后者是下次执行 SQL 时才拒绝；前者在 RAC 各节点可独立设置，后者依赖 PROFILE 且对 INACTIVE 会话基本无效。
确认是否启用了 MAX_IDLE_TIME 及当前值
该参数从 Oracle 12.2 起可用，单位为分钟，只支持在 PDB 或 CDB 级别设置，不能用 ALTER SESSION。必须查实际生效值，而非假设：
-
SHOW PARAMETER max_idle_time—— 查当前实例级别值（CDB 或 PDB） -
SELECT con_id, name, value FROM v$system_parameter WHERE name = 'max_idle_time';—— 查多租户下各容器取值 -
SELECT * FROM v$pdbs WHERE pdb_name = 'YOUR_PDB';—— 确认当前连接所在 PDB 是否处于 OPEN 状态（参数仅对 OPEN PDB 生效）
注意：MAX_IDLE_TIME = 0 表示禁用；若返回 NULL 或空行，说明该参数未显式设置，即等效于 0（不限制）。
验证会话是否真因空闲超时被杀
不能只看错误码，要结合会话生命周期证据：
- 查
v$session中刚断开的会话：用SELECT sid, serial#, username, status, last_call_et, logon_time FROM v$session WHERE status = 'INACTIVE' AND last_call_et > 1800 ORDER BY last_call_et DESC;——last_call_et超过MAX_IDLE_TIME × 60秒，且状态长期为INACTIVE，就是高危信号 - 查
v$session_connect_info中该会话的network_service_banner，确认不是 OCI/JDBC 驱动层主动关闭 - 对比
v$session的sql_id和prev_sql_id：若均为NULL，且last_call_et持续增长，基本排除应用主动执行语句后挂起，属于纯空闲
MAX_IDLE_TIME 断连不会写入 audit_trail，也不会触发 LOGON 或 LOGOFF 触发器，所以日志里找不到直接记录 —— 这是它最难排查的地方。
区分 MAX_IDLE_TIME 和 IDLE_TIME 的共存干扰
两者可能同时存在，但生效逻辑完全不同，容易误判根源：
-
MAX_IDLE_TIME：作用于所有会话（包括INACTIVE和ACTIVE），只要空闲时间达标就立即终止，报ORA-03113 -
IDLE_TIME（PROFILE）：仅在会话下次尝试执行语句时检查，且只对专用服务器模式下的“假空闲”有效，报ORA-02396 - 如果两个都设了，
MAX_IDLE_TIME优先级更高 —— 它在内核网络层直接 kill socket，IDLE_TIME根本没机会触发 - RAC 环境中，
MAX_IDLE_TIME可以 per-node 设置，而IDLE_TIME是全局 PROFILE，需手动同步
最常被忽略的一点：MAX_IDLE_TIME 对“阻塞会话”（blocking session）不生效 —— 它只管空闲，不管锁。如果你的应用有长事务或未提交更新，即使空闲超时也未必被杀，得靠 MAX_IDLE_BLOCKING_TIME 单独控。
