• Please contact your Oracle sales representative to understand the infrastructure upgrades required for supporting Oracle Autonomous Databases.
• Create multiple Autonomous Exadata VM Clusters on a single Exadata Infrastructure resource.
• Create both Autonomous Exadata VM Clusters and Exadata VM Clusters on the same Exadata Infrastructure.
• Support for multiple VM Clusters lets you:
  • Schedule separate maintenance runs for each Autonomous VM Cluster on the same Exadata Infrastructure.
  • Choose different license models for Autonomous Databases on the same Exadata Infrastructure.
  • Create and test Autonomous Data Guard between Autonomous Exadata VM Clusters on the same Exadata Infrastructure.
  • Customize compute, storage, and memory of each Autonomous Exadata VM Cluster configuration for the intended workload.

It is important to understand the various terms used with resource allocation and usage. So, let's look at the important terms you see on the Oracle Cloud Infrastructure (OCI) console and understand what they mean:

• Available CPUs: CPUs available for allocation to provision new Autonomous Databases or scale existing Autonomous Databases.
• Provisioned CPUs: Total CPUs allocated for all the Autonomous Database within the Autonomous VM Cluster.
• Reserved CPUs: Total CPUs reserved to support auto-scaling of Autonomous Databases, Autonomous Database failover on node failure, and lifecycle management of empty Autonomous Container Databases.
• Reclaimable CPUs: Total CPUs from all terminated and scaled-down Autonomous Databases in all the Autonomous Container Databases within the Autonomous VM Cluster.Reclaimable CPUs are not returned to the Available state until Autonomous Container Database is restarted.
• Provisionable ACDs: Number of Autonomous Container Databases that can be created in the Autonomous VM Cluster.
• Provisioned ACDs: Number of Autonomous Container Databases that have been created in the Autonomous VM Cluster.
• Non-provisionable ACDs: Number of Autonomous Container Databases that cannot be created because of a shortage of available CPUs in the Autonomous VM Cluster.
• Total Storage (in TBs): Total storage allocated to the AVMC.
• Available Storage (in TBs): Storage available for Autonomous Databases’ use in this AVMC.
• Used Storage (in TBs): Storage currently used by Autonomous Database(s) in this AVMC.
• Memory per CPU (in GBs): Memory allocated to the AVMC per CPU.

1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
2. Click Autonomous Exadata VM Clusters.
3. Click Create Autonomous Exadata VM Cluster.
4. In the Create Autonomous Exadata VM Cluster dialog, enter the following general information:
   • Compartment: Specify the compartment in which the Autonomous Exadata VM Cluster will be created.
   • Display Name: A user-friendly description or other information that helps you easily identify the infrastructure resource. The display name does not have to be unique. Avoid entering confidential information.
   • Exadata Infrastructure: Select an Exadata Infrastructure.
   • VM Cluster Network: Select a VM Cluster Network.
   • Configure Autonomous VM Cluster Resources
     All DB Servers that have the minimum resources to create an Autonomous VM Cluster are selected by default.

     1. Click Edit DB Server selection for VM placement to allocate VM resources.
     2. In the resulting Add Virtual Machines dialog, select a minimum of two database servers for VM placement. Maximum resources available for allocation per VM are based on the number of database servers selected.
        Note
        
        If the DB server is not added to the VM Cluster Network resources, then that DB server cannot be selected.
     3. Click Save Changes.
     Note
     
     The minimum and maximum values for these parameters change in relation to each other, for example, the OCPU count allocation will impact the number of ACDs you can create.

     Compute Model: Choose a compute model for your Autonomous Exadata VM Cluster resource.

     The default model is ECPU. ECPU is based on the number of cores elastically allocated from a pool of compute and storage servers.

     Click Change compute model if you wish to select OCPU. OCPU compute model is based on the physical core of a processor with hyper-threading enabled.

     Note
     
     The compute model chosen here will apply to all the Autonomous Container Databases and Autonomous Database instances created in this Autonomous Exadata VM Cluster resource.
     • VM Count: Number of database servers selected for the Autonomous Exadata VM Cluster. You cannot modify the VM count.
     • Maximum number of Autonomous Container Databases for the Autonomous VM Cluster: The number of ACDs specified represents the upper limit on ACDs. These ACDs must be created separately as needed. ACD creation also requires 2 available OCPUs or 8 available ECPUs per node.
     • CPU count per VM: Specify the CPU count for each individual VM. The minimum value is 5 OCPUs or 20 ECPUs per VM.
     • Database memory per CPU (GB): The memory per OCPU allocated for the Autonomous Databases in the Autonomous Exadata VM Cluster.
     • Allocate Storage for Local Backups: Check this option to configure the Exadata storage to enable local database backups.
     • Autonomous Database storage for the Autonomous VM Cluster (TB): Data storage allocated for Autonomous Database creation in the Autonomous VM Cluster.
