Session idle time

[padmam]

Hi, 27th Aprril 2001 21:53 hrs chennai

I found out this from a web page for the solution you were looking on Sniped sessions.

Actually this was good questions for us and the replies made by Sambavan was also excellent.

Here it goes more on SNIPED sessions.

===============

We had the same issue under MTS. After talking w/oracle support for a long time the answer was that the entries would stay in v$session while the dispatcher that was serving the connection goes away (i.e. when you bounce your database), this is becuase the dispatcher is holding memory for the session! Other than the unfreed memory Oracle assured us that no further resources were being consumed by these undead connections. If you have no locks (in v$lock) due to these processes then I think you performance problem may be elsewhere. BTW do you have dead connection detection enabled in the sqlnet.ora, this sometimes helps w/the cleanup.
: Oopsss... doesn't work and coz of
: 'no rows selected'
: any suggestions? the system is dying. and the oracle is running under MTS configuration

: : : after issue the alter system kill session command, the killed session still hanging over there. how to release those connection for new request?

: Kill the process from the Operating System (OS) level.
: Determine the OS process id from svrmgrl:
: select spid from v$process
: where addr in
: (select paddr
: from v$session
: where sid =
: and serial# =
: and status = 'KILLED');
: AT the OS prompt:
: $ kill -9 spid
: Explanation:
: Process monitor, PMON, has not woke up
: to clean the killed process.
: NB: 'kill' only "DEDICATED SERVER PROCESSES",
: those of the form:
: oracleXXXX (local=NO)
: where XXX is ORACLE_SID
=============

Cheers

Padmam

[padmam]

Hi Sambavan, 28th April 2001 20:10 hrs chennai

Can you give your further opinion on this issue.

Cheers

Padmam

[sambavan]

Originally posted by padmam

We had the same issue under MTS. After talking w/oracle support for a long time the answer was that the entries would stay in v$session while the dispatcher that was serving the connection goes away (i.e. when you bounce your database), this is becuase the dispatcher is holding memory for the session! Other than the unfreed memory Oracle assured us that no further resources were being consumed by these undead connections. If you have no locks (in v$lock) due to these processes then I think you performance problem may be elsewhere. BTW do you have dead connection detection enabled in the sqlnet.ora, this sometimes helps w/the cleanup.

Padmam

I agree totally to the above posting, b'cos I'm going through this agony. I have been in constant touch with oracle, and I was told that this issue does exists in the 8i Rel3 too. The problem is pretty random and some times the servers would get thrashed and some time the dispatcher would get thrashed. The sad pas as he mention above, if the dispatcher were to get thrashed, that it, its time to bounce your instance, that is the only way I know of to deallocate the allocated memory.

The best option to hadle this issue is not to set the idle time parameter on your profile/ The Oracle's suggestion was to go with the dedicated server process and have the idle time detected. "What a lazy suggestion!! rather than fixing the bug."

I'm currently waiting to see how things would be on the 9i Rel 1, which is due some time on June, 2001.

If any one has any suggestions, I love to hear and try.

Sam

[padmam]

Hi Sam, 29th April 2001 17:31 hrs chennai

I really got laughing as you have said "What a lazy suggestion!! rather than fixing the bug."

As you said lets cross our hand till june for the release of
9i Rel 1.

Thank you very much and appreciative for your opinion on the issue.

Cheers

Padmam

[Edited by padmam on 04-29-2001 at 10:04 AM]

[sambavan]

Here is the bug that addresses this issue: YET TO BE FIXED !!!!

1# if the above one user is a Web server MTS would better however the bug 1308995 and bug 1478254, ORA-600 16365 ORA-600 16365---> also has no
resolution at this point


Sam