Oracle Architecture and ASM Storage Configuration Overview

Today, the author intends to organize Oracle architecture knowledge to help readers quickly and comprehensively grasp Oracle and big‑data domain concepts.

Oracle system structure consists of memory, physical, and logical components. Physical structures related to arrays include data files, control files, online redo log files, and archive log files; RAC clusters also have Voting Files and OCR.

OCR maintains configuration information for the entire RAC and Clusterware resources, such as node members, databases, instances, services, and applications.

IO Characteristics: RAC start/stop accesses with 512 B and 4 KB I/O sizes, random read/write.

Voting Disk manages cluster node membership and arbitrates control during split‑brain scenarios.

IO Characteristics: Performs one I/O per second, with block sizes of 512 B and 256 KB at fixed locations.

Data files store all database data (tables, indexes, etc.) and consist of multiple OS files.

IO Characteristics: Random read/write, typical block size 8 KB, configurable.

Control files contain physical structure information (database name, redo log locations, etc.) and are required for opening or recovering the database.

IO Characteristics: Low load, mostly 16 KB blocks, some 4 KB, random read/write with ~80% read ratio, emphasizing reliability.

Online redo log files record all data changes; LGWR writes transactions to them, enabling recovery.

IO Characteristics: Frequent access in OLTP, multi‑stream small sequential writes; archival adds high‑load sequential reads.

Archive log files are created by ARCn when redo logs fill, used for database recovery.

IO Characteristics: Sequential write during archiving, sequential read during backup.

OLTP Application IO Characteristics

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

Disk access locations are highly random.

At least 30% of data is random write.

Online redo logs involve very frequent sequential writes.

OLTP bottlenecks often arise from storage IOPS capacity, as frequent small reads/writes stress the disk subsystem.

OLAP Application IO Characteristics

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

Read operations are sequential.

Writes usually occur in temporary tablespaces during processing.

Online log writes are rare except during bulk loads.

OLAP workloads primarily stress storage bandwidth, with sequential reads dominating.

Oracle ASM Configuration Recommendations

ASM, introduced in Oracle 10g and enhanced in 11g, is an integrated file system and volume manager for Oracle database files, offering near‑bare‑device performance with file‑system‑like manageability.

ASM on Linux maps each LUN to an ASM Disk; a system disk should host only one partition.

When creating ASM Diskgroups, choose a redundancy level: EXTERNAL (no mirroring), NORMAL (2‑way mirroring), or HIGH (3‑way mirroring). For Voting Disks, NORMAL provides 3‑way mirroring, HIGH provides 5‑way; an odd number of Voting Disks is recommended.

Store different file types in separate ASM Diskgroups. The default Allocation Unit (AU) is 1 MB; for sequential large‑IO workloads, set AU to 4 MB and configure the OS I/O size accordingly. Use a dedicated ASM Diskgroup for temporary tablespaces in heavy GROUP BY environments.

Storage Configuration Recommendations

Use multiple LUNs per ASM Diskgroup to improve utilization and bandwidth. If disks come from the same RAID group (FC, SAS, SSD), plan two ASM Disks per group for dual‑controller load balancing; for SATA, one ASM Disk suffices. When disks span multiple RAID groups, match the number of ASM Disks to RAID groups, with one LUN per group.

Align LUN striping size with ASM AU size.

For OCR, data files, and control files (random small I/O), RAID10 is recommended; avoid SATA due to performance needs. Archive files (large sequential I/O) can use SATA RAID6 for cost efficiency.

Online redo log archival and backup involve 1 MB sequential I/O; set prefetch to a fixed 1 MB.

SSD Optimization for Read Workloads

Array cache provides read prefetch; cache hits serve data instantly, while misses incur disk latency. Sequential read workloads already achieve high cache hit rates, so SSDs offer limited benefit. SSDs are better for random small‑I/O reads, such as hot data files in OLTP or temporary tablespaces in high‑concurrency OLAP.

SSD Optimization for Write Workloads

Array cache write‑back merges multiple host writes into larger internal writes, reducing disk accesses. Online redo logs must be written to disk every 3 seconds or on transaction commit; using write‑back cache ensures low latency. Placing redo logs on SSD can help if write latency becomes a bottleneck, though it is not strictly required.

For more detailed knowledge, refer to the linked e‑books and recommended readings.