- 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. - 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. 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. - 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.

- 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. - 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. - 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. - 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.

2 . On Node 1: apply the patch using opatchauto command. 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.

1
2
3
4
5
6
7

srvctl config database –verbose
crsctl query crs softwareversion –all
opatch version
opatch lsinventory -detail -oh $GRID_HOME
opatch prereq CheckConflictAgainstOHWithDetail -phBaseDir /u01/30135696/29401763

opatchauto apply /u01/30135696

4 . Execute datapatch and run utlrp if any objects are invalid. 5 . Check the patching status using the following queries.

1
2
3
4
5
6
7

opatchauto apply /u01/30135696

nohup ./datapatch -verbose &

SELECT description, ACTION, STATUS, TARGET_BUILD_TIMESTAMP from
dba_registry_sqlpatch;
crsctl query crs releasepatch