Monitoring sessions invoked by a user SQL Developer

Question

Hello Everyone ,
I am a DBA and lot of developers use SQL Developer for their tasks. Off late we have been facing few issues with SQL Developer.
Developers close the working session by "alt+f4" and strangely their sessions are active in the DB's. What is the cause for this ?
Rollback of DML statements takes hours for statements submitted by SQL Developer.
Does OCI driver help in any way ?
Is there any way that I can allow individual users to monitor their sessions in SQL Developer?
Suppose a user connects with a generic application username "xyz" , can I allow the user "xyz"  to monitor sessions invoked by him and also provide him privileges to kill his/her own session.
We are facing lot of performance issues , so help in this regard would be highly appreciated.
Even pointing me towards appropriate documentation would do.
Thanks in anticipation.

Answer 1

1006957 wrote:
I am a DBA and lot of developers use SQL Developer for their tasks. Off late we have been facing few issues with SQL Developer.
Developers close the working session by "alt+f4" and strangely their sessions are active in the DB's. What is the cause for this ?
Rollback of DML statements takes hours for statements submitted by SQL Developer.
Does OCI driver help in any way ?
Is there any way that I can allow individual users to monitor their sessions in SQL Developer?
Suppose a user connects with a generic application username "xyz" , can I allow the user "xyz"  to monitor sessions invoked by him and also provide him privileges to kill his/her own session.
We are facing lot of performance issues , so help in this regard would be highly appreciated.
Even pointing me towards appropriate documentation would do.
Once the DB begins work on a task it will continue that work until: 1) the work is complete, 2) an exception occurs or 3) it discovers that the client is no longer there.
If you begin a transaction (complex query, sorts, etc) that is lengthy it may be a while before the DB even tries to communicate with the client. Then all of that work must be rolled back and the rollback (e.g. for an update or delete) can take much longer than the query took to begin with. That is just the way Oracle works.
If a user connects as "xyz" then the only 'sessions invoked by him' are that ONE session. Any other user might also create a session by connecting as "xyz"; Oracle has no way of knowing if ALL sessions connecting as "xyz" belong to the same person or not.
The ALTER SYSTEM privilege must be granted to allow someone to 'kill his/her own session' but that privilege would allow them to kill any other session, including system sessions.
You could write a procedure to try to control the privilige, as in the following thread, but that also has risks:
https://forums.oracle.com/thread/256935
It is a DBA responsibility to control sessions, not the developers. You should NOT give this ability to the developers IMHO. If your developers are abusing your system it indicates that they need more training in how to prevent runaway queries. A common cause of the problem you describe is when a developer submits a query and then thinks they can just cancel it and start over and they DO NOT UNDERSTAND the first statement I made above: Oracle will keep working.
The proper solution to your problem is to begin logging your developer's requests for session termination so that you can properly monitor the problem and detect developers that need additional instruction or mentoring to keep the problem from happening. Although anyone, even experts, can accidentally let a query get out of control, your problem doesn't occur very frequently for experienced developers.
The DISCONNECT option only politely requests Oracle to terminate the session so it make take considerable time to clean everything up.
If you really need to terminate the session you need to use DISCONNECT IMMEDIATE. See the disconnect session clause of alter system in the sql language doc
http://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_2013.htm#sthref4725
{quote}
DISCONNECT SESSION Clause
Use the DISCONNECT SESSION clause to disconnect the current session by destroying the dedicated server process (or virtual circuit if the connection was made by way of a Shared Sever). To use this clause, your instance must have the database open. You must identify the session with both of the following values from the V$SESSION view:
  For integer1, specify the value of the SID column.
  For integer2, specify the value of the SERIAL# column.
If system parameters are appropriately configured, then application failover will take effect.
  The POST_TRANSACTION setting allows ongoing transactions to complete before the session is disconnected. If the session has no ongoing transactions, then this clause has the same effect described for as KILL SESSION.
  The IMMEDIATE setting disconnects the session and recovers the entire session state immediately, without waiting for ongoing transactions to complete.  If you also specify POST_TRANSACTION and the session has ongoing transactions, then the IMMEDIATE keyword is ignored.
  If you do not specify POST_TRANSACTION, or you specify POST_TRANSACTION but the session has no ongoing transactions, then this clause has the same effect as described for KILL SESSION IMMEDIATE.
{quote}