但是客户说以上的方法只是适用于SQLPLUS,对PL/SQL工具无效，下面讨论一下为什么对PL/SQL无效。
使用test111登陆PL/SQL之后查看数据库会话信息：
成功登陆后在数据库里面看到创建了两个session，可以看到session的login时间是11:17:09和11:17:28两个时间点。由于没有执行任何SQL，登陆成功后的session状态是INACTIVE的。
IDLE_TIME设置的为1分钟，1分钟后两个会话的状态变成了SNIPED，表示会话已经过期。
当在PL/SQL中执行任何SQL语句的时候，PL/SQL没有报错，成功执行。
但是从后台看，登陆时间变成了11:20:47和11:20:51，状态又变成了INACTIVE。
说明在PL/SQL执行SQL语句的时候自动的重新登陆了。
下面是SQLPLUS的情况：
11:37:26登陆成功后，为SQLPLUS创建了一个SESSION，
1分钟没操作后会话变成了SNIPED状态。
再次到该会话操作时，收到如下报错：
从上一张图片可以看出，从后台看SQLPLUS的SESSION已经被KILL。
由此可以判断，PROFILE IDLE_TIME对SQLPLUS有效，对PL/SQL无效跟客户端有很大关系。
通过这个实验还可以发现一点，会话过期后，会话的状态会变成SNIPED，该会话不会被立即KILL，直到会话对应的客户端下次执行SQL时被KILL，说明这段时间会话对应的服务器进程一直存在，如果这样的会话很多，且SNIPED存在的状态持续较长时间，那么数据库可能超过PROCESSES初始化参数的限制。
另外这里解释一下sqlnet.ora配置文件中配置SQLNET.EXPIRE_TIME参数的含义：
SQLNET.EXPIRE_TIME=1表示每过1分钟都向客户端发出一个测试连接的包，客户端收到后会给出响应，如果连接正常，这个连接是不会被杀掉的。
这个参数是用于解决客户端无故关闭，网络出现故障，再指定的时间内杀掉服务器进程。
Oracle推荐PROFILE和SQLNET.EXPIRE_TIME一起使用，但由于PL/SQL工具本身的特点，它会在SESSION的状态变成SNIPED(PROFILE IDLE_TIME超时）后，第一次操作的时候自动重新连接，所以这两种方法都控制不了它。
Oracle提出一种方法，就是在Oracle服务器端部署定时杀掉SNIPED状态会话的脚本。但是为了处理少量的PL/SQL客户端，未免有点大费周章了。
--end--