What you will learn
Physical disks back cell disks; grid disks expose allocated storage to ASM. Availability depends on redundancy across these layers, not merely a running cell service. This lesson turns the older Exadata training and standards lists into an observable pre-maintenance review.
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. Confirm the Exadata System Software release and maintenance guide. Here host1.sample.com is a database node and host2.sample.com is a storage cell. Run CellCLI on the cell with an authorized inspection account.
1. Read cell and disk status
LIST CELL DETAIL
LIST PHYSICALDISK
LIST CELLDISK
LIST GRIDDISK ATTRIBUTES name,status,asmModeStatus,asmDeactivationOutcome
Use the CellCLI prompt. Match results against inventory and investigate abnormal states. Attributes can differ by release; inspect local help if needed. A favorable deactivation outcome is one readiness input, not permission to remove multiple cells simultaneously.
2. Correlate alerts and ASM
LIST ALERTHISTORY
SELECT name,type,free_mb,usable_file_mb FROM v$asm_diskgroup_stat;
SELECT inst_id,group_number,operation,state,est_minutes FROM gv$asm_operation;
Run SQL on ASM as SYSASM, not in CellCLI. Correlate timestamps and affected disks across layers. Distinguish unresolved current problems from old warnings and inspect monitoring trends.
3. Build the maintenance gate
Verify recoverable backups, capacity, healthy failure groups, and absence of conflicting repairs or rebalances. Identify database and Grid homes separately from cell software. Use the procedure for the system generation and release combination; do not copy obsolete fabric tools or old Linux service-stop commands.
4. Repeat the baseline afterward
After the separately planned maintenance operation, repeat cell and ASM checks. Confirm expected grid disks are accessible, recovery/rebalance is complete, and application latency is normal. A normal cell status does not establish that clients have reconnected.
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 status asmModeStatus asmDeactivationOutcome
DATA_CD_00 active ONLINE Yes
This abbreviated sample removes cell-specific naming. Inspect all affected disks and the release-specific outcome semantics.
Verify the result
Retain before/after inventories, alerts, redundancy checks, and application results. Account for every intended disk and complete one maintenance unit before another.
Troubleshooting
If cell and ASM observations disagree, investigate both layers. An unsafe deactivation outcome is a reason to pause the planned change, not force it. Review dependencies and active failures.
Recovery and next steps
This lesson is read-only. Keep service and storage mutations in the version-specific maintenance procedure with a tested recovery path. Recheck protection after any failed maintenance attempt.