Re: enq: ZZ - update hash tables
- From: Tanel Poder <tanel@xxxxxxxxxxxxxx>
- To: mati.vapper@xxxxxxxxx
- Date: Fri, 11 Oct 2013 16:53:54 +0300
Indeed, it probably clears global context values. KSBXIC stands for "kernel
service background cross-instance call". Never seen this event show up
before...
SQL> *@lt zz*
Show lock type info from V$LOCK_TYPE for lock zz
TYPE LOCK NAME ID1 MEANING ID2 MEANING
LT_ DESCRIPTION
---- ------------------------------ -------------------------
------------------------- ---
------------------------------------------------------------
ZZ Global Context Action *KSBXIC Action* 0
NO *Lock held for updating Global context hash tables*
SQL> *@sed "enq: ZZ"*
Show wait event descriptions matching %enq: ZZ%..
EVENT# EVENT_NAME WAIT_CLASS
PARAMETER1 PARAMETER2 PARAMETER3
ENQUEUE_NAME REQ_REASON
REQ_DESCRIPTION
------ -------------------------------------------------------
-------------------- ------------------------- -------------------------
------------------------- ------------------------------
--------------------------------
----------------------------------------------------------------------------------------------------
827 enq: ZZ - update hash tables Other
name|mode KSBXIC Action 0
Global Context Action update hash tables
lock held for updating global context hash tables
--
*Tanel Poder*
Enkitec (The Exadata Experts)
Training <http://blog.tanelpoder.com/seminar/> |
Troubleshooting<http://blog.tanelpoder.com/>
| Exadata<http://www.amazon.com/Expert-Oracle-Exadata-Apress/dp/1430233923>
| Voicee App <http://voic.ee/>
On Thu, Oct 10, 2013 at 4:38 PM, Mati Vapper <mati.vapper@xxxxxxxxx> wrote:
> Hi,
> I have an interesting issue in 3 node cluster where during the backup the
> normal processing is a bit disrupted. I didn't find much information from
> mos either from internet, so maybe here somebody has experienced something
> similar:
>
> Active% | SQL_ID | EVENT | WAIT_CLASS
> | SERVICE_NRNAME | PROGRAM
>
> ------------------------------------------------------------------------------------------------------------------------------
> 95% | | db file parallel write | System I/O
> | SYS$BACKG | oracle@linuxsrv1 (DBW1)
> 81% | | log file parallel write | System I/O
> | SYS$BACKG | oracle@linuxsrv1 (LGWR)
> 57% | | db file parallel write | System I/O
> | SYS$BACKG | oracle@linuxsrv1 (DBW0)
> 24% | b1zbvg2qpwt05 | reliable message | Other
> | service1 | JDBC Thin Client
> 24% | b1zbvg2qpwt05 | enq: ZZ - update hash tables | Other
> | service1 | JDBC Thin Client
> 19% | b1zbvg2qpwt05 | enq: ZZ - update hash tables | Other
> | service1 | JDBC Thin Client
> 19% | b1zbvg2qpwt05 | enq: ZZ - update hash tables | Other
> | service1 | JDBC Thin Client
> 14% | fzbbuz7q4qpka | db file sequential read | User I/O
> | service1 | JDBC Thin Client
> 14% | | log file sync | Commit
> | service1 | JDBC Thin Client
> 14% | | log file sync | Commit
> | service1 | JDBC Thin Client
>
>
> The service1 is an application service which is running on 2 instances. The
> enq: ZZ events are probably related to global context, because the sql is
> the execution of dbms_session.clear_context procedure.
>
> Thanks,
> Mati.
>
>
> --
> //www.freelists.org/webpage/oracle-l
>
>
>
--
//www.freelists.org/webpage/oracle-l
Other related posts:
