Red Hat Enterprise Linux on OCI: A New Option for Licensing, Deployment, and Support

Oracle Cloud Infrastructure (OCI) has introduced a new option for deploying Red Hat Enterprise Linux (RHEL) directly through its cloud platform. Announced on October 19, 2026, this enhancement allows customers to purchase RHEL through OCI rather than relying exclusively on their existing Red Hat subscriptions.

For Linux administrators, cloud architects, and infrastructure teams, this provides greater flexibility when planning operating system deployments, managing subscriptions, and defining support responsibilities.

Let's explore what has changed and what administrators should know before using this option.

1. What Is New?

Previously, customers could run RHEL on OCI using the Bring Your Own Subscription (BYOS) model, where they continued to use their existing Red Hat subscriptions.

With the introduction of OCI-provided RHEL platform images, customers now have another choice: purchase RHEL directly through OCI and use Oracle Universal Credits to pay for RHEL usage.

The new approach integrates operating system image selection, purchasing, software updates, and support into the OCI environment.

Customers can select these platform images through the OCI Console, command-line interface (CLI), or API.

One important point: RHEL usage charges are additional to the cost of OCI infrastructure. Customers should therefore evaluate the combined cost of the operating system and the underlying compute resources when planning their deployments.

2. OCI-Provided RHEL vs. Bring Your Own Subscription

Customers can choose between two approaches based on their existing licensing arrangements and operational requirements.

OCI-Provided RHEL

With this option, customers select an OCI-provided RHEL platform image and pay for RHEL usage through Oracle Universal Credits.

Software packages and updates are available through OCI-hosted Red Hat Update Infrastructure (RHUI).

Oracle provides Tier 1 and Tier 2 support for installation, configuration, usage, and troubleshooting. When deeper investigation or a Red Hat fix is required, Oracle coordinates with Red Hat.

Bring Your Own Subscription (BYOS)

Customers who already have Red Hat subscriptions can continue using the BYOS model.

Under this approach, RHEL licensing and operating system support remain with Red Hat under the existing subscription, while Oracle continues to support the OCI infrastructure.

The right choice depends on your organization's licensing arrangements, support requirements, and purchasing preferences.

3. Which RHEL Versions Are Available?

At launch, OCI-provided RHEL platform images are available for:

  • RHEL 9.8

  • RHEL 10.2

These images are supported on selected x86 virtual machine shapes, including:

Standard Flex shapes

  • VM.Standard3.Flex

  • VM.Standard.E4.Flex

  • VM.Standard.E5.Flex

  • VM.Standard.E6.Flex

Dense I/O shapes

  • VM.DenseIO.E4.Flex

  • VM.DenseIO.E5.Flex

The initial availability covers OCI commercial regions (OC1).

Oracle plans to expand the portfolio with additional RHEL versions and compute configurations as they complete certification. Availability is also planned for Oracle Alloy and OCI Dedicated Region (DRCC).

Before provisioning a server, verify that the required RHEL version and compute shape are available in your target region.

4. How Are Software Updates Managed?

OCI-provided RHEL platform images are configured to connect to OCI-hosted regional Red Hat Update Infrastructure (RHUI).

RHUI synchronizes RHEL software content from Red Hat, enabling administrators to install available packages and apply operating system updates.


5. Understanding the Support Model

Support arrangements differ between OCI-provided RHEL and BYOS deployments.

For OCI-provided RHEL, Oracle provides Tier 1 and Tier 2 support covering installation, configuration, usage, and troubleshooting. If an issue requires deeper investigation or a fix from Red Hat, Oracle works with Red Hat while the customer continues to engage Oracle Support.

For BYOS deployments, Red Hat continues to handle RHEL licensing and operating system support under the customer's existing subscription. Oracle remains responsible for OCI infrastructure support.

Infrastructure teams should account for these responsibilities when defining incident escalation procedures, operational runbooks, and support agreements.

6. How to Launch an OCI-Provided RHEL Instance

Administrators can provision an instance directly through the OCI Console.

Follow these steps:

  1. Sign in to the OCI Console.

  2. Navigate to Compute → Instances.

  3. Select Create instance.

  4. Under Image and shape, choose Change image.

  5. Select Red Hat Enterprise Linux and the required version.

  6. Choose a supported compute shape.

  7. Configure the remaining instance settings.

  8. Create the instance.

