There’s a version of storage management that most Oracle DBAs have lived through at some point — manually carving up LUNs, babysitting disk utilization, rebalancing storage after an expansion, and hoping the underlying RAID configuration holds up when hardware fails. It works, but it’s tedious, error-prone, and doesn’t scale gracefully as environments grow.
Oracle ASM exists to take most of that off your plate. Not by hiding the complexity entirely, but by handling the mechanical parts — striping, mirroring, rebalancing, metadata management — so you can focus on the decisions that actually require judgment.
This is a walkthrough of how ASM is put together architecturally, written for people who want to understand the internals rather than just know which commands to run.
ASM isn’t just a file system
The common shorthand is that ASM is “Oracle’s built-in volume manager and file system,” which is accurate but undersells what it actually does. It manages raw disks directly, distributes data across storage devices intelligently, handles redundancy at a level below the database, and does all of this in a way that’s tuned specifically for Oracle workloads.
Traditional file systems weren’t designed with databases in mind. They make reasonable general-purpose tradeoffs that don’t always align with what a database actually needs from storage. ASM makes different tradeoffs — ones that favor I/O throughput, consistent striping, and high availability over flexibility for non-database use cases.
That’s why it’s the default storage layer for Oracle RAC, and why Exadata is built around it.
The ASM instance: familiar structure, different purpose
If you’ve looked at a regular Oracle database instance, the ASM instance will feel familiar. It has an SGA — with a shared pool, large pool, and ASM cache — and it runs background processes. The structural similarity is intentional; Oracle reused the proven instance architecture rather than building something from scratch.
The key difference is what the ASM instance actually does. It doesn’t store user data or handle transactions. Its job is metadata management: tracking where files live, which allocation units belong to which extents, how disks are organized into groups, and coordinating storage operations across the environment. The actual data I/O goes directly between the database and the storage, bypassing the ASM instance entirely after the initial metadata lookup.
This distinction matters practically. The ASM instance is on the critical path for metadata, not for every read and write — which is why losing an ASM instance is serious but doesn’t necessarily mean immediate data loss.
Background processes worth knowing
A few ASM processes come up often enough that it’s worth understanding what they actually do:
RBAL manages rebalancing operations — whenever you add or drop a disk, RBAL coordinates how data gets redistributed across the group. It’s the orchestrator.
ARBn are the workers RBAL directs. Multiple ARBn processes run in parallel to move data around during rebalancing, which is why large rebalance operations don’t have to take forever.
GMON handles disk group monitoring and metadata consistency. Think of it as the watchdog that keeps tabs on group health.
MARK cleans up allocation units that have been freed or need maintenance. The unglamorous but necessary bookkeeping process.
Single instance vs. FLEX ASM in RAC
How ASM is deployed depends heavily on your architecture.
In a standalone Oracle Restart environment, there’s one ASM instance on the server. Database clients connect to it locally for metadata, then talk directly to storage for I/O. Simple, but with an obvious single point of failure: if that ASM instance goes down, storage access goes with it.
In RAC environments, FLEX ASM changes the picture considerably. Rather than running one ASM instance per cluster node, FLEX ASM typically deploys three ASM instances across the cluster, and database instances connect to whichever one is available. If an ASM instance fails, clients automatically reconnect to another — storage access continues uninterrupted.
This is one of those architectural decisions that looks like a minor implementation detail but has real operational consequences. In large RAC deployments, ASM instance failures can happen. FLEX ASM means they’re an inconvenience rather than an outage.
Disk groups: the core storage abstraction
Everything in ASM revolves around disk groups. A disk group is a logical storage container — a pool of physical or logical disks that ASM manages as a unit. Every ASM file lives inside a disk group, and ASM handles placement, striping, mirroring, and rebalancing within that group automatically.
The naming convention you’ll see everywhere uses the + prefix:
+DATA
+FRA
+RECOMultiple databases can share the same disk group without stepping on each other — ASM maintains separate internal directory structures per database. In practice, most shops separate DATA and FRA (Fast Recovery Area) into distinct groups for cleaner management and to avoid recovery I/O competing with production I/O.
Redundancy options
ASM gives you four redundancy models, and picking the right one for your environment matters:
External redundancy means ASM does no mirroring — you’re relying on your storage array’s RAID configuration to protect data. Reasonable if you have enterprise SAN hardware with proven redundancy. Not a good idea on commodity disks.
Normal redundancy is two-way mirroring. This is where most production environments land — decent protection, manageable storage overhead.
High redundancy is three-way mirroring. More storage cost, but appropriate for environments where data loss is genuinely unacceptable and the hardware budget supports it.
Flex redundancy is newer and more sophisticated. It lets you set redundancy at the file level rather than the disk group level, meaning different databases or even different file types can have different mirroring policies within the same group. Combined with quota management, it gives large environments much finer control over how storage is allocated and protected.
Failure groups
Failure groups are how ASM decides where to place mirror copies. The idea is straightforward: disks that might fail together — because they share a controller, a power supply, or a physical chassis — should be in the same failure group. ASM then ensures that mirrored copies land in different failure groups, so a single hardware failure can’t take out both copies.
Normal redundancy requires at least two failure groups. High redundancy requires three. Getting this wrong undermines the entire point of mirroring, so it’s worth thinking through carefully when you’re initially configuring disk groups.
How ASM stores data: allocation units, extents, and striping
The smallest unit of storage in ASM is the allocation unit (AU), which defaults to 4MB. Extents are collections of allocation units — this is what actually holds database data. As a file grows, ASM allocates more extents, and as storage scales up, extent sizes grow automatically to reduce metadata overhead.
Striping happens automatically across all disks in a disk group. ASM uses two methods depending on the file type:
Coarse striping — one AU per stripe — is the default for datafiles, archive logs, and RMAN backups. The larger stripe unit suits sequential I/O patterns well.
Fine striping — 128KB stripe units — is used for redo logs and control files, where you want low latency on small, frequent writes rather than high throughput on large sequential reads.
You don’t configure this per file; ASM applies the appropriate method based on file type. It’s one of those details that’s handled correctly by default, which is the point.
What can live in ASM
The list of file types ASM manages is broader than most people assume:
- Datafiles, tempfiles
- Control files
- Online and standby redo logs
- Flashback logs
- SPFILEs and password files
- RMAN backup sets and pieces
- Oracle Clusterware files (OCR, voting disks)
- ACFS volumes
ASM assigns internal names to managed files automatically, but you can create aliases when you need human-readable references. For day-to-day operations, most interaction happens through ASMCMD or SQL queries against the v$asm_* views:
sql
SELECT * FROM v$asm_client;
SELECT * FROM v$asm_diskgroup;
SELECT * FROM v$asm_disk;Why it matters to understand this properly
ASM has been around long enough that plenty of DBAs have been using it for years without thinking much about the internals. That works fine — until it doesn’t.
When a rebalance operation runs longer than expected, knowing what ARBn processes do helps you tune it. When a disk group shows degraded redundancy, understanding failure groups tells you what’s actually at risk. When you’re sizing a new RAC environment, knowing how FLEX ASM distributes ASM instances across nodes shapes your architecture decisions.
Storage problems in Oracle environments tend to be serious when they happen. ASM is well-designed and largely self-managing, but it rewards the DBAs who understand what it’s doing underneath.
