IDLE_TIME DOES NOT WORK TO SPECIFY WHEN A SESSION IS AUTOMATICALLY SNIPPED

Hdr: 3315723 9.2.0.1.0 RDBMS 9.2.0.1.0 PRODID-5 PORTID-453 Abstract:       IDLE_TIME DOES NOT WORK TO SPECIFY WHEN A SESSION IS AUTOMATICALLY SNIPPED *** 12/12/03 10:48 am *** TAR: ---- 3536104.995 . PROBLEM: -------- Why do idle sessions DO NOT get snipped (v$session.status) as soon as  IDLE_TIME is reached? . Also if sessions are eventually snipped by Oracle (post the time that  IDLE_TIME criteria has been met), how can we tell (dictionary view) exactly  when Oracle snipped the session and use this information to correlate to the  last time the session was inactive? The data from V$SESSION.LAST_CALL_ET does  not help since this column continues to change even after the session has been  snipped.to  . . DIAGNOSTIC ANALYSIS: -------------------- Tested in-house. . WORKAROUND: ----------- Do not use IDLE_SESSION . RELATED BUGS: ------------- Bug 940247 (not reproducible), however this bug is for sessions that get  snipped before IDLE_TIME expiration.   . REPRODUCIBILITY: ---------------- Everytime . TEST CASE: ---------- I used 9203 on Sun (should be reproducible SESSION A ~~~~~~~~~~~~ Connect / as sysdba; show parameter resource_limit   < -- make sure it is set to TRUE . Create profile idle_test limit idle_time 1; . create user idle_test_user identified by idle_test_user default tablespace users temporary tablespace temp quota 5m on users profile idle_test; . Grant connect,create session to idle_test_user; . . SESSION B ~~~~~~~~~~~~ 	set time on; 	connect idle_test_user/idle_test_user; 	Select * from user_resource_limits;  < -- wait 1 minute . . SESSION A ~~~~~~~~~~~~ alter session set nls_date_format='dd-mm-rr hh24:mi:ss'; username='IDLE_TEST_USER'; select sysdate from dual; . . NOTE: The session does not get SNIPPED at the minute mark. Sometimes it gets  snipped 3-6 times longer than what was specified by IDLE_TIME. . STACK TRACE: ------------ NA . SUPPORTING INFORMATION: ----------------------- NA . 24 HOUR CONTACT INFORMATION FOR P1 BUGS: ---------------------------------------- NA . DIAL-IN INFORMATION: -------------------- NA . IMPACT DATE: ------------ NA . *** 12/12/03 10:49 am *** (CHG: Sta->16) *** 12/12/03 12:20 pm *** (CHG: Asg->NEW OWNER) *** 12/12/03 06:24 pm *** *** 12/12/03 06:25 pm *** (CHG: Sta->10) *** 12/14/03 09:53 am *** (CHG: Sta->16) *** 12/14/03 09:53 am *** From the TAR:   Created a profile with an IDLE_TIME parameter of 1 (minute).     Assigned a test ID, SE1, to the profile.    open an SQLPUS session, connect as SE1 and issue a simple select command.    Open a second session and connect as SYSTEM. Monitor the STATUS and    LAST_CALL_ET for the SE1 session.    The status should change from INACTIVE to SNIPPED after 60 seconds.    Instead it takes from  132 to 171 seconds for the status to change.    If I issue a command from the SE1 session after 60 seconds, but before the    status has been SNIPPED, the command  runs and the LAST_CALL_ET is reset.   If I issue the command after the status is SNIPPED, the command fails with   the ORA-02396 as expected.   I need to able to explain the discrepancy between the IDLE_TIME parameter   and the acutal time out, if not correct it. . In my case, no sessions were snipped before the set value for IDLE_TIME.  However, the time that the sessions stayed INACTIVE and when these actually  get SNIPPED, are never exactly at the time that IDLE_TIME is set or  predictable at what time after IDLE_TIME has passed. It appears that IDLE_TIME  works in the sense of disconnecting sessions, but not when one would expect  (ie, from the value given to it) . *** 12/23/03 06:05 pm *** *** 12/23/03 06:05 pm *** (CHG: Sta->10) *** 12/24/03 01:20 pm *** (CHG: Sta->16) *** 12/24/03 01:20 pm *** . Test 1 (30 minutes) =================== . LAST_CALL_ET 		------------------------------ -------- ----------------- ------------ 		IDLE_TEST_USER                 INACTIVE 24-12-03 09:57:06         1857 . LAST_CALL_ET 		------------------------------ -------- ----------------- ------------ 		IDLE_TEST_USER                 SNIPED   24-12-03 09:57:06         1863 . . Test 2 (30 minutes) =================== . LAST_CALL_ET 		------------------------------ -------- ----------------- ------------ 		IDLE_TEST_USER                 INACTIVE 24-12-03 10:30:26         1891 . LAST_CALL_ET 		------------------------------ -------- ----------------- ------------ 		IDLE_TEST_USER                 SNIPED   24-12-03 10:30:26         1893 . Test 3 (30 minutes) =================== . LAST_CALL_ET 		------------------------------ -------- ----------------- ------------ 		IDLE_TEST_USER                 INACTIVE 24-12-03 12:56:43         1878 . LAST_CALL_ET 		------------------------------ -------- ----------------- ------------ 		IDLE_TEST_USER                 SNIPED   24-12-03 12:56:43         1881 . . Test 4 (5 minutes) ================== . LAST_CALL_ET 		------------------------------ -------- ----------------- ------------ 		IDLE_TEST_USER                 INACTIVE 24-12-03 13:49:51          418 . LAST_CALL_ET 		------------------------------ -------- ----------------- ------------ 		IDLE_TEST_USER                 SNIPED   24-12-03 13:49:51          418 . Test 5 (5 minutes) ================== . LAST_CALL_ET 		------------------------------ -------- ----------------- ------------ 		IDLE_TEST_USER                 INACTIVE 24-12-03 14:01:36          418 . LAST_CALL_ET 		------------------------------ -------- ----------------- ------------ 		IDLE_TEST_USER                 SNIPED   24-12-03 14:01:36          418 . . . Test 6 (5 minutes) ================== . LAST_CALL_ET 		------------------------------ -------- ----------------- ------------ 		IDLE_TEST_USER                 INACTIVE 24-12-03 14:09:41          419 . LAST_CALL_ET 		------------------------------ -------- ----------------- ------------ 		IDLE_TEST_USER                 SNIPED   24-12-03 14:09:41          419 . . . Observations: Test1: Session was snipped 59 seconds after idle_time setting. Test2: Session was snipped 1 minute and 40 seconds after idle_time setting. Test3: Session was snipped 1 minute and 22 seconds after idle_time setting. Test4: Session was snipped 2 minutes after idle_time setting Test5: Session was snipped 2 minutes after idle_time setting Test6: Session was snipped 2 minutes after idle_time setting . Questions: 1) Why do sessions do not get snipped at exactly the time directed by  IDLE_TIME?  2) Is there a dictionary view that one can use to find out the exact time that  a session was snipped due to inactivity?    LAST_CALL_ET cannot be used for this purpose since its value continues to  increase even after the session has been snipped. *** 12/26/03 11:51 am *** *** 12/29/03 07:41 pm *** (CHG: Sta->10) *** 12/29/03 07:41 pm *** *** 12/30/03 09:34 am *** (CHG: Sta->16) *** 12/30/03 09:34 am *** Thx for the update above. We will await dev's response. Also, we still need to know if there is any data dictionary view that can show  (accurately, if possible) how long a session has been sniped due to incativity  by PMON. See details on this on previous update (questions at the end).   *** 12/30/03 03:59 pm *** (CHG: Sta->32) *** 12/30/03 03:59 pm *** It's not a bug that the session is not sniped immediately after idle time expires.  PMON does the idle time check only once per minute, so it can take up to idle_time+60 for an idle session to be noticed.  It may take a bit longer if PMON is very busy. If it takes much longer, there may be a problem (PMON may be stuck, for example).  *** 12/30/03 04:04 pm *** *** 12/31/03 04:33 am ***