Upgrading an Oracle database is a common task for DBAs, especially when moving to newer database versions for performance improvements, security fixes, and new features. However, during upgrade operations in clustered environments such as Oracle RAC, DBAs may encounter the error:
ORA-39701: database must be mounted EXCLUSIVE for UPGRADE or DOWNGRADE
This error typically appears when trying to start the database in upgrade mode while the database is configured for cluster operation. In this article, we’ll explore why this error occurs, what it means, and how to resolve it safely.
Understanding the ORA-39701 Error
When attempting to start the database in upgrade mode, you might run the following command:
SQL> startup upgrade
However, instead of opening successfully, the database throws the following error:
SQL> startup upgradeORACLE instance started.
Total System Global Area 1996486272 bytes
Fixed Size 8898176 bytes
Variable Size 704643072 bytes
Database Buffers 1275068416 bytes
Redo Buffers 7876608 bytes
Database mounted.ORA-00603: ORACLE server session terminated by fatal error
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-39701: database must be mounted EXCLUSIVE for UPGRADE or DOWNGRADE
The error clearly indicates that the database must be mounted in EXCLUSIVE mode before performing an upgrade or downgrade.
This situation most commonly happens in clustered environments, where the database is configured to run with multiple instances.
Why ORA-39701 Happens
In an Oracle RAC environment, the parameter:
cluster_database = TRUE
is enabled.
This configuration allows multiple database instances to access the same database simultaneously across different nodes.
However, database upgrade operations require exclusive access to the database to ensure:
- Data dictionary consistency
- Controlled metadata changes
- Safe structural modifications
Because of this requirement, Oracle forces the database to run in exclusive mode, meaning only one instance can mount and open the database.
If the cluster_database parameter is enabled, Oracle assumes that multiple instances may attempt to access the database, which prevents the upgrade process.
Attempting Alternative Startup Methods
Some DBAs try to resolve the issue by manually mounting the database in exclusive mode:
SQL> startup mount exclusive;
Then attempting to open the database in upgrade mode:
SQL> alter database open upgrade;
But the error still occurs:
ERROR at line 1:
ORA-00603: ORACLE server session terminated by fatal error
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-39701: database must be mounted EXCLUSIVE for UPGRADE or DOWNGRADE
This happens because the cluster configuration still allows multiple instances, which prevents Oracle from entering true exclusive mode.
The Correct Solution
The correct solution is to temporarily disable cluster mode by setting the cluster_database parameter to FALSE.
This ensures that the database behaves like a single-instance database, allowing it to start in upgrade mode.
Step 1: Connect as SYSDBA
$ sqlplus / as sysdba
Step 2: Start the Instance in NOMOUNT Mode
SQL> startup nomount;
This starts the Oracle instance without mounting the database.
Step 3: Disable Cluster Mode
SQL> alter system set cluster_database=FALSE scope=spfile sid='*';
Explanation:
cluster_database=FALSEdisables RAC cluster behaviorscope=spfileensures the change persists after restartsid='*'applies the change to all instances
Step 4: Restart the Database
SQL> shutdown immediate;
Then start the database in upgrade mode:
SQL> startup upgrade
Now the database will successfully start in upgrade mode:
ORACLE instance started.
Total System Global Area 1996486272 bytes
Fixed Size 8898176 bytes
Variable Size 704643072 bytes
Database Buffers 1275068416 bytes
Redo Buffers 7876608 bytes
Database mounted.
Database opened.
At this stage, you can proceed with your database upgrade scripts, such as:
catctl.pldbupgrade- manual upgrade steps
Important Post-Upgrade Step
Once the upgrade or downgrade process is complete, it is very important to restore the cluster configuration.
Otherwise, the RAC environment will not function correctly.
Run the following command:
SQL> alter system set cluster_database=TRUE scope=spfile sid='*';
Then restart the database across the RAC nodes.
Best Practices for RAC Database Upgrades
To avoid encountering this error during upgrades, follow these best practices.
1. Always Run Upgrades in Exclusive Mode
Before starting an upgrade, ensure that:
- Only one instance is running
- Cluster mode is disabled
2. Check the Cluster Parameter
You can verify the parameter using:
show parameter cluster_database
Expected output during upgrade preparation:
cluster_database = FALSE
3. Stop All Other RAC Instances
Ensure all nodes except one are stopped:
srvctl stop instance -d <db_name> -i <instance_name>
This ensures that only a single instance mounts the database.
4. Backup Before Upgrading
Always perform:
- Full RMAN backup
- SPFILE backup
- Control file backup
Example:
RMAN> backup database plus archivelog;
This ensures quick recovery if something goes wrong during upgrade.
5. Document Parameter Changes
Temporary parameter changes should always be documented and reverted after maintenance.
This avoids future confusion in production environments.
Key Takeaways
The ORA-39701 error occurs because database upgrades require exclusive database access, which conflicts with cluster database configurations in RAC environments.
The fix is simple:
- Disable cluster mode
- Restart the database in upgrade mode
- Perform the upgrade
- Re-enable cluster mode after completion
Understanding this behavior helps DBAs perform upgrades smoothly without unnecessary downtime or confusion.
Conclusion
Database upgrades are critical maintenance tasks, but clustered environments introduce additional considerations. The ORA-39701: database must be mounted EXCLUSIVE for UPGRADE or DOWNGRADE error is a common issue when upgrading Oracle databases in RAC setups.
By temporarily disabling the cluster_database parameter and starting the database in upgrade mode, DBAs can safely perform upgrades without interruptions.
Following proper upgrade procedures and best practices will ensure a smooth upgrade process while maintaining database availability and stability.




