RE: Finding the session causing compile to hang

2003-10-30 Thread Khedr, Waleed
The old view v$access can show who is using what. Waleed -Original Message- [mailto:[EMAIL PROTECTED] Sent: Thursday, October 30, 2003 7:14 PM To: Multiple recipients of list ORACLE-L David, You could use Steve Adam's script Executing_packages.sql at http://www.ixora.com.au/scripts/misc

RE: Finding the session causing compile to hang

2003-10-30 Thread Yong Huang
Hi, Bruce, I happen to be loading a lot of data using our stored procedure right now. select sql_text from v$sql where users_executing > 0 shows: INSERT /*+ APPEND PARALLEL(CLAIM) */ INTO CLAIM ( CLAIM_ID, [snipped] BEGIN sp_insert_claim; END; SELECT /*+ Q7898000 NO_EXPAND ROWID(A1) *

RE: Finding the session causing compile to hang

2003-10-30 Thread Reardon, Bruce (CALBBAY)
Yong, Certainly agree Steve's code is good :-) I don't think v$sql will give you the same information - it would show the top level actual package being executed, but not those which are called by that package - these do show up in Steve's code. Regarding the dba_lock_internal code - the only

RE: Finding the session causing compile to hang

2003-10-30 Thread Yong Huang
Hi, Bruce, Steve Adams' code is based on x$kglpn (librarycache pin), which is correct. But the code based on dba_lock_internal blindly assumes id1 is the object name. There's a similar common misinterpretation; many DBAs assume v$lock.id1 is the object ID, which is only true for type = 'TM' (or ma

RE: Finding the session causing compile to hang

2003-10-30 Thread Reardon, Bruce (CALBBAY)
David, You could use Steve Adam's script Executing_packages.sql at http://www.ixora.com.au/scripts/misc.htm to see what packages are executing. More generally, use dba_lock_internal to look at what is being blocked: based on Oracle-L script by Diego Cutrone [mailto:[EMAIL PROTECTED] (Friday, 29