Time for GoodBye!

As most of you have seen, we have not been updating the blog frequently, with the last post being somewhere in the month of March 2013. So, it is decision time to either keep it alive or close it for good. I think it is time to say GoodBye.

At this moment, I would like to thank Tanveer for his contributions to this blog after I stopped writing regularly. I would also like to thank all the followers and readers of this blog for their patronage and encouraging words in the form of comments to various blog posts!

Once again, thanks everyone, GoodBye! Keep troubleshooting....

-Aravind Kamath Posral

ORA-16057: server not in Data Guard configuration

Hi,

Recently when building a DG for a Production Database we faced an issue of the RFS process not starting on the DG side.

Whenever be build DG's, we add the DG parameters to the production during the regular cold backup window when the DB gets bounced and changes take effect. Later we copy the coldbackup to the DG server and build the DG.

In this case after the coldbackup was copied to the DG side and standby controlfile was used to bring up the DG, we were seeing that the RFS process was not starting.

The production for which we were building the DG was already having 2 more DG's.

When we looked at the alert logs on both Production and DG sides we found no specific errors. We did a couple of log switches on the production side but there we no errors recorded in the alert log. The files were getting shipped to the already built DG's but not to our new DG. We also checked whether the listeners were up and tns alias were reachable, but found no issues with it

As we had seen in the previous iterations, when RFS does not start at the DG, we used defer and enable the log_archive_dest_state_n parameter on the Production side and the RFS used to start.
As is the usual practice we tried to defer and enable the log_archive_dest_state_n parameter on the production side and then did a couple of log switches. And atlast we got the below error recorded in the alert log

Tue Feb 26 05:33:25 2013Errors in file /oracle/admin/DPRD2/diag/rdbms/dprd_primary/DPRD2/trace/DBPRD2_arc8_2890.trc:ORA-16057: server not in Data Guard configurationFAL[server, ARC8]: Error 16057 creating remote archivelog file 'DBPRD_STBY_2'FAL[server, ARC8]: FAL archive failed, see trace file.Errors in file /oracle/admin/DPRD2/diag/rdbms/dprd_primary/DPRD2/trace/DPRD2_arc8_2890.trc:ORA-16055: FAL request rejectedARCH: FAL archive failed. Archiver continuingORACLE Instance DPRD2 - Archival Error. Archiver continuing.

Once we got this error we came to know that there is a issue with the log_archive_config parameter that we have setup.

On looking closely we found that the parameter value in production and our new DG was same.
log_archive_config = 'DG_CONFIG=(DPRD,DPRD_STBY_1,DPRD_STBY_2)'

This prompted us to check the already setup DG's and check why they were not getting the error. On the already setup DG's we found the parameter was set as below
log_archive_config = 'DG_CONFIG=(DPRD_PRIMARY,DPRD_STBY_1)'

The DB_UNIQUE_NAME of our production was DPRD_PRIMARY.
Once we changed the parameter on our new DG site to
log_archive_config = 'DG_CONFIG=(DPRD_PRIMARY,DPRD_STBY_2)'
and bounced the database, the RFS process started and the log files began to ship to the DG site.

Learnings

The usual notion is that we should keep the log_archive_config parameter same in both production and DG site.

But as seen from the occurrence above, we find that the log_archive_config parameter is checked only on the standby side.

Unless your configuration is used for SWITCHOVER/FAILOVER this parameter set correctly or incorrectly on the production site does not matter

-- Tanveer Madan