When managing Oracle Database deployments on Exadata Dedicated Infrastructure—including Oracle Database@AWS—backup throughput is directly influenced by how Recovery Manager (RMAN) allocates channels across compute nodes.
By default, the automated tooling computes parallel channels based on available compute capacity (OCPUs or ECPUs). However, smaller test or QA databases with modest compute allocations often need faster backup windows.
Understanding how Oracle allocates channels during backup versus restore operations is critical for sizing your environment and avoiding unnecessary CPU scale-up costs.
OCPU vs. ECPU: Default RMAN Channel Allocation Rules
Oracle’s managed backup frameworks dynamically calculate the default number of channels per compute node based on provisioned core capacity:
ECPU vs. OCPU Metric Conversion: 1 OCPU = 4 ECPUs.
Default Channel Formula:
Compute Ratio & Default Channel Sizing
Oracle Database@AWS uses the following standard core equivalence:
By default, Oracle tooling calculates parallel channels based on available compute capacity. However, backup and restore operations utilize the cluster topology differently.
Backup vs. Restore Channel Behavior
| Operation | Node Utilization | Channel Distribution | Scaling Impact |
| Backup | Dual-Node (Multi-node parallel) | Uses both nodes simultaneously. 4 channels/node times 2 nodes = 8 channels total | Achieves high concurrency without massive single-node scaling. |
| Restore | Single-Node (Instance-isolated) | Limited to a single node during execution. | Requires that individual node to supply all channel capacity |
The Restore Scaling Problem
Because a restore runs on a single node, achieving 8 restore channels automatically under default rules requires scaling that single compute node up to 52 ECPUs (which demands 104 ECPUs across the 2-node cluster).
The Solution: Manual Channel Override with channelsPerNode
Instead of temporarily scaling your cluster to 104 ECPUs just to accelerate to take a high-concurrency backup on low-compute instances (like QA or Dev), override the allocation using the static parameter channelsPerNode via dbaascli.
channelsPerNode via dbaascli.Step-by-Step Configuration Guide
Step 1: Export the Existing Backup Configuration
Extract the current configuration into a temporary configuration file:
dbaascli database backup --getConfig --dbname qatest--configFile /tmp/backup_config_29082026.cfg
Example:
[root@qa-test ~]# dbaascli database backup --getConfig --dbname qatest --configFile /tmp/backup_config_29082026.cfg
DBAAS CLI version 26.3.1.0.0
Executing command database backup --getConfig --dbname qatest --configFile /tmp/backup_config_29082026.cfg
Session log: /var/opt/oracle/log/qatest/database/backup/dbaastools_2026-08-29_03-20-42-AM_67884.log
logfile:/var/opt/oracle/log/dtrs/dcs-dtrs.0.*.log
File /tmp/backup_config_29082026.cfg created
dbaascli execution completed
Step 2: Check and Update the Channel Parameter
Verify the existing parameter entry inside the configuration file:
grep -i "channels" /tmp/backup_config_29082026.cfg
vi /tmp/backup_config_29082026.cfg
Update or add the parameter value to your desired concurrency (for example, 14 channels):
channelsPerNode=14
Step 3: Apply the Updated Configuration
Push the modified configuration back to the managed database framework:
dbaascli database backup --configure --dbname qatest --configFile /tmp/backup_config_29082026.cfg
The output confirms that RMAN has allocated 28 channels across the two nodes, delivering high-throughput parallel backup streams.
Key Takeaways
Avoid Over-Scaling Costs: Setting
channelsPerNodeeliminates the need to scale up to 104 ECPUs just to achieve parallel throughput for recovery operations.Monitor CPU Load: Higher channel counts on lower ECPU shapes will increase CPU pressure on the node during backup/restore windows - schedule intensive operations during low-workload maintenance windows.
Comments
Post a Comment