top of page
Search

Cellcli Cheat Sheet for Exadata X11M — 25 Storage Cell Commands Every Oracle DBA Must Know (2026)

A single Exadata X11M storage cell can push tens of gigabytes per second to the database tier — but only when its grid disks, flash cache, and IORM plan are set up correctly, and none of that is visible from SQL*Plus. The storage cells run their own Linux image and their own command line, cellcli, and that is where most real Exadata tuning and diagnosis actually happens. If you already understand how Smart Scan offloads work, being fluent at the cell layer is the natural next step. This cheat sheet collects the 25 cellcli commands that come up in day-to-day Exadata administration — the same muscle memory a srvctl cheat sheet builds for RAC, or adding a node with addnode.sh builds for cluster expansion.


Exadata cellcli storage stack: physicaldisk, LUN, celldisk, griddisk to ASM disk group
The cellcli object stack on an Exadata X11M storage cell — physical disk through grid disk to ASM.

Why DBAs Still Need Exadata cellcli commands in 2026


Exadata storage cells are sealed appliances — you do not install your own packages on them and you do not run a database there. But the cell is still the layer that decides how fast a query returns, how much I/O is offloaded, and whether a failing disk is quietly degrading a disk group. The Exadata Storage Server software exposes all of that through cellcli, a menu-free CLI you run on each cell. Knowing it is the difference between opening an SR and reading the answer yourself in ten seconds.


There is also a career angle. Exadata exposure is one of the clearest dividing lines on a DBA resume, and interviewers love to probe whether a candidate has actually touched the storage tier or only read about it. Being able to talk through the cellcli object model and a real LIST workflow signals hands-on time that no certification line can fake.


Where cellcli runs

You log in to an individual storage cell (commonly as the celladmin OS user) and launch cellcli. Every command targets only that one cell. To act on the whole rack at once you wrap cellcli inside dcli from a database node — covered below. Most commands are read-only LIST verbs, so they are safe to run on production while you investigate.


The Storage Stack cellcli Exposes


Exadata storage is a layered abstraction, and almost every cellcli object maps to one rung of that ladder. A physical disk is the real spindle or flash device. A LUN is the logical unit presented on top of it. A cell disk wraps the LUN, and a grid disk is sliced from the cell disk and handed to Oracle ASM, where it becomes an ASM disk inside +DATA or +RECO. Flash devices additionally back flash cache and flash log. Keep the diagram above in mind and the LIST commands stop feeling random — each one just walks one level of the stack.


25 cellcli Commands, Grouped by the Job


Orient yourself and list the stack

# Log in to a storage cell as celladmin, then launch cellcli
$ ssh celladmin@cel01
$ cellcli

# Identity and software version of THIS cell
CellCLI> LIST CELL DETAIL

# Walk the storage stack top to bottom
CellCLI> LIST PHYSICALDISK
CellCLI> LIST LUN
CellCLI> LIST CELLDISK
CellCLI> LIST GRIDDISK ATTRIBUTES name, asmDiskGroupName, size, status

Those five commands are 80% of a health check. LIST GRIDDISK with an ATTRIBUTES clause is especially handy: it tells you which ASM disk group each grid disk feeds and whether its status is anything other than active.

Flash cache and flash log

# Flash cache summary: size, status, and the celldisks behind it
CellCLI> LIST FLASHCACHE DETAIL

# What is hot in flash right now, per object
CellCLI> LIST FLASHCACHECONTENT WHERE hitCount > 1000 -
         ATTRIBUTES objectNumber, hitCount, missCount

# Flash log: smart write acceleration for redo
CellCLI> LIST FLASHLOG DETAIL

# Rebuild flash cache across all flash cell disks (after maintenance)
CellCLI> DROP FLASHCACHE
CellCLI> CREATE FLASHCACHE ALL

Flash is where Exadata earns its price. LIST FLASHCACHECONTENT lets you see which objects are actually living in flash, and the DROP/CREATE pair is the standard way to rebuild the cache after a flash card is replaced.

Metrics, alerts and health

# Current cell metrics (flash cache hits, cell disk IOPS, and more)
CellCLI> LIST METRICCURRENT WHERE objectType = 'FLASHCACHE'

# Open critical alerts the cell has raised but nobody has examined
CellCLI> LIST ALERTHISTORY WHERE severity = 'critical' AND examinedBy = ''

# Describe what a metric actually measures before you trust it
CellCLI> LIST METRICDEFINITION WHERE name = 'FC_IO_RQ_R'

# Confirm raw disk throughput after a hardware swap
CellCLI> CALIBRATE FORCE

I

