How Nutanix Database Service Handles Oracle Database Patching: An Out-of-Place, Automated, and Reversible Workflow

Oracle patching carries operational risk. The traditional approach, manual in-place updates, leaves limited margin for error. One misstep in an Oracle software home can mean hours of unplanned downtime and a difficult root-cause conversation afterward.

For supported Oracle configurations, the Nutanix Database Service (NDB) solution  provides a documented workflow designed to help automate prerequisite validation, out-of-place software-home preparation, topology-aware orchestration, post-patch SQL processing, and supported recovery procedures. Execution time, administrator intervention, rollback options, and service availability depend on the Oracle version, NDB release, topology, workload, configuration, and operating environment.

This post gives an overview of how NDB patching works for supported Oracle configurations: the methodology behind it, how it handles different Oracle topologies, what happens when things don't go as planned, and how organizations managing large Oracle estates use maintenance windows to patch at fleet scale.

The Foundation: Out-of-Place Patching

A key architectural choice in NDB's patching design is one you might not notice at first glance: patching does not modify your existing Oracle software home in place.

Instead, NDB uses an out-of-place patching methodology. The new patched software is installed into a separate home directory. In supported configurations, the prior home is retained during the validation and cutover steps. Only after the new home is verified does NDB cut over.

Why does this matter?

• Isolated installation risk. Because the existing home is not modified during installation, the workflow is designed to help isolate installation failures from that home.
• Structured rollback. Because the prior home is retained, NDB can reverse completed steps in reverse order.
• Validation window. Both homes coexist temporarily, which gives you a chance to validate the new environment before cutover.
• For Oracle RAC clusters, NDB extends this with timestamp-based home naming (e.g., dbhome_<timestamp>). This lets old and new homes coexist across all nodes during a rolling update and helps avoid naming conflicts.

Before the First Step: The Pre-Patch Checklist

NDB runs an automated pre-patching validation sweep before patch-related changes are made. These checks are designed to surface common causes of mid-patch failures early.

Environment and Access

• Confirms the NDB user has the necessary sudo privileges for software installation.
• Validates that sshpass is installed across all nodes in a RAC cluster.
• Checks OraInventory health and consistency.
• Confirms the target database is up and in a healthy state before any changes begin.

Resource Thresholds

• At least 1 GB of available swap space and 1 GB of physical memory.
• At least 600 MB free in the NDB temp directory (configurable).
• Dynamic disk space calculation. NDB measures the actual size of the new software home, adds a safety buffer, and confirms the target mount point can hold it. This helps prevent a common "disk full" failure that can abort patch operations partway through.

Software and Version Sanity

• Confirms the target Software Profile Version is newer than the currently installed version, which guards against version-mismatch downgrades during patching.
• Checks that no database files are stored inside software homes, which guards against accidental data loss during home manipulation.
• For RAC, runs asmcmd showclusterstate to confirm the cluster is in a "Normal" state before proceeding.

Three Topologies, One Consistent Approach

Oracle environments come in different shapes. NDB handles each topology with a purpose-built workflow, but the underlying principles stay the same throughout: out-of-place installation, preserve the old home, and cut over cleanly.

Single Instance on File System

NDB performs an out-of-place swap of the Oracle home and preserves the database configuration end to end:

1. Time Machine is paused and software disks are mounted.
2. Pre-patch scripts are executed (your hooks for stopping agents, clearing caches, etc.).
3. The database is stopped on the old Oracle home.
4. The old home is detached and renamed, and the new software is copied to the original home path.
5. Configuration files are migrated from the old home to the new one.
6. The database is started on the new home.
7. datapatch runs, invalid objects are recompiled, post-scripts execute, and Time Machine resumes.

Single Instance with Oracle ASM

When Automatic Storage Management (ASM) is in play, the Oracle High Availability Service (HAS) and Grid home also need to be updated. NDB handles this with a structured two-phase approach:

1. Old Grid and Oracle Database homes are detached, renamed, and replaced.
2. The Grid home is unlocked and roothas.pl is executed in prepatch mode, then in postpatch mode with the patched Grid home as the destination. This migrates the HAS to the patched home.
3. Database configuration files are migrated and the database is started on the new home.
4. datapatch completes the SQL-level changes.

Oracle RAC: A Node-by-Node Rolling Workflow

For supported RAC configurations, NDB patches one node at a time. It is designed to let other healthy cluster nodes keep serving workloads, subject to cluster health, failover configuration, and application behavior.

Each node follows the same sequence:

