The Oracle9i Release 2 Database Migration Guide has a section in it with instructions for upgrading a standby database to 9i. The specific section can be found here.
The following procedure is from the migration guide referenced above:
Prepare to Upgrade
If multiple standby databases exist, then repeat the steps in this section for each standby database to be upgraded:
- Check for the existence of nologging operations. If nologging operations have been performed, then the standby will need to be updated. Refer to Oracle9i Data Guard Concepts and Administration for further details.
- Make note of any tablespaces or datafiles that need recovery due to offline immediate. Tablespaces or datafiles should be recovered and either brought online or taken offline prior to upgrading.
Install the new Oracle9i release on production sites and follow the instructions in Oracle9i for upgrading the production database.
Make the following additional adjustments to your parameter file before the upgrade:
- Do not enable remote archiving within the production database's parameter file if it was not already enabled. If remote archiving is enabled, then set the remote destination to defer.
- Cancel managed recovery on the standby database if running.
- If upgrading from release 8.1.7 or earlier and running Oracle9i Real Application Clusters Guard, make sure to comment out the PARALLEL_SERVER initialization parameter and set CLUSTER_DATABASE = true on the production site.
Ensure that all archived redo logs have been applied to the standby prior to the upgrade.
After the upgrade is complete, switch logfiles to archive any redo that remains in the last log:
SQL> ALTER SYSTEM SWITCH LOGFILE;Manually transfer archive logs from the upgrade from the primary archive destination on the production site to the standby archive destination on the standby host.
Shut down the standby database and listener.
Start up and mount the standby database.
Place the standby database in managed recovery mode. At the SUGGESTION prompt, type AUTO to apply all of the archive logs generated during the upgrade process.
Verify that the standby database has been recovered to the last log that was transferred to the standby host.
Resolve any archive log gaps between the production and the standby.
Re-enable remote archiving on the primary site by changing the standby destination from defer to enable.
Place standby into a recovery state.
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.