Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

208
CHAPTER 6 ■ LOCKING AND LATCHING
• You do not delete from the parent table.
• You do not update the parent table’s unique/primary key value (watch for unintended
updates to the primary key by tools!).
• You do not join from the parent to the child (like DEPT to EMP).
If you satisfy all three conditions, feel free to skip the index—it is not needed. If you meet
any of the preceding conditions, be aware of the consequences. This is the one rare instance
when Oracle tends to “overlock” data.
Lock Escalation
When lock escalation occurs, the system is decreasing the granularity of your locks. An example
would be the database system turning your 100 row-level locks against a table into a single
table-level lock. You are now using “one lock to lock everything” and, typically, you are also
locking a whole lot more data than you were before. Lock escalation is used frequently in databases
that consider a lock to be a scarce resource and overhead to be avoided.
■Note Oracle will never escalate a lock. Never.
Oracle never escalates locks, but it does practice lock conversion or lock promotion—
terms that are often confused with lock escalation.
■Note The terms “lock conversion” and “lock promotion” are synonymous. Oracle typically refers to the
process as “lock conversion.”
Oracle will take a lock at the lowest level possible (i.e., the least restrictive lock possible)
and convert that lock to a more restrictive level if necessary. For example, if you select a row
from a table with the FOR UPDATE clause, two locks will be created. One lock is placed on the
row(s) you selected (and this will be an exclusive lock; no one else can lock that specific row in
exclusive mode). The other lock, a ROW SHARE TABLE lock, is placed on the table itself. This will
prevent other sessions from placing an exclusive lock on the table and thus prevent them from
altering the structure of the table, for example. Another session can modify any other row in
this table without conflict. As many commands as possible that could execute successfully
given there is a locked row in the table will be permitted.
Lock escalation is not a database “feature.” It is not a desired attribute. The fact that a
database supports lock escalation implies there is some inherent overhead in its locking
mechanism and significant work is performed to manage hundreds of locks. In Oracle, the
overhead to have 1 lock or 1 million locks is the same: none.