1. The pre-patch script runs on the node.
2. The database instance is stopped with service failover. Where configured, Oracle Transparent Application Continuity (TAC) can help preserve eligible application sessions during the planned failover.
3. CRS patching: The Grid home is unlocked and rootcrs.pl runs in prepatch mode, then in postpatch mode, which brings CRS up on the new Grid home. DB home patching follows, after which the database starts on the new home so that postpatch executes against it directly.
4. DB home patching: Configuration files are copied, srvctl is updated to point to the new Oracle home, and listener entries are updated.
5. The database instance is started on the new home, and the post-patch script runs.
6. The process repeats for the next node.

Once all nodes are updated, datapatch runs once at the database level, not per node. This applies the SQL-layer changes after the cluster nodes have been updated, according to the documented workflow.

Design note: Running datapatch once at the end, rather than per node, is intended to provide a consistent point at which SQL-layer changes are applied across the cluster.

When Things Go Wrong: Rollback and Recovery

NDB includes documented recovery mechanisms for failures at supported points in the patching process.

• Step-by-step rollback. For supported operations, NDB tracks workflow steps and reverses completed changes in reverse order when a failure occurs.
• RAC failure containment. In a rolling RAC patch, a failure on one node triggers rollback of that node and any nodes already patched. The remaining unpatched nodes stay on the old software, which helps limit the scope of a node-level failure.
• datapatch warning state. If the software migration completes but datapatch fails, NDB flags the operation with a Warning rather than an Error. The software migration is complete and the database is running, but a DBA needs to run datapatch manually to complete the SQL-layer changes. This avoids treating a SQL-layer completion issue as a full software-migration failure.
• Manual revert. After a successful patch, administrators can revert to the previous Software Profile Version through the API and CLI. This operation is not exposed in the GUI, which reduces the chance of an accidental downgrade in production.

The Gold Image Workflow: Validating a Baseline Before Broader Deployment

Before NDB can patch anything, an administrator applies the required patches to a gold image VM outside of NDB. Once that image is validated, a new Software Profile Version is created from it. This version serves as the defined software baseline for supported patch operations.

After administrator validation, databases that patch from the same Software Profile Version can use that baseline, subject to supported configuration and successful execution.

One important note on gold image preparation: patch the gold image with Oracle's standard OPatch or OPatchAuto tooling on top of the existing Oracle home. Don't delete the home and reinstall a fresh copy. A delete-and-reinstall loses the OPatch inventory and patch history that NDB relies on, and the resulting Software Profile Version may not be usable for the documented patching workflow. Standard patch set upgrades preserve this lineage correctly.

Patching at Fleet Scale: Maintenance Windows

The workflows described so far apply to individual databases. For organizations managing large Oracle estates, coordinating those operations across dozens or hundreds of servers is a separate challenge. Maintenance windows are built for that.

A maintenance window is a named, reusable policy that defines when patching should happen and what it should cover. You set a weekly or monthly schedule and associate a set of database server VMs with it. Scheduled operations can then help reduce per-server coordination.

When associating servers with a window, administrators choose OS patching, database engine patching, or both. When both are selected, OS patching runs before database engine patching. For database engine patching, NDB checks whether a newer Software Profile Version is available and applies it. If the server is already current, the workflow skips it and records the resulting status. For cluster topologies like Oracle RAC, the same rolling approach applies: nodes are updated one at a time, and other healthy nodes are intended to remain available, subject to supported configuration, cluster health, application behavior, and failover conditions.

A maintenance window in NDB — "Oracle Patch Demo" — configured to run weekly on Mondays, with five Oracle database servers associated and ready for the next scheduled patch cycle.

Combined with the gold image workflow, maintenance windows provide a structured workflow for coordinating patching across a fleet: validate once, publish a Software Profile Version, and let scheduled windows propagate it consistently across the estate.

"Patching cycles decreased from 12 hours to 90 minutes."

Westgate Resorts operates 60 properties and runs a business-critical internally developed application across its entire estate.
After migrating to NDB, Angel Miranda, CIO at Westgate Resorts, noted: "Our partnership with Nutanix has been instrumental in helping Westgate succeed. We'll continue to leverage that relationship — not just to keep up but to drive innovation."

The Bottom Line

NDB's design is built around out-of-place installation, automated validation, topology-aware orchestration, and structured rollback. Maintenance windows extend that to the fleet, providing a way to coordinate patch levels across large Oracle estates with less per-server scheduling. The workflow is intended to support repeatable patching during scheduled maintenance windows, although duration and the need for administrator intervention may vary by environment.

Ready to simplify Oracle patching for your environment? Learn more about Nutanix Database Service at nutanix.com/ndb or sign up for a demo.