What platform and oracle version are you on???
We had a similar problem where I work on a server running Solaris 2.6 and
oracle 8.1.6.2.
We were getting the same error "WAITED TOO LONG FOR A ROW CACHE ENQUEUE
LOCK..." and the problem seemed to be caused by a fast refresh snapshot.
The snapshot w
We have had a problem with hangs in 8.1.6. The symptom we see is an
extremely high version_count value in many of the rows of the v$sqlarea
table at the time of the hang. v$session_waits also has many sessions
waiting on pins of the shared pool. Basically, in our case, the shared pool
was full
Hi Glenn,
I got one of these last night.
The snapshot refresh process had an exclusive lock on the row cache enqueue for
the snapshot and was waiting for a shared library cache lock on the base table.
This is the WRONG locking order. Oracle is supposed to always take library cache
locks before r
I've continued to research this error and found several references on
various search engines. The most promising seems to point this book by
O'Reilly "Oracle8i Internal Services for Waits, Latches, Locks, and Memory".
There is a section (4.4, pg. 42) which talks about enqueue locks, but I
cannot
Please send me ([EMAIL PROTECTED]) a fax number. Too much to type in,
don't have ready access to a scanner.
- Original Message -
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
Sent: Monday, February 12, 2001 2:45 PM
> I've continued to research this error and found sever
Here's a quick excerpt while awaiting a fax number:
(page 44) "If v$sysstat shows a significant number of enqueue waits, then a break-
down of the resource types for which these waits have been sustained can
be obtained from x$ksqst, or from the APT script enqueue_stats.sql.
Unfortunately, x$ksqs
