Ran into an interesting situation recently with a managed services client running Oracle 18.104.22.168.0 Enterprise Edition on Linux in a two node RAC environment with Dataguard.
The client asked to have the dataguard instance changed over to read/write to do some testing. This is a common request and something that I had done for them in the past. I ran into some issues during the switchover and had to restore the dataguard instance. The restore completed successfully and everything was looking good. I started the redo apply on the standby database using the command alter database recover managed standby database disconnect. The command completed successfully and I then checked to make sure the logs were being applied by querying the v$managed_standby view. Everything looked good and the logs were being shipped over and applied. I then canceled the redo issuing the command alter database recover managed standby database cancel and proceeded to create the standby logs on the physical standby. The logs created successfully and I then started the redo apply by issuing the command alter database recover managed standby database using current logfile disconnect. The command completed successfully and I again queried the v$managed_standby view to ensure the logs were applying correctly. But this time it was not applying the logs and in fact it was looking for sequence# 1 and waiting for gap. This had me totally baffled on how it went from applying log sequence# 24532 to now looking for sequence# 1. Especially since the control file being used was a standby control file created from the primary database. No matter what I did the instance was still looking for sequence# 1.
After talking things over with our senior dba the decision was made to restore the database again. The restore was successful and everything was looking good again. I started the redo apply by issuing the alter database command and again it went back to looking for sequence# 1.
I started thinking about an issue I had encountered on a different client that had a similar environment. I would make changes to the init.ora file and restart the database and check the altered parameters and I would find they had been changed back to the original value. I found out that if you have a dataguard environment and if the parameters in the init.ora file do not match what is in the dataguard configuration they will be overwritten and changed to match. Knowing this I logged into dgmgrl and dropped the current configuration and recreated everything from the beginning. After I did that I shut down the physical standby, brought it back up to the mount mode and started the redo apply again. When I checked the v$managed_standby view the logs were being applied correctly and looking for the current sequence#.