Issue

Today after trying to startup a RAC test database, the resource ended up with INTERMEDIATE state on Clusterware, as below:

ora.racdb.db
      1        ONLINE  INTERMEDIATE rac01                    Instance Starting,ST
                                                             ABLE
      2        ONLINE  INTERMEDIATE rac02                    Instance Starting,ST
                                                             ABLE
      3        ONLINE  INTERMEDIATE rac03                    Instance Starting,ST
                                                             ABLE
      4        ONLINE  INTERMEDIATE rac04                    Stuck Archiver,HOME=
                                                             /u01/app/oracle/prod
                                                             uct/19.0.0/DB1924,ST
                                                             ABLE

When I connected in the local instance to check if the database has some old Restore Point in place, I received the following error:

[oracle@rac01 ~]$ sqlplus / as sysdba

SQL> select status from v$instance;

STATUS
------------
MOUNTED

SQL> select name from v$restore_point;

NAME
--------------------------------------------------------------------------------
AU_PATCHING_9212_RACDB1924000

SQL> drop restore point AU_PATCHING_9212_RACDB1924000;
drop restore point AU_PATCHING_9212_RACDB1924000
*
ERROR at line 1:
ORA-01155: the database is being opened, closed, mounted or dismounted

In the alert log I just noticed a lot of messages about the FRA limit usage:

2025-12-27T10:01:18.668962-03:00
Errors in file /u01/app/oracle/diag/rdbms/racdb/racdb1/trace/racdb1_tt00_17886.trc:
ORA-19809: limit exceeded for recovery files
ORA-19804: cannot reclaim 537919488 bytes disk space from 6442450944 bytes limit

Solution

For this case, I needed to restart the instance cleaning in MOUNT status without trying to open, and so drop the restore point:

[oracle@rac01 ~]$ srvctl stop database -d racdb
[oracle@rac01 ~]$ srvctl start instance -d racdb -i racdb1 -o mount
[oracle@rac01 ~]$ 
[oracle@rac01 ~]$ sqlplus / as sysdba

SQL> select name from v$restore_point;

NAME
--------------------------------------------------------------------------------
AU_PATCHING_9212_RACDB1924000

SQL> 
SQL> drop restore point AU_PATCHING_9212_RACDB1924000;

Restore point dropped.

SQL> alter database open;

Database altered.

SQL> exit

[oracle@rac01 ~]$ 
[oracle@rac01 ~]$ srvctl start instance -d racdb -i racdb2,racdb3,racdb4

Usually we are able to drop a restore point after the instance fails to open and stuck in MOUNT status. I guess this behavior occurred because I tried to execute this procedure connected to instance in node 1, while the first instance to initiate the OPEN process was the instance in node 4.

Maybe in next time I will try to just drop the restore point connected to the instance showed as “Stuck Archiver” in CRS.