Let me be honest with you — when Flex ASM first showed up, a lot of DBAs ignored it. ASM was already working fine, clusters were running, nobody wanted to learn another layer. But once you actually sit with it and understand what Oracle was trying to fix, it clicks pretty fast. And now that it’s the default in 23ai, there’s no more putting it off.
So here’s how it actually works, written the way I’d explain it to someone sitting across from me.
What Was Broken Before
Old-school Oracle RAC put an ASM instance on every node. Full stop. You had a ten-node cluster? Ten ASM instances. Twenty nodes? Twenty instances, most of them sitting there doing almost nothing while still eating memory and CPU.
Nobody loved this. It made sense at smaller scales but fell apart as clusters grew. Oracle’s answer was Flex ASM — run ASM on a handful of nodes, let the rest connect remotely. Simpler. Leaner. Scales without punishing you.
The Part People Get Wrong About ASM
ASM doesn’t move your data. It never did. What it does is tell your database instances where the data lives — it’s a metadata service. The actual reads and writes go directly from your database to the storage, bypassing ASM entirely.
Why does this matter? Because it means remote ASM connections aren’t the liability they sound like. The traffic is light. A database instance reaching across the private network to ask an ASM instance for file locations isn’t a big deal — that conversation is quick, and then the heavy lifting happens directly on storage. Your nodes still need physical access to shared storage, but that’s always been true.
The Network Question
Every RAC cluster has two networks: the public one for application traffic and the private interconnect for internal cluster work — heartbeats, Cache Fusion block transfers, all the behind-the-scenes coordination that keeps RAC running.
Flex ASM traffic runs on that private interconnect by default. In a lot of environments, that’s perfectly fine. But if you’re running a big cluster with heavy workloads, you can end up with ASM metadata traffic and Cache Fusion traffic fighting for the same bandwidth. That’s a bad time.
The fix is a dedicated ASM network — its own separate pipe just for storage management traffic. Not every shop needs it, but if you’re seeing interconnect contention or running a large deployment, it’s worth serious consideration. It’s one of those things that’s much easier to build in early than to retrofit later.
Listeners and Remote Access
Local connections from a database instance to a co-located ASM instance don’t need a listener. They just connect directly.
Remote connections are a different story. Those go through an ASM listener, which tracks which ASM instances are active and routes traffic accordingly. If an ASM instance goes down, the listener handles failover. You’ll typically see these services registered in the cluster as +ASM, +ASM1, +ASM2 and so on. Clusterware manages the registration automatically — it’s not something you generally have to babysit.
ADVM Proxy — Short Answer
If you’re using Oracle ACFS, the ADVM Proxy is the middleware sitting between the file system layer and ASM. It manages file system metadata, tracks storage usage, and keeps the communication flowing between ACFS and ASM.
Not using ACFS? Leave it disabled. You don’t need it.
Managing Instances Without Shooting Yourself in the Foot
Use SRVCTL. That’s the short version.
The longer version: SRVCTL doesn’t just execute your command, it also tells Clusterware what you did. In a Flex ASM environment where clients can relocate automatically, the cluster needs to stay in sync with what’s happening. Going around SRVCTL is how you end up with Clusterware thinking something is running when it isn’t, or vice versa.
srvctl status asm
srvctl start asm
srvctl stop asmIf you need to work directly — maybe you’re doing local troubleshooting — ASMCMD works, and SQL*Plus works too:
sql
sqlplus / as sysasm
STARTUP;
SHUTDOWN IMMEDIATE;One thing that confuses people new to ASM: startup only reaches the mount state. There’s no “open” stage. ASM mounts disk groups, it doesn’t open database files. That’s just how it works — don’t sit there wondering why it stopped.
Cardinality — The Setting You Actually Need to Know
Cardinality tells Clusterware how many ASM instances to maintain across the cluster. The default is three, floor is one, ceiling is five. Change it like this:
srvctl modify asm -count 4Clusterware does the rest. If the nodes are there, it brings up the instances. If your cluster shrinks and doesn’t have enough nodes to support your configured cardinality, it’ll run whatever it can.
For a small cluster, two might be plenty. For a large enterprise environment with high availability requirements, pushing toward four or five makes sense. It’s not a set-and-forget decision — revisit it when your cluster topology changes significantly.
Relocating Clients
This is one of the more practical Flex ASM features for anyone doing regular maintenance. You can move database clients from one ASM instance to another — manually, through load balancing, or during failover.
sql
ALTER SYSTEM RELOCATE CLIENT 'DBPROD' FROM '+ASM1' TO '+ASM2';The real-world use case: you need to take down a node running an ASM instance. Before you do, relocate its clients. They move transparently, applications keep running, and you do your maintenance without anyone calling you about downtime. It works well and it’s genuinely useful.
Initialization Parameters — The Ones Worth Knowing
Most of these are self-explanatory once you see them, but here’s a quick rundown of what actually matters:
INSTANCE_TYPE=ASM — mandatory, marks this as an ASM instance rather than a database. Don’t skip it.
MEMORY_TARGET — 1 GB default, and honestly that’s usually fine. ASM handles metadata, not user data. The memory footprint stays modest.
MEMORY_TARGET=1GASM_DISKGROUPS — which disk groups mount at startup. Leave it blank and ASM mounts everything it can find, which might not be what you want in a shared environment.
ASM_DISKGROUPS=DATA,FRAASM_DISKSTRING — where ASM looks when discovering disks. Wildcards work.
ASM_DISKSTRING='/dev/oracleasm/*'ASM_POWER_LIMIT — how aggressively ASM rebalances after storage changes. Zero disables it. 1024 is maximum parallelism. Turn it up when you need a rebalance done quickly and you have the headroom — just know it will pull resources from other workloads while it runs. Most people pick something in the middle and adjust from there.
ASM_POWER_LIMIT=10Where This Leaves You
Flex ASM is a cleaner architecture than what it replaced. Running a full ASM instance on every node never made sense at scale — it was just technical debt Oracle finally addressed properly.
The practical pieces to internalize are cardinality, client relocation, and network design. Get those right and the rest of day-to-day ASM administration is pretty routine. The goal isn’t to memorize every parameter — it’s to understand the moving parts well enough that when something goes wrong at 2am, you know where to look.
That’s really what Flex ASM knowledge comes down to for a working DBA.
