Managing Autonomous Databases

An Autonomous Database resource is a user database. When you create an Autonomous Database, you choose the Autonomous Container Database for it and you specify "Data Warehouse" or "Transaction Processing" as its workload type to create an Autonomous Data Warehouse database or an Autonomous Transaction Processing database.

You can create hundreds of Autonomous Databases on an Exadata Infrastructure. As described in Available Exadata Infrastructure Hardware Shapes, the maximum is determined by the capacity of your Exadata Infrastructure hardware.

Oracle Autonomous Database for Developers

Oracle Autonomous Database for Developers instances are free Autonomous Databases that developers can use to build and test new applications.

With Autonomous Database for Developers instances, you can try new Autonomous Database features for free and apply them to ongoing or new development projects. Developer databases are limited in resources, so they are not suitable for large-scale testing and production deployments. When you need more compute or storage resources, you can transition to a paid database licensing by cloning your developer database into a regular Autonomous Database.

Requirements

To create an Autonomous Database for Developers instance, you must have access to Oracle Exadata Database Service or Autonomous Database on either a Dedicated Exadata Infrastructure or Exadata Cloud@Customer. In other words, only those customers with active subscriptions to any of the following service platforms can create developer databases:

  • Autonomous Database on Dedicated Exadata Infrastructure
  • Exadata Database Service on Dedicated Exadata Infrastructure
  • Autonomous Database on Exadata Cloud@Customer
  • Exadata Database Service on Cloud@Customer

There is no limit on the number of free developer databases; it’s limited by the capacity of your Exadata infrastructure.

Provisioning Workflow

You can provision an Autonomous Database for Developers instance from the Oracle Cloud Infrastructure (OCI) console or using API. To create a developer database, you need an ACD without an Autonomous Data Guard in an ECPU-based AVMC. If you do not have these resources provisioned already, create the ECPU-based AVMC first and then create an ACD without disaster recovery (Autonomous Data Guard) using that AVMC.

After creating or identifying (if they already exist) the AVMC and ACD, you can create an Autonomous Database for Developers using them. Provisioning a developer database using the OCI console follows the same workflow as creating a regular Autonomous Database, as described in Create Autonomous Database. Once created, the Autonomous Database for Developers instances appear with a Developer label in the list of Autonomous Databases on the OCI console.

Specifications

Each developer database comes with the following specifications:

  • Compute: Fixed 4 ECPUs, with no CPU scaling
  • Storage: Fixed 32 GB ( ~ 20 GB of DATA)
  • Session limits: 30 concurrent database sessions
  • Workload Type: Data Warehouse, Transaction Processing

Excluded Features

Autonomous Database for Developers supports all the features offered by a regular Autonomous Database except those listed below. These limitations are in place to ensure that the developer databases are optimally used as a development sandbox.

Developer database instances:

  • Do not support Autonomous Data Guard. Hence, they can only be provisioned in an ACD without Autonomous Data Guard.
  • Support ECPU only. Therefore, you can provision them only on an ECPU based ACD.
  • Come with fixed compute and storage sizing, do not support manual or auto-scaling and storage scaling.
  • Can not have long-term backups.
  • Do not provide Database In-memory.

Supported Features

  • Cloning: Autonomous Database for Developers offers fewer resources and features than a regular autonomous database. For non-development use, such as load/stress testing and production, or to get access to all features, users can use cloning to clone from a developer database to a regular Autonomous database. You can also clone a regular database into a developer database; however, to successfully clone a regular database into a developer database, the source database's actual used space, rounded up to the next GB, must be <= 32GB.
  • Backup and Recovery: You can enable automatic backups or trigger manual backups of your developer database, as needed. If the backup destination is an Object Storage and Recovery Service, the backups will be billed.
  • Service Maintenance: Developer databases follow the same patching schedule as regular Autonomous Database; however, there will be no support for critical one-off patches.
  • Database Application Development and Developer Tools: With Autonomous Database for Developers, you can use all the developer-related features and built-in tools an Autonomous Database offers.

Autonomous Database for Developers comes with a service level objective (SLO) of 99.5% and you can log service requests (SR) to Oracle Support for assistance. However, there is no Severity 1 SR support for developer databases. See Create a Service Request in My Oracle Support to learn how to contact Oracle Support for assistance.

Create an Autonomous Database

