Re: cursor: mutex S + library cache lock + library cache: mutex X = disaster
From: Tanel Poder <tanel_at_tanelpoder.com>
Date: Mon, 3 Nov 2014 22:03:05 -0600
Message-ID: <CAMHX9J+kFLYkwjWxo7W8TZwfL1qRJPumEXRQEkwhSdF00-N88g_at_mail.gmail.com>
Note that I had a bug in the dashtop.sql that I just fixed and I've reuploaded the script here:
Date: Mon, 3 Nov 2014 22:03:05 -0600
Message-ID: <CAMHX9J+kFLYkwjWxo7W8TZwfL1qRJPumEXRQEkwhSdF00-N88g_at_mail.gmail.com>
Note that I had a bug in the dashtop.sql that I just fixed and I've reuploaded the script here:
http://blog.tanelpoder.com/files/scripts/ash/dashtop.sql
-- *Tanel Poder* Enkitec (The Exadata Experts) Services <http://enkitec.com> | Training <http://blog.tanelpoder.com/seminar/> | Troubleshooting <http://blog.tanelpoder.com/> | Exadata Book <http://www.amazon.com/Expert-Oracle-Exadata-Apress/dp/1430233923> On Mon, Nov 3, 2014 at 10:01 PM, Tanel Poder <tanel_at_tanelpoder.com> wrote:Received on Tue Nov 04 2014 - 05:03:05 CET
> You can look into ASH data from around your problem time - the P1
> parameter for cursor/mutex waits shows the library cache object hash value
> (or likely the libcache hash bucket if it's less than 131072).
> SQL> *_at_ash/dashtop* event,top_level_call_name,sql_opname,p1text,p1 "event
> like 'cursor%'" "TIMESTAMP'2014-11-03 00:40:05'" "TIMESTAMP'2014-11-03
> 21:41:05'"
>
>
-- http://www.freelists.org/webpage/oracle-l