5. Configure automatic maintenance.
   1. Click Edit Maintenance Preferences.
      On the Edit Maintenance Preferences page do the following:

      • No preference: The system assigns a date and start time for infrastructure maintenance.
      • Specify a schedule: Choose your preferred month, week, weekday, start time, and lead time for infrastructure maintenance.
        • Under Maintenance months, specify at least one month for each quarter during which Exadata infrastructure maintenance will take place. You can select more than one month per quarter. If you specify a long lead time for advanced notification (for example, 4 weeks), you may wish to specify 2 or 3 months per quarter during which maintenance runs can occur. This will ensure that your maintenance updates are applied in a timely manner after accounting for your required lead time. Lead time is discussed in the following steps.
        • Optional. Under Week of the month, specify which week of the month maintenance will take place. Weeks start on the 1st, 8th, 15th, and 22nd days of the month, and have a duration of 7 days. Weeks start and end based on calendar dates, not days of the week. Maintenance cannot be scheduled for the fifth week of months that contain more than 28 days. If you do not specify a week of the month, Oracle will run the maintenance update in a week to minimize disruption.
        • Optional. Under Day of the week, specify the day of the week on which the maintenance will occur. If you do not specify a day of the week, Oracle will run the maintenance update on a weekend day to minimize disruption.
        • Optional. Under Start hour, specify the hour during which the maintenance run will begin. If you do not specify a start hour, Oracle will pick the least disruptive time to run the maintenance update.
        • Under Lead Time, specify the minimum number of weeks ahead of the maintenance event you would like to receive a notification message. Your lead time ensures that a newly released maintenance update is scheduled to account for your required minimum period of advanced notification.
   2. Click Save Changes.
6. Choose the license type you wish to use.

   Your choice affects metering for billing. You have the following options:

   • Bring your own license: If you choose this option, make sure you have proper entitlements to use for new service instances that you create.
   • License included: With this choice, the cost of the cloud service includes a license for the Database service.
7. The following Advanced Options are available:
   • Time zone: The default time zone for the Exadata Infrastructure is UTC, but you can specify a different time zone. The time zone options are those supported in both the Java.util.TimeZone class and the Oracle Linux operating system.
     Note
     
     

     If you want to set a time zone other than UTC or the browser-detected time zone, then select the Select another time zone option, select a Region or country, and then select the corresponding Time zone.

     If you do not see the region or country you want, then select Miscellaneous, and then select an appropriate Time zone.

   • Listener: VM Cluster Networks are created with the default ports (non-TLS: 1521 and TLS: 2484). You can select a non-default SCAN listener port for both TLS and non-TLS connections within the permissible range of ports.
     Note
     
     

     • You can configure SCAN listener ports and TLS/mTLS authentication mode only when you provision a new VM Cluster.
     • You cannot change the settings after provisioning the VM Cluster.
     • Once configured, the configuration applies to all ACDs in the cluster.
     • Non-TLS port:
       • Default: 1521
       • Permissible range:1024 - 8999
       • Exceptions:
         • Agent port: 7070
         • Admin port: 7879
         • Connect to agent port: 7060
         • Oracle notification service: 6100, 6200
     • TLS port:
       • Default: 2484
       • Permissible range:1024 - 8999
       • Exceptions:
         • Agent port: 7070
         • Admin port: 7879
         • Connect to agent port: 7060
         • Oracle notification service: 6100, 6200
     • Enable mutual TLS (mTLS) authentication: Select or deselect this check box to choose between one-way TLS and mutual TLS for database SSL certificates.
   • Tags: Optionally, you can apply tags. If you have permission to create a resource, you also have permission to apply free-form tags to that resource. To apply a defined tag, you must have permission to use the tag namespace. For more information about tagging, see Resource Tags. If you are not sure if you should apply tags, skip this option (you can apply tags later) or ask your administrator. Avoid entering confidential information.