For automated deployments, administrators can also use the OCI CLI or the OCI API.

Refer to the official OCI documentation for the latest image availability, supported configurations, and instance creation procedures.

7. What Should Linux and OCI Administrators Consider?

Before adopting OCI-provided RHEL, administrators should review the following areas:

Licensing and cost: Compare the OCI-provided purchasing model with your existing Red Hat subscriptions. Include both operating system usage charges and OCI infrastructure costs in the evaluation.

Regional availability: Confirm that the required image and compute shape are available in your target OCI region.

Operating system updates: Understand how RHUI is configured and incorporate package updates into your regular maintenance schedule.

Support and escalation: Document whether the operating system is covered through OCI-provided RHEL or BYOS, and align incident escalation procedures accordingly.

Automation: If you use infrastructure-as-code, OCI CLI scripts, or API-driven provisioning, evaluate how the selected RHEL image fits into your existing deployment workflows.

Standardization: Review the supported RHEL versions and image release notes before defining a standard operating system image for new deployments.

Conclusion

The introduction of OCI-provided RHEL platform images gives customers an additional way to deploy and manage Red Hat Enterprise Linux on Oracle Cloud Infrastructure.

Organizations can continue using their existing Red Hat subscriptions through BYOS or choose the integrated OCI purchasing and support model.

For infrastructure teams, the key is to evaluate licensing costs, image availability, update management, and support responsibilities before selecting the deployment approach.

As OCI expands the available RHEL versions and compute configurations, this option provides another choice for organizations standardizing their Linux workloads on Oracle Cloud Infrastructure.


at No comments:

EBS Customer – How to Plan for Expanded OCI Database Release Update Choices

Have you ever had to adjust your database patching or provisioning plans because the required database release was not available for selection in OCI?

On October 14, 2026, Oracle announced expanded software release update selection options for Oracle Database cloud services. This change provides greater flexibility to select older releases during supported lifecycle operations, while the latest available release remains the default and recommended option.

This announcement updates Oracle's June 2026 guidance on OCI Database software image availability for EBS customers. It introduces additional options when planning database provisioning, patching, migrations, and business continuity activities.

What Has Changed?

Where release selection is supported, Oracle generally provides the following options:

  • Latest available release (N): The default and recommended option.

  • Two preceding releases (N-1 and N-2): Available through self-service acknowledgment.

  • Earlier releases: Require an approved Service Request (SR), subject to applicable release limits.

The updated policy covers supported lifecycle operations for the following OCI database services:

  • Oracle Base Database Service

  • Oracle Exadata Database Service on Dedicated Infrastructure

  • Oracle Exadata Database Service on Exascale Infrastructure

  • Oracle Exadata Database Service on Cloud@Customer

Why Does This Matter to EBS Customers?

EBS environments often require coordinated testing, maintenance planning, and change management before database changes can be implemented in production.

For example, your project may require additional time to complete application testing and obtain production approval. The expanded release selection options provide greater flexibility to align database provisioning and patching with project timelines, provided the required release remains available under Oracle's policy.

However, release availability does not automatically mean that the database release is certified for your EBS environment. Always verify the applicable EBS certification and procedural requirements before proceeding.

Need an Earlier Database Release?

Although Oracle has expanded the available choices, certain restrictions still apply to older releases:

  • Oracle Database 19c: Approved exceptions are limited to release 19.25 or later. These exceptions enable the creation of a custom database software image for provisioning or updates.

  • Grid Infrastructure (GI): Releases earlier than N-2 are unavailable.

  • Exadata System Software: Exceptions are limited to the six most recent monthly maintenance releases within the active release.

  • Older custom images: Their selection is subject to additional controls.

If your project requires an older database release, review the applicable restrictions and exception requirements before raising a Service Request.

Key takeaway: Oracle's expanded release selection options provide EBS customers with greater flexibility in planning database lifecycle activities. Before provisioning or patching, verify release availability, EBS certification, and the applicable Oracle requirements to ensure that your database changes align with project needs.

at No comments:

Oracle Linux lastboot: A Quick Way to Investigate Unexpected Reboots



