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 Type	Retention
Automatic Boot Volume Backup	7 Days
On-Demand Boot Volume Backup	Does 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 Backup	Database Backup
Protects operating system	Protects database
Includes kernel and OS configuration	Includes data files
Includes installed agents	Includes redo logs
Includes system packages	Includes control files
Used for OS recovery	Used 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.

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.

Why File Storage Service Matters in OCI: Understanding the Right Storage Choice for Shared Files

Introduction

One of the most common questions during OCI architecture discussions is:

"Why can't we simply use Object Storage or Block Volumes if applications need shared storage?"

At first glance, all storage services appear to solve the same problem: storing files and data. However, the way applications access those files makes a significant difference.

Many enterprise applications require multiple servers to access the same files simultaneously, including:

Oracle E-Business Suite environments
Web applications
Middleware platforms
Analytics solutions
Content management systems
Custom enterprise applications

These applications expect a traditional shared filesystem where files can be created, modified, and accessed concurrently by multiple servers.

        This is where OCI File Storage Service (FSS) becomes important.

        OCI FSS provides a shared, NFS-based filesystem that allows multiple compute instances
        to access the same files simultaneously without requiring application changes.

Storage Choice	Common Assumption	What Administrators Discover Later	Operational Impact
Object Storage Services	"It stores files and costs less, so it can replace shared storage."	Applications cannot use it like a regular Linux filesystem. File locking and directory operations are unavailable.	Application redesign or additional integration effort may be required.
Shared Block Volumes	"One volume can simply be attached everywhere."	Multiple servers writing simultaneously can damage the filesystem unless specialized clustering technology is used.	Data consistency risks and increased administration effort.
Instance-Local Storage	"Local disks provide the fastest access."	Data remains only on the local server and cannot be shared with other systems.	Potential data loss during instance replacement or termination.
Database-Based File Storage	"The database already exists, so documents can be stored there."	Large files increase database size, backup duration, and recovery complexity.	Higher database costs and reduced operational efficiency.
Self-Managed NFS Server	"Building our own file server is straightforward."	The NFS server becomes critical infrastructure requiring backups, patching, and monitoring.	Additional administration effort and possible single points of failure.
Object Storage Mount Utilities	"Mounting object storage makes it behave like a filesystem."	Applications may experience latency, inconsistent metadata, and compatibility issues.	Unpredictable behavior during heavy workloads.

Understanding the Oracle E-Business Suite 12.2 Technology Stack

Oracle E-Business Suite (EBS) is one of the most widely deployed enterprise applications across industries. Behind every EBS environment is a collection of technology components that work together to deliver business functionality, manage user requests, and communicate with the database tier. This collection of components is known as the Oracle E-Business Suite Application Technology Stack.

What is the EBS Application Technology Stack?

The Application Technology Stack consists of the software components installed on the EBS application tier. These components are responsible for processing business logic, serving web pages, running forms and reports, and enabling communication between end users and the database.

For Oracle E-Business Suite Release 12.2, the technology stack includes:

Oracle Fusion Middleware (FMW)
Oracle WebLogic Server (WLS)
Oracle HTTP Server (OHS)
Oracle Developer (Forms and Reports)
Java Development Kit (JDK)

Together, these components provide the foundation required to run EBS applications efficiently and securely.

The Classic Technology Stack

Since the release of EBS 12.2, most environments have been running on what Oracle refers to as the Classic Technology Stack. This stack is built on Oracle Fusion Middleware 11g and Java 7.

The certified component versions are:

Component	Certified Release
Oracle Fusion Middleware (FMW)	11.1.1.9
Oracle WebLogic Server (WLS)	10.3.6
Oracle HTTP Server (OHS)	11.1.1.9
Oracle Developer (Forms and Reports)	10.1.2
Java Development Kit (JDK)	7

For many years, this technology stack has provided a stable and reliable platform for Oracle E-Business Suite deployments worldwide.

The Next Generation Technology Stack

As technology evolves, Oracle is modernizing the EBS application tier with a newer and more secure technology foundation known as the Next Generation Technology Stack.

The planned certified releases include:

Component	Planned Certified Release
Oracle Fusion Middleware (FMW)	14.1.2
Oracle WebLogic Server (WLS)	14.1.2
Oracle HTTP Server (OHS)	14.1.2
Oracle Developer (Forms and Reports)	14.1.2
Java Development Kit (JDK)	17

This modernization introduces newer middleware and Java versions that align with current enterprise standards, helping organizations improve security, maintainability, and long-term supportability.

Why Does This Matter?

Many EBS customers continue to run mission-critical workloads on Release 12.2. Understanding the differences between the Classic and Next Generation Technology Stacks is important when planning upgrades, security initiatives, and future platform strategies.

Moving to the Next Generation Technology Stack provides organizations with:

Modern middleware architecture
Support for Java 17
Enhanced security capabilities
Improved compatibility with current infrastructure standards
Better long-term support from Oracle