8. Optionally, you can save the resource configuration as a stack.
   • To save the resource configuration as a Stack:
     1. Click Save as Stack.
     2. In the resulting Save as Stack dialog, provide the following details:
        1. Name: (Optional) Provide an easy-to-remember descriptive name.
        2. Description: (Optional) Enter a short description.
        3. Compartment: Select a compartment where this Stack will reside.
        4. Tags: Add tags.
     3. Click Save.

        After saving the Stack, the system displays a banner with a link to the saved Stack.

     4. Click the link to open the Stack in the Resource Manager Service console.

        See, Resource Manager and Terraform.

   • To view the details of a Stack:
     1. Open the navigation menu. Under Developer Services, click Resource Manager.
     2. Click Stacks.
     3. Click the name of the Stack that you want to view details.

        Or, click the Actions menu (three dots), and select the View stack details option.

9. Click Create Autonomous Exadata VM Cluster.

1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
2. Under Infrastructure, click Exadata Infrastructure.
3. In the list of Exadata Infrastructures, click the display name of the infrastructure you wish to view details.
4. Under Resources, click DB Servers.
5. In the list of DB Servers, click the name of the DB Server that you wish to view details.

   DB Server lists VMs from each cluster hosted on them along with resources allocated to them.

1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
2. Click Autonomous Exadata VM Clusters.

   Autonomous Exadata VM Clusters view page lists AVMCs in the chosen Exadata Infrastructure and displays details that include:

   • Name: Name of AVMC
   • State: Lifecycle state of AVMC such as Updating, Provisioning, Available, and so on.

   • CPU(%): Available and total CPUs and percentage of used CPUs represented as a color-coded bar chart. The colors on this bar represent the following:

     • Less than 70%: Green
     • Between 70 to 90%: Yellow
     • Greater than 90%: Red
   • Reclaimable CPUs: Total CPUs from all terminated and scaled-down Autonomous Databases in all the Autonomous Container Databases within the Autonomous VM Cluster. Reclaimable CPUs are not returned to the Available state until Autonomous Container Database is restarted.

   • Storage (TB) (%): Available and total storage in TB and the percentage of used storage are represented as a color-coded bar chart. The colors on this bar represent the following:

     • Less than 70%: Green
     • Between 70 to 90%: Yellow
     • Greater than 90%: Red
   • Provisionable ACDs: The number of Autonomous Container Databases that can be created in the Autonomous VM Cluster.
   • Memory per CPU: Represents the size of memory in GB per CPU.
   • Created: Date and time of creation of AVMC.

