Rac patch installation

Run the Pre-Upgrade Information Tool with an inclusion list, using the -c option. The output of the command is displayed to the terminal, and the output is displayed as text. A rolling patch allows one node to be patched to the latest version, while other nodes continue to use the older version and provide business service.

This methodology is best suited when you are applying one-off patches that support rolling methodology, maintaining high availability of your targets, so when one node is being patched, the other nodes are available for service.

Rolling patches are enabled by using locally accessible, nonshared file system to store the software files. Rolling patches cannot be done when the Oracle software files are stored in a shared cluster file system in which a single copy of the software is shared among all nodes.

A single copy requires much less disk space and a single copy to patch or upgrade. However, to patch or upgrade, the software must be stopped. Stopping the Oracle Clusterware software also requires all databases, applications, and services that depend on Oracle Clusterware to be stopped.

This technique requires a complete outage with down time to patch or upgrade. Out-of-place rolling patching involves installing the patch in a new home, modifying the Oracle home of the database, and then restarting instances in a rolling fashion. It works on all operating systems for which Oracle releases software. OPatch is included with the Oracle Clusterware 12c installation.

The utility contains help for its syntax by using the —help option as follows:. In general, RAC patches can be applied in a rolling fashion—that is, one node at a time.

However, it is still important to check each patch for exceptions to this rule. To verify that a patch supports rolling applications, unzip the downloaded patch into a directory of your choosing and, from that directory, issue the following command:. It is best practice to back up the software directory you are patching before performing any patch operation.

The backup should include the Oracle Inventory directory as well. If you manually download the patch and use OPatch to install the patch, you must stage the patch on each node. If you use Enterprise Manager to download the patch and you selected all the nodes in your cluster as targets for the patch, then the patch is automatically staged on those nodes.

Verify that Oracle Inventory is properly configured. Determine whether any currently installed interim patches conflict with patch to be installed. Start the patch installation. When patching is finished on host01, the OPatch dialog will inform you that the instance can be restarted on host01 and will prompt you for the name of the next node to patch. It operates by querying existing configurations and automating the steps required for patching each Oracle RAC database home of the same version and the GI home.

The utility must be executed by an operating system user with root privileges usually the user root , and it must be executed on each node in the cluster if the Grid Infrastructure home or Oracle RAC database home is in non-shared storage.

The utility should not be run in parallel on the cluster nodes. You can also roll back the patch with the same selectivity. You should enter a complete path of OCM response file if you already have created this in your environment. If you do not have the OCM response file ocm. Only the RAC instance that is currently being patched needs to be brought down.

The other instances can continue to remain available. This means that the impact on the application downtime required for such scheduled outages is further minimized. Rolling upgrade of patches is currently available for one-off patches and PSU patches. Rolling patch upgrades are not available for deployments where the Oracle Database software is shared across the different nodes.

Before Opatchauto utility, we need to manually down the instance and cluster related services prepatch. The GI System patch includes updates for both the Clusterware home and Database home that can be applied in a rolling fashion.

OPatchAuto calls datapatch to complete post patch actions upon installation of the binary patch and restart of the database. Previous Post Gathers object stats using…. Optional In the Apply SQL Script section, retain the default selection so that the default SQL script that is packaged with the patch is used for modifying the schemas. If you want to run any custom script, then select Enter the script to apply SQL and specify the full path to the location where the custom script is available.

Enterprise Manager Grid Control automatically runs certain scripts such as Catcpu. However, some scripts mentioned in the ReadMe of a patch might have to be run manually. To run those scripts, you can select Enter the script to apply SQL and specify the full path to the location where the custom scripts are available. You have an option of running both the scripts by selecting both these options or one of the scripts by selecting only one of these options.

If you select both these options, then both the scripts are run, that is, the default script runs first and then the custom script runs. Optional In the Upgrade OPatch section, retain the default selection so that the OPatch software on the target host is upgraded before the patches are applied on the database targets.

It is assumed that this software is already available on the target hosts managed by Oracle Management Agents Management Agent , but Oracle recommends you to retain the selection so that the existing software is upgraded to the latest release. Optional In the Black Out Associated Targets section, retain the default selection so that all targets associated with the clusterware to be patched are blacked out while the patching is in progress.

Optional In the Clean Up Backup Files section, select the option if you want to clean up all patching backup files after the patches are applied. The backup files are cleaned up by running OPatch utility cleanup command. Select this option depending on the space available on the target Oracle home. Optional In the Advanced OPatch Options section, specify any opatch-related options you want to pass while running this Deployment Procedure.

Typically, you can use this section when you have patch conflicts or when inventory location is not default for the target Oracle home being patched. For example, after running the Deployment Procedure in Analyze Mode , if you identified any patch conflicts, then you can pass options to rectify the patch conflicts. If you have multiple Oracle RAC databases in a cluster and if you are not sure of the selection, then search for all RAC databases in that cluster by selecting Cluster from the Target Type list.

Then click Next. On the Library Step Properties page appears only if you had customized the Deployment Procedure and marked some steps to be prompted at runtime , specify values for the library steps. If you had already set up My Oracle Support credentials for the Enterprise Manager user account being used, then the fields are pre- filled with those details.

If you have a proxy server, then provide details about the proxy server, and click Next. If you do not want to configure Oracle Configuration Manager, then delete the details appearing on this screen, and click Next. On the Credentials page, in the Home Credentials section, specify the Oracle home credentials required to patch the Oracle homes, and in the Host Credentials section, specify the operating system credentials to log in to the hosts where the Oracle homes are present.

For both sections, choose to use the preferred credentials so that the credentials stored in the Management Repository can be used. Of course, you can always override the preferred credentials with a new set of credentials.

If you choose to do so, you can specify either a common set of credentials to be used across Oracle homes and hosts, or a unique set of credentials for each Oracle home and host. After specifying a new set of credentials to override the preferred credentials, click Save OH Credential if you want to store the new credentials in the Management Repository. For Instance Name , specify a unique name for this Deployment Procedure instance so that it can be tracked later and reused with the same settings.

If you have already checked for prerequisites or if you do not want to check for prerequisites, then click Deploy to patch the selected databases. Although the instructions remain the same, when you submit the Deployment Procedure, Enterprise Manager Grid Control internally patches all the nodes of Oracle RAC collectively, that is, all the nodes are shut down and the patch is applied on all of them at the same time.

This methodology is best suited when you are applying a patch set or those one-off patches that support this methodology, or when you want to patch a shared Oracle RAC home. For example, if you are patching a shared Oracle home clusterware that has five nodes, the patch and the scripts within it are run only once on the shared Oracle home, and the other nodes are ignored or skipped.

This saves time as the patching operation is performed only once, that is, only on the shared Oracle home, not on all the nodes. Patching of shared Oracle homes is supported only for Oracle Database 10g Release 2 This option is best suited when you do not have an Internet connection on the host where Enterprise Manager Grid Control is running. In offline mode, you can either patch the nodes one by one, or patch all the nodes at a time, in parallel.