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

Error During active duplicate command RMAN-06136: Oracle error from auxiliary database: ORA-00600: internal error code, arguments: [krbi_init_fra_metadata_not_backup_ctl]

 Hi,

I got error while running active duplicate command from physical standby database.

RMAN-05501: aborting duplication of target database
RMAN-06136: Oracle error from auxiliary database: ORA-00600: internal error code, arguments: [krbi_init_fra_metadata_not_backup_ctl], [], [], [], [], [], [], [], [],

Fix:

This is some issue( I DONT KNOW) with recovery area, it could be a bug since oracle 11g.

To fix it, just need to disable the recovery area in auxiliary instance before starting the duplicate command, means remove the db_recovery_file_dest and db_recovery_file_dest_size parameters from pfile and start in no mount and start duplicate command.

Oracle 23c New features for DBAs

 Lets see new features introduced in 23c which helpful for DBAs.

1. Schema Privileges: 

I am waiting for this feature since i started working as DBA, Thanks to oracle, finally its added in 23c.

Prior to 23c, if you want to grant access on all objects in a schema to another schema, its a long route, we have to generate grant commands on all objects using dynamic sql  and run the grant commands. if new object created in the schema, we need to grant the privs again on new object.

Now with this Schema privileges allow us to simplify grant a user or role needs privileges on all objects in a schema.

If any new object added in the schema, no need to add privs again for that object. it will have access by default

Ex: 

GRANT SELECT ANY TABLE ON SCHEMA appusr TO devusr;

Dictionary views to see schema privileges are DBA_SCHEMA_PRIVS,ROLE_SCHEMA_PRIVS, USER_SCHEMA_PRIVS, SESSION_SCHEMA_PRIVS

 

2. Read-Only PDB Users:  

Oracle database 23c allows us to make PDB users read-only, which makes a connected session act like the database is opened in read-only mode, preventing the session from performing write operations.

3. DB_DEVELOPER_ROLE Role: 

Oracle database 23c introduced a new DB_DEVELOPER_ROLE role, to provide the basic roles and privileges Oracle believe are necessary for a database developer.

So now we don't need to create a role assign bulk of privs to that role and grant that role to the user, simply DBA can grant DB_DEVELOPER_ROLE role to developer after user creation. 

ORA-19809:limit exceeded for recovery files | while recovering database to another server

I dont know how many DBAs will face this issue, but i wanted to write this in my blog.

If you use source pfile/spfile for creating new database, you will not get this issue.

I wanted to create a database in a server using backup of a database that running in another server.

Restore completed successfully but while starting recover database its failed saying  " limit exceeded for recovery files" as below.

Oracle Error:
ORA-01547: warning: RECOVER succeeded but OPEN RESETLOGS would get error below
ORA-01152: file 1 was not restored from a sufficiently old backup
ORA-01110: data file 1: '+DATA/TEST/DATAFILE/system.1271.1160540667'
released channel: c1
released channel: c2
released channel: c3
released channel: c4
released channel: c5
released channel: c6
released channel: c7
released channel: c8
released channel: c9
released channel: c10
released channel: c11
released channel: c12
released channel: c13
released channel: c14
released channel: c15
released channel: c16
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 02/11/2024 07:40:15
ORA-19870: error while restoring backup piece AL_AUTO_21_12_2023_080100_arc_TEST_115137294_iondfe_131900_1_1_20231221_1156147280_set131900
ORA-19809: limit exceeded for recovery files
ORA-19804: cannot reclaim 3999268864 bytes disk space from 2190433320960 bytes limit

I checked, recovery area does not have any data in it, but if I use below query to check recovery area usage it shows 100% used. 

And if i check list archivelog all, it lists many archivelogs.

So its obvious that this info is taken from restored control file.

Now why its showing recovery area is filled, because in source database recovery area was 25TB, but for new database i am creating i have given only 2TB. So oracle calculating databased on info available in controlfile, it has list of archivelogs and its size even though physically does not exists.

As a fix, to make oracle to consider there is space in reco, i modified db_recovery_file_dest_size to 25TB( though RECO disk group does not have that much space).

alter system set db_recovery_file_dest_size=25TB scope=both;

Recover successful.