What you will learn
ASM free space differs from capacity safely available for mirrored files. The old resize notes assumed a specific Exadata layout. This lesson teaches the health and capacity gates, so cell-specific drop/recreate commands do not become a generic storage procedure.
Before you begin
Use an isolated Oracle Database 19c Linux lab with a certified patch level. Names host1.sample.com and host2.sample.com identify distinct lab hosts; replace them consistently with your own addresses. Use oracle for database software and grid for Grid Infrastructure where ownership is separated. Connect through local operating-system authentication or a configured wallet; no example includes a password. Preserve a tested backup and record the database identity before changes. Connect to ASM as an authorized SYSASM user. This lesson focuses on NORMAL or HIGH redundancy. FLEX and EXTEND groups require their own capacity interpretation.
1. Inspect usable capacity
SELECT name,type,total_mb,free_mb,required_mirror_free_mb,usable_file_mb
FROM v$asm_diskgroup_stat ORDER BY name;
FREE_MB is unused raw space. REQUIRED_MIRROR_FREE_MB reserves space for restoring redundancy after a relevant failure, while USABLE_FILE_MB accounts for mirroring in the classic redundancy cases. Do not treat the old arithmetic rule as a universal admission test. Check disk balance and the proposed failure scenario.
2. Inspect disks and operations
SELECT group_number,name,failgroup,mount_status,header_status,mode_status,state
FROM v$asm_disk ORDER BY group_number,failgroup,name;
SELECT inst_id,group_number,operation,state,power,actual,sofar,est_work,est_minutes
FROM gv$asm_operation;
Membership, online state, and failure groups must match the design. No reported operation does not mean every disk is healthy. Progress estimates can change under load.
3. Plan one storage change
Calculate headroom for failure, ongoing growth, and rebalance. Confirm backups and the platform procedure. ASM ADD DISK needs verified candidate paths and failure-group placement; Exadata also needs matching cell/grid-disk configuration. A cell-wide FORCE DROP sequence is not appropriate without those prerequisites.
4. Observe before continuing
During an approved change, repeat the queries and watch database latency. Rebalance power affects resource use; an old value is not automatically suitable. Wait for completion and restored redundancy before another failure-group change. Retain the inventory at every stage.
5. Read the example output
The following is illustrative, normalized output, not a transcript from a customer system. Values depend on your release and lab state.
NAME TYPE TOTAL_MB FREE_MB REQUIRED_MIRROR_FREE_MB USABLE_FILE_MB
DATA NORMAL 100000 40000 10000 15000
Here (40000 - 10000) / 2 gives 15000 MB. This synthetic capacity example does not authorize disk removal.
Verify the result
Confirm expected disks are online, failure groups are correct, no rebalance errors remain, and capacity satisfies the failure scenario. Test database queries and backup access afterward.
Troubleshooting
Raw free space can coexist with inadequate usable mirrored space. Investigate unexpectedly low capacity before removal. Check ASM alerts, disk state, and pressure before raising rebalance power.
Recovery and next steps
Use platform-specific recovery for partial changes. A dropped disk may pass the point where undrop is possible, so removal is not always reversible. Preserve healthy failure groups while restoring redundancy.