Upgrading and Opening a Physical Standby when the Primary has failed during upgrade
(Doc ID 975614.1)
Last updated on APRIL 03, 2020
Applies to:Oracle Database - Enterprise Edition - Version 10.2.0.1 to 126.96.36.199 [Release 10.2 to 11.1]
Oracle Database Cloud Schema Service - Version N/A and later
Oracle Database Exadata Cloud Machine - Version N/A and later
Oracle Cloud Infrastructure - Database Service - Version N/A and later
Oracle Database Exadata Express Cloud Service - Version N/A and later
Information in this document applies to any platform.
The following has occurred in this environment:
1. An attempt has been made to upgrade the Primary from 10.2.0.3 to 10.2.0.4. This has failed.
2. A Physical Standby Database is in place and attempts are being made to activate the Standby Site.
3. The Standby Site has had the 10.2.0.4 Patchset applied however the RDBMS itself is still 10.2.0.3.
4. The requirement here is to recover the Standby Site to a point where it is synchronised and the open it with the upgrade switch where catupgrd.sql can be run to upgrade the RDBMS and then open it read write.
An upgrade of the Standby Site Binaries to 10.2.0.4 has been performed. The RDBMS is still at 10.2.0.3.
Managed Recovery was disabled prior to attempting to perform the upgrade and no new redo has been generated from the primary other that occurring prion to upgrade. Standby Redo logs are in place however real time apply is not in use.
To view full details, sign in with your My Oracle Support account.
Don't have a My Oracle Support account? Click to get started!
In this Document