Notes on Patching or Upgrading Oracle

Dbvisit Standby version 6 has been developed so that Dbvisit Standby is compatible with all versions of Oracle from Oracle 8i (8.1.7.4 recommended and higher).

Dbvisit Standby version 7 only support Oracle Database 9.2 (9.2.0.8 recommended) and above.  For Oracle ASM 11.2 and above is recommended.
When Oracle is upgraded or patched to a new version, Dbvisit Standby will not have to be upgraded.  It is however recommended to stay up to date with the Dbvisit Standby releases and updates.

For more detail on the latest change log please see - http://www.dbvisit.com/products/standby_latest_changes 

IMPORTANT:

  • Even though Dbvisit Standby upgrades are not required when doing database upgrades, it is always recommended to stay up to date with the latest version of Dbvisit Standby.
  • Please make sure you follow the Oracle support documentation and patch notes when upgrading Oracle software or applying patches.
  • It is also recommended (and it is good practice) to test Oracle patches or upgrades on a test environments first before applying them to a production system.


Below are some key notes with regards to Dbvisit Standby and Patching or Upgrading Oracle Database Software:

KEY NOTES:

  1. Make sure that your Standby Database is up to date - meaning it is not lagging behind primary.
    • Run a log gap report to verify if there are gaps. On the primary, execute:  dbvisit -i <DDC>
    • where DDC is the name of the Dbvisit Database Configuration. In most cases this is the same as the database name. The DDC refers to the DDC file name which is in the form: dbv_DDC.env and contains the Dbvisit Standby settings for a particular primary and standby configuration.
    • If there are gaps (Archive log gap and/or Transfer log gap is > 0), run the default dbvisit commands on the primary and on the standby to send and apply the archive logs accordingly.
    • On the primary, execute:  dbvisit <DDC>  to send logs to standby.
    • On the standby, execute:  dbvisit <DDC>  to apply logs to standby.
    • Once completed, run a log gap report again to verify if primary and standby are sync.
  2. Disable Dbvisit Schedules on primary and standby database servers.
  3. Make sure there are backups prior to any upgrades / patches - This is critical in any patching or upgrading scenario.
  4. Make sure Dbvisit Standby is stopped while Oracle Patching or software upgrades are performed.
  5. Make sure "force logging" is enabled in the primary database - this is recommended.
  6. There is no need to run any patch scripts against the standby database - it cannot be opened read/write.  Only the standby server's Oracle executables (software) should be updated/installed as per Oracle documentation (patch notes).
  7. Follow the Oracle supplied patch/upgrade notes and run required scripts as directed by the patch readme on the primary database.  The standby database will be updated via the archive logs.
  8. Once all the patch/upgrade scripts  have finished successfully on the primary database, start the primary database as normal.
  9. Start the standby database as a standby database (you can use the command: dbv_oraStartStop start <DDC>) NOTE: If your standby ORACLE_HOME patch changed, you cannot use dbv_ commands, until you change your DDC file as stated in key note#11.
  10. Perform a number of manual log switches on the primary using the command:  sql> alter system switch log file;
  11. Only if ORACLE_HOME is changed, 
    • On the primary, update the DDC file with the new ORACLE_HOME/ORACLE_HOME_DR  and run Dbvisit Standby:  dbvisit -c <DDC> to sync the DDC files between primary and standby servers.
  12. Run dbvisit as normal on the primary - archive logs will be shipped to the standby.
  13. Run dbvisit as normal on the standby. The archive logs will be applied to standby.
  14. Optionally, the standby database can be opened on read-only if you want to run some queries on the dictionary to view versions, etc using the command: dbv_oraStartStop open <DDC>
  15. Enable the Dbvisit Standby schedules on both the primary and standby servers.