I’ll be straight with you — disk groups aren’t the exciting part of Oracle administration. Nobody gets into this field because they dreamed of managing storage pools. But after years of working in Oracle environments, I can tell you that more production issues trace back to poorly configured disk groups than most people want to admit. Bad names, wrong compatibility levels, content types nobody ever set, disk repair timers that trigger rebalances over a blip — it adds up.
So here’s what I actually wish someone had told me earlier.
Start With the Simple Version
A disk group is a storage pool. You hand ASM some physical disks or LUNs, it wraps them into a named group, and from that point forward it owns them. Striping, mirroring, rebalancing, space management — all of that becomes ASM’s problem, not yours. You stop worrying about individual disks and start thinking about the pool as a whole.
Everything Oracle stores through ASM lives inside one of these groups. Datafiles, control files, redo logs, archive logs, backups — all of it. There’s no such thing as an ASM-managed file that doesn’t belong to a disk group. Which means if your disk groups are misconfigured, everything built on top of them is sitting on a shaky foundation.
The flow before any of this works is simple: get your storage recognized by the OS, create the disk group, let ASM mount it, and then your database clients can connect. That’s the whole chain. Miss a step and you’re going nowhere.
Three Ways to Create One — Pick Your Preference
ASMCA gives you a GUI wizard. Click through it, pick your redundancy type, select your disks, hit create. It works and there’s nothing wrong with it, especially if you’re doing initial setup and want to see what you’re doing. It starts showing its limits when you need to set advanced attributes or want to script anything repeatable.
SQL is honestly where most experienced DBAs end up. You can see exactly what you’re doing, you can version-control it, and nothing is hidden from you:
sql
CREATE DISKGROUP FRA
NORMAL REDUNDANCY
DISK
'/dev/oracleasm/disks/FRA01',
'/dev/oracleasm/disks/FRA02';ASMCMD is your command-line option and where you’ll live if you’re building deployment scripts or doing anything automated. Once you get comfortable with it, a lot of routine administration gets faster through ASMCMD than any other method.
All three paths get you to the same place. Use whichever fits how you actually work.
The Attributes That Will Bite You If You Ignore Them
Allocation Unit Size
Think of this as the granularity knob. Default is 4 MB, you can go down to 1 MB or up to 64 MB. For most environments, 4 MB is perfectly fine and you never need to touch it. Where it starts to matter is large databases doing heavy sequential I/O — bumping this up reduces the metadata overhead and can give you a real throughput improvement. It’s not something to stress over for every new disk group, but it’s worth a conscious decision rather than just taking the default every time without thinking about it.
Disk Repair Time
This one has saved me from unnecessary headaches more than once. When a disk drops offline, ASM doesn’t immediately panic and start shuffling data around. It waits out the repair time window first — giving you a window to fix whatever caused the problem before ASM decides the disk is permanently dead.
That window matters. A flaky cable, a storage path hiccup, a brief network interruption to your SAN — these things happen and they’re usually fixable quickly. If your repair time is set too short, ASM starts rebalancing before your storage team has even opened the alert. That’s wasted I/O, unnecessary stress on your storage, and time you could have spent actually fixing the root cause. Set this to something that honestly reflects how fast your team can respond to a storage alert, not the shortest value that sounds safe.
Compatibility Settings: One-Way Door
This is the one that gets people into trouble, usually once, usually memorably.
Compatibility attributes control what ASM features are available to a disk group. Three settings to know:
- compatible.asm — what ASM functionality the disk group can use
- compatible.rdbms — minimum database version allowed to access it
- compatible.advm — ADVM feature support
Raising them is straightforward:
ALTER DISKGROUP DATA
SET ATTRIBUTE 'compatible.asm'='23.0';Here’s the thing nobody emphasizes enough until someone learns it the hard way: you cannot lower this setting once it’s raised. Not ever. The disk group is permanently committed to that compatibility level the moment you run that statement.
What that means practically: if you raise compatibility and later discover you need to run an older database version against that disk group — maybe a rollback scenario, maybe a migration that didn’t go as planned — you’re stuck. The disk group doesn’t care about your situation. It will not go backward.
So before touching compatibility settings, think through your upgrade path. Think through your rollback options. Be certain, not pretty sure.
Checking What’s Actually Configured
Two commands, both take under a minute, both give you a clear picture:
SELECT * FROM V$ASM_ATTRIBUTE;asmcmd lsattr -G DATAI’m genuinely surprised how rarely these get run in production environments. Configuration drift is real — settings get changed, documentation doesn’t get updated, people forget. Running these checks as part of a regular health review has caught more than a few surprises for me over the years. A compatibility mismatch that nobody knew about. A disk repair time set to something ridiculous. Content types that were never configured on disk groups that have been running for three years.
Takes two minutes. Worth doing.
Content Type: The Setting That’s Almost Always Missing
Honest question: how many production environments have you worked in where content type was actually configured? For most of us, the answer is not many. It’s one of those settings that doesn’t break anything if you skip it — so people skip it.
But here’s why it matters.
ALTER DISKGROUP DATA SET ATTRIBUTE 'content.type'='data';
ALTER DISKGROUP FRA SET ATTRIBUTE 'content.type'='recovery';When you tell ASM what type of files live in each disk group, it gets smarter about where it places mirrors. Without this, ASM places mirror copies based on general disk failure domains — it’s doing its best, but it doesn’t know that your FRA group is specifically supposed to be your safety net for your DATA group.
With content type set, ASM understands that relationship. It deliberately places primary and mirror copies in a way that accounts for the fact that if you lose your data files, you’re going to need your recovery files. So it keeps them separated in ways that improve your chances of having a complete recoverable copy when things go wrong.
In most properly built environments, DATA and FRA are separate disk groups precisely because you want them to serve different roles during a failure. Not configuring content type partially undermines that thinking. It takes thirty seconds to fix and most environments never bother. Don’t be most environments.
Mounting in a Cluster — The Thing That Trips People Up
Single instance? Mount the disk group, you’re done.
RAC? Every ASM instance across every node needs to mount the disk group before the database clients on those nodes can use it. That sounds obvious but it’s easy to miss when you’re setting up a new cluster or adding a disk group to an existing one.
I’ve spent time troubleshooting intermittent storage errors on one node of a RAC cluster that turned out to be nothing more complicated than the disk group not being mounted on that node’s ASM instance. Everything else looked fine — three nodes were working perfectly, one was quietly failing. Check mounting across all nodes first before going deeper into any cluster storage issue. It’s a five-second check that eliminates a whole category of problems.
Habits Worth Building
Name your disk groups like you’ll have to explain them to a stressed-out colleague at midnight. DATA, FRA, RECO, OCR — clear, obvious, unambiguous. I’ve inherited environments with disk groups named things like DG3 and TEMP2 where nobody alive could explain what they were for. Don’t do that to the next person.
Keep compatibility levels aligned between ASM and your databases. When they drift apart, the problems are subtle and annoying to diagnose.
Set content types on your DATA and FRA disk groups. Every time. Takes seconds.
Calibrate disk repair time against how your team actually operates, not against some theoretical ideal.
Run attribute checks periodically. V$ASM_ATTRIBUTE and lsattr are your friends.
The Real Point
None of this is glamorous. Disk group configuration isn’t what you put on your resume or talk about at conferences. But it’s foundational — and foundational things have a way of making their importance known at the worst possible times.
Get this layer right and it disappears into the background, quietly doing its job while you focus on everything else. Get it wrong and you’ll be revisiting it eventually, probably under pressure, probably at an inconvenient hour.
Thirty minutes spent on proper disk group configuration at setup time is worth hours of troubleshooting later. That math has always been true and it always will be.