What About Support for the Classic Technology Stack?

One of the most common questions among Oracle E-Business Suite administrators is whether upgrading to the Next Generation Technology Stack is mandatory.

The answer is yes—if organizations want to remain aligned with Oracle's long-term support strategy.

Oracle has indicated that EBS Release 12.2 production environments are expected to move to the Next Generation Technology Stack to ensure continued supportability in the future. Once the Next Generation Technology Stack becomes generally available, Oracle will publish a detailed support timeline outlining key milestones and support dates.

How Long Will the Classic Technology Stack Be Supported?

At the time of writing, Oracle has not announced an end date for error correction support for the Classic Technology Stack. However, Oracle has stated that an updated support roadmap will be provided following the general availability of the Next Generation Technology Stack.

For organizations currently running the Classic Technology Stack, this means there is no immediate deadline to migrate. However, IT teams should begin evaluating the impact of the upgrade, reviewing infrastructure requirements, and planning their modernization roadmap to avoid future support challenges.

Planning Ahead

While the Classic Technology Stack remains fully functional today, the introduction of the Next Generation Technology Stack signals Oracle's strategic direction for EBS 12.2. Organizations that proactively prepare for the transition will be better positioned to:

Maintain Oracle support eligibility
Benefit from newer middleware and Java technologies
Improve security and compliance posture
Reduce technical debt
Simplify future upgrades and maintenance

The move to the Next Generation Technology Stack should therefore be viewed not only as a technology upgrade, but as an important step in ensuring the long-term sustainability of Oracle E-Business Suite environments.

Final Thoughts

The Oracle E-Business Suite 12.2 Application Technology Stack is the foundation that powers the application tier of EBS environments. While the Classic Technology Stack has served organizations well for years, Oracle's Next Generation Technology Stack represents the future direction of EBS technology.

Organizations running EBS 12.2 should begin evaluating their technology stack roadmap and prepare for the transition to the newer platform to take advantage of modern security, performance, and support capabilities.

OCI Block Volume Enforcement Update: What Every OCI Customer Should Know Before Launching New Instances

Oracle has introduced an important enhancement to the way Oracle Corporation Cloud Infrastructure (OCI) validates Block Volume storage limits and quotas during Compute instance provisioning. While the update may appear operational in nature, it can directly impact infrastructure deployments if organizations are not prepared.

This change strengthens governance and capacity enforcement across OCI environments and ensures that storage consumption aligns with configured tenancy-level limits and compartment quotas.

What Has Changed?

Previously, when launching a Compute instance in OCI, the platform did not fully validate tenancy-level total_storage_gb limits and compartment quotas during the boot volume creation process.

As a result, certain instance launches could still succeed even if the configured storage thresholds had technically been exceeded.

With the latest OCI Block Volume service update, Oracle now enforces these validations before a boot volume is created during Compute instance provisioning.

If the requested boot volume size exceeds:

Tenancy-level Block Volume storage limits
Compartment-level storage quotas

the Compute instance launch will fail immediately with a quota or limit-related error.

This enhancement brings consistent enforcement behavior across OCI storage workflows and improves overall resource governance.

Why This Change Matters

In many OCI environments, administrators configure storage quotas and limits to:

Control cloud spending
Prevent uncontrolled resource growth
Segregate departmental resource usage
Enforce governance and compliance policies

Without strict validation during boot volume provisioning, there was a gap where deployments could unintentionally bypass those controls.

Oracle has now closed that gap.

For organizations using automation pipelines, Infrastructure-as-Code (IaC), Terraform, autoscaling, or dynamic provisioning, this update becomes especially critical because new deployments may unexpectedly fail if storage limits are not monitored properly.

What Is Impacted?

The enforcement applies only to workflows that create new boot volumes.

Affected Workflows

Launching new Compute instances
Autoscaling events that provision new instances
Automated deployment pipelines
Any workflow that creates new boot volumes

Not Affected

The following existing resources remain unaffected:

Existing boot volumes
Existing Block Volumes
Running Compute instances
Previously provisioned infrastructure

This means there is no disruption to currently running workloads.

Oracle’s Proactive Measures

To reduce operational impact, Oracle is proactively increasing capacity limits for affected tenancies where necessary before enabling strict enforcement.

This helps minimize unexpected failures for customers already operating close to their storage thresholds.

However, organizations should not rely solely on automatic adjustments and should independently review their storage configurations.

Strengthening Oracle Autonomous AI Database Security with Multi-Factor Authentication

As organizations continue moving mission-critical workloads to the cloud, database security has become more important than ever. Password-based authentication alone is no longer sufficient to protect sensitive enterprise data from evolving cyber threats. To address this challenge, Oracle Autonomous AI Database now supports Multi-Factor Authentication (MFA), providing an additional layer of protection for database access and SQL execution.

What is MFA in Autonomous AI Database?

