asm_power_limit changing dynamically
Dynamically Tuning ASM_POWER_LIMIT in Oracle 23ai on Exadata 25.x
While performing a cell patching upgrade to Exadata System Software 25.x on a customer environment running Oracle Grid Infrastructure 23ai, I noticed something unexpected — the ASM_POWER_LIMIT was changing on its own during a rebalance operation. Here's what I observed when querying GV$ASM_OPERATION:
Notice the POWER column jumping from 5 → 8 → 9 → 28 across successive queries — without any manual intervention. This was the first clue that something new was at work.
What is happening here?
Reviewed the ASM alert log and noticed the ASM_POWER_LIMIT kept changing. Customer confirmed no one was touching it manually. Checked for any automated jobs or cron jobs that could explain it — nothing.
This is a new feature introduced with Exadata System Software 25.1.x, working in conjunction with Oracle Grid Infrastructure 23ai or later. When both of these version requirements are met, ASM automatically and continuously tunes ASM_POWER_LIMIT up or down during a rebalance operation, based on available I/O headroom — without any DBA action required.
The enhancement works as follows:
I/O headroom is available: Exadata System Software detects spare I/O bandwidth and automatically raises the ASM_POWER_LIMIT, allowing the rebalance to complete as fast as possible.
Client database workload is detected: When the system senses active database I/O from client workloads, it automatically lowers the ASM_POWER_LIMIT to avoid impacting those workloads.
This means rebalance operations are no longer a static, fixed-cost background job. The system behaves intelligently — it gets out of the way when clients need I/O, and accelerates aggressively when capacity is free.
Requirements at a Glance
Oracle Grid Infrastructure23ai
Exadata System Software25.1.0
Both conditions must be satisfied for dynamic tuning to activate.
Why does this matter?
Traditionally, DBAs had to carefully choose an ASM_POWER_LIMIT value during patching or disk replacement events — too high and you risk impacting production workloads; too low and the rebalance drags on for hours. This feature removes that trade-off entirely by making the decision dynamic and workload-aware. For Exadata customers upgrading to the 25.x image with Grid 23ai, this is a meaningful operational improvement worth being aware of — especially if you notice your power limit changing and wonder whether something is wrong. It isn't. The system is working exactly as designed.
Reference Oracle Documentation —
Thank you for reading! 😊
If you found this blog helpful, please like ❤️ and Share 🔗 it.
Feel free to drop your questions or feedback in the comments below. 💬
