You should always run prerequisite checks before doing the actual update. The prerequisite checks do not require downtime and perform important validations such as:

• Validation of the Exadata release

• Validation of user input

• Validation of the installation media (YUM repository, either ISO or HTTP)

• Validation of disk space and snapshots

• Validation of YUM settings that are important for the update to finish successfully

• Checks based on known issues and best practices

The most important validation performed by the update utility is the YUM dependency check. The YUM dependency check is a YUM update dry-run command (introduced in 11.2.3.3.0) that does not do the actual YUM update but does validate dependencies. This is a final test in determining whether or not the update can proceed. It is often due to customizations that prevent successful updates. For example, installation of additional RPMs might require dependent packages that are not in the YUM repository. If this happens, you need to take corrective action to resolve the conflict.

The YUM dependency check (dry-run) is validated against minimum and exact dependencies. These dependencies are enforced by non-functional Exadata RPMs and help administrators stay exactly at (or close to) the original Exadata release when customizing the system. The update utility uses the exadata-*-computenode-exact and the exadata-*-computenode-minimum RPMs as follows:

• The exadata-*-computenode-exact RPM ensures that only a specific release of Oracle Exadata branded packages is allowed during the update. (release = x)

• The exadata-*-computenode-minimum RPM ensures that a specific or later release of Oracle Exadata branded packages is allowed during the update. (release >= x)

The relevant RPM depends on your system configuration. The following list shows possible names for the exadata-*-computenode-exact RPM:

• exadata-ib-computenode-exact: Bare-metal system with InfiniBand Network Fabric.

• exadata-sun-computenode-exact: Bare-metal system or KVM host with RoCE Network Fabric.

• exadata-sun-kvm-computenode-exact: Virtual machine (VM) guests on Oracle Linux KVM.

• exadata-sun-ovs-computenode-exact: Oracle VM Server (OVS) management domain (Dom0).

• exadata-sun-vm-computenode-exact: Oracle VM Server (OVS) user domain (DomU).

Using the exadata-*-computenode-exact RPM, the system is maintained as if it were freshly imaged because all the Oracle Exadata packages are exactly the same as on a fresh installation. The exadata-*-computenode-minimum RPM sets the minimum dependencies and enforces that all required packages are installed, but it also allows packages to be at a later version. A fresh installation always starts with both RPMs. To allow customization or updates, you need to remove the exadata-*-computenode-exact RPM. However, never remove the exadata-*-computenode-minimum RPM.

By default, the update utility attempts to match the exact dependencies when updating to a later Exadata release. When exact dependencies conflict and cannot be enforced, the utility falls back and attempts to apply the exadata-*-computenode-minimum RPM to enforce minimum dependencies. In such cases the exadata-*-computenode-exact RPM is not installed.

Missing or not updating with exact dependencies is allowed and not a problem. If a system needs to be updated to the exact dependencies, then the conflict needs to be resolved first. Check the log file to see what packages conflict, remove them cautiously, and then re-run the update utility in prerequisite check mode.

If the prerequisite check fails, you can examine the update utility’s log file for more details and determine which dependencies failed. When both exact and minimum dependencies do not match, the update cannot proceed.

For such cases, check the log file to determine what caused the dependencies to fail. After removing the failed dependencies, re-run the update utility to ensure that at least the minimum dependencies can be enforced.

When dependency errors occur during the prerequisite check or before the update starts, examine the log file (dbnodeupdate.log ) and resolve an issues. Depending on the situation, you may need to de-install, install, or update the RPM packages causing a dependency issue or conflict. The log file lists the failed dependencies.

After the update, you may re-install custom RPM packages that you de-installed, assuming you still require the packages and the packages are compatible with the updated system.

For more options, see the update utility built-in help.

Prerequisite Check Examples

The following command shows an example of a prerequisite check using an ISO repository. The command is run as root.

[root@pmserver ]# ./patchmgr --dbnodes dbs_group --precheck --repo /var/stage/p35869377_231000_Linux-x86-64.zip --target_version 23.1.8.0.0.231109

• --dbnodes specifies the list of database nodes to be updated.

• --precheck specifies the prerequisite check action.

• --repo specifies the location of the compressed ISO file containing the update repository. If you specify a compressed ISO file, the file path must be accessible on the node running the updating utility. Alternatively, you can provide a URL to a YUM repository.

• --target_version specifies the target release the database servers are being updated to.