ORA-15001: diskgroup "DATAC1" does not exist or is not mounted | encountered while duplicate command for standby

     I am creating standby database using duplicate command. i encountered ORA-15001 error for password file modification, but error saying DATAC1 disk group does not exists, this error message is misleading and not recognizable.

After contacting oracle, its identified that its an issue with password file update by oracle.  

RMAN command used:

duplicate target database for standby from active database nofilenamecheck;

Error message:

sql statement: alter system set  control_files =   ''+DATAC1/XYZ/CONTROLFILE/current.274.1174401739'' comment= ''Set by RMAN'' scope=spfile
Oracle instance shut down
connected to auxiliary database (not started)
Oracle instance started
released channel: prmy1
released channel: prmy2
released channel: prmy3
released channel: prmy4
released channel: prmy5
released channel: prmy6
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 07/17/2024 12:37:28
RMAN-05501: aborting duplication of target database
RMAN-03015: error occurred in stored script Memory Script
RMAN-04006: error from auxiliary database: ORA-01993: error writing password file '+DATAC1/XYZ/PASSWORD/pwdxyz.267.1174401509'
ORA-15001: diskgroup "DATAC1" does not exist or is not mounted
Recovery Manager complete.

Solution:

1. Remove existing password file.

2. Recreate password file or copy password file from primary.

3. Run the duplicate command.

Reference to recreate password file is here

No SRLs available for T-1

 

 No SRLs available for T-1     

   This message in standby database alertlog indicates no standby redo logs using by standby database for syncing with primary.

        There will be some situations where standby redo logs will not be used even standby redo logs created in standby side. This causes the sync will happen using archivelogs implies the lag in apply.

This can be due to below:

1.Primary thread number and standby thread number is different.

Example:  

  select group#,THREAD#,sum(bytes/1024/1024),status from v$log group by group#,THREAD#,status;

    GROUP#    THREAD# SUM(BYTES/1024/1024) STATUS

---------- ---------- -------------------- ----------------

         9          1                16384 INACTIVE

        10          1                16384 INACTIVE

         8          1                16384 INACTIVE

        12          1                16384 CURRENT

select a.group#,b.THREAD#, b.bytes/1024/1024/1024, b.status FROM v$logfile a, v$standby_log b WHERE a.group# = b.group#;

    GROUP#    THREAD# B.BYTES/1024/1024/1024 STATUS

---------- ---------- ---------------------- ----------

        20          0                     16 UNASSIGNED

        21          0                     16 UNASSIGNED

        22          0                     16 UNASSIGNED

        23          0                     16 UNASSIGNED

        24          0                     16 UNASSIGNED

you can see primary thread 1 and standby thread 0. Drop the standby redologs in standby side and recreate with correct thread number matching with primary.

2. Standby redo logs might not be available in physical level, you can check in location whether the standby redo logs available in location or not.

    

3.Standby redo logs size is less than the primary redo logs size.

Primary:

select group#,THREAD#,sum(bytes/1024/1024),status from v$log group by group#,THREAD#,status;

    GROUP#    THREAD# SUM(BYTES/1024/1024) STATUS

---------- ---------- -------------------- ----------------

         9          1                16384 INACTIVE

        10          1                16384 INACTIVE

         8          1                16384 INACTIVE

        12          1                16384 CURRENT

Standby:

select a.group#,b.THREAD#, a.member, b.bytes/1024/1024/1024, b.status FROM v$logfile a, v$standby_log b WHERE a.group# = b.group#;

    GROUP#    THREAD# MEMBER                                                       B.BYTES/1024/1024/1024 STATUS

---------- ---------- ------------------------------------------------------------ ---------------------- ----------

         4          1 +RECO/PSTRPRD_XS6_AMS/ONLINELOG/group_4.259.1160134445                            1 UNASSIGNED

         5          1 +RECO/PSTRPRD_XS6_AMS/ONLINELOG/group_5.260.1160134447                            1 UNASSIGNED

         6          1 +RECO/PSTRPRD_XS6_AMS/ONLINELOG/group_6.261.1160134451                            1 UNASSIGNED

         7          1 +RECO/PSTRPRD_XS6_AMS/ONLINELOG/group_7.262.1160134455                            1 UNASSIGNED

    In primary redo size is 16G but in standby redo logs in standby side is 1G, you can create new standby redologs with correct size and drop old standby redo.

reference: https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=34273136522105&id=2747195.1&_afrWindowMode=0&_adf.ctrl-state=1cxt9fg1sq_151

4. Miss configuration of DEST_1 parameter.

 No need to specify db_unique_name and valid_for for local archiving, you can use below command.

 Alter system set log_archive_dest_1='LOCATION=USE_DB_RECOVERY_FILE_DEST'; 

reference: https://support.oracle.com/epmos/faces/DocumentDisplay?_afrLoop=33554000415773&id=2864452.1&_afrWindowMode=0&_adf.ctrl-state=1cxt9fg1sq_102