ORA-16012: database identifier mismatch

If this error message is appearing in the alert log file, most of the time it is related to log_archive_dest_1 for standby database’s local archive generation and/or log_archive_dest_2, that points to the primary database. You should check if every parameter is set properly and TNS string used to point to the primary database is set properly. For further information, you can see this article that explains how to properly configure dataguard.

Entries similar to the following can be found in the standby alert log file.

Standby database ID mismatch [0x2c45003e:0x2be0792d] (742719550:736131373) Errors in file /u01/app/oracle/base/diag/rdbms/mydb/MYDB/trace/MYDB_rfs_30624.trc: ORA-16012: database identifier mismatch Tue Apr 10 03:32:51 2018 Redo Shipping Client Connected as PUBLIC -- Connected User is Valid RFS[20]: Assigned to RFS process 31515 RFS[20]: Identified database type as 'physical standby': Client is ARCH pid 113942 Standby database ID mismatch [0x2c45003e:0x2be0792d] (742719550:736131373) Errors in file /u01/app/oracle/base/diag/rdbms/mydb/MYDB/trace/MYDB_rfs_31515.trc: ORA-16012: database identifier mismatch Tue Apr 10 03:33:52 2018 Redo Shipping Client Connected as PUBLIC -- Connected User is Valid RFS[21]: Assigned to RFS process 31885 RFS[21]: Identified database type as 'physical standby': Client is ARCH pid 113942 Standby database ID mismatch [0x2c45003e:0x2be0792d] (742719550:736131373) Errors in file /u01/app/oracle/base/diag/rdbms/mydb/MYDB/trace/MYDB_rfs_31885.trc: ORA-16012: database identifier mismatch Tue Apr 10 03:34:09 2018 Redo Shipping Client Connected as PUBLIC -- Connected User is Valid RFS[22]: Assigned to RFS process 32083 RFS[22]: Identified database type as 'physical standby': Client is ARCH pid 49368 Standby database ID mismatch [0x2c45003e:0x2be0792d] (742719550:736131373) Errors in file /u01/app/oracle/base/diag/rdbms/mydb/MYDB/trace/MYDB_rfs_32083.trc: ORA-16012: database identifier mismatch

 There is something different in above excerpt of alert log file and that is highlighted in red. This actually shows that database ID is different on both primary and standby database. DBID (queried from v$database) should be same on primary and standby database, otherwise same error would be reported in the alert log file, despite your all dataguard related parameters are configured correctly. If DBID is different, probably a rebuilt of physical standby database would be needed.