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

CHAPTER 6 ■ LOCKING AND LATCHING 209
Lock Types
The three general classes of locks in Oracle are as follows:
• DML locks: DML stands for Data Manipulation Language. In general this means SELECT,
INSERT, UPDATE, MERGE, and DELETE statements. DML locks are the mechanism that
allows for concurrent data modifications. DML locks will be, for example, locks on a
specific row of data or a lock at the table level that locks every row in the table.
• DDL locks: DDL stands for Data Definition Language (CREATE and ALTER statements, and
so on). DDL locks protect the definition of the structure of objects.
• Internal locks and latches: Oracle uses these locks to protect its internal data structures.
For example, when Oracle parses a query and generates an optimized query plan, it will
“latch” the library cache to put that plan in there for other sessions to use. A latch is a
lightweight, low-level serialization device employed by Oracle, similar in function to a
lock. Do not confuse or be misled by the term “lightweight”—latches are a common
cause of contention in the database, as you will see. They are lightweight in their implementation,
but not in their effect.
We will now take a more detailed look at the specific types of locks within each of these
general classes and the implications of their use. There are more lock types than I can cover
here. The ones I cover in the sections that follow are the most common and are held for a long
duration. The other types of lock are generally held for very short periods of time.
DML Locks
DML locks are used to ensure that only one person at a time modifies a row and that no one
can drop a table upon which you are working. Oracle will place these locks for you, more or
less transparently, as you do work.
TX (Transaction) Locks
A TX lock is acquired when a transaction initiates its first change, and it is held until the
transaction performs a COMMIT or ROLLBACK. It is used as a queuing mechanism so that other
sessions can wait for the transaction to complete. Each and every row you modify or
SELECT FOR UPDATE in a transaction will “point” to an associated TX lock for that transaction.
While this sounds expensive, it is not. To understand why this is, you need a conceptual
understanding of where locks “live” and how they are managed. In Oracle, locks are stored as
an attribute of the data (see Chapter 10 for an overview of the Oracle block format). Oracle
does not have a traditional lock manager that keeps a long list of every row that is locked in
the system. Many other databases do it that way because, for them, locks are a scarce resource,
the use of which needs to be monitored. The more locks are in use, the more these systems
have to manage, so it is a concern in these systems if “too many” locks are being used.
In a database with a traditional memory-based lock manager, the process of locking a row
would resemble the following: