1. Administering Oracle Database Exadata Cloud Service (OCI-C)
  2. Managing the Exadata Cloud Service Life Cycle
  3. Scaling an Exadata Cloud Service Instance

Scaling an Exadata Cloud Service Instance

Two kinds of scaling operations are supported for an Oracle Database Exadata Cloud Service instance:

  • Scaling within an Exadata system enables you to modify compute node processing power within the confines of your existing Exadata system.

  • Scaling across Exadata system configurations enables you to move to a different Exadata system configuration. For example, from a Quarter Rack to a Half Rack.

Scaling Within an Exadata System

If an Exadata Cloud Service instance requires more compute node processing power, you can scale up the number of enabled CPU cores in the corresponding Oracle Exadata Database Machine. For a non-metered service instance, you can temporarily modify the compute node processing power (bursting) or add compute node processing power on a more permanent basis. For a metered service instance, you can simply modify the number of enabled CPU cores.

The maximum number of enabled CPU cores depends on your system configuration. See Exadata System Configuration. However, your subscription may impose additional limits.

To modify the number of enabled CPU cores within an existing Exadata Cloud Service instance:

  1. Open the My Services dashboard.

    For detailed instructions, see Accessing the My Services Dashboard and the Oracle Database Cloud Service Console.

  2. Click the action menu (Menu icon) in the Exadata Classic tile and choose View Details.

    The Service Details page is displayed, with the Overview tab showing.

  3. Locate your service instance in the list. Click the action menu (Menu icon) located beside the service instance name and choose Modify.

    The Modify Oracle Database Exadata Cloud Service Instance wizard starts and the Instance Details page is displayed.

  4. On the Instance Details page, specify the type of scaling operation that you want to perform (if applicable) and use the slider control to set the number of enabled CPU cores on each compute node. Then, click Modify.

    1. If available, specify the type of scaling operation that you want to perform by selecting the Subscription option or the Burst option:

      Note:

      This option is not available for metered service instances. If this option is not available for your service instance, then any changes are charged according to the normal terms of your subscription.

      • Select Subscription if you want to scale the service in line with a subscription change.

        To use this option you must first adjust your subscription and purchase the additional CPU core entitlements. Thereafter, the slider control enables the placement of the additional CPU cores on your compute nodes.

      • Select Burst if you want to temporarily scale the service instance.

        With bursting, you can quickly scale up beyond your subscription level to cater for workload peaks. You can also scale back to the subscription level at any time. CPU cores beyond your subscription level are charged separately using an hourly rate for the bursting period.

        Note:

        For non-metered subscriptions only, the maximum number of enabled CPU cores available with bursting is limited to twice the number of CPU cores in the associated service subscription. For example, if your service subscription contains 11 enabled CPU cores on each compute node, then the bursting maximum is 22 CPU cores on each compute node. This limit does not apply to other subscription types, such as Universal Credits.

    2. Use the slider control to set the new number of enabled CPU cores on each compute node. When you make a change, the change is reflected in the Configuration after Update summary. At any point, you can click Reset to return the slider to its original setting.

      Note:

      The slider setting represents the total number of enabled CPU cores for each compute node and not the number of additional CPU cores to enable.

  5. On the Confirmation page, review the configuration settings. If you are satisfied, click Modify.

    Otherwise, click Cancel on the Confirmation page and again on the Instance Details page to cancel out of the wizard without updating the service instance.

Modifying the number of enabled CPU cores is an online operation, which does not require a reboot of the affected compute nodes.

If you have explicitly set the CPU_COUNT database initialization parameter, that setting is not affected by modifying the number of enabled CPU cores. Consequently, if you have enabled the Oracle Database instance caging feature, the database instance will not use additional CPU cores until you alter the CPU_COUNT setting. If CPU_COUNT is set to 0 (its default setting), then Oracle Database continuously monitors the number of CPUs reported by the operating system and uses the current count.

Scaling Across Exadata System Configurations

Scaling across Exadata system configurations enables you to move to a different Exadata system configuration, such as moving from a Quarter Rack to a Half Rack for example. This is useful when a database deployment requires:

  • Processing power that is beyond the capacity of the current system configuration.

  • Storage capacity that is beyond the capacity of the current system configuration.

  • A performance boost that can be delivered by increasing the number of available compute nodes.

  • A performance boost that can be delivered by increasing the number of available Exadata Storage Servers.

Scaling across Exadata system configurations requires that the data associated with your database deployment is backed up and restored on a different Exadata Database Machine, which requires an amount of planning and coordination between you and Oracle. To commence the process, submit a service request to Oracle.