One of the most important tasks of a DBA is to make sure the Oracle Database software is kept up to date. The same applies to the Dbvisit Standby software. Updates and patches are released on a regular basis and it is important to stay up to date.
This document will discuss the high level steps to follow when you need to apply Oracle Patches to an environment running Dbvisit Standby.
Note - the assumption is that you are running Oracle Standard Edition (SE,SE1 or SE2) but the steps should not be any different when using Enterprise Edition.
Where to start? Well the first recommendation is to review the Oracle Support site for details on the patches you are looking to apply. Example, let's say you are running Oracle Database 22.214.171.124 (Standard Edition) on Oracle Linux and both the primary and standby servers are identical (This is highly recommended). You review the Oracle Latest Patch Set Updates and would like to apply the latest patch bundle.
Now if you have never applied patches before... prepare yourself for some reading and most important - Testing! Yes, you never ever should apply patches to a production server, without testing it first. If you do not do this (testing) you could run into serious problems, example the patch might take longer than expected which could interfere with your small outage window or the patch might have warning or error messages which might require further investigation. If you have never applied patches before, or maybe you have not recently - do not skip reading the supplied Patch notes. No matter if it is a big or small patch being applied - Read the README file supplied with the patch as there might be steps required before or after the patch - and not following these steps could cause undesired effects.
In most cases before you can apply any patches to your Oracle Database software you have to update the Oracle supplied OPATCH utility. We are not going into detail into this utility - but using the latest version is recommended - and for some patches required.
For more detail on OPatch please see the following Oracle Support Documents:
- Master Note For OPatch (Doc ID 293369.1)
- OPatch - Where Can I Find the Latest Version of OPatch(6880880)? (Doc ID 224346.1)
- How To Download And Install The Latest OPatch(6880880) Version (Doc ID 274526.1)
Useful OPatch Commands:
oracle@kiwi91[/usr/dbvisit/standby]: export PATH=$ORACLE_HOME/OPatch:$PATH oracle@kiwi91[/usr/dbvisit/standby]: opatch lsinventory
Make sure that if you are using Grid Infrastructure (ASM) that you install/configure OPatch for both the GI and Database software homes.
The next is to review the latest Oracle Patch Updates - below are a number of Oracle Support Notes which may help you in identifying the latest Patch Set Updates, Security Patch Updates or Patch Bundles for your environment.
- Quick Reference to Patch Numbers for Database PSU, SPU(CPU), Bundle Patches and Patchsets (Doc ID 1454618.1)
- Oracle Recommended Patches -- Oracle Database (Doc ID 756671.1)
The next steps are high level steps you should review before installing Oracle Database Patches in your Dbvisit Standby managed environment:
- Make sure you have good - well tested, database backups. This is good practice and recommended for any patching or upgrade process. No matter how well tested a migration or upgrade or patching is, you should always have good backups.
- Identify the required patches to be applied (see above notes)
- Download the patches to both your Primary and Standby Database servers
- Important - Read the patch installation notes (README file) - Make sure you understand the steps required to apply the patch. In most cases you need to make sure that OPatch is up to date. Make sure the patch is extracted using the correct user (especially when using role separation when GI is used). Make sure you know which user to run the patch as - root, grid or oracle.
- Recommended : enable force logging on the primary database. This is highly recommended when using standby databases. But not a strict requirement. In summary it is to ensure all changes in the database is logged to the redo which will be used to apply (archive logs) to the standby - in effect updating the standby database.
- Stop the Dbvisit Standby schedules - this is recommended till you are sure the patching completed with success on the primary. Once the primary database patching is complete these will be re-enabled to apply the changes to the standby - but think of your standby is an extra backup in case something goes wrong with the patching.
- Apply the patch to the primary
- This would be a two step process in most cases (read the patch notes)
- First the executables are patched (using opatch)
- Second - optional - depending on patch notes, you might need to run certain scripts in the primary database. Again follow the patch readme and notes on this as it will state if scripts are to be run and where they are located etc.
- Once the above is complete with success you have an up to date patched primary database. Now continue to the next step
- Apply the patch to the standby:
- Important - only apply the software (executable patch) updates (again review patch notes for the steps). Do not try and run scripts against the standby database - remember it is not open read-write and you should not attempt to open it read-write. The standby database will be updated using the archive logs that will be applied to it. In effect the changes in the archive logs will update the standby database - remember these changes reflect what happened on the primary database.
- Once the standby database Oracle software is patched, you can run Dbvisit Standby. First on the primary (you might need to execute a number of log switches to ensure all redo logs on the primary is archived) then on the standby database server - this will start the applying of the archived redo to the standby database (in effect patching/updating the standby database)
- Once Dbvisit Standby was executed successfully on the primary then standby, you can run the log gap report to review the status. You should now have a fully patched primary and standby database environment
- Create another backup of your primary database - optional but highly recommended. You can never have enough backups.
Probably the most important is that you should test the process in a test or development environment prior to doing it in production. There is a number of reasons for this:
- You get to see the full process!
- You can make notes on the time it takes to perform these steps
- You might run into issues / warnings or error messages while applying the patches and need to investigate
- You get familiar with the process and time and the end result is that when you have to perform these steps in production - you will have less stress as you know you have done this before - are familiar with the steps and the expected time it should take.