Tried to create a standby controlfile from a RAC database, but it failed with ORA-00245 or ORA-245.
[oracle@primary01 ~]$ sqlplus / as sysdba
SQL> alter database create standby controlfile as '/tmp/standby.ctl';
alter database create standby controlfile as '/tmp/standby.ctl'
ERROR at line 1:
ORA-00245: control file backup failed; in Oracle RAC, target might not be on shared storage
ORA-00245 means that trying to backup controlfile to an unshared local storage is not allowable. You should seek for some shared storage among all nodes.
Solution to ORA-00245
We should backup the controlfile in a shared storage.
Shared File System
For example, NFS, GPFS or creating an ACFS to be the shared file system.
SQL> alter database create standby controlfile as '/shared_folder/standby.ctl';
If you don't have shared file system in this moment, you may consider to put it in ASM.
Create Standby ControlFile
SQL> alter database create standby controlfile as '+DATA/ORCLCDB/FLASHBACK/standby.ctl';
Copy Standby ControlFile out of ASM
This step is just like I said in How to Copy Files From One ASM Instance to Another.
[grid@primary01 ~]$ asmcmd cp +DATA/ORCLCDB/FLASHBACK/standby.ctl /tmp/
copying +DATA/ORCLCDB/FLASHBACK/standby.ctl -> /tmp//standby.ctl
[grid@primary01 ~]$ ll /tmp/standby.ctl
-rw-r----- 1 grid oinstall 23248896 Aug 26 12:36 /tmp/standby.ctl
Release 19c Onward
However, I found that I can manually create a standby controfile file into a local folder in 19c RAC DB. For routine backup by script, the successful rate of daily backing up controlfile to local file system is about 99%, 1% fails with ORA-00245.
Therefore, if there's any failure on backing up control file, we need to manually backup the controlfile during business hours.
Is there a bug or something?
Hi! The above has been implemented on a RAC environment. Just wanted to let you know that time to time I still get this error message. By any chance do you know why the error is still received ORA-00245 even if correct config was made? The error appears in some instances not every time. Thank you
As I said in the last paragraph, I have never seen this error after release 12.1. So I guess the policy could have been changed since release 12.2.