An unexpected server reboot can be difficult to investigate, especially when the system is already back online. By the time an administrator starts checking the issue, important logs or information about what happened before the reboot may no longer be easy to correlate.

Oracle Linux Enhanced Diagnostics provides the oled lastboot tool to help with this situation.

What is oled lastboot?

lastboot is part of the oled-tools package. It installs a small systemd service that runs once during every boot.

Its purpose is simple:

  • Check what happened during the previous boot.

  • Determine whether the reboot was graceful or unexpected.

  • Check whether the unexpected reboot appears to be related to a kernel crash.

  • Generate a report that can be reviewed after the server comes back online.

  • For abnormal reboots, optionally collect additional information using hooks.

This is particularly useful when a server unexpectedly restarts and you need to start the investigation after the system has recovered.

Enable lastboot

After installing the required oled-tools package, enable the service:

# oled lastboot enable

Check its status:

# oled lastboot status

The service runs during boot and then exits. It is not a continuously running background process.

The generated reports are stored under:

/var/oled/lastboot-report/

You can also check the service activity using:

# journalctl -u oled_lastboot_report.service -b

How does it identify the previous reboot?

lastboot checks recent reboot and shutdown records from wtmp.

If a shutdown record exists before the reboot, the previous reboot is classified as:

Graceful reboot

If a reboot record exists without a matching shutdown record, it is classified as:

Unexpected reboot

This distinction is important because an unexpected reboot could have several causes, including power loss, host reset, kernel panic, or another failure path.

How does it detect a possible kernel crash?

For an unexpected reboot, lastboot looks for a vmcore file in the configured kdump location.

It reads the path setting from:

/etc/kdump.conf

It also checks:

/var/crash
/var/oled/crash

If a recent vmcore is found within the defined crash-detection window, the event is reported as:

Kernel crash

The report also provides recommended follow-up actions, such as collecting the vmcore, an sosreport, PCP data and console or serial logs when available.

The most useful command for an administrator

Once the server is back online, start with:

# oled lastboot report

The report provides information such as:

  • Host name

  • Boot time

  • Time zone

  • Reboot status

  • Kernel crash status

  • Detected vmcore path

  • Recommended follow-up actions

The status gives you a quick indication of what happened:

Graceful reboot – A matching shutdown record was found.

Unexpected reboot – The previous boot did not have a matching graceful shutdown record.

Kernel crash – The reboot was unexpected and a recent vmcore was found.

Going beyond the basic report

For abnormal reboots, lastboot can also run administrator-defined hooks.

Hooks are executable scripts placed under:

/usr/libexec/oled-tools/lastboot-hooks.d/

These can collect environment-specific information such as logs, command output, sosreport, vmcore metadata or application-specific files.

The collected artifacts are stored under:

/var/oled/lastboot-artifacts/

The corresponding state information is stored under:

/var/lib/oled/lastboot/state/

The state file also records whether a hook completed successfully, failed, timed out or was skipped.

Why this is useful during an incident

For a junior or mid-level administrator, one of the challenges after an unexpected reboot is knowing where to start.

Instead of immediately going through multiple logs, oled lastboot provides a starting point:

# oled lastboot report

If the reboot was unexpected, you can then check:

# journalctl -u oled_lastboot_report.service -b

and review the generated report and any collected artifacts.

This helps preserve and organize information close to the time of the reboot, making the initial investigation more structured.

Key takeaway

oled lastboot is a useful Oracle Linux diagnostic tool to have enabled on systems where unexpected reboots need to be investigated.

The workflow is straightforward:

Enable → Reboot occurs → Server comes back → Review oled lastboot report → Investigate further if the reboot was abnormal.

For abnormal reboots, the tool can go further by running hooks, collecting environment-specific information and, when configured, uploading the collected artifacts.

For administrators responsible for Oracle Linux servers, knowing about lastboot can make the first few steps after an unexpected reboot much easier and more consistent.

at No comments:

Preparing Oracle E-Business Suite 12.2 for the Next Generation Technology Stack


As Oracle E-Business Suite 12.2 customers prepare for the Next Generation Technology Stack, one of the most important activities is to understand both the environment readiness and the existing customization footprint.

A useful starting point is the TSUA Readiness Check, which validates the EBS environment and, at the end of the process, gathers information about customizations.

