No longer used. For Autonomous Database on dedicated Exadata infrastructure, the container database is created within a specified {@code cloudAutonomousVmCluster}.
The OCID of the Autonomous VM Cluster.
The availability domain of the Autonomous Container Database.
Sum of CPUs available on the Autonomous VM Cluster + Sum of reclaimable CPUs available in the Autonomous Container Database. Note: Numbers greater than Number.MAX_SAFE_INTEGER will result in rounding issues.
The OCID of the cloud Autonomous Exadata VM Cluster.
The OCID of the compartment.
The compute model of the Autonomous Container Database. For Autonomous Database on Dedicated Exadata Infrastructure, the CPU type (ECPUs or OCPUs) is determined by the parent Autonomous Exadata VM Cluster's compute model. ECPU compute model is the recommended model and OCPU compute model is legacy. See Compute Models in Autonomous Database on Dedicated Exadata Infrastructure for more details.
The Database name for the Autonomous Container Database. The name must be unique within the Cloud Autonomous VM Cluster, starting with an alphabetic character, followed by 1 to 7 alphanumeric characters.
The value above which an Autonomous Database will be split across multiple nodes. This value defaults to 16 when the "CPU per VM" value on the Autonomous VM Cluster is greater than 16. Otherwise, it defaults to the "CPU per VM" value. Note: Numbers greater than Number.MAX_SAFE_INTEGER will result in rounding issues.
Deprecated. The {@code DB_UNIQUE_NAME} value is set by Oracle Cloud Infrastructure. Do not specify a value for this parameter. Specifying a value for this field will cause Terraform operations to fail.
Oracle Database version of the Autonomous Container Database.
Defined tags for this resource. Each key is predefined and scoped to a namespace. For more information, see Resource Tags.
The user-provided name for the Autonomous Container Database.
This option determines whether to open an Autonomous Database across the maximum number of nodes or the least number of nodes. The default will be for the minimum number of VMs.
DST Time-zone File version of the Autonomous Container Database.
Free-form tags for this resource. Each tag is a simple key-value pair with no predefined name, type, or namespace. For more information, see Resource Tags.
Example: {@code {\"Department\": \"Finance\"}}
The OCID of the Autonomous Container Database.
The infrastructure type this resource belongs to.
Indicates if an automatic DST Time Zone file update is enabled for the Autonomous Container Database. If enabled along with Release Update, patching will be done in a Non-Rolling manner.
Key History Entry.
The OCID of the key store of Oracle Vault.
The wallet name for Oracle Key Vault.
The OCID of the key container that is used as the master encryption key in database transparent data encryption (TDE) operations.
The OCID of the key container version that is used in database transparent data encryption (TDE) operations KMS Key can have multiple key versions. If none is specified, the current key version (latest) of the Key Id is used for the operation. Autonomous Database Serverless does not use key versions, hence is not applicable for Autonomous Database Serverless instances.
The largest Autonomous Database (CPU) that can be created in a new Autonomous Container Database. Note: Numbers greater than Number.MAX_SAFE_INTEGER will result in rounding issues.
The OCID of the last maintenance run.
Additional information about the current lifecycle state.
The current state of the Autonomous Container Database.
List of One-Off patches that has been successfully applied to Autonomous Container Database
The amount of memory (in GBs) enabled per ECPU or OCPU in the Autonomous VM Cluster. Note: Numbers greater than Number.MAX_SAFE_INTEGER will result in rounding issues.
Enabling SHARED server architecture enables a database server to allow many client processes to share very few server processes, thereby increasing the number of supported users.
The OCID of the next maintenance run.
The OCID of the last patch applied on the system.
Database patch model preference.
An array of CPU values that can be used to successfully provision a single Autonomous Database.
The number of CPUs provisioned in an Autonomous Container Database. Note: Numbers greater than Number.MAX_SAFE_INTEGER will result in rounding issues.
CPUs that continue to be included in the count of CPUs available to the Autonomous Container Database even after one of its Autonomous Database is terminated or scaled down. You can release them to the available CPUs at its parent Autonomous VM Cluster level by restarting the Autonomous Container Database. Note: Numbers greater than Number.MAX_SAFE_INTEGER will result in rounding issues.
The number of CPUs reserved in an Autonomous Container Database. Note: Numbers greater than Number.MAX_SAFE_INTEGER will result in rounding issues.
The Data Guard role of the Autonomous Container Database or Autonomous Database, if Autonomous Data Guard is enabled.
The service level agreement type of the container database. The default is STANDARD.
The scheduling detail for the quarterly maintenance window of the standby Autonomous Container Database. This value represents the number of days before scheduled maintenance of the primary database. Note: Numbers greater than Number.MAX_SAFE_INTEGER will result in rounding issues.
The date and time the Autonomous Container Database was created.
The timestamp of last successful backup. Here NULL value represents either there are no successful backups or backups are not configured for this Autonomous Container Database.
The date and time the Autonomous Container Database will be reverted to Standby from Snapshot Standby.
The number of CPUs allocated to the Autonomous VM cluster. Note: Numbers greater than Number.MAX_SAFE_INTEGER will result in rounding issues.
The next maintenance version preference.
The percentage of CPUs to reserve for a single node Autonomous Database, in increments of 25. Note: Numbers greater than Number.MAX_SAFE_INTEGER will result in rounding issues.
An Autonomous Container Database is a container database service that enables the customer to host one or more databases within the container database. A basic container database runs on a single Autonomous Exadata Infrastructure from an availability domain without the Extreme Availability features enabled.