Oracle Internals: An 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.

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.

Figure 1-1. The Oracle kernel layers

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.