TSUA Readiness Check

Oracle provides the p38474509_R12_GENERIC package for the TSUA readiness check.

One important point for EBS administrators:

This is not a patch that needs to be applied using OPatch or ADOP.

The package can simply be extracted, and the readiness check can be executed directly.

After extracting the package, run:

./tsua readiness

The command starts validating the EBS environment against the prerequisites required for the Next Generation Technology Stack.

The readiness process checks several important components of the environment, including the operating system, database, EBS patch levels, AD, TXK, ATG_PF and System Schema Migration status.

For example, the readiness output may identify issues such as:

ERRORMSG: OS release check.
Minimum OS release required is Oracle Linux 8.7.

ERRORMSG: Minimum Database version of 19.31 or 23.26.2 is required.

ERRORMSG: EBS CPU version check.
Minimum EBS CPU Version required is April 2026 (2026.04).

ERRORMSG: AD version check.
Minimum AD version required is delta.18.

ERRORMSG: TXK version check.
Minimum TXK version required is delta.18.

ERRORMSG: ATG_PF version check.
Minimum ATG_PF version required is Delta.14.

ERRORMSG: EBS System Schema Migration Completion Patch Check.
EBS System Schema Migration is not complete.

These messages provide a clear picture of what needs to be addressed before proceeding.

For example, the environment may need:

  • An operating system upgrade

  • Database patching

  • Application of the required EBS CPU

  • AD and TXK updates

  • ATG_PF updates

  • Completion of EBS System Schema Migration

The Important Part

The tsua readiness process does more than just validate the environment.

At the end of the readiness process, TSUA gathers information about EBS customizations and generates adcustlist.rpt.

This makes the same readiness exercise useful for both technology-stack prerequisite validation and customization discovery.

Understanding adcustlist.rpt

The adcustlist.rpt report provides visibility into the customization footprint of the EBS environment.

It categorizes the identified customizations into five sections:

SECTION-1: C Customizations
SECTION-2: Java Customizations
SECTION-3: Jsp Customizations
SECTION-4: Forms Customizations
SECTION-5: Reports Customizations

This is particularly valuable for long-running EBS environments where customizations may have accumulated over several years.


Recommended Preparation Steps

The next steps should focus on understanding the customization impact and preparing well before the production update.

Step 1 – Run the Next Gen Tech Stack Readiness Checker Now

Do not wait until the actual technology-stack migration window.

Run:

./tsua readiness

Review all readiness errors and identify the prerequisite updates required for your environment.

Step 2 – Build a Complete Customization Inventory

Build a complete inventory of your customizations and source code based on:

  • Your existing customization inventory

  • The information provided in adcustlist.rpt

This is particularly important for older EBS environments where customizations may have been developed by different teams over many years.

Step 3 – Review Technology-Specific Compatibility

Review the compatibility requirements for each technology area and identify dependencies on the Classic Technology Stack.

Pay particular attention to:

  • C customizations

  • Java customizations

  • JSP customizations

  • Forms customizations

  • Reports customizations

  • Third-party libraries and dependencies

Step 4 – Recompile, Remediate and Test

Before the production update, recompile and, where necessary, remediate and test your customizations.

The objective should be to complete as much of this work as possible before the Next Generation Technology Stack becomes the production platform.

Why Start Early?

Starting this work early gives you time to understand the actual scope of your customization changes.

Instead of discovering a compatibility issue during the production technology-stack update, you can identify it earlier, obtain the required source code, remediate the customization, and complete functional testing.

This can significantly reduce the amount of work remaining when the Next Generation Technology Stack becomes available.

Final Takeaway

The preparation can be summarised simply:

Run TSUA → Review Readiness → Review adcustlist.rpt → Inventory Customizations → Check Compatibility → Recompile/Remediate → Test → Prepare for Production

The important point is that technology-stack readiness is not only about checking Oracle components and patch levels.

Your customization readiness is equally important.

Start early, understand what you have, identify what needs to change, and complete the remediation and testing before the production update.

The more you prepare today, the fewer surprises you will have during the Next Generation Technology Stack transition.

at No comments:

🕵️ The Curious Case of the Read-Only User That Could Create Tables


In EBS, we often assume that a user named APPSRO is exactly what it sounds like—a read-only account. Recently, I came across an interesting privilege investigation that proved once again why assumptions and Oracle databases don't always agree.

