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.

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.

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.

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

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.

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.

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.

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.

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.

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;

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.

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.

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.

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.

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

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.

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 from a Backup
  
• Restore to a 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 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.

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.

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.

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.

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.

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.

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.
• View Aggregated Metrics for Autonomous Databases in a Compartment
  Learn to view aggregated metrics for Autonomous Databases in a compartment.
• 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.