认真就输

 

 

How to use this document 

Each wait scenario will be given , along with key points in the systemstate which can be used to match to the corresponding entry 
in your own systemstates. It will then give you examples of matching holders (ie what you need to find in the rest of the systemstate 
to be able to identify who is blocking) 

What is a Systemstate ? 

A systemstate is made up of the processstate of each process in the instance found at the time the systemstate was called for. Each 
processtate is made up of SO (State Objects) which hold details of the state of current objects owned by each PROCESS. 

How to Navigate through a systemstate

What you need to do is start by determining what most session are waiting for (or in the case of a session you know 
is blocked, the PROCESS number of the process). So – you will now have either a PROCESS XX or a , for example, ‘latch free’ 
which you need to begin with. What you then need to do is navigate (through vi or a windows editor) and find either 
PROCESS XX or the first example of ‘latch free’. If you are using PROCESS XX then you now need to find what the process 
is waiting for. You will now have :-

PROCESS XX waits for YYYYYYY

What you then need to do is find, by using this guide, the SO for the resource the session is waiting for and then find (by 
searching back from that point) the PROCESS XX of that session. You now have:- 

PROCESS XX waits for YYYYYYY 
PROCESS YY holds YYYYYYY 

You then begin again, finding the resource it is waiting 
for (if any) and that resources holder. Eventually you will come to a process which is on the CPU (last waited) or you will 
have navigated back to a PROCESS you already know about. In the case of the process which is on the CPU you will then need 
to get an errorstack to determine why it is blocking. In the case of a ‘deadlock’ you will now have a dependency tree of the form:- 

PROCESS XX waits for YYYYYYY 
PROCESS YY holds YYYYYYY and waits for ZZZZZZZZ 
PROCESS ZZ holds ZZZZZZZ … etc etc 

Common wait scenarios and corresponding Entries

1 – Enqueues 

To find more details on the enqueue, simply do a search for the string ‘req:’ (searching DOWN) 

Now you have the enqueue name as a string(TX-00020009-0001FA04) which you can use to search for the HOLDER:-

We can see we hold the enqueue (mode:X) in a incompatible mode to the req:X request… 

2 – Rowcache locks

To find the HOLDER, search for object,MODE of holder ( ie object=7000000eedc13a0, mode=X):- 

3 – Library Cache Pins (10G – Mutexes)

To find more details use the idn=XXXXXX to search down in the systemstate (ie idn=535d1a6c)

To find the HOLDER, search for idn XXXXXXX oper until you find one which is held (ie not GET_XXX)( ie idn 535d1a6c oper):- 

4 – Library Cache Pins (Pre 10G – non mutex)

To find more details use the handle=XXXXXX to search down in the systemstate (ie handle=c00000006c0f8490) and you will see a ‘request’ line

To find the HOLDER, search for ‘handle=XXXXXXXXX mode’ oper until you find one which is held in an incompatible mode( ie handle=c00000006c0f8490 mode):- 

5 – Library Cache Lock

To find more details use the handle address in the form handle=address to search down in the systemstate (ie handle=70000030de975a8)

To find the HOLDER, search for ‘handle=XXXXXXXXXX mode=’ until you find one which is held (but not in NULL)( ie handle=70000030de975a8 mode=):- 

6 – Latch free

If you look towards the top of the PROCESS dump you will see the exact latch we are waiting for and even who holds it:

So – PROCESS 127 holds it. If we now go to PROCESS 127 we will see :-

Other useful information

If you wish to find what object a handle refers to then use the handle=XXXXXXXXXX until you come across the LIBRARY OBJECT HANDLE. ie handle=c00000006c0f8490:-