What started as a simple privilege check turned into a deeper lesson on roles, effective privileges, and one subtle Oracle dictionary view that many DBAs overlook.

The Setup

The user was created with what appeared to be only read-related privileges.

CREATE USER APPSRO
DEFAULT TABLESPACE xxxx
TEMPORARY TABLESPACE TEMP;

GRANT CONNECT TO APPSRO;
GRANT RESOURCE TO APPSRO;
GRANT ADJ_SYS_VIEW_SELECT TO APPSRO;
GRANT ADJ_FULL_TAB_SELECT TO APPSRO;

GRANT UNLIMITED TABLESPACE TO APPSRO;
GRANT SELECT ANY TABLE TO APPSRO;
GRANT SELECT ANY SEQUENCE TO APPSRO;
GRANT SELECT ANY DICTIONARY TO APPSRO;
GRANT CREATE ANY SYNONYM TO APPSRO;
GRANT DEBUG CONNECT SESSION TO APPSRO;

Looking at these grants, the account appeared to be intended for read access.

Naturally, I expected the following statement to fail.

CREATE TABLE testread AS
SELECT *
FROM apps.some_table;

Instead...

Table created.

Wait...

How did a supposedly read-only user create a table?

First Suspect: Direct System Privileges

My first assumption was simple.

There must be a direct CREATE TABLE privilege.

So I checked:

SELECT privilege
FROM dba_sys_privs
WHERE grantee = 'APPSRO';

The output showed:

CREATE ANY SYNONYM
DEBUG CONNECT SESSION
SELECT ANY DICTIONARY
SELECT ANY SEQUENCE
SELECT ANY TABLE
UNLIMITED TABLESPACE

No CREATE TABLE.

To be absolutely certain:

SELECT *
FROM dba_sys_privs
WHERE grantee='APPSRO'
AND privilege='CREATE TABLE';

Result:

no rows selected

So the privilege wasn't granted directly.

Second Suspect: Roles

Maybe the privilege was inherited through a role.

Checking the assigned roles:

SELECT granted_role
FROM dba_role_privs
WHERE grantee='APPSRO';

Result:

RESOURCE
CONNECT
ADJ_SYS_VIEW_SELECT
ADJ_FULL_TAB_SELECT

The custom roles looked harmless.

That left one interesting candidate:

RESOURCE

The Plot Twist

To inspect what the RESOURCE role contained, I queried:

SELECT role,
       privilege
FROM role_sys_privs
WHERE role='RESOURCE';

The output immediately solved the mystery.

RESOURCE  CREATE CLUSTER
RESOURCE  CREATE INDEXTYPE
RESOURCE  CREATE OPERATOR
RESOURCE  CREATE PROCEDURE
RESOURCE  CREATE SEQUENCE
RESOURCE  CREATE TABLE
RESOURCE  CREATE TRIGGER
RESOURCE  CREATE TYPE

There it was.

CREATE TABLE.

The privilege wasn't granted directly to the user.

It was inherited through the RESOURCE role.

Session Privileges Never Lie

To confirm what Oracle actually allowed during the session:

SELECT privilege
FROM session_privs
ORDER BY privilege;

The output included:

CREATE TABLE
CREATE PROCEDURE
CREATE TRIGGER
CREATE TYPE

Even though DBA_SYS_PRIVS showed no direct grant, Oracle clearly allowed table creation because SESSION_PRIVS reflects the effective privileges available in the current session.

This is one of my favorite Oracle views during privilege investigations.

When someone asks,

"What can this user actually do?"

SESSION_PRIVS usually provides the quickest answer.

Why the CTAS Worked

When Oracle executed:

CREATE TABLE testread AS
SELECT *
FROM apps.some_table;

it validated three requirements.

✔ CREATE TABLE
(via the RESOURCE role)

✔ SELECT ANY TABLE
(to read the source table)

✔ UNLIMITED TABLESPACE
(to allocate storage)

Since all three conditions were satisfied, Oracle created the table successfully.

Bonus Discovery: ROLE_SYS_PRIVS Doesn't Show Every Role

While testing the solution, I revoked the RESOURCE role.

REVOKE RESOURCE FROM APPSRO;

