Creating a disk group is the easy part. You run the command, ASM mounts it, databases connect, and everything works. What nobody really prepares you for is everything that comes after — the day a disk starts failing, the week storage runs low, the maintenance window where you need to swap hardware without anyone noticing. That’s where real ASM administration lives.
This is the stuff I wish had been written down clearly when I was first learning this.
Know What You Have Before You Touch Anything
This sounds obvious but it’s worth saying anyway: before you make any change to ASM storage, look at what’s actually there. Not what you think is there. What’s actually there.
SELECT * FROM V$ASM_DISKGROUP;This gives you everything at the disk group level — name, total capacity, free space, current state, compatibility settings. The group number in here is ASM’s internal identifier, mostly useful to know exists when you’re reading through logs or correlating information across views.
If you prefer the command line:
asmcmd lsdgSame information, faster to type, easier to grep through when you’re looking at multiple environments. I tend to use the SQL view when I need to dig into specifics and ASMCMD when I just want a quick sanity check.
For individual disks:
SELECT * FROM V$ASM_DISK;This is where you see disk names, paths, states, fail group assignments, and mount status. Without a WHERE clause it returns everything across all disk groups, which can be a lot in a busy environment. Filter it down to what you’re actually looking at.
One thing worth knowing: there are also statistical variants of these views.
SELECT * FROM V$ASM_DISKGROUP_STAT;
SELECT * FROM V$ASM_DISK_STAT;The difference matters more than it sounds. The regular views trigger a fresh disk discovery scan every time you query them. The STAT versions return cached data without that overhead. For routine monitoring — things you might be running frequently or from a script — use the STAT views. Save the discovery-triggering queries for when you actually need fresh discovery results.
Adding Disks When You’re Running Low
Storage fills up. It always does, usually faster than anyone planned for. When you need to expand a disk group, adding a disk is straightforward:
ALTER DISKGROUP DATA
ADD DISK '/dev/oracleasm/disks/DATA10';Before ASM accepts the disk, it validates sector size compatibility, checks disk group compatibility settings, confirms the disk is actually available, and verifies the configuration is consistent. If anything doesn’t line up, it’ll tell you before touching anything. That’s the behavior you want — better to get an error here than have a disk group that’s internally inconsistent.
Once the disk is added, ASM starts rebalancing automatically. Which brings us to the part that generates the most questions.
Rebalancing — What It Is and Why You Need to Understand It
Rebalancing is ASM redistributing data evenly across all disks in a disk group. The goal is simple: every disk carries roughly the same amount of data and handles roughly the same I/O load.
It runs automatically whenever the disk group changes — when you add a disk, remove one, replace one, or resize one. You don’t have to trigger it manually in most cases. But you do need to understand how to control it, monitor it, and sometimes wait for it.
The speed of rebalancing is controlled by power level. The initialization parameter ASM_POWER_LIMIT sets the default, and you can override it per operation:
ALTER DISKGROUP DATA REBALANCE POWER 16;Power level goes from 0 (disabled) to 1024 (maximum parallelism). The default is 1, which is conservative — it’ll get there eventually without stressing your system. Bump it up during a maintenance window when you need things done faster and you have the I/O headroom to spare. Just don’t crank it to maximum on a busy production system and walk away.
To see what’s currently happening:
SELECT * FROM V$ASM_OPERATION;This shows active operations, progress percentages, and estimated completion times. If it returns nothing, nothing is running. During any significant storage maintenance, keep this open. It tells you whether ASM is still working or whether it finished quietly while you weren’t watching.
ASMCMD equivalent:
asmcmd lsopRemoving a Disk
Sometimes you need to retire storage — old hardware, a failed disk being decommissioned, a reorganization. The command is simple:
ALTER DISKGROUP DATA DROP DISK DATA10;What’s not simple is what happens next. If there’s data on that disk, ASM has to move it somewhere else before the disk can actually leave the disk group. That’s rebalancing again, and depending on how much data is involved and what your power level is set to, it can take a while.
Don’t pull the physical disk while the rebalance is running. I’ve seen that happen. It doesn’t go well.
If you drop a disk by accident, or a disk goes offline temporarily and you don’t actually want it removed, there’s a window where you can recover it:
ALTER DISKGROUP DATA UNDROP DISKS;This only works if the rebalance hasn’t completed yet. Once ASM finishes redistributing the data and considers the disk gone, it’s gone. The UNDROP window is your one chance to reverse course, so if you realize you’ve made a mistake, don’t wait.
Replacing a Failed Disk
This is the maintenance task that comes up most often in production environments. A disk starts throwing errors, predictive failure kicks in, the storage team flags it — whatever the trigger, you need to swap it without losing data or taking downtime.
ALTER DISKGROUP DATA
REPLACE DISK DATA07
WITH '/dev/oracleasm/disks/DATA18';ASM handles the data migration to the replacement disk and runs the rebalance. The old disk gets decommissioned, the new one takes its place, and if your redundancy is configured correctly, databases keep running throughout.
If you’re doing a larger maintenance project with multiple disks being replaced, you can do them together rather than one at a time. Running multiple replacements in parallel typically means one rebalance pass instead of several sequential ones, which is faster overall and puts less sustained load on your storage.
Resizing When the Underlying Storage Grows
Some storage configurations let you expand a LUN in place — you add capacity on the storage array side and then tell ASM about it:
ALTER DISKGROUP DATA RESIZE DISK DATA01 SIZE 500G;When you’re growing, the new space becomes available immediately after ASM updates its metadata. When you’re shrinking — which comes up occasionally when reclaiming storage — ASM has to rebalance data off the space you’re removing before it can release it. Make sure you actually have somewhere for that data to go before you try to shrink.
Mounting and Dismounting
ALTER DISKGROUP DATA MOUNT;
ALTER DISKGROUP DATA DISMOUNT;These are straightforward, but the operational context matters. In a RAC cluster, use SRVCTL for this whenever possible rather than running SQL directly against ASM:
srvctl start diskgroup -diskgroup DATA
srvctl stop diskgroup -diskgroup DATASRVCTL tells Clusterware what you’re doing so it can manage dependent services appropriately. Going around it with direct SQL means Clusterware doesn’t know what changed, which can create mismatches between what’s actually running and what Clusterware thinks is running. That’s a headache you don’t need, especially before a maintenance window.
Check What’s Connected Before You Do Anything Disruptive
Before dismounting a disk group, dropping a disk, or doing anything that could interrupt access, check who’s using it:
SELECT * FROM V$ASM_CLIENT;This shows you every database instance, Clusterware component, and OCR/voting file connection to ASM. ASMCMD can do the same:
asmcmd lsctI can’t count the number of times someone has gone to dismount a disk group for maintenance and discovered it’s connected to something they forgot about. Takes thirty seconds to check. Much better than discovering the connection exists because something broke when you dismounted.
Dropping a Disk Group Entirely
When a disk group genuinely isn’t needed anymore:
DROP DISKGROUP FRA INCLUDING CONTENTS;The INCLUDING CONTENTS clause is necessary if there are files in it. Without it, ASM will refuse if the disk group isn’t empty — which is the right default behavior, honestly.
Before running this, verify nothing is connected to it. Check V$ASM_CLIENT. Check that no databases reference it in their initialization parameters. Check that Clusterware isn’t using it for OCR or voting files. The command itself is irreversible and ASM isn’t going to ask you twice.
If the disk group has storage integrity issues that are preventing a clean drop, there’s a FORCE option — but that’s a last resort for broken situations, not a shortcut.
Habits That Save You From Yourself
Check VASMDISKGROUPandVASM_DISK regularly, not just when something looks wrong. Capacity creep is real and catching it at 75% full is a much more comfortable conversation than at 95%.
Schedule rebalance-heavy operations for maintenance windows. ASM rebalancing at full power on a busy production system during peak hours is a bad day for everyone.
Match your power level to the situation. Slow and steady during business hours. Higher during windows when you need things done.
Always check V$ASM_CLIENT before any disruptive operation. Always.
Replace disks before they fail completely. Predictive failure alerts exist for a reason. A controlled replacement during a maintenance window beats an emergency recovery.
Keep V$ASM_OPERATION open during any significant storage maintenance. It tells you when things finish and catches anything that’s taking longer than expected before it becomes a problem.
The Honest Version
ASM does a lot of the heavy lifting automatically. The rebalancing, the mirroring, the placement decisions — you don’t micromanage most of it. What you do need is enough understanding of these operations to know when something is running, when something is wrong, and what to do when you need to intervene.
The DBAs who get into trouble with ASM are usually the ones who treat it as a black box and only look at it when something breaks. The ones who stay out of trouble check it regularly, understand what normal looks like, and catch problems early enough that they’re solved before anyone else notices them.
That’s really all this comes down to
