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.
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.
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.
Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
Click Autonomous Databases.
Click Create Autonomous Database.
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.
Optionally, you can save the resource configuration as a stack.
To save the resource configuration as a Stack:
Click Save as Stack.
In the resulting Save as
Stack dialog, provide the following details:
Name: (Optional) Provide an
easy-to-remember descriptive name.
Description: (Optional) Enter a
short description.
Compartment: Select a compartment
where this Stack will reside.
Tags: Add tags.
Click Save.
After saving the Stack, the system displays a banner with a
link to the saved Stack.
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:
Open the navigation menu. Under
Developer Services, click
Resource Manager.
Click Stacks.
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.
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.
Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
Choose your Compartment.
In the list of Autonomous Databases, click the display name of the database you
want to administer.
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.
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.
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.
Follow these steps to view detailed information about an autonomous database on an Oracle Exadata Database Service on
Cloud@Customer system.
Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
Click Autonomous Databases.
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.
Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
Click Autonomous Databases.
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.
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
Click Add customer contact and enter the contact email address.
Optionally, click Add customer contacts to add another contact email.
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
Select the email addresses that you are editing. To edit all email addresses, select the top column next to Email.
Click Edit.
On the Edit customer contacts dialog, modify the contact email as needed, and click Save.
Delete Customer Contacts
Select the email addresses to remove. To remove all email addresses, select the top column next to Email.
Click Remove.
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.
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.
Open the navigation menu. Under Oracle Database, click Exadata
Cloud@Customer.
Click Autonomous Databases.
In the list of Autonomous Databases, click the display name of the database you
wish to view details.
On the Autonomous Database Details page, from
the More Actions drop-down list, select Rotate Encryption
Key.
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.
Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
Click Autonomous Databases.
In the list of Autonomous Databases, click the display name of the database you wish to administer.
From the More Actions drop-down list, select
Admin Password.
The Admin Password dialog opens.
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
Enter the password again in the Confirm Password
field.
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.
Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
Click Autonomous Databases.
In the list of Autonomous Databases, click the display name of the database you wish to view details.
Click Scale Up/Down.
Note
This option is not enabled for an Autonomous Database for Developers instance.
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.
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.
Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
Click Autonomous Databases.
In the list of Autonomous Databases, click the display name of the database you wish to view details.
Click Scale Up/Down.
Check Auto Scaling to enable the auto-scaling feature, or uncheck
Auto Scaling to disable the feature.
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.
Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
Click Autonomous Databases.
In the list of Autonomous Databases, click the display name of the database you wish to move.
From the More Actions drop-down list, select
Move Resource.
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.
Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
Click Autonomous Databases.
In the list of Autonomous Databases, click the display name of the database you wish to restart.
Click Restart.
Confirm that you want to restart your Autonomous Database in the confirmation
dialog.
The system stops and then immediately starts your database.
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.
Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
Click Autonomous Databases.
In the list of Autonomous Databases, click the display name of the database you wish to back up.
On the Details page, under Resources, click Backups.
Click Create Manual Backup.
In the Create Manual Backup dialog, enter a name for your backup. Avoid entering confidential information.
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:
Long-term backups are not available with Autonomous Database for Developers instances. See Oracle Autonomous Database for Developers for more details.
Open the navigation menu. Under Oracle Database, click
Exadata Database Service on Cloud@Customer.
Click Autonomous Databases.
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.
Under Resources, click
Backups.
In the Backups section, click Create long-term
backup.
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.
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.
Follow these steps to restore an autonomous database on an Oracle Exadata Database Service on
Cloud@Customer system to a specific point in time.
Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
Click Autonomous Databases.
In the list of Autonomous Databases, click the display name of the database you want to restore.
From the More Actions drop-down list, select Restore.
Click Specify Timestamp.
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-DDHH:MM:SS
GMT).
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
Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
Click Autonomous Databases.
In the list of Autonomous Databases, click the display name of the database you
want to clone.
From the More Actions drop-down list, select Create Clone.
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.
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.
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
Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
Click Autonomous Databases.
In the list of Autonomous Databases, click the display name of the database you
want to clone.
Under Resources, click Backups.
In the list of backups, find the backup that you want to clone, click the
action icon (three dots), and then click Create Clone.
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.
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.
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
Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
Click Autonomous Databases.
In the list of Autonomous Databases, click the display name of the primary
database.
Under Resources, click Autonomous Data Guard.
In the list of standby databases, find the database that you want to clone, and
then click the display name to view details.
From the More Actions drop-down list, select Create Clone.
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.
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.
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
Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
Click Autonomous Databases.
In the list of Autonomous Databases, click the display name of the primary
database.
Under Resources, click Autonomous Data Guard.
In the list of standby databases, find the database that you want to clone, and
then click the display name to view details.
Under Resources, click Backups.
In the list of backups, find the backup that you want to clone, click the
action icon (three dots), and then click Create Clone.
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.
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.
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.
Open the navigation menu. Under Oracle Database, click Exadata Database Service on Cloud@Customer.
Click Autonomous Databases.
In the list of Autonomous Databases, click the display name of the database you wish to terminate.
From the More Actions drop-down list, select
Terminate.
Confirm that you wish to terminate your Autonomous Database in the confirmation
dialog.
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.
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.
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:
On the Autonomous Database Details page, under
Resources, click
Metrics.
There is a chart for each metric. In each chart, you can select the
Interval and Statistic or use the default
values.
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.
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:
On the Service Metrics page, under
Compartment select your compartment.
On the Service Metrics page, under Metric
Namespace select
oci_autonomous_database.
If there are multiple Autonomous Databases in the compartment you can show
metrics aggregated across the Autonomous Databases by selecting
Aggregate Metric Streams.
If you want to limit the metrics you see, next to
Dimensions click Add (click
Edit if you have already added dimensions).
In the Dimension Name field select a
dimension.
In the Dimension Value field select a
value.
Click Done.
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.
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.