Then I reran the same query:

SELECT role,
       privilege
FROM role_sys_privs
WHERE role='RESOURCE';

To my surprise, Oracle returned:

no rows selected

At first, I wondered whether someone had modified the RESOURCE role.

But then I revisited the Oracle documentation for ROLE_SYS_PRIVS.

It states:

Information is provided only about roles to which the user has access.

That small sentence explains everything.

Before the revoke:

  • APPSRO had access to the RESOURCE role.

  • ROLE_SYS_PRIVS displayed the role's privileges.

After the revoke:

  • APPSRO no longer had access to RESOURCE.

  • Oracle filtered the view.

  • The role still existed in DBA_ROLES, but ROLE_SYS_PRIVS no longer displayed its privileges.

This is a subtle behavior that's easy to overlook during privilege investigations.

The Bigger Lesson

This investigation wasn't really about CREATE TABLE.

It was about understanding where Oracle gets a user's privileges.

No single dictionary view tells the complete story.

Each answers a different question.

ViewAnswers
SESSION_PRIVSWhat can this session actually do?
DBA_SYS_PRIVSWhat system privileges are granted directly to the user?
DBA_ROLE_PRIVSWhich roles are granted to the user?
ROLE_SYS_PRIVSWhat system privileges are granted to roles that the current user can access?

Understanding the purpose of each view makes privilege troubleshooting much easier.

A Handy Diagnostic Checklist

Whenever I troubleshoot Oracle privilege issues, I usually start with these queries.

-- Current user
SHOW USER;

-- Effective session privileges
SELECT privilege
FROM session_privs
ORDER BY privilege;

-- Direct system privileges
SELECT *
FROM dba_sys_privs
WHERE grantee='APPSRO';

-- Granted roles
SELECT *
FROM dba_role_privs
WHERE grantee='APPSRO';

-- System privileges contained in accessible roles
SELECT role,
       privilege
FROM role_sys_privs
ORDER BY role, privilege;

These four queries answer almost every privilege-related question.

Final Takeaway

This investigation started with a simple question:

"Why can a read-only user create tables?"

The answer wasn't hidden in DBA_SYS_PRIVS.

It wasn't obvious from the user definition.

It was buried inside a role.

Along the way, I also learned something I hadn't paid much attention to before:

ROLE_SYS_PRIVS only shows the system privileges of roles that the current user can access.

That small detail completely explained why the view's output changed immediately after revoking the RESOURCE role.

Sometimes the most valuable lessons come not from solving the original problem, but from discovering how Oracle's privilege model really works.

And that's what makes troubleshooting so rewarding.

at No comments:

OCI Base Database Service: Boot Volume Backups Explained – What Every DBA Should Know

 When managing Oracle Base Database Service (DBCS) on Oracle Cloud Infrastructure (OCI), most DBAs focus on database backups, Recovery Manager (RMAN), and recovery strategies. However, one equally important component is often overlooked—the Boot Volume.

A common misconception is that a Boot Volume Backup protects the entire database environment. In reality, it only safeguards the operating system, while your database requires a completely different backup strategy.

This article explains what Boot Volume Backups are, what they protect, when they should be used, and when they are unnecessary.

What is a Boot Volume in OCI Base Database Service?

A Boot Volume is the operating system disk attached to your Base Database Service virtual machine. It is typically presented to the operating system as the sda device.

The boot volume contains:

  • Oracle Linux operating system

  • System libraries

  • Operating system configuration

  • Installed OS packages

  • Security agents and monitoring tools

  • Kernel and boot-related files

It does NOT contain:

  • Database data files

  • Redo logs

  • Control files

  • Fast Recovery Area (FRA)

  • Oracle Database Home binaries

Think of it this way:

Boot Volume = Operating System
Database Backup = Database

These are two separate layers, each requiring its own protection strategy.

Why Are Boot Volume Backups Important?

Boot Volume Backups provide a recovery point for the operating system. If the OS becomes unusable, the backup allows Oracle to restore the VM to a previously healthy state.

Typical scenarios include:

  • Operating system corruption

  • Failed kernel updates

  • Failed RPM installations

  • Accidental deletion of system files

  • Boot failures

  • OS instability after configuration changes

