Data Source: oci_database_autonomous_container_database

This data source provides details about a specific Autonomous Container Database resource in Oracle Cloud Infrastructure Database service.

Gets information about the specified Autonomous Container Database.

Example Usage

data "oci_database_autonomous_container_database" "test_autonomous_container_database" {
	#Required
	autonomous_container_database_id = oci_database_autonomous_container_database.test_autonomous_container_database.id
}

Argument Reference

The following arguments are supported:

• autonomous_container_database_id - (Required) The Autonomous Container Database OCID.

Attributes Reference

The following attributes are exported:

• autonomous_exadata_infrastructure_id - No longer used. For Autonomous Database on dedicated Exadata infrastructure, the container database is created within a specified cloudAutonomousVmCluster.

• autonomous_vm_cluster_id - The OCID of the Autonomous VM Cluster.

• availability_domain - The availability domain of the Autonomous Container Database.

• available_cpus - Sum of CPUs available on the Autonomous VM Cluster + Sum of reclaimable CPUs available in the Autonomous Container Database.
  For Autonomous Databases on Dedicated Exadata Infrastructure, the CPU type (OCPUs or ECPUs) is determined by the parent Autonomous Exadata VM Cluster’s compute model. See Compute Models in Autonomous Database on Dedicated Exadata Infrastructure for more details.

• backup_config - Backup options for the Autonomous Container Database.

  • backup_destination_details - Backup destination details.
    • dbrs_policy_id - The OCID of the DBRS policy used for backup.
    • id - The OCID of the backup destination.
    • internet_proxy - Proxy URL to connect to object store.
    • type - Type of the database backup destination.
    • vpc_password - For a RECOVERY_APPLIANCE backup destination, the password for the VPC user that is used to access the Recovery Appliance.
    • vpc_user - For a RECOVERY_APPLIANCE backup destination, the Virtual Private Catalog (VPC) user that is used to access the Recovery Appliance.
  • recovery_window_in_days - Number of days between the current and the earliest point of recoverability covered by automatic backups. This value applies to automatic backups. After a new automatic backup has been created, Oracle removes old automatic backups that are created before the window. When the value is updated, it is applied to all existing automatic backups. If the number of specified days is 0 then there will be no backups.

• cloud_autonomous_vm_cluster_id - The OCID of the cloud Autonomous Exadata VM Cluster.

• compartment_id - The OCID of the compartment.

• compute_model - 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.

• db_name - 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.

• db_split_threshold - The CPU value beyond which an Autonomous Database will be opened across multiple nodes. The default value of this attribute is 16 for OCPUs and 64 for ECPUs.

• db_unique_name - Deprecated. The 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.

• db_version - Oracle Database version of the Autonomous Container Database.

• defined_tags - Defined tags for this resource. Each key is predefined and scoped to a namespace. For more information, see Resource Tags.

• display_name - The user-provided name for the Autonomous Container Database.

• distribution_affinity - Determines whether an Autonomous Database must be opened across the maximum number of nodes or the least number of nodes. By default, Minimum nodes is selected.

• dst_file_version - DST Time-zone File version of the Autonomous Container Database.

• freeform_tags - 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: {"Department": "Finance"}

• id - The OCID of the Autonomous Container Database.

• infrastructure_type - The infrastructure type this resource belongs to.

• is_dst_file_update_enabled - 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 - Key History Entry.

  • id - The id of the Autonomous Database Vault service key management history entry.
  • kms_key_version_id - 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.
  • time_activated - The date and time the kms key activated.
  • vault_id - The OCID of the Oracle Cloud Infrastructure vault. This parameter and secretId are required for Customer Managed Keys.

• key_store_id - The OCID of the key store of Oracle Vault.

• key_store_wallet_name - The wallet name for Oracle Key Vault.

• key_version_id - (Optional) The OCID of the key version that is used in rotate key operations.

• kms_key_id - The OCID of the key container that is used as the master encryption key in database transparent data encryption (TDE) operations.

• kms_key_version_id - 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.

• largest_provisionable_autonomous_database_in_cpus - The largest Autonomous Database (CPU) that can be created in a new Autonomous Container Database.

• last_maintenance_run_id - The OCID of the last maintenance run.

