9.0.2.1621 - Connections hanging around after logout

MjH

Member²
I have determined that this version of PL/SQL Developer is not completely disconnecting from the database when you log out. Periodically, we will find PL/SQL Developer connections to the database, which according to the 'Sessions' window (viewed from a DBA login), are in the status 'ACTIVE' and are running the SQL:

select s.synonym_name as object_name, o.object_type
from all_synonyms s, sys.all_objects o
where s.owner in ('PUBLIC', :schema)
and o.owner = s.table_owner
and o.object_name = s.table_name
and o.object_type in ('TABLE', 'VIEW', 'PACKAGE','TYPE', 'PROCEDURE', 'FUNCTION', 'SEQUENCE')


I ran into this personally, just yesterday. I logged into a schema that I was preparing to drop, just to verify that it did not have any objects (which it didn't). I logged out (Session -> Log off) and then connected with my DBA account (Session -> Log on...).

When I tried to drop the schema, I received the 'cannot drop user, somebody is logged in' error. I opened up a Sessions window and found the session. It was a PL/SQL Developer session, from my workstation/account, and running the SQL above. I run in 'Dual Session' mode, if that helps any.

I did some searching around the forum before entering this, and I'm wondering if this is somehow related to the following topics:

IDLE_TIME not considered in version 9.0.2

Long "Initializing..." delay running SQL queries in Rel 9

Thanks,
 
You can prevent this query by disabling the "Describe Context" option of the Code Assistant (Tools > Preferences > Code Assistant). Alternatively you can edit the CANames.sql file in the PL/SQL Developer installation directory to change or remove one or more queries used for this Code Assistant feature. The sql file includes an explanation.
 
Marco:

Thanks for the response.

However, I'm not so much concerned about the specific query, but the fact that after having explicitly selecting 'Log out', an active session is left hanging around by PL/SQL Developer.

I've upgraded to the 9.0.3.1641, so I'll see if it still occurs in this version.
 
Marco:

The session is doing the query that I specified in the original post.

I had several occurrences of it today. I have a script (the script disables a few foreign keys, does some updates to 3 tables and then enables the foreign keys) that I had to run in a number of schemas in our development database this morning.

I had the script loaded into the Editor tab of a Command window, and I repeatedly did the following:

Step 1: Session -> Log off
Step 2: Session -> Log on
Step 3: CTRL-Enter (to run the script)
Step 4: Go to Step 1

After repeating this a number of times, our monitoring software noted that the database server had become heavily loaded.

From the OS, I could see that there were a lot of oracle processes consuming CPU. In the database, I found a bunch of PL/SQL Developer sessions from my workstation. All were in an active state, running the previously mentioned SQL. They were the usernames that I had been running the script in. I had to manually kill the sessions.

I have a number of other schemas that I still need to run the script in, but I see that there is a new update (9.0.4), so I'll update PL/SQL Developer before trying it again.
 
Okay, I've verified that it still occurs in 9.0.4.1644.

I monitored the sessions while I was logging in and out, and it doesn't appear to be related to what is done during the session.

The 'rogue' session appears as soon as I log in. When I log out and log in other another user, a new session appears, while the old session(s) continue on. All of the sessions stay in an active state, consuming CPU, until they are killed manually, or until I do a File -> Exit to close the PL/SQL Developer window.

Let me know if there is anything else you need to help track this down.

Thanks,
 
Can you test the following? Go to Tools > Preferences > User Interface / Code Assistant and disable the "Describe Context" option?
 
I disabled the 'Describe Context' option, and it did not have any effect. Active sessions are still hanging around after logout.
 
We're now using 9.0.6.1665 and if anything the rate of occurrence of this has increased (or maybe we're just more aware of it). Is there anything we can be doing on our end in order to help you guys identify the issue and resolve it? It is happening to all of our developers in various databases (RAC, non-RAC).

Thanks...
 
The current SQL (as reported in the SQL Text tab in the Tools->Sessions window) is:

select s.synonym_name as object_name, o.object_type
from sys.all_synonyms s, sys.all_objects o
where s.owner in ('PUBLIC', :schema)
and o.owner = s.table_owner
and o.object_name = s.table_name
and o.object_type in ('TABLE', 'VIEW', 'PACKAGE','TYPE', 'PROCEDURE', 'FUNCTION', 'SEQUENCE')

