I have not done much research on latch levels. Others may have better input. If your first question is about how Oracle determines what level a given latch should be on, well, we probably have to ask their kernel developers. They hard code level#'s with different latches. For instance, in 9i, library cache latches are at level 5 and shared pool latches are at 7, etc. I suppose they think a shared pool latch is more critical and should be held for a shorter time than a library cache latch. Yes, levels imply priority. As documentation says, a process, if it's holding a latch, cannot get a lower (or even equal) level latch. We can also say it your way: if the process wants to get a latch at level x, it checks to see if it already holds a latch >= x. If so, the attempt is aborted. Your last question is why >=x? Why not >x and allow latch gets at levels =x? Let's imagine this case: i. Session 1 gets latch A ii. Session 2 gets latch B iii. Session 1 tries to get B iv. Session 2 tries to get A where A and B are at the same level x. If your rule only prohibits >x latch gets instead of >=x, then steps i through iv will all go through and a deadlock will occur. But if processes cannot hold latches A and B at the same time, i and ii work but steps iii and iv won't work (to be more correct, they won't work for willing to wait gets, not immediate gets). On the other hand, if A's level is lower than B's, i through iii works but iv fails. A deadlock is also avoided. Yong Huang