Skip to main content
Broadpin

Autoupgrade E-Business Suite 12.2 to Exascale - Part 1 Overview

Introduction to Exascale on Shared Infrastructure and its New Certification for E-Business Suite

The landscape of #Oracle E-Business Suite (#EBS) hosting is shifting dramatically with the recent announcement that EBS 12.2 is now officially certified on Oracle #Exascale Infrastructure with Oracle Databases 26ai and 19c.

Traditionally, virtual machines like the VM.Standard.E6.Flex shape provided a solid foundation, but they required manual intervention and sizing estimates that often led to over-provisioning. Oracle Exascale on shared infrastructure completely reimagines this paradigm. It provides the extreme performance of Exadata with unparalleled (auto)scaling capabilities, allowing your database and application tiers to flexibly adjust to varying loads without missing a beat.

I recently went through the journey of upgrading an E-Business Suite 19c Database with one of our Broadpin customers which was already running on OCI (Database on Compute) to 26ai and "in a single shot" also did the migration to a 2-node Exascale environment. The overall procedure was (surprisingly) smooth given that the combination is only certified for roughly a month.

Simplified overall Architecture; Basis as of oracle.com

Blog Structure

This is a 4 parts series of blog posts with the following sections:

If you are planning this migration, the community and Oracle Support have provided excellent foundational materials. Before embarking on the journey, we highly recommend reviewing the following references which guided our process:

Pricing components of Exadata on Exascale Infrastructure

When looking at the OCI cost estimator you see, that Exascale has basically 4 pricing components:

In detail you have to pay for the following components:

  • for the Exascale Compute Infrastructure (which defines the total ECPU available as well as the amount of memory). In above scenario there are 2x32=64 ECPU available

  • for the File Storage for the Database Software. This is needed "per node", so in above scenario you'll pay for 2*280GB=560GB of storage

  • For the "Smart DB Storage" containing your actual database. In above example this is a 3 TB database. Obviously this is shared across all nodes. And the nice thing is that you can increase it dynamically to any level.

  • For the actual database ECPUs. This may be BYOL or (especially interesting for dynamic scenarios as described in the last part of the blog) include the database license and support.

Note: The ECPUs can not be different accross different nodes of your cluster. So any resizing change has an impact on all cluster nodes. This is true both for the VM and the Database ECPUs.

Setup of Exascale infrastructure

For an example migration I started with a two node environment as follows:

Basic creation of a 26ai Exascale VM Cluster

In my case the new exascale VMs where connected to the same Database subnet that was also used by my source environment.

After an upgrade of the Exadata OS Image (which took roughly an hour):

Upgrading the Exadata OS Image

I was then easily able to provision an 26ai Database into my new VM Cluster:

Provisioning new Container Database

Note: The PDB created here will be immediately dropped again anyways, so feel free to name it "DUMMYPDB".

Summary

This concludes the first part of my blog series. As you've seen you can provision an empty CDB on Exascale Infrastructure within a couple of hours.

In the next part, we will dive into the technical details of relocating our Pluggable Database (PDB) using Oracle Autoupgrade.