1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
2. Click Autonomous Exadata VM Clusters.
3. In the list of Autonomous Exadata VM Clusters, click the display name of the Exadata VM cluster you wish to view details.

   (or)

   1. Click Exadata Infrastructure.
   2. In the list of Exadata Infrastructure, click the display name of the Exadata Infrastructure you wish to view details.

      Infrastructure Details page is displayed.

   3. Under Resources, click Autonomous Exadata VM Clusters.
   4. In the list of Autonomous Exadata VM Clusters, click the display name of the Autonomous Exadata VM Clusters you wish to view details. Or, click the action menu (three dots), and then select View Details.

      Autonomous Exadata VM Clusters Details page is displayed.

      The Resource allocation section provides an overview of the resources allocated.

      • CPU(%): Available and total CPUs and percentage of used CPUs represented as a color-coded bar chart. The colors on this bar represent the following:
        • Less than 70%: Green
        • Between 70 to 90%: Yellow
        • Greater than 90%: Red
      • ADB Storage (TB) (%): Available and total storage in TB and the percentage of used storage are represented as a color-coded bar chart. The colors on this bar represent the following:
        • Less than 70%: Green
        • Between 70 to 90%: Yellow
        • Greater than 90%: Red
      • Database memory per CPU: This represents the size of memory in GB per CPU.
      • Provisionable ACDs: The number of Autonomous Container Databases that can be created in the Autonomous VM Cluster.

      Click View details to view resource allocation details.

      The resulting Resource allocation details page has two tabs: Autonomous Exadata VM Cluster to view details of the resources allocated to AVMC and Autonomous Container Database to view details of the resources allocated to ADB.

      Autonomous Exadata VM Cluster:

      • Total resources allocated: This section lists the latest values for the following resources allocated to this AVMC:
        • CPUs
        • Exadata Storage in TB
        • Local Storage in GB
        • Memory in GB
        • Maximum number of ACDs
        • Autonomous Database Storage in TB
        • Autonomous Database Memory per CPU in GB.
        • You can also see if the Storage for local backups is enabled or disabled.

      • Resource usage visualization: This section has graphical and tabular representations of AVMC's resource usage.

        Note: You can choose to see this information either in the graphical or tabular view by selecting Chart view or Table view from the drop-down list at the top-right corner of this section.

        • Chart View: Chart view is the default view. In this view, you can see 4 graphical visualizations that provide usage details for different resources, as:
          • CPU usage: Depicts the Total number of CPUs allocated to this AVMC and how many of those CPUs are reclaimable, available, provisioned, and reserved. This is a doughnut chart with the total number of CPUs shown in the center of the chart.
          • CPU usage at VM level: This is a horizontal bar graph giving a breakdown of the CPU usage for each VM in the cluster. Each bar shows the number of reclaimable, available, provisioned, and reserved CPUs for that VM with color coding. Hovering on each colored part of the horizontal bar displays the number of reclaimable, available, provisioned, and reserved CPUs for that specific VM. Clicking the reclaimable, provisioned, and reserved bars will open a new panel with the breakdown of those CPU components by ACDs.
          • Autonomous Container Database (ACD) usage: Depicts the Total number of ACDs that can be created in this AVMC along with a break-up of Provisionable ACDs, Provisioned ACDs, and Non-provisionable ACDs. See Resource Terminology to understand what each of these means. This is a doughnut chart with the total number of ACDs shown in the center of the chart.
          • Autonomous Database (ADB) storage (in TBs) usage: This is a doughnut chart depicting the available, used, and total Autonomous Database storage in TBs. The total storage value is shown in the center of the chart with available and used storage values shown on the chart in different colors.
        • Table View: To see the resource usage details of an AVMC in the table view, select Table View from the drop-down list at the top-right corner of the Resource usage visualizations section. The table view shows the exact same details as the chart view, in the form of tables. The four tables you can see are:
          • CPU usage: Lists the number of total, available, provisioned, reserved, and reclaimable CPUs in this AVMC.
          • CPU usage at VM level: Lists the number of available, provisioned, reserved, and reclaimable CPUs for each VM in this VM cluster.
          • Autonomous Container Database (ACD) usage: Lists the number of provisionable, provisioned, and non-provisionable ACDs in this AVMC.
          • Autonomous Database (ADB) storage (in TBs) usage: Shows the available and used Autonomous Database storage in TBs.
      Autonomous Container Database: This tab lists the following details for all the ACDs, in the selected AVMC, created in any compartment in the tenancy:

      • ACD's display name
      • CPU value of the largest provisionable Autonomous Database.
      • The number of CPUs provisioned to Autonomous Databases.
      • The number of reserved CPUs.
      • The number of reclaimable CPUs.

1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
2. Click Autonomous Exadata VM Clusters.
3. In the list of Autonomous Exadata VM Cluster, click the Autonomous Exadata VM Cluster that you want to scale.
4. On the Autonomous Exadata VM Clusters details page, click Scale Autonomous VM Cluster.
5. In the resulting Scale Autonomous VM Cluster panel, adjust the sliders to increase or decrease the following resources:
   • CPU count per VM
   • Maximum number of Autonomous Container Databases
   • Database storage (TB)

   The minimum and maximum values on the sliders are the smallest and largest values the resources can scale to.

   Note
   
   

   Modifying CPU count per VM or the maximum number of Autonomous Container Databases of an AVMC triggers a rolling restart of the AVMC. This results in restarting all the ACDs and Autonomous Databases created in that AVMC.

6. Click Save Changes.
7. To confirm a rolling restart, enter the AVMC name in the Confirm rolling restart dialog, and click Confirm.
   Note
   
   

   In case of an ongoing maintenance activity on this AVMC or the ACDs and Autonomous Databases within it, your scale request fails with an appropriate message.

Exadata Cloud Service updates are released on a quarterly basis. You can set a maintenance window to determine the time your quarterly infrastructure maintenance will begin.

You can also view scheduled maintenance runs and the maintenance history of your Autonomous Exadata VM Cluster in the Oracle Cloud Infrastructure Console.

• Set the Automatic Maintenance Schedule for Autonomous Exadata VM Cluster
  
• View or Edit the Time of the Next Scheduled Maintenance for Autonomous Exadata VM Cluster
  