Instead of rebuilding the operating system from scratch, the boot volume can be restored to a known-good state, significantly reducing recovery time.

Do Boot Volume Backups Protect My Database?

No.

This is one of the biggest misconceptions.

A Boot Volume Backup protects only the operating system. It does not include any database content.

To protect your database, continue using:

  • Oracle-managed automatic database backups

  • Oracle-managed on-demand database backups

  • Customer-managed manual backups

If your objective is recovering database data, Boot Volume Backups are not the solution.

When Should You Consider a Boot Volume Backup?

Although Oracle automatically manages Boot Volume Backups for Base Database Service, it is useful to understand when having a recent backup is especially valuable.

Recommended before:

  • Operating system patching

  • Kernel updates

  • RPM package installations or updates

  • Network configuration changes

  • Firewall modifications

  • SSH configuration updates

  • Changes to sysctl.conf

  • Updates to limits.conf

  • Installing Vulnerability Scanners

  • Deploying EDR or Antivirus agents

  • Troubleshooting unstable operating systems

  • Major OS-level maintenance activities

Any change that affects the operating system layer increases the value of having a recent Boot Volume Backup.

When Is a Boot Volume Backup NOT Required?

Boot Volume Backups should not be considered a replacement for database backups.

They are unnecessary for activities such as:

  • Database parameter changes

  • Schema modifications

  • Application deployments

  • Tablespace operations

  • Data modifications

  • PL/SQL changes

  • Oracle Grid Infrastructure patching

  • Oracle Database Home patching

  • Database upgrades

  • DB System or node operating system upgrades (for example, Oracle Linux 7 to Oracle Linux 8)

These operations require proper database backup and recovery mechanisms instead.

Can Boot Volume Backups Help During Malware or Ransomware Incidents?

Yes—provided the compromise is limited to the operating system.

If malware or ransomware affects the OS layer, restoring from a clean Boot Volume Backup provides a faster recovery path compared to rebuilding the operating system.

It is important to remember that this does not recover encrypted or corrupted database files. Database recovery still depends on database backups.

Do Boot Volume Backups Help Meet Compliance Requirements?

Yes.

Many security and governance frameworks recommend maintaining recoverable operating system images to support disaster recovery and operational resilience.

Having recent Boot Volume Backups helps organizations demonstrate that operating system recovery procedures are in place.

How Frequently Are Boot Volume Backups Taken?

For OCI Base Database Service:

  • Automatic Boot Volume Backups are taken weekly.

  • Automatic backups are retained for 7 days.

Oracle manages this process automatically.

Can Customers Trigger a Boot Volume Backup?

Currently, No.

There is no customer-facing API or Console option to initiate an on-demand Boot Volume Backup for OCI Base Database Service.

If an immediate Boot Volume Backup is required, customers must raise a Service Request (SR) with Oracle Base Database Support.

What Is the Retention Period?

OCI Base Database Service currently follows these retention rules:

Backup TypeRetention
Automatic Boot Volume Backup7 Days
On-Demand Boot Volume BackupDoes not expire by default (Oracle typically requests a retention timeline)

A few important limitations:

  • Multiple ad hoc Boot Volume Backup copies are not supported.

  • Creating a new Boot Volume Backup for the same node replaces the previous one.

  • There is currently no option to retain on-demand Boot Volume Backups indefinitely.

Boot Volume Backup vs Database Backup

Boot Volume BackupDatabase Backup
Protects operating systemProtects database
Includes kernel and OS configurationIncludes data files
Includes installed agentsIncludes redo logs
Includes system packagesIncludes control files
Used for OS recoveryUsed for database recovery

Both are important—but they solve different recovery problems.

How Do Boot Volume Backups Help During Failed OS Changes?

Suppose an operating system update results in:

  • Kernel panic

  • Boot failure

  • Broken networking

  • Firewall misconfiguration

  • Security agent startup failures

  • Loss of SSH access

Instead of rebuilding the operating system manually, Oracle can restore the Boot Volume Backup, returning the VM to its previous working state.

This significantly reduces downtime during OS-related incidents.

Can Customers Restore a Boot Volume Themselves?

Currently, No.

OCI Base Database Service does not provide self-service Boot Volume restore functionality.

To perform a restore, customers must open a Service Request (SR) with Oracle Base Database Support.

