Re: Duplicate for standby failing on recover phase

If you still have the ArchiveLogs you can manually copy them to the Standby Server and then either
a. RMAN CATALOG START WITH (if you place them in a dedicated directory holding these archivelogs)
OR
b. SQL ALTER DATABASE REGISTER PHYSICAL LOGFILE 'path_to_archivelog' -- for each copied ArchiveLog

after that, you can
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION -- monitor the alert log to see that it it is apply the archivelogs

(Note : All this is with the Standby database in the MOUNT state)

Subsequent ArchiveLogs should ship properly if you have log_archive_dest_2 (and log_archive_dest_state_2) configured properly on the new Prmary and the password file is the same on both servers.

Hemant K Chitale

On Mon, Feb 15, 2021 at 9:37 PM Sandra Becker <sbecker6925_at_gmail.com> wrote:

> DB Version: Oracle EE 11.2.0.4
>
> I won't bore you with the details, but due to several kernel panics and
> server crashes, we had to switchover from the primary on node1 to the
> standby on node2 so they could address the problem on node1. DataGuard
> wasn't configured, so the DBA tried a manual switchover. The switchover
> moved the primary to node2, but node1 did not become the standby for some
> reason. All attempts to get it to startup as a standby failed with errors
> suggesting a failover was done, not a switchover. After they fixed node1,
> we decided to rebuild the standby on node1 from the active database on
> node2. The duplicate phase, which takes approximately 12 hours, worked
> just fine. However, the DORECOVER fails due to missing archivelogs. Kind
> of stuck at this point since we can copy the logs manually, but I don't
> know the command to use to perform recovery. It doesn't appear that the
> logs are being shipped during the duplicate phase. I have searched MOS as
> well as google for answers, but nothing has popped up which seems to offer
> a good solution. Due to the restricted nature of the environment, I can't
> post any log details. However, we do receive the following errors during
> the DORECOVER phase:
>
> - RMAN-03009
> - RMAN-03002
> - RMAN-05501
> - RMAN-03015
> - ORA-19625
> - ORA-27037
>
> I think I still have the ability to open a ticket with MOS, but not sure.
> In a cost cutting measure management canceled most of our Oracle support
> contracts and I need to find out if this was one of them.
>
> I have thought of two possible options to get around archivelogs not being
> shipped right away, although I would prefer to find out why it isn't
> happening and correct it.
>
> 1. Duplicate only in the script. Ships logs manually if necessary.
> Recover manually. (Just not sure what the commands would be to do the
> recovery.) Start managed recovery.
> 2. Since the mount where both node1 and node2 write their archivelogs
> is shared, use the same log_archive_dest for both the primary and standby.
> Make sure logs are shipping from the primary to log_archivelog_dest_2.
> Change the standby to log_archive_dest to the original node1 location.
> Start managed recovery. I'm not sure if this is a viable option or not.
>
> The DBA I'm training configured a couple of days ago. I took a look at
> the DataGuard configuration last night. It was valid for the primary now on
> node2, but not enabled. I have enabled it and it shows as valid and
> happy. The standby has not been added to the configuration yet. I know I
> need to verify the FAL, dg_broker_start, and log_archive_dest parameters on
> both sides.
>
> What am I missing? What else should I look at? Any specific DocIDs in
> MOS or URL that might help? Any help you can offer would be greatly
> appreciated.
>
> Thank you,
>
> Sandy B.
>
>

--
http://www.freelists.org/webpage/oracle-l