Chapter 1. Introduction

Chapter 1. Introduction
Why are people so intensely interested in Oracle internals? Partly because
internals information can be useful for tuning and troubleshooting. But also
because Oracle Corporation has kept most of the internals secret, while revealing
just enough to tantalize.
In fact, Oracle internals information is needed only for advanced performance
tuning. It's true that basic application tuning is the kind of tuning that's most
often needed, and the kind that has the biggest impact. Nevertheless, there are
times when advanced performance tuning is necessary, and that is when you
need a deep understanding of how Oracle works. This book provides some of the
foundations for that understanding.
To appreciate the contribution that this book makes, and to put it in context, you
need to have a basic understanding of the layers of the Oracle kernel.
1.1 The Oracle Kernel Layers
The Oracle kernel is comprised of layers; the main layers are shown in Figure
1.1. Each layer depends upon the services of the layers below it, and may call any
of them directly, in any order. However, control is never passed up the stack,
except when returning from a call.
The one apparent exception to this rule is that the data layer and the transaction
layer sometimes need to perform recursive transactions for tasks such as index
block splits or extent space management, and recursive calls are needed for tasks
such as trigger execution or SQL statement execution from within stored
program units. However, instead of calling back to the kernel execution or
compilation layer from within the same session or call context, a separate context
is established and the stack is reentered from the top layer.
Each layer has a short name, or abbreviation, that is used as a prefix to the names
of its modules. For example, KC is the short name for the kernel cache layer.
These short names are shown in Figure 1.1 and in the following list. Similarly,
each of the modules that comprise the layers has a short name too. For example,
KCR is the redo management module within the cache layer. These module
names are prefixed to the names of their data structures and function calls. For
example, KCRFAL is the redo allocation latch. This naming convention makes
Oracle's names seem rather cryptic and formidable at first, but they soon become
surprisingly easy to recognize and a great aid to understanding. Nevertheless, you
will be pleased to know that this book uses the verbose names in preference to
their somewhat cryptic alternatives.
The Oracle call interface (OCI)
The Oracle call interface is the lowest level at which client programs are
intended to interact with Oracle. This interface is well documented and
provides access to most of the functionality of Oracle, including advanced
features such as object navigation, and sophisticated transaction and
session control. Applications with advanced requirements have to use OCI
directly, in order to access the features that are not available in Oracle's
other development tools.
The user program interface (UPI)
OCI is based on the user program interface. There are some UPI facilities
that are not yet available via OCI, and so some of the Oracle tools actually
call this interface directly. Precompiler programs also call the user
program interface, but indirectly via the SQLLIB library, which is an
undocumented alternative to OCI.
The Oracle program interface (OPI)
The user program interface is the lowest layer of the client-side call stack,
and the Oracle program interface is the highest layer of the server-side call
stack. In most configurations, Net8 bridges the gap between UPI and OPI.
However, in single-task executables there is no gap, and the UPI calls
correspond directly to OPI calls.
The compilation layer (KK)
This is the top layer of the Oracle kernel proper. This layer is responsible
for the parsing and optimization of SQL statements and for the
compilation of PL/SQL program units.
The execution layer (KX)
This layer handles the binding and execution of SQL statements and
PL/SQL program units. It is also responsible for the execution of recursive
calls for trigger execution, and for the execution of SQL statements within
PL/SQL program units.
The distributed execution layer (K2)
The distributed execution layer establishes the transaction branches for
distributed transactions, and handles the management of the two-phase
commit protocol.
The network program interface (NPI)
When remote objects are referenced in a SQL statement, the network
program interface sends the decomposed statement components to the
remote database instances and receives the data in return.
The security layer (KZ)
This layer is called by the compilation and execution layers to validate the
required object and system privileges.
The query layer (KQ)
This layer provides rows to the higher layers. In particular, the query layer
is responsible for caching rows from the data dictionary, for use by the
security and compilation layers.
The recursive program interface (RPI)
The recursive program interface is used to populate the dictionary cache
from the data dictionary. Row cache recursive SQL statements are
executed in a separate call context, but are not parsed and optimized in the
compilation layer.
The access layer (KA)
The access layer is responsible for access to database segments. This is the
first layer of the lower half of the kernel.
The data layer (KD)
This layer is responsible for the management and interpretation of data
within the blocks of database segments such as tables, clusters, and
indexes.
The transaction layer (KT)
This layer is responsible for the allocation of transactions to rollback
segments, interested transaction list changes within data blocks, changes
to rollback segment blocks for undo generation, transaction control
facilities such as savepoints, and read consistency. The transaction layer is
also responsible for space management, both at the level of segment free
lists and at the level of tablespace extent allocation.
The cache layer (KC)
The cache layer manages the database buffer cache. It uses operating
system dependent facilities for data file I/O, provides concurrency control
facilities for local access to the cache buffers, and provides parallel cache
management (PCM) instance locking facilities for Oracle parallel server.
The other main responsibility of the cache layer is the control of redo
generation into the log buffer, and the writing of redo to the log files. The
cache layer also caches control file information.
The services layer (KS)
The services layer provides low-level services that are used by all the
higher layers, such as error handling, debugging, and tracing facilities, as
well as parameter control and memory services. In particular, the service
layer is responsible for generic concurrency control facilities such as
latches, event waits, enqueue locks, and instance locks. This layer is also
responsible for the management of the data structures for background and
user processes and sessions, as well as state objects, inter-process
messages, and system statistics.
The lock management layer (KJ)
This layer is responsible for the locking used for synchronization and
communication between the instances of a parallel server database.
The generic layer (KG)
The generic layer provides management for the generic data structures
that are used by the higher layers, such as linked lists. Of particular
interest are the library cache and the memory allocation heaps used for the
shared pool and session memory.
The operating system dependencies (S)
Oracle uses operating system facilities for I/O, process scheduling,
memory management, and other operations. The implementation details
are operating system dependent, and so these details are isolated into a
separate layer.
1.2 The Kernel Services
This book covers the kernel services for waits, latches, locks, and memory.
Although there is relatively little you can do to tune these services themselves,
you will need to understand them when you tune any other part of Oracle.
Chapter 2
The wait statistics are the most important Oracle statistics for advanced
performance tuning. This chapter explains how to gather and use these statistics.
Chapter 3
Oracle makes extensive use of latches, and advanced performance tuning often
involves the prevention of latch contention. This chapter provides a foundation
for such tuning by explaining how latches are used.
Chapter 4
Oracle uses many types of locks. This chapter explains how locks are used, and
how to diagnose locking problems.
Chapter 5
Oracle parallel server technology adds an extra dimension to Oracle tuning. This
chapter explains how parallel server locking is implemented, and what the
statistics mean.
Chapter 6
This chapter explains how Oracle's internal memory management works. I pay
particular attention to the inner workings of the shared pool, and to assessing
whether it is sized correctly.
Although there is much more to Oracle internals than this small book covers,
these chapters provide the foundation that you need for advanced performance
tuning.