Re: strange select issue

"Tom" <tomNOSPAM_at_teameazyriders.com> wrote in message news:<1063966865.59360.0_at_dyke.uk.clara.net>...
> > WAIT #1: nam='enqueue' ela= 0 p1=1397948422 p2=2 p3=1
> > WAIT #1: nam='enqueue' ela= 0 p1=1397948422 p2=2 p3=1
> > WAIT #1: nam='enqueue' ela= 0 p1=1397948422 p2=2 p3=1
> > WAIT #1: nam='enqueue' ela= 0 p1=1397948422 p2=2 p3=1
> > WAIT #1: nam='enqueue' ela= 0 p1=1397948422 p2=2 p3=1
> > WAIT #1: nam='enqueue' ela= 0 p1=1397948422 p2=2 p3=1
> > WAIT #1: nam='enqueue' ela= 0 p1=1397948422 p2=2 p3=1
>
> looking for info on this i see that these could be related to locks however the docs say...
>
> enqueue - The process is waiting on an enqueue (a lock you can see in v$lock). This commonly occurs when one user is trying to
> update a row in a table that is currently being updated by another user
>
> however this is occuring when i'm trying to import the data into an empty user also? am i missing something as i don't really see
> where the issue is.

Hi, Tom,

Based on p1 of your enqueue event, you're waiting on SS lock. In this case, your tablespace is ts# 2. p3=1 simply means this is a local enqueue. If your ts# 2 is TEMP, why does the session request for this lock? Is TEMP really temporary? What does select * from v$sort_usage give? What other wait events show up in v$session_wait at the moment (excluding those with word "message")? Anything special in alert.log? You may also search on Metalink regarding sort segment for 8.1.5.

Yong Huang Received on Fri Sep 19 2003 - 12:47:46 CDT