• lifecycle_details - Additional information about the current lifecycle state.

• list_one_off_patches - List of One-Off patches that has been successfully applied to Autonomous Container Database

• maintenance_window - The scheduling details for the quarterly maintenance window. Patching and system updates take place during the maintenance window.

  • custom_action_timeout_in_mins - Determines the amount of time the system will wait before the start of each database server patching operation. Custom action timeout is in minutes and valid value is between 15 to 120 (inclusive).

  • days_of_week - Days during the week when maintenance should be performed.

    • name - Name of the day of the week.

  • hours_of_day - The window of hours during the day when maintenance should be performed. The window is a 4 hour slot. Valid values are

    • 0 - represents time slot 0:00 - 3:59 UTC - 4 - represents time slot 4:00 - 7:59 UTC - 8 - represents time slot 8:00 - 11:59 UTC - 12 - represents time slot 12:00 - 15:59 UTC - 16 - represents time slot 16:00 - 19:59 UTC - 20 - represents time slot 20:00 - 23:59 UTC

  • is_custom_action_timeout_enabled - If true, enables the configuration of a custom action timeout (waiting period) between database server patching operations.

  • is_monthly_patching_enabled - If true, enables the monthly patching option.

  • lead_time_in_weeks - Lead time window allows user to set a lead time to prepare for a down time. The lead time is in weeks and valid value is between 1 to 4.

  • months - Months during the year when maintenance should be performed.

    • name - Name of the month of the year.

  • patching_mode - Cloud Exadata infrastructure node patching method, either “ROLLING” or “NONROLLING”. Default value is ROLLING.

    IMPORTANT: Non-rolling infrastructure patching involves system down time. See Oracle-Managed Infrastructure Maintenance Updates for more information.

  • preference - The maintenance window scheduling preference.

  • skip_ru - If true, skips the release update (RU) for the quarter. You cannot skip two consecutive quarters. An RU skip request will only be honoured if the current version of the Autonomous Container Database is supported for current quarter.

  • weeks_of_month - Weeks during the month when maintenance should be performed. Weeks start on the 1st, 8th, 15th, and 22nd days of the month, and have a duration of 7 days. Weeks start and end based on calendar dates, not days of the week. For example, to allow maintenance during the 2nd week of the month (from the 8th day to the 14th day of the month), use the value 2. Maintenance cannot be scheduled for the fifth week of months that contain more than 28 days. Note that this parameter works in conjunction with the daysOfWeek and hoursOfDay parameters to allow you to specify specific days of the week and hours that maintenance will be performed.

• memory_per_oracle_compute_unit_in_gbs - The amount of memory (in GBs) enabled per ECPU or OCPU in the Autonomous VM Cluster.

• net_services_architecture - 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.

• next_maintenance_run_id - The OCID of the next maintenance run.

• patch_id - The OCID of the last patch applied on the system.

• patch_model - Database patch model preference.

• provisionable_cpus - An array of CPU values that can be used to successfully provision a single Autonomous Database.

• provisioned_cpus - The number of CPUs provisioned in an Autonomous Container Database.

• reclaimable_cpus - 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.

• reserved_cpus - The number of CPUs reserved in an Autonomous Container Database.

• role - The Data Guard role of the Autonomous Container Database or Autonomous Database, if Autonomous Data Guard is enabled.

• service_level_agreement_type - The service level agreement type of the container database. The default is STANDARD.

• standby_maintenance_buffer_in_days - 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.

• state - The current state of the Autonomous Container Database.

• time_created - The date and time the Autonomous Container Database was created.

• time_of_last_backup - 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.

• time_snapshot_standby_revert - The date and time the Autonomous Container Database will be reverted to Standby from Snapshot Standby.

• total_cpus - The number of CPUs allocated to the Autonomous VM cluster.
  For Autonomous Databases on Dedicated Exadata Infrastructure, the CPU type (OCPUs or ECPUs) is determined by the parent Autonomous Exadata VM Cluster’s compute model.

• vault_id - The OCID of the Oracle Cloud Infrastructure vault.

• version_preference - The next maintenance version preference.

• vm_failover_reservation - The percentage of CPUs reserved across nodes to support node failover. Allowed values are 0%, 25%, and 50%, with 50% being the default option.