f you have never watched an instructor run these against a live cell and read the metrics out loud, it clicks far faster than reading docs. That hands-on cell walkthrough is exactly how DBNexus Training & Consulting (formerly Oracle DBA Online Training) teaches the Exadata module — on real storage servers, not slides.


Run It Across Every Cell at Once with dcli

cellcli only ever talks to one cell. On a real rack you have several, and you want the same answer from all of them. dcli (Distributed CLI) fans a single cellcli command out to a group of cells and labels each line with the cell it came from.

# Build a cell group file once (one hostname per line)
$ cat /home/oracle/cell_group
cel01
cel02
cel03

# Fan one cellcli command out to EVERY storage cell at once
$ dcli -g /home/oracle/cell_group -l celladmin \
    cellcli -e "LIST GRIDDISK ATTRIBUTES name, status, asmDeactivationOutcome"

# Check flash cache size on all cells in a single line
$ dcli -g cell_group -l celladmin \
    cellcli -e "LIST FLASHCACHE ATTRIBUTES name, size, status"

The asmDeactivationOutcome attribute is a quiet hero here: before you take a cell offline for patching, it tells you whether ASM redundancy will survive the outage. For the full attribute lists and provisioning rules, Oracle's own Exadata Storage Management overview and the Exadata command reference are the authoritative sources.



Watch: a step-by-step walkthrough of LUNs, cell disks, and grid disks on Exadata storage — more on the Oracle DBA Online Training YouTube channel.

How do I check the Exadata flash cache hit ratio with cellcli?

Sample the cumulative flash-cache read metrics and compare hits against misses. There is no single "hit ratio" attribute, so you derive it from the request counters.

# Flash cache read requests vs read misses
CellCLI> LIST METRICCURRENT FC_IO_RQ_R, FC_IO_RQ_R_MISS -
         ATTRIBUTES name, metricValue

# hit ratio ~= (FC_IO_RQ_R - FC_IO_RQ_R_MISS) / FC_IO_RQ_R

Your cellcli Warm-Up This Week

  • Day 1: SSH into one cell and run LIST CELL DETAIL plus the four LIST stack commands. Map the output to the diagram.

  • Day 2: Run LIST GRIDDISK ATTRIBUTES name, asmDiskGroupName, status and match every grid disk to an ASM disk group.

  • Day 3: Inspect LIST FLASHCACHE DETAIL and LIST FLASHCACHECONTENT to see what is hot in flash.

  • Day 4: Use dcli to pull grid disk status from all cells in one command.

  • Day 5: Review LIST ALERTHISTORY and LIST METRICCURRENT so cell metrics become familiar before an incident makes them urgent.


Exadata cellcli FAQ


Is cellcli the same as dcli?


No. cellcli runs commands on a single storage cell. dcli is a wrapper that runs the same cellcli (or OS) command across many cells at once and tags each result with its source cell.


Can I run cellcli from the database node?

Not directly — cellcli lives on the storage cells. From a database (compute) node you reach the cells either by SSHing into a cell, or by using dcli with the -e flag to execute a cellcli command remotely.


Does cellcli work the same on Exadata Cloud@Customer and X11M?

The command vocabulary is the same, but on Exadata Cloud@Customer and Exadata Database Service some cell operations are managed by Oracle and are read-only for you. The LIST commands remain your day-to-day diagnostic toolkit on every Exadata shape.


What is the difference between a cell disk and a grid disk?

A cell disk is the cell's abstraction over one LUN (one physical disk). A grid disk is a slice carved out of a cell disk and presented to ASM. One cell disk usually holds several grid disks — for example a +DATA slice and a +RECO slice.


Do I need root to run cellcli?

For everyday diagnostics, no. The celladmin account can run the LIST and metric commands you will use most. Creating or dropping grid disks and flash cache, or altering the cell, requires the cellmonitor/celladmin privileges configured by your platform team, and some destructive operations are restricted further on managed Exadata Cloud shapes.


Ready to ship Exadata in production? Train with DBNexus.

DBNexus runs live, instructor-led Oracle DBA programs covering Exadata, RAC, Data Guard, RMAN, GoldenGate and Oracle 26ai. Real labs. Real scenarios. Recorded sessions. Lifetime access.

  • Hands-on labs on real Exadata storage cells, RAC clusters and Data Guard standbys

  • Production scenarios and troubleshooting, not slideware

  • 10,000+ DBAs trained globally

  • Interview preparation plus CV/resume review

  • Flexible weekday and weekend batches

  • Free downloadable cellcli + dcli command PDF for every enrolled DBA

  • Subscribe to the Oracle DBA Online Training YouTube channel for weekly labs

Seats in the next Exadata + RAC cohort fill fast — lock yours before the June 2026 batch closes.

Comments

bottom of page