Follow these steps to create an autonomous database on an Oracle Exadata Database Service on Cloud@Customer system.
Note

  • If the standby ACD is in snapshot standby mode, then you cannot create an ADB in the primary ACD.
  • For better management and sharing of the underlying SGA/memory resources, Oracle recommends that all Autonomous Databases configured for In-Memory be in the same Autonomous Container Database.
  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
  2. Click Autonomous Databases.
  3. Click Create Autonomous Database.
  4. In the Create Autonomous Database dialog, enter the following:

    Basic Database Information

    • Compartment: Select the compartment of the Autonomous Database.
    • Display Name: A user-friendly description or other information that helps you easily identify the resource. The display name does not have to be unique. Avoid entering confidential information.
    • Database Name: The database name must consist of letters and numbers only, starting with a letter. The maximum length is 14 characters. Avoid entering confidential information.

    Workload Type

    Select the desired workload type.
    • Data Warehouse
    • Transaction Processing
    See About Autonomous Database for information about each workload type.

    Autonomous Container Database: Select an Autonomous Container Database.

    Compartment: Specify the compartment containing the Autonomous Container Database you wish to use.

    Configure the database: Free Instance:
    Note

    As developer database instances can only be created on ECPU-based ACDs without Autonomous Data Guard, the Free instance toggle button is disabled for ACDs with OCPU, Autonomous Data Guard, or both.

    Toggle the Free instance button on, if you want to create an Autonomous Database for Developers instance.

    ECPU count and Storage (GB) are auto-populated with 4 and 32 respectively because Autonomous Database for Developers comes fixed at 4 ECPUs and 32GB storage

    Compute auto-scaling is disabled because developer database instances do not support manual or auto-scaling.

    Configure the database

    • CPU Count: Select the number of CPUs for your database from the list of provisionable CPUs.

      The CPU type, that is, OCPU or ECPU is determined by the parent Autonomous Exadata VM Cluster resource's compute type.

      This value defaults to 1 OCPU.

      For ECPUs, this value defaults to 2 ECPUs.

      You can also select a fractional OCPU value for databases that do not need an entire OCPU. This allows you to overprovision CPU and run more databases on each infrastructure instance. Refer to CPU Overprovisioning for more details.

      Note

      CPU Overprovisioning is not allowed with ECPUs.

      Databases with CPU over-provisioning can only connect using tp and low services.

      Auto scaling: Enable or disable auto-scaling, which permits Autonomous Database to automatically use up to three times the allocated CPUs as the workload on the database increases.

    • Storage (GB): Specify the storage you wish to make available to your Autonomous Database, in GB. The available storage depends on the infrastructure shape and what is already consumed by other Autonomous Databases.
      • Default: 1024 GB
      • Minimum: 32 GB
      • Increment: 1 GB

    Administrator Credentials

    Set the password for the Autonomous Database Admin user by entering a password that meets the following criteria. Use this password when accessing the Autonomous Database service console and when using an SQL client tool.

    • Contains from 12 to 30 characters
    • Contains at least one lowercase letter
    • Contains at least one uppercase letter
    • Contains at least one number
    • Does not contain the double quotation mark (")
    • Does not contain the string "admin", regardless of casing
    Configure network access You can optionally create an ACL during database provisioning, or at any time thereafter.
    • Select the Enable database level access control checkbox.
    • Click Access Control Rule.
      Note

      The database-level access control will be enabled without any IP addresses in the access control list. Enabling an access control list with an empty list of IP addresses makes the database inaccessible to all clients

    • Specify the following types of addresses in your list by using the IP notation type drop-down selector:
      • IP Address allows you to specify one or more individual public IP addresses. Use commas to separate your addresses in the input field.
      • CIDR Block allows you to specify one or more ranges of public IP addresses using CIDR notation. Use commas to separate your CIDR block entries in the input field.

    Advanced Options:

    • Encryption Key: ADB inherits encryption settings from the parent ACD. If the parent ACD is configured for customer-managed OKV-based encryption, then the child ADB will also have a TDE Master Key generated and managed in the same OKV wallet used to store ACD master keys. Additionally, any backups taken on the Autonomous Database will have the OKV-based key associated with it.
    • Database In-memory:
      • Enable database In-memory: It requires at least four OCPUs and a percentage of the System Global Area (SGA) to enable in-memory. If you enable In-memory, select the percentage of SGA to allocate to the IM Column Store. In-memory may have an impact on the autonomous database's performance if a large amount of memory is allocated or if it is disabled.
    • Management: Choose a Character Set and National Character from the drop-down list.
    • 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.
  5. 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.

  6. Click Create Autonomous Database.
    Note

    The following naming restrictions apply to Autonomous Transaction Processing and Autonomous Data Warehouse databases:

    • Names associated with databases terminated within the last 60 days cannot be used when creating a new database.
    • A database name cannot be used concurrently for both an Autonomous Data Warehouse and an Autonomous Transaction Processing database.

Manage Access Control List of an Autonomous Database

An access control list (ACL) provides additional protection to your database by allowing only the clients with specific IP addresses to connect to the database. You can add IP addresses individually, or in CIDR blocks.

You can optionally create an ACL during database provisioning, or at any time thereafter. You can also edit an ACL at any time. Enabling an access control list with an empty list of IP addresses makes the database inaccessible.

Note the following about using an ACL with your Autonomous Database:

  • The Autonomous Database Service console is not subject to ACL rules.
  • Oracle Application Express (APEX), RESTful services, SQL Developer Web, and Performance Hub are not subject to ACLs.
  • While creating a database, if setting ACL fails, then provisioning the database also fails.
  • Updating ACL is allowed if the database is in Available and AvailableNeedsAttention states.
  • Restoring a database does not overwrite the existing ACLs.
  • Cloning a database, full and metadata, will have the same access control settings as the source database. You can make changes as necessary.
  • All CDB operations are allowed during ACL update. However, ADB operations are not allowed during ACL update.
  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
  2. Choose your Compartment.
  3. In the list of Autonomous Databases, click the display name of the database you want to administer.
  4. Under Network in the database details, find the Access Control List field and click Edit to enable or disable your database-level access control and make changes to the ACL rules.
    Note

    Autonomous Data Guard enabled Automonous databases:
    • You can only view ACLs for standby databases.
    • You can reset ACL for both the primary and standby databases from the primary database details page. You cannot configure ACL from the standby database details page.
  5. In the Access Control List dialog, add or modify entries, as applicable.

    If you are editing an ACL, the ACL's existing entries display in the Access Control List dialog. Do not overwrite the existing values unless you intend to replace one or more entries. To add new ACL entries, click + Access Control Rule.

    You can specify the following types of addresses in your list by using the IP notation type drop-down selector:

    • IP Address allows you to specify one or more individual public IP addresses. Use commas to separate your addresses in the input field.
    • CIDR Block allows you to specify one or more ranges of public IP addresses using CIDR notation. Use commas to separate your CIDR block entries in the input field.

    Click + Access Control Rule to add additional access rules to your list.

    To remove an access control rule, simply delete the entry from the list. Deleting all access control rules from the ACL will render the database inaccessible because the allow list is empty.

    To disable the database-level access control configuration, clear the Enable database level access control checkbox. Once ACL is disabled and the configuration is saved, all the access control rules are removed from the ACL and no longer applicable.

  6. Click Save Changes.

    If the Lifecycle State is Available when you click Save, the Lifecycle State changes to Updating until the ACL update is complete. The database is still up and accessible, there is no downtime. When the update is complete the Lifecycle State returns to Available and the network ACL rules from the access control list are in effect.

View a List of Autonomous Databases

Follow these steps to view a list of autonomous databases on an Oracle Exadata Database Service on Cloud@Customer system.
  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
  2. Click Autonomous Databases.

View Details of an Autonomous Database

Follow these steps to view detailed information about an autonomous database on an Oracle Exadata Database Service on Cloud@Customer system.
  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
  2. Click Autonomous Databases.
  3. In the list of Autonomous Databases, click the display name of the database you wish to view details.

    In the resulting Autonomous Database details page

    • Encryption details are displayed in the Encryption section.
      • If you have chosen customer-managed keys while creating the database, then you will see a link to the Encryption Key Store and OKV Wallet Name. Click the Key Store link to view details.
      • If you have chosen Oracle-managed keys while creating the database, then you will not see the link to Encryption Key Store and OKV Wallet Name.
    • In-memory details are displayed in the Resource allocation section.
      • If you have not enabled In-memory, then the system displays the Enable link. Click it to enable In-memory.
      • If you have enabled and wish to modify the settings, then click Edit.

Manage Customer Contacts for an Autonomous Database

You can add, edit, and remove customer contacts for an Autonomous Database from its details page.
  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
  2. Click Autonomous Databases.
  3. In the list of Autonomous Databases, click the display name of the database you wish to manage customer contacts.
    Note

    For databases that use Autonomous Data Guard, go to the details page of the primary database.
  4. Select More Actions and then select Manage customer contacts.

    The Manage customer contacts page opens, enabling you to perform the following actions:

    Add Customer Contacts

    1. Click Add customer contact and enter the contact email address.
    2. Optionally, click Add customer contacts to add another contact email.
    3. Click Add customer contacts at the bottom of the page to add the new contacts.
      Note

      Oracle recommends using the email address of an administrator group rather than an individual's, whenever possible, to ensure no important notifications or announcements are missed.

    Edit Customer Contacts

    1. Select the email addresses that you are editing. To edit all email addresses, select the top column next to Email.
    2. Click Edit.
    3. On the Edit customer contacts dialog, modify the contact email as needed, and click Save.

    Delete Customer Contacts

    1. Select the email addresses to remove. To remove all email addresses, select the top column next to Email.
    2. Click Remove.
    3. On the Confirm remove customer contact page, click Remove to confirm.

    The lifecycle state of the Autonomous Database will change to Updating while the customer contact list is updated after you add, edit, or remove contacts.

Rotate ADB Encryption Key

Follow these steps to rotate the TDE Master key. On key rotation, the ADB life cycle goes through the regular updating state and returns to available.

You can rotate the TDE Master key as many times as you want. The new TDE Master Key is stored in the same wallet in which the previous key was stored. Rotating the TDE Master Key leads to the new key being generated in OKV and assigned to this database. You can view all of the keys in OKV.

Note

You can rotate both Oracle-managed and customer-managed encryption keys.

  1. Open the navigation menu. Under Oracle Database, click Exadata Cloud@Customer.
  2. Click Autonomous Databases.
  3. In the list of Autonomous Databases, click the display name of the database you wish to view details.
  4. On the Autonomous Database Details page, from the More Actions drop-down list, select Rotate Encryption Key.
  5. On the Rotate Encryption Key dialog, click Rotate Encryption Key.

Set the Password of an Autonomous Database's ADMIN User

Follow these steps to set the ADMIN database user's password for an autonomous database on an Oracle Exadata Database Service on Cloud@Customer system.
  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
  2. Click Autonomous Databases.
  3. In the list of Autonomous Databases, click the display name of the database you wish to administer.
  4. From the More Actions drop-down list, select Admin Password.
    The Admin Password dialog opens.
  5. Enter a password for the Autonomous Database.

    The password must meet the following criteria:

    • Contains from 12 to 30 characters
    • Contains at least one lowercase letter
    • Contains at least one uppercase letter
    • Contains at least one number
    • Does not contain the double quotation mark (")
    • Does not contain the string "admin", regardless of case
    • Is not one of the last four passwords used for the database
    • Is not a password you previously set within the last 24 hours
  6. Enter the password again in the Confirm Password field.
  7. Click Update.

Scale the CPU Core Count or Storage of an Autonomous Database, or Enable/Disable or Alter the Percentage of System Global Area (SGA) for IM Column Store

Follow these steps to scale the CPU core count or storage of an autonomous database on an Oracle Exadata Database Service on Cloud@Customer system up or down.
Note

  • If the standby ACD is in snapshot standby mode, then you cannot scale an ADB in the primary ACD.
  • For better management and sharing of the underlying SGA/memory resources, Oracle recommends that all Autonomous Databases configured for In-Memory be in the same Autonomous Container Database.
  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
  2. Click Autonomous Databases.
  3. In the list of Autonomous Databases, click the display name of the database you wish to view details.
  4. Click Scale Up/Down.
    Note

    This option is not enabled for an Autonomous Database for Developers instance.
  5. Enter a new value for CPU Core Count or Storage.
    • OCPU Count: Select the number of CPUs for your database from the list of provisionable CPUs.

      Based on the resource utilization on each node; not all the values of the available CPUs can be used to provision or scale Autonomous Databases. For example, suppose you have 20 CPUs available at the AVMC level, not all the values from 1 to 20 CPUs can be used to provision or scale Autonomous Databases depending on the resource availability at the node level. The list of CPU values that can be used to provision or scale an Autonomous Database is called Provisionable CPUs.

      On the console, when you try to provision or scale an Autonomous Database, the CPU count will be validated against the list of provisionable CPUs, and if the value is not provisionable, you will be provided with the two nearest provisionable CPU values. Alternatively, if you want to see the complete list of provisionable CPU values for an Autonomous Exadata VM Cluster, you can use the following API:

      GetAutonomousContainerDatabase returns a list of provisionable CPU values that can be used to create a new Autonomous Database in the given Autonomous Container Database. See GetAutonomousContainerDatabase for more details.

      GetAutonomousDatabase returns a list of provisionable CPU values that can be used for scaling a given Autonomous Database. See GetAutonomousDatabase for more details.

      You can also select a fractional OCPU value for databases that do not need an entire OCPU. This allows you to overprovision CPU and run more databases on each infrastructure instance. Refer to CPU Overprovisioning for more details.

    • Auto scaling: Enable or disable auto-scaling, which permits Autonomous Database to automatically use up to three times the allocated CPUs as the workload on the database increases.
    • Storage (GB): Specify the storage you wish to make available to your Autonomous Database, in GB. The available storage depends on the infrastructure shape and what is already consumed by other Autonomous Databases.
      • Default: Current value
      • Minimum: 32 GB
      • Increment: 1 GB
    • Enable/Disable or Alter Percentage of System Global Area (SGA): It requires at least four OCPUs and a percentage of the System Global Area (SGA) to enable in-memory. If you enable In-memory, select the percentage of SGA to allocate to the IM Column Store. In-memory may have an impact on the autonomous database's performance if a large amount of memory is allocated or if it is disabled.
  6. Click Update.

    You can find the memory allocated to In-memory in the Resource allocation section on the Autonomous Database details page.

    • Click Edit to modify the settings.
    • If you have not enabled In-memory, then the system displays the Enable link. Click it to enable In-memory.

Enable or Disable Auto Scaling for an Autonomous Database

Oracle Autonomous Database on Oracle Exadata Cloud@Customer systems provides an auto-scaling feature that automatically increases the number of CPUs in an autonomous database during periods of increased demand and, as demand returns to normal, automatically decreases the number of cores down to the databases's base number.

Note the following points regarding the auto-scaling feature:

  • With auto-scaling enabled, the database can use up to three times more CPU and IO resources than specified by the number of CPUs currently shown in the Scale Up/Down dialog.
  • If auto-scaling is disabled while more CPU cores are in use than the database's currently assigned number of cores, then Autonomous Database scales the number of CPU cores in use down to the assigned number.
  • Enabling auto scaling does not change the concurrency and parallelism settings for the predefined services.

Follow these steps to enable or disable auto-scaling for an autonomous database.

  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
  2. Click Autonomous Databases.
  3. In the list of Autonomous Databases, click the display name of the database you wish to view details.
  4. Click Scale Up/Down.
  5. Check Auto Scaling to enable the auto-scaling feature, or uncheck Auto Scaling to disable the feature.
  6. Click Update.

    Tip:

    You can view the number of CPUs the database is currently using by running the following SQL statements:
    • ECPU:
      SELECT AVG_RUNNING_SESSIONS FROM V$RSRCPDBMETRIC;
    • OCPU:
      SELECT AVG_RUNNING_SESSIONS / 2 FROM V$RSRCPDBMETRIC;

Move an Autonomous Database to Another Compartment

Follow these steps to move an autonomous database on an Oracle Exadata Database Service on Cloud@Customer system from one compartment to another compartment.

Note

  • To move an autonomous database you must have the right to manage it in its current compartment and in the compartment you are moving it to.
  • As soon as you move an autonomous database to a different compartment, the policies that govern the new compartment apply immediately and affect access to the autonomous database. Therefore, both your and other Oracle Cloud users' access to it may change, depending on the policies governing the user account's access to resources. For example, a user may lose the ability to manage the autonomous databae, given its new compartment.
  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
  2. Click Autonomous Databases.
  3. In the list of Autonomous Databases, click the display name of the database you wish to move.
  4. From the More Actions drop-down list, select Move Resource.
  5. Select the new compartment.
  6. Click Move Resource.

Stop or Start an Autonomous Database

Follow these steps to stop or start an autonomous database on an Oracle Exadata Database Service on Cloud@Customer system.
  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
  2. Click Autonomous Databases.
  3. In the list of Autonomous Databases, click the display name of the database you wish to view details.
  4. Click Stop (or Start).

    When you stop your Autonomous Database, billing stops for CPU usage. Billing for storage continues when the database is stopped.

  5. Confirm that you want to stop or start your Autonomous Database in the confirmation dialog.
Note

Stopping your database has the following consequences:

  • On-going transactions are rolled back.
  • You will not be able to connect to your database using database clients or tools.

Restart an Autonomous Database

To resolve some autonomous database issues with minimal downtime on Exadata Database Service on Cloud@Customer systems, you can restart the database.

Restarting an autonomous database on an Oracle Exadata Database Service on Cloud@Customer system is equivalent to manually stopping and then starting the database. Using restart allows you to minimize downtime and requires only a single action.

Follow these steps to restart an autonomous database.

  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
  2. Click Autonomous Databases.
  3. In the list of Autonomous Databases, click the display name of the database you wish to restart.
  4. Click Restart.
  5. Confirm that you want to restart your Autonomous Database in the confirmation dialog.
    The system stops and then immediately starts your database.

Back Up an Autonomous Database Manually

Oracle Autonomous Database automatically backs up autonomous databases on an Oracle Exadata Database Service on Cloud@Customer system. In addition, you can manually back up an autonomous database should the need arise.
Note

During the backup operation, your autonomous database remains available. However, lifecycle management operations such as stopping it, scaling it, or terminating it are disabled.
  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
  2. Click Autonomous Databases.
  3. In the list of Autonomous Databases, click the display name of the database you wish to back up.
  4. On the Details page, under Resources, click Backups.
  5. Click Create Manual Backup.
  6. In the Create Manual Backup dialog, enter a name for your backup. Avoid entering confidential information.
  7. Click Update.
    The backup operation begins. This operation may take several hours to complete, depending on the size of the database.
Optionally, you can check the state of your backup in the list of backups on the database details page. For some states, an information icon is displayed to provide additional details regarding the state or ongoing operations like deletions. The backup has one of the following states:
  • Creating
  • Active
  • Deleting
  • Deleted
  • Failed

Create a Long-Term Backup

To create a long-term backup, use this procedure.
Note

Long-term backups are not available with Autonomous Database for Developers instances. See Oracle Autonomous Database for Developers for more details.
  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
  2. Click Autonomous Databases.
  3. In the list of Autonomous Databases, click the display name of the database you wish to create a long-term backup.

    Autonomous Details page is displayed.

  4. Under Resources, click Backups.
  5. In the Backups section, click Create long-term backup.
  6. In the resulting window, enter the following details:
    • Name: Enter a user-friendly description or other information that helps you easily identify the backup.
    • Backup destination type: Network File System (NFS) is selected by default. In this release only NFS is supported, so you cannot change it no matter what destination type (Object Storage, Network File System, or Oracle Zero Data Loss Recovery Appliance) you have chosen for the ACD.

    • Backup destinations: Specify an NFS destination. You can use an existing NFS destination or create one for this long-term backup.
      • To choose an existing NFS destination:
        • Click Backup Destinations under Infrastructure.
        • Choose an NFS destination from the list of NFS backup destinations in the chosen compartment.
      • To create an NFS backup destination, see Using the Console to Create a Backup Destination.
    • Retention period: Set the retention period.
  7. Click Create

View Details and Edit Retention Period of a Long-Term Backup

To view the details of a long-term backup and edit the retention period, use this procedure.
  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
  2. Click Autonomous Databases.
  3. In the list of Autonomous Databases, click the display name of the database you wish the details of a long-term backup.
  4. In the resulting Autonomous Details page, under Resources, click Backups.
  5. In the Backups section, identify the backup, and review the details.
  6. To edit the retention period, click the action icon (three dots) and select Edit retention period.
  7. In the resulting window, set the retention period.
  8. Click Save.

Delete a Long-Term Backup

To delete a long-term backup, use this procedure.
  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
  2. Click Autonomous Databases.
  3. In the list of Autonomous Databases, click the display name of the database you wish to view the details of a long-term backup.
  4. In the resulting Autonomous Details page, under Resources, click Backups.
  5. In the Backups section, identify the backup, click the action icon (three dots), and then select Delete.
  6. In the resulting window, click Delete if you are sure about deleting it.

Restore an Autonomous Database

You can use any existing manual or automatic backup to restore and recover an autonomous database on an Oracle Exadata Database Service on Cloud@Customer system, or you can restore and recover the database to any point in time during the retention period of its automatic backups.

Note

  • Restoring an autonomous database puts the database in an unavailable state during the restore operation. You cannot connect to a database in this state. The only lifecycle management operation supported in the unavailable state is terminate.
  • You cannot perform a restore operation on a primary ADB if the standby database is in snapshot standby mode. Convert your standby ACD to physical standby mode to restore an Autonomous Database.

Restore from a Backup

Follow these steps to restore an autonomous database on an Oracle Exadata Database Service on Cloud@Customer system from a specific backup.
  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
  2. Click Autonomous Databases.
  3. In the list of Autonomous Databases, click the display name of the database you want to clone.
  4. From the More Actions drop-down list, select Restore.
  5. Specify the date range for a list of backups to display.
  6. Select the backup.
  7. Click Restore.

Restore to a Point in Time

Follow these steps to restore an autonomous database on an Oracle Exadata Database Service on Cloud@Customer system to a specific point in time.
  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
  2. Click Autonomous Databases.
  3. In the list of Autonomous Databases, click the display name of the database you want to restore.
  4. From the More Actions drop-down list, select Restore.
  5. Click Specify Timestamp.
  6. Enter a timestamp.
    Your Autonomous Database decides which backup to use for faster recovery. The timestamp input allows you to specify precision to the seconds level (YYYY-MM-DD HH:MM:SS GMT).
  7. Click Restore.

Clone an Autonomous Database

Follow these steps to clone an autonomous database on an Oracle Exadata Cloud@Customer system.

You can use the cloning feature to create a point-in-time copy of your Autonomous Database for purposes such as testing, development, or analytics. To clone only the database schema of your source database, choose the metadata clone option.

Note

Autonomous Databases with 23ai software version can not be cloned into an Autonomous Database with 19c version and vice-versa.

Note

If IM is enabled, the source In-Memory Column Store settings or parameters will not be applied to the clone. However, you can enable In-Memory Column Store like a normal ADB creation flow.

Clone Types

The clone feature offers the following two types of Autonomous Database clones:
  • The full-clone option creates a database that includes the metadata and data from the source database.
  • The metadata-clone option creates a database that includes only the metadata from the source database.

Steps

  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
  2. Click Autonomous Databases.
  3. In the list of Autonomous Databases, click the display name of the database you want to clone.
  4. From the More Actions drop-down list, select Create Clone.
  5. On the Create Autonomous Database Clone page, provide the following information:

    In the Clone Type section, select the type of clone you want to create. Choose either Full Clone or Metadata Clone.

    Clone Source: The clone source selection allows you to specify whether the clone is created from a running database or from a database backup. Select one of the following options:
    • Clone from a database instance: Creates a clone of a running database as it exists at the current moment.
    • Clone from a backup: Creates a clone from a database backup. If you choose this option, select one of the following options:
      • Specify a timestamp: Creates a point-in-time clone. The timestamp has to be between the first and latest backups of the database.
      • Select from a list of backups: Creates a clone using all data from the specified backup. To limit your list of backups to a specific date range, enter the starting date in the From field and the ending date in the To field.

    Provide basic information for the Autonomous Database.

    • Choose a compartment: Your current compartment is the default selection but you can select a different compartment in which to create the clone from the drop-down list.
    • Source database name: The name of the source database displays in the read-only Source database name field.
    • Display name: Enter a description or other information to identify the database clone. You can change the display name any time and it does not have to be unique. Avoid entering confidential information.
    • Database name: Enter a database name for the clone that contains only letters and numbers, begins with a letter. Avoid entering confidential information.
    • Three additional fields are displayed if you opt to clone from a backup.
      • Region: Choose your preferred region to place the clone database.
      • Exadata Infrastructure: You can choose to create the database clone in the same Exadata Infrastructure where the source database resides, or you can choose a different compartment by clicking CHANGE COMPARTMENT and choosing one from the drop-down list.
      • Autonomous Exadata VM Cluster: You can choose to create the database clone in the same Autonomous Exadata VM Cluster where the source database resides, or you can choose a different compartment by clicking CHANGE COMPARTMENT and choosing one from the drop-down list.
    • Autonomous Container Database: You can choose to create the database clone in the same compartment and container database as the source database, or you can choose a different compartment by clicking CHANGE COMPARTMENT, and a different container database by choosing one from the drop-down list.
    • Configure the database: Free Instance: Toggle the Free instance button on, if you want to create an Oracle Autonomous Database for Developers instance. ECPU count and Storage (GB) are auto-populated with 4 and 32 respectively because Oracle Autonomous Database for Developers comes fixed at 4 ECPUs and 32GB storage Compute auto-scaling is disabled because developer database instances do not support manual or auto-scaling.
      Note

      • As developer database instances can only be created on ECPU-based ACDs without Autonomous Data Guard, the Free instance toggle button is disabled for ACDs with OCPU, Autonomous Data Guard, or both.
      • To successfully clone a backup to an Oracle Autonomous Database for Developers instance, the current storage allocation of the backup database must be 32GB. In case, this condition is not met, you can try cloning the database instance to a developer database, as long as its actual used space, rounded up to the next GB, must be <= 32GB.

    Configure the database

    • CPU Count: Select the number of CPUs for your clone database from the list of provisionable CPUs.

      The CPU type, that is, OCPU or ECPU is determined by the parent Autonomous Exadata VM Cluster resource's compute type.

      This value defaults to 1 OCPU.

      You can also select a fractional OCPU value for databases that do not need an entire OCPU. This allows you to overprovision CPU and run more databases on each infrastructure instance. Refer to CPU Overprovisioning for more details.

      Note

      CPU Overprovisioning is not allowed with ECPUs.

      Databases with CPU over-provisioning can only connect to the tp and low services for the Autonomous Database for Transaction Processing and Mixed Workloads workloads. In the case of an Autonomous Database for Analytics and Data Warehousing workloads, you can only connect to the low services when create on over-provisioned CPUs.

      For ECPUs, this value defaults to 2 ECPUs. For databases that need 2 or more ECPUs, you must specify the number of assigned ECPUs in increment of 1.

    • Storage (GB): Specify the amount of storage, in GB, that you want to make available to your cloned Autonomous Database, and it depends on the storage available to use. For full clones, the size of the source database determines the minimum amount of storage you can make available.
      • Default: 1024 GB
      • Minimum: 32 GB
      • Increment: 1 GB
    • Auto scaling: Enable or disable auto scaling, which permits Autonomous Database to automatically use up to three times the allocated CPUs as the workload on the database increases.

    Create administrator credentials

    Set the password for the Autonomous Database administrator user by entering a password that meets the following criteria.

    • Password cannot be one of the three most recently used passwords of the source database
    • Between 12 and 30 characters long
    • Contains at least one lowercase letter
    • Contains at least one uppercase letter
    • Contains at least one number
    • Does not contain the double quotation mark (")
    • Does not contain the string "admin", regardless of casing

    Use this password when accessing the service console and when using a SQL client tool.

    Configure Network Access

    You can change the access control list to enable or disable database-level access control or add or modify entries to the access control list.

    • Click Modify Access Control.

    • Select the Enable database level access control check box.

    • Click Access Control Rule.

      Note: The database-level access control will be enabled without any IP addresses in the access control list. Enabling an access control list with an empty list of IP addresses makes the database inaccessible to all clients.

    • Specify the following types of addresses in your list by using the IP notation type drop-down selector:
      • IP Address allows you to specify one or more individual public IP addresses. Use commas to separate your addresses in the input field.

      • CIDR Block allows you to specify one or more ranges of public IP addresses using CIDR notation. Use commas to separate your CIDR block entries in the input field.
    Advanced Options:
    • Encryption Key:
      • Clone from a database instance: The source and the target ACD must be the same Keystore type. When the source is OKV, the target must also be the same OKV destination.

      • Clone from a backup: The source and the target ACDs can be different Keystore types. When the source is OKV, the target must also be the same OKV destination.
    • Database In-memory:
      • Enable database In-memory: It requires at least four OCPUs and a percentage of the System Global Area (SGA) to enable in-memory. If you enable In-memory, select the percentage of SGA to allocate to the IM Column Store. In-memory may have an impact on the autonomous database's performance if a large amount of memory is allocated or if it is disabled.
    • Management: Choose a Character Set and National Character from the drop-down list.
    • 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.
  6. Click Create Autonomous Database Clone.

The Console displays the details page for the new clone of your database and the service begins provisioning the Autonomous Database. Note the following:

  • The new clone displays the Provisioning lifecycle state until the provisioning process completes.
  • The source database remains in the Available lifecycle state.
  • Backups associated with the source database are not cloned for either the full-clone or the metadata-clone option.

The Clone source is displayed in the General Information section of the cloned database details page. Click the name to view details of the source database. Note that if the source database is deleted, then this key/value pair is not displayed.

Clone an Autonomous Database Backup

Follow these steps to clone an autonomous database on an Oracle Exadata Cloud@Customer system.

You can use the cloning feature to create a point-in-time copy of your Autonomous Database for purposes such as testing, development, or analytics. To clone only the database schema of your source database, choose the metadata clone option.

Note

If IM is enabled, the source In-Memory Column Store settings or parameters will not be applied to the clone. However, you can enable In-Memory Column Store like a normal ADB creation flow.

Clone Types

The clone feature offers the following two types of Autonomous Database clones:
  • The full-clone option creates a database that includes the metadata and data from the source database.
  • The metadata-clone option creates a database that includes only the metadata from the source database.

Steps

  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
  2. Click Autonomous Databases.
  3. In the list of Autonomous Databases, click the display name of the database you want to clone.
  4. Under Resources, click Backups.
  5. In the list of backups, find the backup that you want to clone, click the action icon (three dots), and then click Create Clone.
  6. On the Create Autonomous Database Clone page, provide the following information:

    Provide basic information for the Autonomous Database.

    • Choose a compartment: Your current compartment is the default selection but you can select a different compartment in which to create the clone from the drop-down list.
    • Source database name: The name of the source database displays in the read-only Source database name field.
    • Display name: Enter a description or other information to identify the database clone. You can change the display name any time and it does not have to be unique. Avoid entering confidential information.
    • Database name: Enter a database name for the clone that contains only letters and numbers, begins with a letter. Avoid entering confidential information.
    • Region: Choose your preferred region to place the clone database.
    • Exadata Infrastructure: You can choose to create the database clone in the same Exadata Infrastructure where the source database resides, or you can choose a different compartment by clicking CHANGE COMPARTMENT and choosing one from the drop-down list.
    • Autonomous Exadata VM Cluster: You can choose to create the database clone in the same Autonomous Exadata VM Cluster where the source database resides, or you can choose a different compartment by clicking CHANGE COMPARTMENT and choosing one from the drop-down list.
    • Autonomous Container Database: You can choose to create the database clone in the same compartment and container database as the source database, or you can choose a different compartment by clicking CHANGE COMPARTMENT, and a different container database by choosing one from the drop-down list.
      Note

      When the target Autonomous Exadata VM Cluster is the same as the source, then the database name cannot be the same as the source database name.

    • Configure the database: Free Instance: Toggle the Free instance button on, if you want to create an Oracle Autonomous Database for Developers instance. ECPU count and Storage (GB) are auto-populated with 4 and 32 respectively because Oracle Autonomous Database for Developers comes fixed at 4 ECPUs and 32GB storage Compute auto-scaling is disabled because developer database instances do not support manual or auto-scaling.
      Note

      • As developer database instances can only be created on ECPU-based ACDs without Autonomous Data Guard, the Free instance toggle button is disabled for ACDs with OCPU, Autonomous Data Guard, or both.
      • To successfully clone a backup to an Oracle Autonomous Database for Developers instance, the current storage allocation of the backup database must be 32GB. In case, this condition is not met, you can try cloning the database instance to a developer database, as long as its actual used space, rounded up to the next GB, must be <= 32GB.

    Configure the database

    • CPU Count: Select the number of CPUs for your clone database from the list of provisionable CPUs.

      After the clone, you can resize to a lower value if needed. You can even resize the CPU count to less than 1 OCPU (0.1 to 0.9 in increments of 0.1 OCPUs) to databases that do not need a full CPU. This allows you to overprovision CPU and run more databases on each infrastructure instance. Note that fractional CPU applies to OCPU only.

      There is a minimum requirement of 1 OCPU or 4 ECPUs for an Autonomous Database clone from Backup.

      The total number of CPUs available to all databases within the Autonomous Exadata VM Cluster depends on the infrastructure shape and what is already allocated to other Autonomous Databases.

      The CPU type, that is, OCPU or ECPU is determined by the parent Autonomous Exadata VM Cluster resource's compute type.

      The time taken to clone an Autonomous Database depends on the CPU Count and the network bandwidth between the Backup Destination and the target Autonomous Container Database.

      You can also select a fractional OCPU value for databases that do not need an entire OCPU. This allows you to overprovision CPU and run more databases on each infrastructure instance. Refer to CPU Overprovisioning for more details.

      For databases that need 2 or more ECPUs, you must specify the number of assigned ECPUs in increment of 1.

      Note

      CPU Overprovisioning is not allowed with ECPUs.

      Databases with CPU over-provisioning can only connect to the tp and low services for the Autonomous Database for Transaction Processing and Mixed Workloads workloads. In the case of an Autonomous Database for Analytics and Data Warehousing workloads, you only connect to the low services when created on over-provisioned CPUs.

    • Storage (GB): Specify the amount of storage, in GB, that you want to make available to your cloned Autonomous Database, and it depends on the storage available to use.
      • Default/Minimum: Allocated storage of the source database
      • Increment: 1 GB
    • Auto scaling: Enable or disable auto-scaling, which permits Autonomous Database to automatically use up to three times the allocated CPUs as the workload on the database increases.

    Create administrator credentials

    Set the password for the Autonomous Database administrator user by entering a password that meets the following criteria.

    • Password cannot be one of the three most recently used passwords of the source database
    • Between 12 and 30 characters long
    • Contains at least one lowercase letter
    • Contains at least one uppercase letter
    • Contains at least one number
    • Does not contain the double quotation mark (")
    • Does not contain the string "admin", regardless of casing

    Use this password when accessing the service console and when using a SQL client tool.

    Configure Network Access

    You can change the access control list to enable or disable database-level access control or add or modify entries to the access control list.

    • Click Modify Access Control.

    • Select the Enable database level access control check box.

    • Click Access Control Rule.

      Note: The database-level access control will be enabled without any IP addresses in the access control list. Enabling an access control list with an empty list of IP addresses makes the database inaccessible to all clients.

    • Specify the following types of addresses in your list by using the IP notation type drop-down selector:
      • IP Address allows you to specify one or more individual public IP addresses. Use commas to separate your addresses in the input field.

      • CIDR Block allows you to specify one or more ranges of public IP addresses using CIDR notation. Use commas to separate your CIDR block entries in the input field.
    Advanced Options:
    • Encryption Key:
      • Clone from a database instance: The source and the target ACD must be the same Keystore type. When the source is OKV, the target must also be the same OKV destination.

      • Clone from a backup: The source and the target ACDs can be different Keystore types. When the source is OKV, the target must also be the same OKV destination.
    • Database In-memory:
      • Enable database In-memory: It requires at least four OCPUs and a percentage of the System Global Area (SGA) to enable in-memory. If you enable In-memory, select the percentage of SGA to allocate to the IM Column Store. In-memory may have an impact on the autonomous database's performance if a large amount of memory is allocated or if it is disabled.
    • Management: Choose a Character Set and National Character from the drop-down list.
    • 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.
  7. Click Create Autonomous Database Clone.

The Console displays the details page for the new clone of your database and the service begins provisioning the Autonomous Database. Note the following:

  • The new clone displays the Provisioning lifecycle state until the provisioning process completes.
  • The source database remains in the Available lifecycle state.

Clone a Standby Database

Follow these steps to clone a standby autonomous database on an Oracle Exadata Cloud@Customer system.

You can use the cloning feature to create a point-in-time copy of your Autonomous Database for purposes such as testing, development, or analytics.

Clone Types: The clone feature offers the full-clone option to create a database that includes the metadata and data from the source database.

Steps

  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
  2. Click Autonomous Databases.
  3. In the list of Autonomous Databases, click the display name of the primary database.
  4. Under Resources, click Autonomous Data Guard.
  5. In the list of standby databases, find the database that you want to clone, and then click the display name to view details.
  6. From the More Actions drop-down list, select Create Clone.
  7. On the Create Autonomous Database Clone page, provide the following information:

    In the Clone Type section, select Full Clone.

    Clone Source: You can clone the standby database only from a backup.
    • Clone from a backup: Creates a clone from a database backup. If you choose this option, select one of the following options:
      • Specify a timestamp: Creates a point-in-time clone.
      • Select from a list of backups: Creates a clone using all data from the specified backup. To limit your list of backups to a specific date range, enter the starting date in the From field and the ending date in the To field.

    Provide basic information for the Autonomous Database.

    • Choose a compartment: Your current compartment is the default selection but you can select a different compartment in which to create the clone from the drop-down list.
    • Source database name: The name of the source database displays in the read-only Source database name field.
    • Display name: Enter a description or other information to identify the database clone. You can change the display name any time and it does not have to be unique. Avoid entering confidential information.
    • Database name: Enter a database name for the clone that contains only letters and numbers, begins with a letter. Avoid entering confidential information.
    • Three additional fields are displayed if you opt to clone from a backup.
      • Exadata Infrastructure: You can choose to create the database clone in the same Exadata Infrastructure where the source database resides, or you can choose a different compartment by clicking CHANGE COMPARTMENT and choosing one from the drop-down list.
      • Autonomous Exadata VM Cluster: You can choose to create the database clone in the same Autonomous Exadata VM Cluster where the source database resides, or you can choose a different compartment by clicking CHANGE COMPARTMENT and choosing one from the drop-down list.
    • Autonomous Container Database: You can choose to create the database clone in the same compartment and container database as the source database, or you can choose a different compartment by clicking CHANGE COMPARTMENT, and a different container database by choosing one from the drop-down list.
    • Configure the database: Free Instance: Toggle the Free instance button on, if you want to create an Oracle Autonomous Database for Developers instance. ECPU count and Storage (GB) are auto-populated with 4 and 32 respectively because Oracle Autonomous Database for Developers comes fixed at 4 ECPUs and 32GB storage Compute auto-scaling is disabled because developer database instances do not support manual or auto-scaling.
      Note

      • As developer database instances can only be created on ECPU-based ACDs without Autonomous Data Guard, the Free instance toggle button is disabled for ACDs with OCPU, Autonomous Data Guard, or both.
      • To successfully clone a backup to an Oracle Autonomous Database for Developers instance, the current storage allocation of the backup database must be 32GB.

    Configure the database

    • CPU Count: There is a minimum requirement of 1 OCPU or 4 ECPUs for an Autonomous Database clone from Backup.

      Specify the number of OCPU for your database. The total number of cores available to all databases within the Autonomous Exadata Infrastructure depends on the infrastructure shape and what is already allocated to other Autonomous Databases.

      The time taken to clone an Autonomous Database depends on the CPU Count and the network bandwidth between the Backup Destination and the target Autonomous Container Database.

      The CPU type, that is, OCPU or ECPU is determined by the parent Autonomous Exadata VM Cluster resource's compute type.

      For databases that need 2 or more ECPUs, you must specify the number of assigned ECPUs in increment of 1.

      Note

      CPU Overprovisioning is not allowed with ECPUs.

      For OCPUs, you can assign a fractional OCPU value from 0.1 to 0.9 (in increments of 0.1 OCPU) to databases that do not need a full OCPU. For databases that need 1 or more OCPUs, you must specify the number of assigned OCPUs as an integer. For example, you cannot assign 3.5 OCPUs to a database. The next available number of OCPUs above 3 is 4.

      Databases with CPU over-provisioning can only connect to the tp and low services for the Autonomous Database for Transaction Processing and Mixed Workloads workloads. In the case of an Autonomous Database for Analytics and Data Warehousing workloads, you only connect to the low services when created on over-provisioned CPUs.

    • Storage (GB): Specify the amount of storage, in GB, that you want to make available to your cloned Autonomous Database, and it depends on the storage available to use. For full clones, the size of the source database determines the minimum amount of storage you can make available.
      • Default: 1024 GB
      • Minimum: 32 GB
      • Increment: 1 GB
    • Auto scaling: Enabling auto-scaling allows the system o automatically use up to three times more CPU and I/O resources to meet the workload demand.

    Create administrator credentials

    Set the password for the Autonomous Database administrator user by entering a password that meets the following criteria.

    • Password cannot be one of the three most recently used passwords of the source database
    • Between 12 and 30 characters long
    • Contains at least one lowercase letter
    • Contains at least one uppercase letter
    • Contains at least one number
    • Does not contain the double quotation mark (")
    • Does not contain the string "admin", regardless of casing

    Use this password when accessing the service console and when using a SQL client tool.

    Configure Network Access

    You can change the access control list to enable or disable database-level access control or add or modify entries to the access control list.

    • Click Modify Access Control.

    • Select the Enable database level access control check box.

    • Click Access Control Rule.

      Note: The database-level access control will be enabled without any IP addresses in the access control list. Enabling an access control list with an empty list of IP addresses makes the database inaccessible to all clients.

    • Specify the following types of addresses in your list by using the IP notation type drop-down selector:
      • IP Address allows you to specify one or more individual public IP addresses. Use commas to separate your addresses in the input field.

      • CIDR Block allows you to specify one or more ranges of public IP addresses using CIDR notation. Use commas to separate your CIDR block entries in the input field.
    Advanced Options:
    • Encryption Key:
      • Clone from a database instance: The source and the target ACD must be the same Keystore type. When the source is OKV, the target must also be the same OKV destination.

      • Clone from a backup: The source and the target ACDs can be different Keystore types. When the source is OKV, the target must also be the same OKV destination.
    • Management: Choose a Character Set and National Character from the drop-down list.
    • 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. Click Create Autonomous Database Clone.

The Console displays the details page for the new clone of your database and the service begins provisioning the Autonomous Database. Note the following:

  • The new clone displays the Provisioning lifecycle state until the provisioning process completes.
  • The source database remains in the Available lifecycle state.
  • Backups associated with the source database are not cloned for either the full-clone or the metadata-clone option.

The Clone source is displayed in the General Information section of the cloned database details page. Click the name to view details of the source database. Note that if the source database is deleted, then this key/value pair is not displayed.

Related Topics

Clone a Standby Database Backup

Follow these steps to clone an autonomous database backup on an Oracle Exadata Database Service on Cloud@Customer system.

You can use the cloning feature to create a point-in-time copy of your Autonomous Database for purposes such as testing, development, or analytics. To clone only the database schema of your source database, choose the metadata clone option.

Clone Types

The clone feature offers the following two types of Autonomous Database clones:
  • The full-clone option creates a database that includes the metadata and data from the source database.
  • The metadata-clone option creates a database that includes only the metadata from the source database.

Steps

  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
  2. Click Autonomous Databases.
  3. In the list of Autonomous Databases, click the display name of the primary database.
  4. Under Resources, click Autonomous Data Guard.
  5. In the list of standby databases, find the database that you want to clone, and then click the display name to view details.
  6. Under Resources, click Backups.
  7. In the list of backups, find the backup that you want to clone, click the action icon (three dots), and then click Create Clone.
  8. On the Create Autonomous Database Clone page, provide the following information:

    In the Clone Type section, select Full Clone.

    Clone Source: The clone source section displays the source backup details.

    Provide basic information for the Autonomous Database.

    • Choose a compartment: Your current compartment is the default selection but you can select a different compartment in which to create the clone from the drop-down list.
    • Source database name: The name of the source database displays in the read-only Source database name field.
    • Display name: Enter a description or other information to identify the database clone. You can change the display name any time and it does not have to be unique. Avoid entering confidential information.
    • Database name: Enter a database name for the clone that contains only letters and numbers, begins with a letter. Avoid entering confidential information.
    • Exadata Infrastructure: You can choose to create the database clone in the same Exadata Infrastructure where the source database resides, or you can choose a different compartment by clicking CHANGE COMPARTMENT and choosing one from the drop-down list.
    • Autonomous Exadata VM Cluster: You can choose to create the database clone in the same Autonomous Exadata VM Cluster where the source database resides, or you can choose a different compartment by clicking CHANGE COMPARTMENT and choosing one from the drop-down list.
    • Autonomous Container Database: You can choose to create the database clone in the same compartment and container database as the source database, or you can choose a different compartment by clicking CHANGE COMPARTMENT, and a different container database by choosing one from the drop-down list.
      Note

      When the target Autonomous Exadata VM Cluster is the same as the source, then the database name cannot be the same as the source database name.

    • Configure the database: Free Instance: Toggle the Free instance button on, if you want to create an Oracle Autonomous Database for Developers instance. ECPU count and Storage (GB) are auto-populated with 4 and 32 respectively because Oracle Autonomous Database for Developers comes fixed at 4 ECPUs and 32GB storage Compute auto-scaling is disabled because developer database instances do not support manual or auto-scaling.
      Note

      • As developer database instances can only be created on ECPU-based ACDs without Autonomous Data Guard, the Free instance toggle button is disabled for ACDs with OCPU, Autonomous Data Guard, or both.
      • To successfully clone a backup to an Oracle Autonomous Database for Developers instance, the current storage allocation of the backup database must be 32GB.

    Configure the database

    • CPU Count: Specify the number of CPUs for your clone database. The total number of CPUs available to all databases within the Autonomous Exadata Infrastructure depends on the infrastructure shape and what is already allocated to other Autonomous Databases.

      After the clone, you can resize it to a lower value if needed. You can even resize to a fractional OCPU value to databases that do not need a full CPU. This allows you to overprovision CPU and run more databases on each infrastructure instance. Note that fractional CPU applies to OCPU only.

      Note

      The time taken to clone an ADB depends on the CPU Count and the network bandwidth between the Backup Destination and the target ACD.

      The selected CPU count is validated against a list of provisionable CPUs, and if the database can not be scaled up to the chosen CPU count, you will be provided with the two nearest provisionable CPU values.

      You can use the GetAutonomousContainerDatabase API to get a complete list of provisionable CPU values.

      There is a minimum requirement of 1 OCPUs or 4 ECPUs for an Autonomous Database clone from Backup.

      The CPU type, that is, OCPU or ECPU is determined by the parent Autonomous Exadata VM Cluster resource's compute type.

      For databases that need 2 or more ECPUs, you must specify the number of assigned ECPUs in increment of 1.

      Note

      CPU Overprovisioning is not allowed with ECPUs.

      For OCPUs, you can assign a fractional OCPU value from 0.1 to 0.9 (in increments of 0.1 OCPU) to databases that do not need a full OCPU. For databases that need 1 or more OCPUs, you must specify the number of assigned OCPUs as an integer. For example, you cannot assign 3.5 OCPUs to a database. The next available number of OCPUs above 3 is 4.

      Databases with CPU over-provisioning can only connect to the tp and low services for the Autonomous Database for Transaction Processing and Mixed Workloads workloads. In the case of an Autonomous Database for Analytics and Data Warehousing workloads, you only connect to the low services when created on over-provisioned CPUs.

    • Storage (GB): Specify the amount of storage, in GB, that you want to make available to your cloned Autonomous Database, and it depends on the storage available to use.
      • Default/Minimum: Allocated storage of the source database
      • Increment: 1 GB
    • Auto scaling: Enabling auto-scaling allows the system o automatically use up to three times more CPU and I/O resources to meet the workload demand.

    Create administrator credentials

    Set the password for the Autonomous Database administrator user by entering a password that meets the following criteria.

    • Password cannot be one of the three most recently used passwords of the source database
    • Between 12 and 30 characters long
    • Contains at least one lowercase letter
    • Contains at least one uppercase letter
    • Contains at least one number
    • Does not contain the double quotation mark (")
    • Does not contain the string "admin", regardless of casing

    Use this password when accessing the service console and when using a SQL client tool.

    Configure Network Access

    You can change the access control list to enable or disable database-level access control or add or modify entries to the access control list.

    • Click Modify Access Control.

    • Select the Enable database level access control check box.

    • Click Access Control Rule.

      Note: The database-level access control will be enabled without any IP addresses in the access control list. Enabling an access control list with an empty list of IP addresses makes the database inaccessible to all clients.

    • Specify the following types of addresses in your list by using the IP notation type drop-down selector:
      • IP Address allows you to specify one or more individual public IP addresses. Use commas to separate your addresses in the input field.

      • CIDR Block allows you to specify one or more ranges of public IP addresses using CIDR notation. Use commas to separate your CIDR block entries in the input field.
    Advanced Options:
    • Encryption Key:
      • Clone from a database instance: The source and the target ACD must be the same Keystore type. When the source is OKV, the target must also be the same OKV destination.

      • Clone from a backup: The source and the target ACDs can be different Keystore types. When the source is OKV, the target must also be the same OKV destination.
    • Management: Choose a Character Set and National Character from the drop-down list.
    • 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.
  9. Click Create Autonomous Database Clone.

The Console displays the details page for the new clone of your database and the service begins provisioning the Autonomous Database. Note the following:

  • The new clone displays the Provisioning lifecycle state until the provisioning process completes.
  • The source database remains in the Available lifecycle state.

Terminate an Autonomous Database

Follow these steps to terminate an Autonomous Database on an Oracle Exadata Database Service on Cloud@Customer system.

Note

If the standby ACD is in snapshot standby mode, then you cannot delete an ADB in the primary ACD.

WARNING:

Terminating an Autonomous Database permanently deletes it. The database data will be lost when the system is terminated. However, automatic backups are not deleted if you have chosen Recovery Appliance or NFS as a backup destination. You can delete automatic backups directly from the Recovery Appliance or NFS.

  1. Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
  2. Click Autonomous Databases.
  3. In the list of Autonomous Databases, click the display name of the database you wish to terminate.
  4. From the More Actions drop-down list, select Terminate.
  5. Confirm that you wish to terminate your Autonomous Database in the confirmation dialog.
  6. Click Terminate Autonomous Database.

API to Manage Autonomous Databases

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 Databases.

Operation REST API Endpoint

Create an Autonomous Database

CreateAutonomousDatabase

View a list of Autonomous Databases

ListAutonomousDatabases

View details of an Autonomous Database

GetAutonomousDatabase

View a list of character sets supported by Autonomous Database. ListAutonomousDatabaseCharacterSets

Set the password of an Autonomous Database's ADMIN user

UpdateAutonomousDatabase

Scale the CPU core count or storage of an Autonomous Database

UpdateAutonomousDatabase

Enable or disable auto scaling for an Autonomous Database

UpdateAutonomousDatabase

Move an Autonomous Database to another compartment

ChangeAutonomousDatabaseCompartment

Stop or start an Autonomous Database

StartAutonomousDatabase

Stop or start an Autonomous Database

StopAutonomousDatabase

Restart an Autonomous Database

RestartAutonomousDatabase

Back up an Autonomous Database manually

CreateAutonomousDatabaseBackup

View the list of Autonomous Database backups

ListAutonomousDatabaseBackups

Restore an Autonomous Database

RestoreAutonomousDatabase

Clone an Autonomous Database

CreateAutonomousDatabase

Terminate an Autonomous Database

DeleteAutonomousDatabase

Monitor Performance with Autonomous Database Metrics

You can monitor the health, capacity, and performance of your Autonomous Databases with metrics, alarms, and notifications. You can use Oracle Cloud Infrastructure console or Monitoring APIs to view metrics.

View Top Six Metrics for an Autonomous Database

Displays the top six metrics that are available in the metrics section on the Autonomous Database details page.

To view metrics you must have the required access as specified in an Oracle Cloud Infrastructure policy (whether you're using the Console, the REST API, or other tools). See Getting Started with Policies for information on policies.

Perform the following prerequisite steps as necessary:
  • Open the Oracle Cloud Infrastructure console by clicking the hamburger menu next to Oracle Cloud.

  • From the Oracle Cloud Infrastructure left navigation list click Oracle Databases > Exadata Cloud@Customer.

  • On the Autonomous Databases page select an Autonomous Database from the links under the Name column.

To view metrics for an Autonomous Database instance:

  1. On the Autonomous Database Details page, under Resources, click Metrics.
  2. There is a chart for each metric. In each chart, you can select the Interval and Statistic or use the default values.
  3. To create an alarm on a metric, click Options and select Create an Alarm on this Query.

    See Managing Alarms for information on setting and using alarms.

    For more information about metrics see Database Metrics.

    You can also use the Monitoring API to view metrics. See Monitoring API for more information.

View Aggregated Metrics for Autonomous Databases in a Compartment

Learn to view aggregated metrics for Autonomous Databases in a compartment.

To view metrics you must have the required access as specified in an Oracle Cloud Infrastructure policy (whether you're using the Console, the REST API, or other tool). See Getting Started with Policies for information on policies

Perform the following prerequisite steps as necessary:
  • Open the Oracle Cloud Infrastructure console by clicking the hamburger menu next to Oracle Cloud.

  • From the left navigation list click Solutions and Platform > Monitoring > Service Metrics.

To use the metrics service to view Autonomous Database metrics:

  1. On the Service Metrics page, under Compartment select your compartment.
  2. On the Service Metrics page, under Metric Namespace select oci_autonomous_database.
  3. If there are multiple Autonomous Databases in the compartment you can show metrics aggregated across the Autonomous Databases by selecting Aggregate Metric Streams.
  4. If you want to limit the metrics you see, next to Dimensions click Add (click Edit if you have already added dimensions).
    1. In the Dimension Name field select a dimension.
    2. In the Dimension Value field select a value.
    3. Click Done.
    4. In the Edit dimensions dialog click +Additional Dimension to add an additional dimension. Click x to remove a dimension.

To create an alarm on a specific metric, click Options and select Create an Alarm on this Query. See Managing Alarms for information on setting and using alarms.

Autonomous Database Metrics and Dimensions

You can limit the instances where you see metrics with dimensions. The available dimensions include: workload type, instance display name, region, and the instance OCID.

Use dimensions by selecting values in the Oracle Cloud Infrastructure Console Service Metrics page or by setting dimension values with the API. See View Aggregated Metrics for Autonomous Databases in a Compartment to view metrics and to select metric dimensions.

See Database Metrics for a list of the database metrics and dimensions.