Quick Reference




Final Thoughts

Boot Volume Backups are an essential part of the overall recovery strategy for OCI Base Database Service—but they serve a very specific purpose.

They are designed to protect the operating system, not the database.

Understanding this distinction helps DBAs make informed decisions during maintenance, troubleshooting, and disaster recovery planning.

The key takeaway is simple:

  • Use Boot Volume Backups to recover the operating system.

  • Use database backups to recover your database.

Together, these two layers provide comprehensive protection for your OCI Base Database Service environment.

at No comments:

Oracle E-Business Suite 12.2 Next Generation Technology Stack: Understanding the Special Online Patching Cycle

In my previous article, I introduced Oracle's 𝗡𝗘𝗫𝗧 𝗚𝗘𝗡𝗘𝗥𝗔𝗧𝗜𝗢𝗡 𝗧𝗘𝗖𝗛𝗡𝗢𝗟𝗢𝗚𝗬 𝗦𝗧𝗔𝗖𝗞 for Oracle E-Business Suite Release 12.2 and discussed the move to modern components such as WebLogic 14c, Oracle Fusion Middleware 14c, and Java 17.

While reviewing Oracle's documentation, I came across another interesting enhancement—not to the technology itself, but to the upgrade process.

Oracle has introduced a Special Online Patching Cycle that is used exclusively for upgrading to the Next Generation Technology Stack.

A Special Online Patching Cycle

It's important to clarify that Oracle has not changed the standard Online Patching (ADOP) cycle used for everyday patching and maintenance.

The familiar workflow remains:

Prepare → Apply → Finalize → Cutover → Cleanup

However, when upgrading from the Classic Technology Stack to the Next Generation Technology Stack, Oracle provides a dedicated online patching workflow.

In this special upgrade cycle, the traditional Apply phase is replaced by Technology Stack Update Assistant (TSUA).

The workflow becomes:

Prepare → TSUA → Finalize → Cutover → Cleanup → Synch

This workflow is designed specifically for the one-time migration to the Next Generation Technology Stack.

What is TSUA?

The Technology Stack Update Assistant (TSUA) is a new Oracle utility introduced specifically to simplify the migration from the Classic Technology Stack to the Next Generation Technology Stack.

Instead of using the standard Apply phase during this one-time migration, Oracle leverages TSUA as part of the Special Online Patching Cycle to automate and orchestrate the technology stack upgrade.

Behind the scenes, TSUA performs several critical tasks that would otherwise require significant manual effort, including:

  • Validates the environment by performing prerequisite checks and ensuring the system is ready for the upgrade.
  • Creates backups and installs the Next Generation Technology Stack software from the staged media.
  • Updates the application tier directory structure to align with the new technology stack.
  • Reconfigures the EBS middleware environment, including:
    • Updating the Oracle WebLogic Server (WLS) domain
    • Creating the Oracle HTTP Server (OHS) domain
    • Configuring the required Node Managers
  • Applies the migration patch along with any required co-requisite patches.
  • Regenerates Oracle Forms and Reports to ensure compatibility with the upgraded technology stack.

After TSUA completes successfully, the remaining online patching phases continue with:

  • Finalize
  • Cutover
  • Cleanup
  • Synch

Why Did Oracle Introduce This?

According to Oracle, this special online patching cycle is intended to make the technology stack migration:

  • Less disruptive
  • More streamlined
  • Capable of keeping users productive for most of the upgrade process
  • Simpler than performing a traditional EBS technology stack upgrade

Because the update leverages Online Patching, organizations can migrate to the Next Generation Technology Stack without requiring a major EBS upgrade.

Final Thoughts

One important point to remember is that TSUA does not replace the standard Apply phase for normal Oracle E-Business Suite patching.

Instead, it is part of a special online patching workflow introduced exclusively for migrating to the Next Generation Technology Stack.

This distinction is important for EBS administrators. Your regular ADOP patching process remains unchanged. TSUA comes into play only when performing the one-time transition from the Classic Technology Stack to Oracle's Next Generation Technology Stack.

As Oracle continues to modernize EBS 12.2, understanding this new upgrade workflow will help administrators plan and execute their technology stack migration with confidence.

at No comments:
Subscribe to: Posts (Atom)