Patching and Upgrading oracle RAC
1 . Applying Oracle RAC Patches (Grid Infrastructure and Database)
Patch Types:
- Bundle Patches (BP): Cumulative patches that include fixes for various issues.
- Patch Set Updates (PSU): Critical Patch Updates (CPUs) that include security and critical bug fixes.
- One-off Patches: Specific patches for particular issues that are not yet included in PSUs or BPs.
- Patching Components: In Oracle RAC, you typically need to patch both the Oracle Grid Infrastructure (GI) and the Oracle RAC Database. This involves applying patches to the Clusterware, ASM, and the database software.
Patching Process:
- Download and Verify Patch: Ensure that the correct patch is downloaded from My Oracle Support (MOS) and verify its checksum.
- Backup Critical Data: Before applying any patch, it’s critical to back up the Grid Infrastructure and database, including the OCR (Oracle Cluster Registry) and voting disks.
- Patch Grid Infrastructure: Use the opatch utility to apply patches to Grid Infrastructure. Start by patching the Grid Infrastructure on one node at a time (in a rolling fashion) to ensure high availability.
- Patch RAC Database: Once the GI is patched, apply the necessary database patches. This process can also be done in a rolling manner to minimize downtime.
2 . Rolling and Non-Rolling Patching in RAC
1 . Rolling Patching:
Concept: Rolling patching allows patches to be applied to one node at a time without shutting down the entire cluster. This ensures that the database remains available throughout the patching process.
Steps:
- Stop the database instance on the node to be patched.
- Apply the patch to that node.
- Restart the database instance on the patched node.
- Repeat the process for each node in the cluster.
Benefits: The main advantage of rolling patching is that it reduces downtime and ensures continuous service availability.
2 . Non-Rolling Patching:
Concept: Non-rolling patching requires shutting down the entire cluster to apply the patch. This method is usually faster but involves complete downtime.
When to Use: Non-rolling patching is typically used when a patch affects critical components that require all nodes to be at the same software version simultaneously, or when performing major upgrades that can’t be done node by node.
Steps:
- Shut down the entire cluster.
- Apply the patch to all nodes.
- Restart the cluster.
3. Upgrading Oracle RAC Environments
Upgrade Types:
- In-Place Upgrade: Upgrading the existing Oracle RAC installation to a newer version (e.g., from Oracle 18c to 19c) without changing the hardware or operating system.
- Out-of-Place Upgrade: Installing a new Oracle RAC version on new hardware or software and then migrating the database to the new environment.
Upgrade Process:
- Pre-Upgrade Steps:
- Compatibility Check: Verify the compatibility of the current environment with the new Oracle version. This includes hardware, operating system, and database compatibility checks.
- Backup: Perform a full backup of the database and Grid Infrastructure.
- Database Validation: Use the pre-upgrade information tool (preupgrd.sql) to identify any issues that need to be addressed before upgrading.
- Patch the Current Version: Ensure the current Oracle version is fully patched before starting the upgrade.
Upgrade Grid Infrastructure:
- Start with upgrading the Oracle Grid Infrastructure, which includes the Clusterware and ASM components.
- Perform the upgrade using the gridSetup.sh script and follow the prompts to complete the upgrade.
Upgrade Database:
- Once the Grid Infrastructure is upgraded, upgrade the RAC database. This can be done using the dbua (Database Upgrade Assistant) or manually.
- Convert the database to the new version and apply necessary configuration changes.
- Post-Upgrade Steps:
- Validate the upgrade by running utlu122s.sql or the appropriate post-upgrade validation scripts.
- Re-enable any disabled features, such as scheduled jobs or backups.
4 . Best Practices for RAC Patching and Upgrades
- Backup Before Patch/Upgrade: Always take a full backup of your RAC environment, including databases, OCR, voting disks, and configuration files.
- Test in a Staging Environment: Before applying patches or upgrades to production, test them in a staging or non-production environment that closely mirrors your production setup.
- Use Rolling Patching Where Possible: To minimize downtime, use rolling patching whenever applicable. Ensure that all nodes are patched individually to maintain availability.
- Monitor Throughout the Process: Actively monitor the cluster during patching or upgrade processes to identify issues in real-time.
- Update Documentation: After patching or upgrading, update all relevant documentation, including configuration changes and new software versions.
- Plan for Downtime (if Necessary): For non-rolling patching or major upgrades, plan for downtime and notify stakeholders in advance.
- Post-Patch/Upgrade Testing: After applying patches or upgrades, perform comprehensive testing, including failover testing, to ensure that the environment is stable.
5 . What are the high-level steps to apply patches in rolling manner in Oracle RAC?
1 . Perform the patching pre-checks
srvctl config database –verbose crsctl query crs softwareversion –all opatch version opatch lsinventory -detail -oh $GRID_HOME opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /u01/30135696/29401763
2 . On Node 1: apply the patch using opatchauto command.
opatchauto apply /u01/30135696
opatchauto will bring down services on the patching node and bring up the services after
patching
3 . On Node 2: apply the patch using opatchauto command.
opatchauto apply /u01/30135696
4 . Execute datapatch and run utlrp if any objects are invalid.
nohup ./datapatch -verbose &
5 . Check the patching status using the following queries.
SELECT description, ACTION, STATUS, TARGET_BUILD_TIMESTAMP from dba_registry_sqlpatch; crsctl query crs releasepatch