Oracle ASM Architecture, File Types, I/O Characteristics, and Storage Configuration Recommendations

Oracle ASM Architecture and Storage Recommendations

Oracle System Structure

Oracle consists of memory, physical, and logical structures. The physical structures closely related to storage arrays include data files, control files, online redo log files, and archive log files; RAC clusters also have a Voting File and OCR.

Key Physical Files and Their I/O Characteristics

OCR (Oracle Cluster Registry) maintains configuration information for RAC and Clusterware resources. I/O: accessed during RAC start/stop, 512 B and 4 KB random reads/writes.

Voting Disk manages node membership and arbitrates control during split‑brain scenarios. I/O: one operation per second, 512 B and 256 KB fixed‑position accesses.

Data Files store all database data (tables, indexes, etc.). I/O: random reads/writes, typical block size 8 KB (configurable).

Control Files contain metadata about the database (name, redo log locations, etc.). I/O: low load, mostly 16 KB blocks, some 4 KB, 80 % reads, random within a small range, emphasizing reliability.

Online Redo Log Files record every transaction change; LGWR writes to them. I/O: very frequent, multi‑stream small sequential writes, with high‑load sequential reads during archiving.

Archive Log Files are copies of filled redo logs created by ARCn in archive mode. I/O: sequential writes during archiving and sequential reads during backup.

OLTP I/O Characteristics

Each I/O is small (2 KB–8 KB).

Access locations are highly random.

At least 30 % of data is random write.

Online redo logs are written sequentially at very high frequency.

Performance bottlenecks often appear in storage IOPS capacity because OLTP workloads generate many small, random reads and frequent redo log writes.

OLAP I/O Characteristics

Each I/O is large (64 KB–1 MB).

Predominantly sequential reads.

Writes, when they occur, are usually to temporary tablespaces.

Online redo log writes are minimal except during bulk loads.

OLAP workloads stress storage bandwidth rather than IOPS, and cache benefits are limited.

Oracle ASM Overview

ASM (Automatic Storage Management) introduced in Oracle 10g and enhanced in 11g provides an integrated file system and volume manager for database files, delivering near‑bare‑metal performance with file‑system‑like manageability.

ASM Structure on Linux

Each LUN presented to the OS becomes a system disk; a partition of that disk forms an ASM Disk. Oracle recommends one partition per system disk.

Configuration Recommendations

Redundancy Levels : EXTERNAL (no mirroring), NORMAL (2‑way mirroring), HIGH (3‑way mirroring). For Voting Disks, NORMAL provides 3‑way mirroring, HIGH provides 5‑way; use an odd number of Voting Disks.

AU (Allocation Unit) Size : Default 1 MB; for large sequential I/O workloads set AU to 4 MB and configure the OS I/O size accordingly.

Diskgroup Design : Use multiple LUNs per Diskgroup to increase utilization and bandwidth. If all disks come from the same RAID group (FC, SAS, SSD), allocate two ASM Disks per group for dual‑controller load balancing; for SATA, one ASM Disk per group is sufficient. When disks originate from different RAID groups, match the number of ASM Disks to the number of RAID groups, creating one LUN per group.

RAID Recommendations : Place OCR, data files, and control files (random small I/O) on RAID 10; place archive logs (large sequential I/O) on SATA RAID 6 for cost efficiency. Set a fixed 1 MB prefetch for online redo log archiving and archive log backup.

SSD Optimization for Read Workloads

Cache hit reads are served from memory; when a miss occurs, the cache must fetch from disk, incurring latency. Sequential read workloads already achieve high cache hit rates, so SSDs provide limited benefit. SSDs are best for low‑cache‑hit, random small‑I/O workloads such as hot OLTP data files or hot indexes, and for temporary tablespaces in high‑concurrency OLAP environments.

SSD Optimization for Write Workloads

Array cache write‑back merges multiple host writes into larger internal writes, reducing physical I/O. Online redo logs must be written to disk every 3 seconds or at commit; they should use write‑back cache to meet latency requirements. Placing redo logs on SSDs can help when commit latency becomes a bottleneck, though it is not strictly required.

Overall, proper ASM Diskgroup sizing, RAID selection, AU configuration, and selective SSD placement can significantly improve Oracle database performance for both OLTP and OLAP workloads.