ODyS on OCI - Oracle Dynamic Scaling (oh this is what I needed)

#oracle #oci #database #exadata

{ Abhilash Kumar Bhattaram : Follow on LinkedIn }

What is ODyS

ODyS is Oracle Dynamic Scalaing utility mainly used for Exadata (ExaDB-D/ExaDB-C@C) and also works with ExaCS with a plugin

Below is the master note on how this works

*(ODyS) Oracle Dynamic Scaling engine - Scale-up and Scale-down automation utility for OCI DB System (ExaDB-D/ExaDB-C@C) (Doc ID 2719916.1)

*

*(ODCC) Dynamic CPU Count - automation utility to change cpu_count dynamically (ExaDB-D/ExaDB-C@C) (Doc ID 2915837.1) *

Why is it needed ?

Compute costs on ExaCS are not cheap and Oracle has provided a utility to scalae up / down OCPU cores based on compute usage.

How it works

ODyS is a utility which when configures understands the CPU usage continuisly and it has a ability to scale up / down the OCPU cores based on a custom configuration.

Such a feature provides tremendous cost savings to customers who in a day have a few high peak loads and a low utilization for large periods of time.

Deciphering ODyS and ODCC

The MOS Documentation gives a clear representation of how this needs can be done , the purpose of this blogs is to show the detaisl on ODyS is not a complete product.

Both ODyS and ODCC seems to be literally a backported feature of Autonomous Database.

ODyS - Scale the Physical Cores
ODCC - Scale the Database settings Logically with Instance Caging

ODyS

ODyS has basically needs a one time configuration based on whats needed for your cluster in terms of rate of scale up / down

The dynamicscaling.bin is also a one time configuration for ODyS

./dynamicscaling.bin --db-system-id <DB system OCID> |--cloud-vm-cluster-id <cloud VM cluster OCID> |--vm-cluster-id <VM cluster OCID> --ociregion <DB System region> \
--tenancy-id <tenancy OCID> \
--user-id <user OCID> \
--keyfingerprint <user keyfingerprint> \
--privatekey <user privatekey> \
--interval 300 \
--maxthreshold 80 \
--minthreshold 60 \
--maxocpu 96 \
--minocpu 22 \
--ociregion eu-frankfurt-1 \
--plugin '<path>/dynamicscaling_LoadAverage_plugin.sh'

Once this is set up a systemctl service will be sufficient to start/stop the service ( Refer MOS 2719916.1 ) fo rmore details

ODCC

If ODyS is implemented ODCC should also be implemented due to the following

Possibility of a cpu_count parameter imbalance across your cluster , i.e. if ODyS scales down the CPU and for some reason there is a node evition, in that case the database will start up with the cores at the time of the startup and not prior to what was actually set. This is a risky area.
The database system metrics DBA_HIST_SYSMETRIC_SUMMARY will have wrong measurement of the system metrics and will provide misleading metrics in AWR , ASH and OEM metrics.
The optimizer essentially relies on cpu_count parameters for identifying the correct execution plans , working around cpu_count by maxing the cpu_count values is not advisable.

The dcpucount.bin is also a one time configuration for ODCC

Usage:
dcpucount.bin --conf <database config file>
             [--dryrun]
             [--interval <Number of seconds>]
             [--logfile <log file name>]
             [--logpath <log file path>]
             [--nodaemon]
             [--nolog]
             [--nowait]
             [--onetime]
             [--overprovisioning]
             [--debug]
dcpucount.bin OPTIONS
  --conf             Database CPU_COUNT Configuration file
  --dryrun           CPU_COUNT change is disabled
  --interval         Number of seconds (Default: 180)
  --logfile          Log file name (Default: dcpucount.log)
  --logpath          Log file path (Default: /tmp)
  --nodaemon         It will run as standlone
  --nolog            It will not make the log '/tmp/dcpucount.log'
  --nowait           It will not wait for CPU number synchronization between nodes
  --onetime          It will execute one time only
  --overprovisioning It's permitted over provisioning setup

Precautions

It's better to identify the CPU loads manually to observe the rate of scale up/down , the dry run feature helps in doing this.

For both ODyS and ODCC its better not to have the log files in /tmp as in my experience this is causing a lot of logging for busy environments.

Summary

ODyS and ODCC are the perfect cost saving utilities provided by OCI if implemented correctly woudl give tremendous value for money , such a feature was dream in On Prem Exadata Environments , this is the sweet spot for on scale massive workloads for OCI ExaCS