Every now and again I have to check what a particular lock (or enqueue) type is for and what the associated parameter values represent. This often means I have to think about the names of a couple of views and a collection of columns – then create a few column formats to make the output readable (though sometimes I can take advantage of the “print_table()” procedure that Tom Kyte a long time ago. It’s only takes a little time to get the code right, but it’s a nuisance when I’m in a hurry so I’ve just scribbled out a few lines of a script that takes a lock type as an input parameter and reports all the information I want.
rem
rem Script: lock_types.sql
rem Author: Jonathan Lewis
rem Dated: Mar 2018
rem Usage: start lock_types {lock type}
rem
define m_lock_type='&1'
column display new_value m_display
select
case when substr(version,1,2) = '12'
then
'display_name'
else
'name'
end display
from
v$instance
;
set linesize 160
set pagesize 60
set trimspool on
column type format a4
column name format a32
column description format a132
column id1_tag format a32
column id2_tag format a32
column is_user format a4 heading "User"
column is_recycle format a4 heading "Rcyc"
set feedback off
break on report skip 1
spool lock_types
select *
from V$lock_type
where type = upper('&m_lock_type')
order by
type
;
column name format a42
column parameter1 format a9
column parameter2 format a24
column parameter3 format a22
column wait_class format a14
column display_name format a42
select
eve.name,
eve.parameter1,
eve.parameter2,
eve.parameter3,
eve.wait_class,
nullif(eve.&m_display, eve.name) display_name
from
v$event_name eve
where
eve.name like 'enq: ' || upper('&m_lock_type') || '%'
order by
nullif(eve.wait_class,'Other'),
eve.name
;
set feedback on
I’ve included a check (and hack) on the value of the major version because 12c introduced a “display_name” as well as a “name” for events, and the latter is sometimes a little more descriptive than the former, so it’s nice to have a single script that could print two different values for the versions that have them.
Here’s a sample of the output when I pass ‘IV’ as an input parameter:
TYPE NAME ID1_TAG ID2_TAG User Rcyc ---- -------------------------------- -------------------------------- -------------------------------- ---- ---- DESCRIPTION CON_ID ------------------------------------------------------------------------------------------------------------------------------------ ---------- IV Library Cache Invalidation object # time stamp NO NO Synchronizes library cache object invalidations across instances 0 NAME PARAMETER PARAMETER2 PARAMETER3 WAIT_CLASS DISPLAY_NAME ------------------------------------------ --------- ------------------------ ---------------------- -------------- ------------------------------------------ enq: IV - contention type|mode id1 id2 Other
As you can see from the presence of the con_id column in v$lock_type this output came from a 12c instance. I picked the IV lock because that’s the one that prompted me to check the meanings of the id[12] and parameter[123] columns when a question about waits for the IV lock appeared recently on Oracle-L. I’ve got two reasons for carrying on with this particular example – first that it demonistrates that the descriptions can be wrong, second that it allows me to demonstrate a quick tip on translation.
The question on Oracle-L related to a 4-node RAC system and reported one instance suffering long waits on the IV enqueue on a fairly regular basis when running a particular batch task. The OP reported the following values as the p1, p2, p3 values from v$session while the wait was going on:
P1 type|mode 1230372869 P2 id1 1398361667 P3 id2 3
According to the details in v$lock_type the enqueue is about library cache invalidation across instances – and that fits the OPs complaint because the system is a RAC system. The id1 value is supposed to be an obj# (object_id), but the OP said it wasn’t; and the id2 value is supposed to be a timestamp, but 3 is an odd value for a timestamp (though it might represent – for example – the 3 second wait that is a common time-out interval for enqueues). So, clearly, the descriptions can be wrong.
Translation
Take another look at p1 and p2, and turn them into Hexadecimal:
1230372869 (dec) = 0x49560005 (hex) 1398361667 (dec) = 0x53594E43 (hex)
If you happen to be good with Hex and ASCII code you’ll know that 2-byte values in the range 41-5F are mostly the capital letters of the Roman alphabet (while 61 – 7f are mostly the lower case letters), so a second translation step gives us:
1230372869 (dec) = 0x49560005 (hex) = 'IV' 5 1398361667 (dec) = 0x53594E43 (hex) = 'SYNC'
The p1 parameter is described (correctly) as “type/mode” – this is an IV enqueue held or requested in mode 5; the p2 parameter is not an object number, it looks more like a text description of why the enqueue is being requested (the enqueue is, after all, described as being used to “synchronize library cache object invalidation”).
I still don’t know what the final parameter represents – I doubt if it’s really about a three second wait (but that could be checked by examining v$session_wait over a period of several seconds or v$session_wait_history), it might be an indication of the instance that the session is trying to synchronize with (though, again, that seems a long shot), or it might just be a “reason-code” describing why the synchronisation is necessary.
Whenever in doubt about the meaning for the various parameters, it’s always worth a quick dec -> hex -> ASCII check, just in case it offers some clues about the function of the enqueue.