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@xxxxxxxxx> 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.
