If you manage Oracle databases on Oracle Cloud Infrastructure (OCI), you've probably received Oracle's notification about upgrading your Base Database Service from Oracle Linux 7 (OL7) to Oracle Linux 8 (OL8). This upgrade is required because Oracle Linux 7 is approaching End of Life (EOL), meaning it will no longer receive security patches and critical updates. In this guide, we'll walk through the complete Oracle Linux 8 upgrade process for OCI DB Systems, including prerequisites, prechecks, downtime, rollback options, Data Guard considerations, and post-upgrade validation.
This post breaks down what that email actually means, what's involved in the upgrade, and how to approach it methodically so you avoid surprises in production.
Why Am I Getting This Email?
Oracle Linux 7 on Base Database Service is nearing its end of life. Once a platform version reaches EOL, it stops receiving security patches and critical fixes, which makes staying on it a growing operational risk rather than a stable, "if it ain't broke" decision. Oracle's notification is essentially an early warning: your DB system is running on OL6 or OL7, and it's time to start planning the move to OL8 before support runs out.
It's worth separating two related but distinct upgrade paths that Oracle bundles under this umbrella:
- Operating System (OS) Upgrade — moving the DB system's compute layer from OL6/OL7 to OL8.
- Grid Infrastructure (GI) / Database Upgrade — moving Grid Infrastructure to a newer supported version (e.g., 19c, and subsequently up to 26ai), which has its own OS-version dependency.
Understanding which one (or both) applies to your environment is the first step in planning the work.
Prerequisites Before You Touch Anything
Before initiating any upgrade activity on a production DB system, make sure the following boxes are checked:
- OS eligibility: Your DB system must currently be on OL6 or OL7 to be eligible for the OS upgrade path to OL8.
- Full standalone backup: Oracle strongly recommends taking a complete, standalone backup of the database before starting. Don't rely solely on automatic backups scheduled mid-upgrade — take a deliberate, verified backup first.
- IAM policy access: Confirm you (or your operating group) have the correct OCI IAM policy permissions to manage database resources. If you hit a permissions error, it usually means the policy scoping your compartment access needs a review by an administrator.
- Maintenance window: DB system upgrades involve downtime, even on RAC configurations. This is not a zero-downtime operation, so it needs to be scheduled and communicated like any other planned maintenance.
- Data Guard considerations: If your database participates in a Data Guard configuration, the upgrade can only be performed on the standby — never the primary directly. It's also advisable to switch the Data Guard protection mode to "Maximum Performance" before starting, to avoid a
NET_TIMEOUTon the primary. You can switch back to "Maximum Availability" once the upgrade is complete. - Networking hygiene: Avoid launching new compute instances in the DB system's subnet during the upgrade window. There's a brief interval where private IPs and hostnames are temporarily released, and a stray instance could grab that IP and stall the process.
What Actually Happens Under the Hood
It helps to know that this isn't an in-place patch — it's closer to a controlled replacement:
- The upgrade process provisions a new compute instance and clones the existing data disks onto it.
- Private IPs and hostnames carry over to the new instance, so internal connectivity and DNS records generally remain unaffected.
- Ephemeral public IPs do not carry over — expect a new public IP after the upgrade, and update any external-facing configurations accordingly.
- All OS-level customizations are wiped. Any manually installed packages, custom users, groups, cron jobs, or configuration tweaks on the OS layer will not survive the upgrade and must be reapplied afterward.
- All Clusterware customizations (beyond the database and services) are also removed, since the GI stack is reinstalled. Extra virtual IPs, custom services, and similar Clusterware-level changes need to be reconfigured post-upgrade.
This is the part most teams underestimate — treat this like a rebuild from a configuration-management perspective, not a simple reboot-and-patch.
Step 1: Database Upgrade Considerations
Depending on your current database version, the upgrade path may involve moving the database itself before or alongside the OS/GI upgrade:
- Databases on versions earlier than 19.21 or 21.12 will continue to be associated with OL7 environments (including scenarios like restoring from backup or creating a Data Guard standby).
- From 19.21 / 21.12 onwards, new DB systems are always provisioned on OL8 — regardless of the OS version on the source system.
- If your organization has a specific reason to remain on OL7 with a recent patch level, you'd need to launch with an older database version and apply the update afterward, since newer database versions force an OL8 provisioning.
This dependency between database version and OS version is important to map out early, especially if you're standardizing multiple DB systems across environments (dev, test, prod) that may currently be on different patch levels.
Step 2: OS Upgrade Procedure (OL7/OL6 → OL8)
Once prerequisites are confirmed and a backup is in hand, the OS upgrade itself follows a structured flow through the OCI Console:
- Navigate to the DB system you intend to upgrade from the DB Systems list page.
- Open the Updates (OS) tab on the DB System details page to view available OS upgrades.
- From the Actions menu for the relevant upgrade, you have three options:
- View details — see the upgrade description, target version, and last precheck status.
- Precheck — validate prerequisites before committing to the upgrade. Always run this first.
- Apply OS Update — execute the actual upgrade.
While the upgrade is in progress, the DB system's state will show as Updating, and lifecycle operations may be temporarily unavailable. Once complete, the state changes to Applied, and the system status returns to Available.
A couple of important callouts here:
- On a single-node DB system, expect downtime for the duration of the OS upgrade.
- Any OS-level customizations (extra users, groups, configs) will need to be manually reapplied afterward — they are not preserved.
Step 3: Grid Infrastructure Upgrade
If your DB system also requires a GI upgrade (for example, moving from 19c/21c toward 26ai, or from an earlier version up to 19c as an interim step), the process mirrors the OS upgrade flow:
- On the DB system's details page, go to the Updates (GI) tab.
- From the Actions menu, choose:
- View details
- Precheck
- Apply update
Note the version dependency here: to upgrade GI to 26ai, the DB system must already be on OL8. To upgrade GI to 19c, the system can still be on OL6 or OL7. In other words, your OS upgrade path may be a hard prerequisite for your GI upgrade path — plan the sequence accordingly rather than assuming they're independent tracks.
Handling Failures: Roll Forward vs. Roll Back
Not every upgrade completes cleanly on the first attempt, and Oracle provides two recovery mechanisms depending on the failure point:
- Roll Forward: Applicable when the OS and GI upgrade themselves succeeded, but something downstream failed — such as database registration or database startup. Oracle Support can help roll the process forward from that point rather than starting over.
- Roll Back: If the upgrade fails earlier in the process, a rollback reverts the DB system to its pre-upgrade state. Keep in mind that any public IPs assigned during the failed attempt cannot be reclaimed, and all changes made during/after the failed upgrade are lost. You can retry the upgrade once the root cause is identified and resolved.
To check status or initiate a rollback, use the Update History tab on the DB system's details page — failed upgrades surface an alert banner there with a Rollback option.
Post-Upgrade Checklist
Once the upgrade reports success, don't consider the job done just yet. Run through this checklist:
- ✅ Re-enable automatic backups if you had disabled them before the upgrade (the process disables/re-enables them automatically, but it's worth confirming).
- ✅ Reapply OS customizations — additional users, groups, packages, monitoring agents, or configuration files that existed pre-upgrade.
- ✅ Reapply Clusterware customizations — additional services, virtual IPs, or other GI-level configurations.
- ✅ Update external references to public IPs, since ephemeral public IPs change post-upgrade.
- ✅ Restore Data Guard protection mode to "Maximum Availability" if you had switched it to "Maximum Performance" before the upgrade.
- ✅ Validate application connectivity end-to-end, not just database availability, since downstream systems may reference the old public IP or hostname configuration.
Frequently Asked Questions (FAQs)
Does upgrading to Oracle Linux 8 cause downtime?
Yes. Oracle Linux 8 upgrades on OCI Base Database Service require downtime, including RAC environments. Plan a suitable maintenance window before starting.
Will my private IP address change after the upgrade?
No. OCI migrates the existing private IP address and hostname to the newly provisioned compute instance.
Will my public IP address remain the same?
No. Ephemeral public IP addresses are replaced after the operating system upgrade.
Are custom OS configurations preserved?
No. Any manually installed packages, cron jobs, users, groups, monitoring agents, and configuration changes must be reapplied after the upgrade.
Can I upgrade the primary database in a Data Guard configuration?
No. Oracle recommends upgrading the standby database first.
Can I rollback the Oracle Linux 8 upgrade?
Yes. Depending on where the upgrade fails, Oracle provides rollback or roll-forward options through Update History.
- ✔ Oracle Linux 7 is reaching End of Life.
- ✔ Plan downtime before starting the upgrade.
- ✔ Run the OCI precheck first.
- ✔ Take a verified standalone backup.
- ✔ Reapply OS and Clusterware customizations after the upgrade.
- ✔ Validate application connectivity before handing the system back to users.
Final Thoughts
The emails Oracle is sending out aren't just administrative noise — they reflect a genuine platform lifecycle transition that, if ignored, leaves your database infrastructure running on an unsupported OS with no further security patches. The good news is that Oracle has built a fairly guided, console-driven upgrade workflow, complete with prechecks, rollback safety nets, and clear status visibility at every stage.
The keys to a smooth upgrade come down to three things: plan your maintenance window with real downtime in mind, back up before you start, and budget time after the upgrade to reapply every OS and Clusterware customization that the process will strip away. Treat it less like a patch and more like a mini-migration, and it will go a lot more smoothly.
For the complete, authoritative procedure and any updates Oracle makes over time, refer to the official documentation: Upgrade a DB System – Oracle Help Center