Multi-Factor Authentication enhances database security by requiring users to verify their identity using two separate authentication factors:

Something the user knows — typically a username and password
Something the user has — such as a one-time token, authenticator app, push notification, or secure verification mechanism

With MFA enabled, even if database credentials are compromised, unauthorized access becomes significantly more difficult.

Key MFA Capabilities

Oracle Autonomous AI Database provides flexible MFA options designed for modern enterprise environments:

1. MFA for Database Logins

Administrators can enforce MFA during user authentication to ensure only verified users can establish database sessions.

2. MFA for SQL Access

Organizations can require additional verification before executing sensitive SQL operations, adding another layer of protection for critical workloads.

3. Multiple Verification Methods

Oracle supports different MFA delivery channels, including:

Email-based verification
Authenticator applications
Push notifications
Slack-based token delivery

This flexibility allows enterprises to align MFA with their operational and security standards.

How Oracle Implements MFA

Oracle provides the DBMS_MFA_ADMIN package to simplify MFA administration. Database administrators can:

Register users for MFA
Configure token delivery channels
Enable or disable MFA policies
Manage token attributes and session validation

This package enables centralized MFA governance while maintaining operational simplicity.

Why MFA Matters for Cloud Databases

Cloud databases are constantly exposed to risks such as:

Credential theft
Password reuse attacks
Unauthorized privileged access
Insider threats

By introducing MFA, organizations can significantly reduce the attack surface and strengthen compliance with modern security frameworks and regulatory standards.

For enterprises hosting critical ERP, financial, healthcare, or customer data in Oracle Autonomous AI Database, MFA becomes an essential component of a defense-in-depth security strategy.

Additional Security Benefits in Oracle AI Database

Oracle continues to strengthen its database security portfolio with features such as:

TLS 1.3 support
SQL Firewall
Enhanced auditing
Stronger password policies
Improved encryption capabilities
IAM integration for centralized access control

Optimizing OCI IAM Policies Across Compartment Hierarchies

Oracle Cloud Infrastructure (OCI) Identity and Access Management (IAM) enables organizations to securely control access to cloud resources. A critical aspect of IAM in OCI is how policies behave within a compartment hierarchy, particularly in large-scale enterprise environments.

As OCI deployments grow, managing IAM policies effectively becomes essential to ensure scalability, compliance, and operational efficiency.

Understanding Policy Evaluation in a Hierarchy

OCI evaluates IAM policies from the root compartment down through each level of the compartment structure. Every policy statement attached to the root or to intermediate compartments contributes to the total number of statements evaluated along a path from the root to a specific leaf compartment.

Key implications of this model include:

Policies defined at the root compartment apply broadly and affect all child compartments.
Policies defined in lower-level compartments impact only their respective branches.
OCI enforces a limit of 500 policy statements per compartment hierarchy path.

If the accumulated policy statements along a path exceed this limit, operations such as creating, updating, or deleting policies may fail.

Why Policy Limits Matter

As organizations introduce additional compartments to segregate workloads, teams often create policies independently to meet their operational needs. Over time, this leads to:

Redundant policy statements
Overlapping access grants
Excessively granular permissions
Increased administrative complexity

When the total evaluated statements exceed the allowed limit, policy changes can fail unexpectedly, impacting governance and agility.

Best Practices for Managing IAM Policies

To maintain a scalable and efficient IAM framework, consider the following structured approach:

1. Eliminate Redundant or Unused Policies

Review existing policies for overlapping permissions. For example:

Avoid defining both read and manage permissions separately when manage already includes read.
Consolidate multiple statements granting similar permissions to the same group.

Periodic cleanup significantly reduces policy statement count.

2. Define Policies at the Appropriate Compartment Level

Root-level policies affect every branch of the hierarchy. Where possible:

Move policies closer to the target compartments.
Restrict scope to the minimum required hierarchy path.

This reduces unnecessary inheritance and keeps the evaluation path efficient.

3. Consolidate and Simplify Policy Statements

Instead of writing multiple narrowly scoped permissions, use broader resource families where appropriate. For example:

Replace multiple individual resource permissions with a single family-level permission.
Standardize policy patterns across business units.

Simplification improves both maintainability and scalability.

4. Leverage Tag-Based Access Control

Attribute-based access control using defined tags can significantly reduce policy sprawl. By applying consistent tagging strategies:

Policies can reference tags instead of compartments.
Access can scale without creating additional compartment-specific statements.

This approach supports large, dynamic environments effectively.

Conclusion

IAM policy management in OCI is not merely a configuration activity — it is a governance discipline. Understanding how policies accumulate within a compartment hierarchy is crucial to preventing operational constraints.

By removing redundancy, scoping policies appropriately, simplifying statements, and leveraging tag-based access control, organizations can maintain a secure, scalable, and efficient IAM framework.

Proactive policy governance today prevents scalability challenges tomorrow.