Problem Description:
An Oracle RAC database restore job may fail with the error ORA-12528: TNS:listener: all appropriate instances are blocking new connections during the control file or database restore phase.
This typically occurs when the Oracle instances are started in NOMOUNT mode and fail to dynamically register with the listener, causing the restore agent to be unable to establish a valid session with the target instance.
In this case, initially failed with ORA-12528 but was successfully completed after reconfiguring the connection method to bypass the dynamic registration issue.
Cause:
The failure was not due to data corruption but was caused by a dynamic service registration issue in the Oracle RAC environment.
When the instance was started in NOMOUNT mode using:
srvctl start instance -d <DB_NAME> -i <INSTANCE_NAME> -o nomount
the PMON process could not register the instance with the local listener, leading the listener to mark it as BLOCKED or UNKNOWN.
As a result, the restore agent could not establish a connection for the control file restore.
Error Details (From Job Logs):
ORA-12528: TNS:listener: all appropriate instances are blocking new connections
Listener status output:
$ lsnrctl status
...
Instance "TESTDB1", status BLOCKED, has 1 handler(s) for this service...
Verification and Analysis Performed:
Checked listener status:
lsnrctl statusInstance status showed as BLOCKED or UNKNOWN.
Verified LOCAL_LISTENER parameter:
show parameter LOCAL_LISTENER;Confirmed it was correctly set to the node’s 1 address,
e.g. LOCAL_LISTENER = (ADDRESS=(PROTOCOL=TCP)(HOST=node1-VIP)(PORT=1521))
Confirmed PMON process was active:
ps -ef | grep pmonVerified instance PMON process was running.
Validated srvctl behavior:
Running srvctl start instance -o nomount did not cause listener registration.
Starting instance normally (startup) changed listener state to READY.
This confirmed that the dynamic registration mechanism failed specifically in NOMOUNT state.
Resolution (Oracle End Steps):
To bypass the dynamic registration failure and allow the restore to proceed:
Step 1: Modify the restore connection configuration
Instead of using the SCAN listener name, update the restore configuration to connect directly to the node’s VIP listener.
Example:
tnsnames.ora entry for restore:
RESTORE_CONN =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST=node1-vip)(PORT=1521))
(CONNECT_DATA = (SERVICE_NAME=TESTDB))
)
Step 2: Restart the listener
lsnrctl stop
lsnrctl start
Step 3: Start instance in NOMOUNT
srvctl start instance -d TESTDB -i TESTDB1 -o nomount
Step 4: Validate listener registration
lsnrctl status
Ensure instance is now showing as READY for the node VIP listener.
Step 5: Re-run the restore job
Use the updated connection string.
The restore should now successfully connect and proceed with the control file restore phase.
Validate database mount and open states:
alter database mount;
alter database open;
Prevention / Best Practices:
Ensure that all RAC nodes have correctly configured and reachable VIP listeners.
Keep the LOCAL_LISTENER parameter pointing to the node1-VIP, not SCAN, for local operations like restore.
Test listener registration with lsnrctl status before performing any control file restores.
Maintain consistency between the tnsnames.ora entries used by RMAN, srvctl, and the backup agent.