8.5.2 Installing, Updating, and Managing Non-Oracle Software

Installing and updating non-Oracle branded RPMs on Oracle Exadata database servers are allowed as long as kernel and RDMA Network Fabric packages remain untouched.

Note that customizing the operating system by adding or updating packages may introduce problems when applying an Oracle Exadata System Software update because the non-Oracle software may add new dependencies which will not be provided by the Oracle Exadata System Software update. For this reason it is recommended to stay close to the Oracle Exadata image and customize as little as possible.

Note:

Oracle Exadata does not ship with 32-bit software. This means any customization that introduces 32-bit RPMs on the system will break the Oracle Exadata System Software update and will need to be removed.

In case you have added or updated packages supplied by the Oracle Exadata image, you can remove the exadata-sun-computenode-exact RPM when needed as follows:

[root@dm01 ]# rpm -e exadata-sun-computenode-exact

If you have installed customized packages, it is recommended that you have scripts to automate the removal (to run before updating Oracle Exadata System Software) and installation (to run after the Oracle Exadata System Software update) of those packages. After the Oracle Exadata System Software update, verify that the customized packages are still compatible and are still needed, before re-installing them.

Note:

Packages should not be forced in using the rpm -Uvh --nodeps command, unless directed by Oracle Support Services.

The same principle applies for customizations other than installation of additional software. Oracle recommends customizing the operating system as little as possible. Be aware that while changes on the database server are allowed within the earlier described boundaries, it is not possible for Oracle to anticipate each and every customization on every configuration item of the operating system.

There are certain common standards that Oracle Exadata utilities depend on. These standards are based on best practices and have been validated over time. By moving away from Oracle Exadata standards, systems might be missing optimal settings, and risk is introduced because it is difficult for Oracle to anticipate and validate software for one-off configurations. This is why customizations can cause unexpected results. As a result of adding software or customizing system configuration, you might require changes or additional steps to the standard Oracle Exadata update process. With or without customizations, it is highly recommended to validate Oracle Exadata System Software updates on test systems before doing them on production systems.