• View the Maintenance History of Autonomous Exadata VM Cluster
  

1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
2. Click Autonomous Exadata VM Clusters.
3. In the list of Autonomous Exadata VM Clusters, click the display name of the Exadata VM cluster you wish to administer.
4. Click Update License Type.
5. On the Update License Type dialog box, choose one of the following license types.
   • Bring Your Own License (BYOL): Select this option if your organization already owns Oracle Database software licenses that you want to use on the VM cluster.
   • License Included: Select this option to subscribe to Oracle Database software licenses as part of Exadata Database Service on Cloud@Customer.

   Updating the license type does interrupt the operation of the VM cluster.

6. Click Save Changes.

1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
2. Click Autonomous Exadata VM Clusters.
3. In the list of Autonomous Exadata VM Clusters, click the display name of the Exadata VM cluster you wish to administer.
4. Click Move Resource.
5. Select the new compartment.
6. Click Move Resource.

1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
2. In the list of Autonomous Exadata VM Clusters, click the display name of the Exadata VM cluster you wish to administer.
3. Click Terminate.
4. Confirm that you wish to terminate your Autonomous Exadata VM Cluster in the confirmation dialog.
5. Click Terminate VM Cluster.

For information about using the API and signing requests, see REST APIs and Security Credentials. For information about SDKs, see Software Development Kits and Command Line Interface.

The following table lists the REST API endpoints to manage Autonomous Exadata VM Clusters.

1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
2. Click Autonomous Exadata VM Clusters.
3. In the list of Autonomous Exadata VM Clusters, click the display name of the Exadata VM cluster for which you want to rotate certificates.

   The Network section provides an overview of the SCAN listener ports (TLS, non-TLS), authentication mode (One way TLS, Mutual TLS), and the expiry dates for the Database and ORDS TLS certificates.

   Note
   
   

   • Six weeks before certificates expire, a warning banner displays a list of certificates to rotate. Until the certificates are refreshed, the banner will continue to display.
   • The system displays an error banner if the certificate has already expired, indicating that the database on this VM cluster cannot be accessed. Also, it suggests that you can access the database using 1521, a non-TLS port.
4. In the Autonomous Exadata VM Clusters Details page, click Manage Certificates.
   Manage Certificates page is displayed.

   Note
   
   

   • Six weeks before certificates expire, a warning banner displays a list of certificates to rotate. Until the certificates are refreshed, the banner will continue to display.
   • The system displays an error banner if the certificate has already expired, indicating that the database on this VM cluster cannot be accessed. Also, it suggests that you can access the database using 1521, a non-TLS port.
5. Select a certificate type to manage.

   Database TLS Certificate: Select this option to manage Autonomous Database client connections.

   A warning banner is displayed six weeks prior to the certificate expires.

   1. Select a certificate generation type.
      • System generated: Select this option if you want to use Oracle provided certificate.
      • Bring your own certificate: Select this option to choose your own certificate.
        • Certificate source: Defaults to VM Cluster managed certificate. You cannot edit this field.
        • Certificate: Select a certificate from a compartment of your choice.
        • Specify CA certificate: Select this check box to provide CA details.
          • Certificate Authority: Select a CA from the compartment of your choice.
          • CA Bundle: Select a CA bundle from the compartment of your choice.
   2. Click Save changes.

      Confirm Database TLS certificate update dialog is displayed.

   3. Review the information on the banner.
   4. Click Update DB TLS certificate.

      The status of Autonomous Exadata VM Cluster changes to Updating and the status changes to Available after updating the changes successfully.

   ORDS TLS Certificate: Select this option to rotate the TLS certificate for APEX application.

   A warning banner is displayed six weeks prior to the certificate expires.

   1. Select a certificate generation type.
      • System generated: Select this option if you want to use Oracle provided certificate.
      • Bring your own certificate: Select this option to choose your own certificate.
        • Certificate source: You cannot edit this field.
        • Certificate: Select a certificate from a compartment of your choice.
        • Specify CA certificate: Select this check box to provide CA details.
          • Certificate Authority: Select a CA from the compartment of your choice.
          • CA Bundle: Select a CA bundle from the compartment of your choice.
   2. Click Save changes.

      Confirm ORDS TLS certificate update dialog is displayed.

   3. Review the information on the banner.
   4. Click Update ORDS TLS certificate.

      The status of Autonomous Exadata VM Cluster changes to Updating and the status changes to Available after updating the changes successfully.