Lesson 5	Disk I/O and Oracle
Objective	Explain the importance of disk I/O to Oracle database performance, with a focus on how modern Oracle 23c/23ai deployments interact with the operating system and storage layer.

Disk I/O and Oracle 23c Database Performance

One of the most important factors in Oracle database performance is the time required to move data between persistent storage and memory. No matter how fast your CPU or how large your SGA, a database that performs excessive or slow disk I/O will deliver poor response times. This lesson shows how a single block read flows through Oracle, the operating system, and the storage layer, and why minimizing physical I/O remains critical in Oracle 23c and 23ai environments.

1. Why disk I/O still dominates response time

Oracle is designed around the principle of caching: it tries to satisfy as many requests as possible from memory (the buffer cache, shared pool, and other SGA components). When a needed block is not already in memory, Oracle must perform a physical read from storage. Even on modern SSD or NVMe devices, a physical read is orders of magnitude slower than reading from RAM. In high-throughput systems, thousands of such reads per second can quickly become the dominant component of response time.

The goal of tuning is not just to make disk I/O faster, but also to reduce the amount of disk I/O the database has to perform. Good schema design, effective indexing, appropriate caching, and well-chosen execution plans all work together to keep the physical I/O load under control.

2. A single block read: step-by-step

When a session issues a query that needs a data block, Oracle follows a predictable sequence of checks and I/O requests. The following image series illustrates this path through Oracle, the operating system, and the storage subsystem. Although the original diagrams used a UNIX example and spinning disks, the same logical sequence applies today on Linux, Windows, cloud block storage, SSD, or NVMe devices.

Oracle Database Application Clusters

Oracle checks the database buffer cache before requesting a block from storage. — 1) Oracle requests a data block and first checks the database buffer cache to see whether the block is already in memory. If the block is found, the read is a *logical read* and no physical I/O is required.

If the block is not in the buffer cache, Oracle asks the operating system I/O layer for the block. — 2) If the block is not in the buffer cache, Oracle issues a read request to the operating system I/O subsystem (for example, Linux or UNIX) to fetch the block from the underlying storage.

The operating system I/O driver checks its own page cache for the block. — 3) The operating system I/O driver checks its own page cache (OS buffer cache) to see whether the block is already in memory.

I/O request from Oracle

Operating system I/O drivers

If the block is present in the OS cache, the read can be satisfied without touching the physical device.

If the OS page cache does not contain the block, a native I/O is issued to the storage device. — 4) **Operating system I/O drivers:** If the block is not in the OS cache, the OS issues a native I/O request to the storage device (local disk, SAN, or cloud volume).

If the storage device has a cache, it checks there for the requested block. — 5) **Device cache:** If the storage device has a controller cache, the device checks its own cache to see whether the data block is already present.

If the block is not cached, a physical read from the underlying media occurs. — 6) **Physical I/O:** If the block is not in device cache, a physical read occurs from the underlying media (spinning disk, SSD, or NVMe). This step contributes most of the I/O latency.

The block is transferred from the device to the operating system cache. — 7) **Operating system I/O drivers:** After the device read completes, the block is transferred into the OS data cache. This is an in-memory transfer and is relatively fast compared to the physical read.

The block is copied from the OS cache into the Oracle buffer cache. — 8) **Operating system I/O drivers:** The OS then copies the block from its cache into the Oracle database buffer cache in the SGA, where the requesting session can access it.

The OS acknowledges completion and Oracle reads the block from the buffer cache. — 9) The operating system I/O subsystem sends an acknowledgement (ACK) back to Oracle. Oracle then reads the data block from the buffer cache and continues processing the user’s SQL statement.

In this chain, the most expensive step is the physical I/O at the storage layer. Everything else—moving data between caches and the SGA—is measured in microseconds compared to the milliseconds of a device read or write.

Illustration emphasizing that reading the data block from storage is the slowest step. — Reading the data block from storage (disk, SSD, or cloud volume) is typically the slowest and most critical step in the I/O path.

3. I/O latency and why it matters

A single disk I/O may take only a few milliseconds, but an Oracle database that performs hundreds or thousands of physical I/O operations per second will show noticeable response-time degradation if those operations are slow or poorly distributed. The time required to service an I/O request is called latency. Conceptually, latency is made up of several components:

Conceptual equation for I/O latency. — **Conceptual latency equation**

`Rotational delay + Seek or access time + Transfer time ========================= I/O latency`
On traditional spinning disks, rotational and seek delays dominate. On SSD and NVMe, controller and queueing delays replace mechanical movement, but the idea is the same: the combination of device and transfer time determines how quickly Oracle can get a block from storage into memory.

From the DBA’s perspective, the key performance indicators are:

Latency: Time to complete a read or write request.
IOPS: I/O operations per second that the storage can sustain.
Throughput: Volume of data transferred per second (MB/s or GB/s).
Queue depth: How many outstanding I/O requests are waiting on the device or storage service.

4. Modern strategies for reducing disk I/O in Oracle 23c/23ai

In Oracle 23c/23ai, the principles of I/O tuning are similar to earlier releases, but the tooling and storage technologies have evolved. Effective strategies include:

Design for fewer physical reads: Use appropriate indexing, partitioning, and access paths so that queries touch the smallest possible set of blocks.
Tune the buffer cache: Size the buffer cache so frequently accessed data stays in memory, but avoid oversizing it at the expense of PGA or OS-level caching.
Use Oracle ASM and modern storage: With Automatic Storage Management, stripe data across disks or LUNs to balance I/O, and leverage SSD or NVMe where appropriate for redo, temp, and hot data.
Monitor I/O wait events: In AWR and ASH reports, watch events such as db file sequential read, db file scattered read, and direct path read to identify I/O-bound SQL.
Align database workload with storage capabilities: For example, tune batch jobs to run during off-peak hours, and avoid mixing latency-sensitive OLTP workloads with large sequential scans on the same storage tier.

5. Why disk I/O remains central to external environment tuning

Even with modern memory sizes, advanced caching, and high-speed flash storage, disk I/O remains the single largest component of operating system response time for many Oracle databases. Understanding how a single block read moves from Oracle through the OS to the storage device—and back again—helps you interpret wait events, design schemas that minimize unnecessary I/O, and choose storage configurations that match the workload.

In the next lesson, you will look more closely at memory usage in the operating system environment and how it interacts with Oracle’s own memory structures.