Autoupgrade E-Business Suite 12.2 to Exascale - Part 4 Scaling and Performance

To perform a trivial benchmark that highlights Exascale's storage offloading, we can run a full table scan against a massive transaction table (like OE_ORDER_LINES_ALL or XLA_AE_LINES in EBS) looking for a specific, unindexed value:

select sum(SHIPPED_QUANTITY) 
from oe_order_lines_all 
where ordered_item='2702';

On a standard E6.Flex VM, the database must pull every block of the table into the buffer cache to evaluate the WHERE clause. If that oe_order_lines_all table has roughly 38 million rows as in the environment of our Broadpin customer that took roughly 2 minutes for the first "such" query and then 75 seconds for a second execution to run.

Doing the same query on a (much smaller than the source environment) Exascale environment took only 40 seconds directly after starting the instance. A second run brought it down to a whopping 3.2 seconds; so a factor of 40 in performance improvements:

When scaling an exascale environment there are 3 basic options available:

1. Add or remove entire nodes to the cluster

2. Add "VM CPUs" to each node: This gives additional Memory, even if the new CPUs are not used for a database

3. Enable or Disable VMs for the Database

Those scaling operations have implications on the costs, the duration of scaling and (most importantly) on the availability of the instance. You may want to revisist the chapter "Pricing components of Exadata on Exascale Infrastructure" of the first part of this blog series first and to understand the pricing implications. Most notably is probably the downtime / availability aspect. If you scale the second (VM CPU) aspect of your environment this will involve a rolling VM reboot across all nodes of the cluster:

The easiest way to scale your environment is by "just" enabling and disabling the ECPUs for the database within the reserved capacity of your environment. Give that the Infrastructure of an ECPU is only 0.025$ per hour compared to 0.336$ for the database license and given that you probably still need the SGA/Memory in your VM even during low load phases it is definitely easiest to just scale the infrastructure for "maximum load" - eventually even on a single node. Then you can dynamically scale up- and down the database itself and pay just for the seconds you need this performance.

As you can see in the following screenshots this happens without interruptions and within seconds:

If you need to scale beyond those VM infrastructure limits but still need to keep your Application up and running the best way to do so for an E-Business Suite environment might be adding an additional RAC cluster node. Imagine you have high load during the 2 days around month end closing then you could put the relevant concurrent requests onto a dedicated Concurrent Manager Queue that prefers to use a special RAC service as described in KB858300. Then on the morning of the month end closing you scale your environment up by an additional node where you make sure that it only serves those requests. After the month end closing operations are finished you can bring up that additional node again - without having any downtime. Adding an additional node takes roughly an hour; and after the scaling operation you just have to make that node known to auto config.

As shown in this series of blog post the migration from a 19c "classical" Oracle Database on traditional hardware to exascale with 26ai is quite straight forward. Even when not using the various 26ai benefits of the database, the gain in both performance and scalability is immense. And this is compared with an E6.Flex AMD CPU which is also a factor of 2.5 faster than an average hardware that you might get from other hyperscalers as presented at last years Ascend event in another session. By moving to exascale and not to a dedicated exadata environment you can do this now even for relatively small environments. And you even get the dynamic scaling benefits there so that you only pay for what you need at this point in time.