The open cursors for that same session (Cursors tab in the Tools->Sessions window) are:

select col#,intcol#,reftyp,stabid,expctoid from refcon$ wher
select col#,intcol#,reftyp,stabid,expctoid from refcon$ wher
select timestamp, flags from fixed_obj$ where obj#=:1
select timestamp, flags from fixed_obj$ where obj#=:1
select con#,obj#,rcon#,enabled,nvl(defer,0) from cdef$ where
select con#,obj#,rcon#,enabled,nvl(defer,0) from cdef$ where
select con#,obj#,rcon#,enabled,nvl(defer,0) from cdef$ where
select /*+ index_ss(obj$ i_obj2) */ obj#,type#,ctime,mtime,s
select /*+ index_ss(obj$ i_obj2) */ obj#,type#,ctime,mtime,s
select /*+ index_ss(obj$ i_obj2) */ obj#,type#,ctime,mtime,s
select /*+ index_ss(obj$ i_obj2) */ obj#,type#,ctime,mtime,s
select /*+ index_ss(obj$ i_obj2) */ obj#,type#,ctime,mtime,s
select /*+ index_ss(obj$ i_obj2) */ obj#,type#,ctime,mtime,s
select /*+ index_ss(obj$ i_obj2) */ obj#,type#,ctime,mtime,s
select /*+ index_ss(obj$ i_obj2) */ obj#,type#,ctime,mtime,s
select /*+ index_ss(obj$ i_obj2) */ obj#,type#,ctime,mtime,s
select /*+ index_ss(obj$ i_obj2) */ obj#,type#,ctime,mtime,s
select /*+ index_ss(obj$ i_obj2) */ obj#,type#,ctime,mtime,s
update seq$ set increment$=:2,minvalue=:3,maxvalue=:4,cycle#
select parttype, partcnt, partkeycols, flags, defts#, defpct
select col#,intcol#,ntab# from ntab$ where obj#=:1 order by
select col#,intcol#,ntab# from ntab$ where obj#=:1 order by
select con#,type#,condlength,intcols,robj#,rcon#,match#,refa
select con#,type#,condlength,intcols,robj#,rcon#,match#,refa
select con#,type#,condlength,intcols,robj#,rcon#,match#,refa
select name,intcol#,segcol#,type#,length,nvl(precision#,0),d
select name,intcol#,segcol#,type#,length,nvl(precision#,0),d
select name,intcol#,segcol#,type#,length,nvl(precision#,0),d
select name,intcol#,segcol#,type#,length,nvl(precision#,0),d
select name,intcol#,segcol#,type#,length,nvl(precision#,0),d
select decode(u.type#, 2, u.ext_username, u.name), o.name,
select /*+ rule */ bucket, endpoint, col#, epvalue from hist
select /*+ rule */ bucket, endpoint, col#, epvalue from hist
select grantee#,privilege#,nvl(col#,0),max(mod(nvl(option$,0
select grantee#,privilege#,nvl(col#,0),max(mod(nvl(option$,0
select grantee#,privilege#,nvl(col#,0),max(mod(nvl(option$,0
select grantee#,privilege#,nvl(col#,0),max(mod(nvl(option$,0
select increment$,minvalue,maxvalue,cycle#,order$,cache,high
select text from view$ where rowid=:1
select value$ from props$ where name = 'GLOBAL_DB_NAME'
select o.owner#,o.name,o.namespace,o.remoteowner,o.linkname,
select o.owner#,o.name,o.namespace,o.remoteowner,o.linkname,
select o.owner#,o.name,o.namespace,o.remoteowner,o.linkname,
select col#,intcol#,charsetid,charsetform from col$ where ob
select col#,intcol#,charsetid,charsetform from col$ where ob
select intcol#,nvl(pos#,0),col#,nvl(spare1,0) from ccol$ whe
select intcol#,nvl(pos#,0),col#,nvl(spare1,0) from ccol$ whe
select intcol#,nvl(pos#,0),col#,nvl(spare1,0) from ccol$ whe
select intcol#, toid, version#, intcols, intcol#s, flags, sy
select intcol#, toid, version#, intcols, intcol#s, flags, sy
select i.obj#,i.ts#,i.file#,i.block#,i.intcols,i.type#,i.fla
select i.obj#,i.ts#,i.file#,i.block#,i.intcols,i.type#,i.fla
select i.obj#,i.ts#,i.file#,i.block#,i.intcols,i.type#,i.fla
select col#,intcol#,toid,version#,packed,intcols,intcol#s,fl
select col#,intcol#,toid,version#,packed,intcols,intcol#s,fl
select pos#,intcol#,col#,spare1,bo#,spare2,spare3 from icol$
select pos#,intcol#,col#,spare1,bo#,spare2,spare3 from icol$
select pos#,intcol#,col#,spare1,bo#,spare2,spare3 from icol$
select privilege#,nvl(col#,0),max(mod(nvl(option$,0),2))from
select col#, grantee#, privilege#,max(mod(nvl(option$,0),2))
select col#, grantee#, privilege#,max(mod(nvl(option$,0),2))
select col#, grantee#, privilege#,max(mod(nvl(option$,0),2))
select col#, grantee#, privilege#,max(mod(nvl(option$,0),2))
select privilege#,level from sysauth$ connect by grantee#=pr
select SYS_CONTEXT('USERENV', 'SERVER_HOST'), SYS_CONTEXT('U
select user#,password,datats#,tempts#,type#,defrole,resource
select t.ts#,t.file#,t.block#,nvl(t.bobj#,0),nvl(t.tab#,0),t
select t.ts#,t.file#,t.block#,nvl(t.bobj#,0),nvl(t.tab#,0),t
select t.ts#,t.file#,t.block#,nvl(t.bobj#,0),nvl(t.tab#,0),t
select decode(failover_method, NULL, 0 , 'BASIC', 1, 'PRECON
select privilege# from sysauth$ where (grantee#=:1 or grante
select cols,audit$,textlength,intcols,property,flags,rowid f
select cols,audit$,textlength,intcols,property,flags,rowid f
select /*+ rule */ bucket_cnt, row_cnt, cache_cnt, null_cnt,
select /*+ rule */ bucket_cnt, row_cnt, cache_cnt, null_cnt,
select /*+ rule */ bucket_cnt, row_cnt, cache_cnt, null_cnt,
select /*+ rule */ bucket_cnt, row_cnt, cache_cnt, null_cnt,
select intcol#,type,flags,lobcol,objcol,extracol,schemaoid,
select intcol#,type,flags,lobcol,objcol,extracol,schemaoid,
select node,owner,name from syn$ where obj#=:1
select node,owner,name from syn$ where obj#=:1

Is that what you're looking for?
 
Thanks. Can you go to Tools > Preferences > Code Assistant, disable the "Describe Context" option, and check if this helps? You will need to do this for all PL/SQL Developer installations involved.
 
Marco:

Yes, that seems to stop the creation of the sessions. However, it disables the Code Assistant for objects in the user's schema when typing in statements (I'm assuming you expected that :) ).

That's a nice feature to have, so that work-around is less than ideal. Where do we go from there?
 
I have no idea why these sessions would be hanging after PL/SQL Developer terminates. What you can try is to edit the CANames.sql file in the PL/SQL Developer directory and remove the synonym query and check if this affects the problem.
 
Okay, we've determined the exact problem and have a workaround. It turns out that the query in question hangs (or takes a verrrrry long time) in Oracle 11.0.7. I've reproduced the problem in several of our databases, in both RAC and non-RAC configurations.

If you strip out the owner and object type clauses from the where clause (i.e. s.owner in ('PUBLIC', :schema) and o.object_type in ('TABLE', 'VIEW', 'PACKAGE','TYPE', 'PROCEDURE', 'FUNCTION', 'SEQUENCE')), the query returns promptly. After some playing around, I found the following runs to completion quickly and returns the proper data:

select object_name, object_type
from (
select s.synonym_name as object_name, o.object_type, s.owner
from all_synonyms s, sys.all_objects o
where o.owner = s.table_owner
and o.object_name = s.table_name
)
where owner in ('PUBLIC', :schema)
and object_type in ('TABLE', 'VIEW', 'PACKAGE','TYPE', 'PROCEDURE', 'FUNCTION', 'SEQUENCE')
;

We've created our own copy of CANames.sql with the new query, had all our developers upgrade to the latest version of PL/SQL Developer (some were running v7 and v8), and had them replace CANames.sql with our modified version. We are no longer (cross your fingers) experiencing the problem.
 
Back
Top