The Oracle Exadata plug-in provides a consolidated view of the Exadata Database Machine within Oracle Enterprise Manager, including a consolidated view of all the hardware components and their physical location with indications of status. Oracle recently released the latest version of Exadata plug-in 18.104.22.168.0 which include verity of new features and bug fixes. But the feature which caught my attention was that it supports additional patching features for Exadata entire stack. Exadata plug-in 22.214.171.124.0 support following additional patching features to enhance Exadata patching effort:
– A comprehensive overview of the maintenance status and needs.
– Proactive patch recommendations for the quarterly full stack patches.
– Supports auto patch download, ability to patch either in rolling or non-rolling modes.
– Ability to schedule runs.
– Proactive notification of the status updates.
– Granular step-level status tracking with real-time updates.
– Log monitoring and aggregation, supporting the quick filing of support issues with pre-packaged log dumps
Even though Oracle Offers free Exadata patching to their Exadata customers under Oracle Platinum Services, you might still end up applying patches to your Exadata Machine for many reasons. There can be a compliance issue or scheduling problem which may prevent you from using Oracle Platinum Service to patch your Exadata systems. Remember, Oracle needs Minimum 8-12 weeks prior notice before customer wants to be patched and might not work for you. So if you are one of those lucky Exadata Machine Admin planning to apply patches to your Exadata systems, here are some guidelines for safely completing patching task with minimum risks.
- You must carefully review the patch readme file and familiarize yourself with known issues and rollback options.
- Create a detailed workbook to Patch Exadata Machine including rollback option.
- Find Test system in your organization mimicking production system in terms of capacity and software version.
- Run Exachk utility before you start applying the patch to establish a baseline. Additionally, fix any major issues you see in the Exadata Health Check report.
- Reboot your Exadata Machine before you start applying the patch.
- Make sure you have enough Storage on all the mounts affected by the patch.
- Backup everything, I mean everything. Backup all the databases and storage mount holding software binaries.
- Apply the patch on a test system and document each step in a workbook to deploy patches for rest of the Exadata systems.
- Run Exachk utility after the successful patch application and compare its baseline Exachk report.
- Reboot Exadata Machine after deploying the patch to make sure there will not be issues with future Exadata Reboots.
- Verify all the Exadata Software and Hardware components InfiniBand, Storage Cells and Compute nodes.
- Move to applying the patch to Production systems, after successful patching exercise.
Oracle Exadata patches can be applied in rolling manner while the database remains online and available, or non-rolling manner where the databases are shutdown. The number of patches needs to be applied will be the same if you chose rolling or non-rolling patches but usually rolling patches takes longer to complete. Let me briefly describe following 2 different patches methods.
Rolling patching method don’t required application downtime. Most of the components can be patched while databases are running requiring little or no downtime compared to non-rolling patches but the overall length of time to complete the rolling patches is longer. It is best to use rolling patches if your disk groups are configured with high redundancy.
Non-rolling patching can be done with minimum time if planned properly. Non-rolling patches are applied while the database is offline and unavailable. This typically means that all applications serviced by Exadata Database Machine are moved to a standby system or are unavailable for the duration of the update. Non-rolling method is typically faster than rolling method for overall maintenance time because multiple systems are updated in parallel, but there may be a longer outage to the application.
If multiple components will be updated in the same maintenance window, it is possible to use a combination of rolling and non-rolling methods to achieve the desired balance of application downtime and maintenance time. One typical combination used when an application does not handle connection disruption efficiently is to apply Exadata Storage Server patches in a rolling manner, and Grid Infrastructure and Database, and Exadata Database Server patches in a non-rolling manner.
Whatever method you choose to patch Exadata machine, make sure to follow below guidelines to minimize your risk.
- Create a detail patching plan
- Patch your non production system first
- Make sure to backup databases, Oracle home and configuration files
- Use same patching method for all