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.

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.

🕵️ 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.

View	Answers
SESSION_PRIVS	What can this session actually do?
DBA_SYS_PRIVS	What system privileges are granted directly to the user?
DBA_ROLE_PRIVS	Which roles are granted to the user?
ROLE_SYS_PRIVS	What 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.

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.