You can now create or delete up to 10 PDBs concurrently, even when the container database is in an updating state. However, you cannot create PDBs while a CDB is in updating state due to non-PDB operation.
Provisioned storage servers can be removed from a Cloud Exadata Infrastructure. A "provisioned" storage server refers to one that has had disk groups configured. Refer to the ASM required free disk group capacity and note that an ASM rebalancing operation will need to be completed after storage severs are removed.
With this enhancement, you can now perform concurrent operations on Container Databases (CDBs) and Pluggable Databases (PDBs) alongside Data Guard associations and actions. This improvement significantly enhances efficiency and flexibility in managing your Oracle databases. The supported concurrent operations include:
Creating or deleting a CDB while a Data Guard setup is running on another database within the same Oracle home, and vice versa.
Creating or deleting a PDB while a Data Guard setup is running on another database within the same Oracle home, and vice versa.
Performing Data Guard actions (switchover, failover, and reinstate) while a Data Guard setup is running on another database within the same Oracle home, and vice versa.
Creating or deleting a CDB while concurrently performing Data Guard actions (switchover, failover, and reinstate) on different databases within the same Oracle home, and vice versa.
Creating or deleting a PDB while concurrently performing Data Guard actions (switchover, failover, and reinstate) on different databases within the same Oracle home, and vice versa.
Creating or deleting a CDB while concurrently creating or deleting a PDB of a different CDB within the same Oracle home, and vice versa.
Creating or deleting a CDB concurrently on different databases within the same Oracle home.
Creating or deleting a PDB concurrently on different databases within the same Oracle home.
Performing Data Guard setup concurrently on different databases within the same Oracle home.
Performing Data Guard actions (switchover, failover, and reinstate) concurrently on different databases within the same Oracle home.
Creating or deleting a CDB/PDB, performing Data Guard setup, and performing Data Guard actions (switchover, failover, and reinstate) while simultaneously updating VM Cluster tags.
You can now provision VM clusters with IPv4/IPv6 dual-stack networking in Oracle Exadata Database Service on Dedicated Infrastructure (ExaDB-D). This feature enables organizations to utilize both IPv4 and IPv6 concurrently, providing a cost-effective solution to manage IPv4 address scarcity, ensure compliance with regulatory requirements, and facilitate a smooth transition to IPv6 for future scalability and growth. The following scenarios are supported in this release:.
IPv4/IPv6 dual-stack support for new Exadata VM clusters on the client and backup subnets.
Configure Data Guard to migrate Data from an IPv4-only Exadata VM cluster to a dual stack Exadata VM cluster.
Configure an Application VIP with both IPv4 and IPv6 addresses.
Note
Minimum requirements for configuring a dual stack network:
Exadata System Software 24.1.4
Oracle Database and Oracle Grid Infrastructure:
19c -> 19.26
23ai -> 23.7
Note
Oracle Exadata Database Service on Dedicated Infrastructure supports GUA, BYOIP and ULA IPv6 prefixes. While provisioning a VM Cluster a subnet should have only one IPv6 prefix. ExaDB-D does not support subnet with multiple IPv6 prefixes.
With Long-Term Retention Backup (LTR), you can store full backups for up to 10 years or a shorter duration, enabling you to search for and retrieve archived data to meet compliance, regulatory, or other business requirements. During this retention period, LTR backups can be restored to create a new database, a process referred to as "out-of-place restore."
With this enhancement, you will have the flexibility to plan and apply quarterly infrastructure updates to fit smaller maintenance windows. You can choose to perform maintenance across all infrastructure components in a single window or split them into multiple smaller windows to align with your business needs. Based on your preferred time slots, Oracle automation will perform maintenance on specific infrastructure components across these maintenance windows to ensure all components have software updates applied to meet security and compliance guidelines.
This enhancement provides fine-grained control over VM cluster update operations.
You can now assign granular permissions for VM Cluster operations, such as enabling the DBA group to scale only memory or CPU, allowing the storage administrator group to manage local/Exadata storage, or permitting the security administrator group to add SSH keys to a VM cluster.
This enhancement provides the ability to create and manage multiple local and remote standby databases linked to a primary database, providing flexibility for both data protection and disaster recovery. Local standby databases help minimize data loss, while remote standby databases safeguard against regional failures. This enhancement allows creation of up to 6 standby databases for a primary database.
In a typical Data Guard configuration, two standby databases are commonly used:
Local Standby: A standby database in the same region as the production database is ideal for failover scenarios, offering zero data loss for local failures (such as database, cluster, or availability domain failures). Application failover impact is reduced in this case, as applications continue operating without the performance overhead of communicating with a remote region.
Remote (Cross-Region) Standby: A remote standby database, located in a different region, is typically used for disaster recovery or to offload read-only query processing. A remote standby database setup ensures data protection against regional failures.
Some enterprise customers aim for symmetry after a site switch. For example, they may prefer to have both the primary and local standby in Region 1, and a remote standby with its own local standby in Region 2. In this configuration, there will be three standby databases. After a site switch, you will still have a primary database and a local standby readily available in the new primary region.
Additionally, customers can enhance their configurations by adding another standby database for testing purposes, leveraging our snapshot (read/write) standby capabilities.
Note
Creating a standby database associated with another standby database ("cascading standby") is not supported.
Oracle Exadata Database Service on Dedicated Infrastructure now can accept Microsoft Entra ID (MS-EI) tokens to access the database. Azure users and applications can use the MS-EI token to access the database.
MS-EI integration will be available for databases patched to 19.17 and above. This feature is not available on Oracle Database release 21c.
For information on configuring MS-EI, configuring the database, and configuring the database client, see:
Delegate Access Control service enables Oracle Exadata Database Service Dedicated customers to subscribe to VM and database maintenance and support services, delegate access to service providers, and control when those service providers can access VM and database resources. These service providers include Oracle global support, Oracle cloud support, and Oracle professional services.
In Oracle Data Guard configurations, it's common to have primary and standby databases in a synchronized state, including the same Release Updates (RUs) applied to both database homes. However, there are scenarios where you might need to allow different RUs between the primary and standby database homes, particularly during the patching cycle or for testing purposes.
Create Data Guard Associations:
The primary and standby Oracle Homes must be of the same major database version.
If the primary and standby Oracle Homes are running different RUs, a Data Guard association can be created only if the standby is on the same or higher RU than the primary database.
The home for the standby can be a custom DSI or an Oracle image regardless of whether the primary is running on a custom DSI or Oracle image.
Switchover or Failover Database: The primary and standby Oracle Homes can be of any major database version or running different RUs.
Upgrade Database: The primary and standby Oracle Homes can of different major database versions.
Patch Database: If the primary and standby Oracle Homes are running different RUs, the standby can be patched to a higher RU than the primary database.
Protect your data against unauthorized access and exfiltration with Oracle Cloud Infrastructure Zero Trust Packet Routing (ZPR), a data-aware cloud security control.
Bring-Your-Own-Key (BYOK) allows users to import their own keys or key versions instead of having the vault service generate the keys internally. BYOK enables users to import keys into the OCI Vault service and utilize their imported keys for database encryption. Currently, when an ExaDB-D customer employs BYOK to create a new database (CDB), the customer's key is only used for the CDB, while a system-generated key version is assigned to the PDB. Users cannot assign specific key versions to the PDBs.
With this enhancement:
Associate a key version with both CDB and PDB.
Rotate keys independently at the CDB and PDB levels.
Note
In a Data Guard association, key rotation is only possible for the primary database, not the standby database.
This enhancement allows you to use the Recovery Service or Object Storage to back up the standby databases.
Before getting started, note the following:
You can schedule automatic backups and configure retention periods and backup schedules on the standby database.
You can create a database in another availability domain (AD) within the same region or a different region from a backup of the standby database.
Backups can be configured on the primary database, the standby database, or both. However, when configured, the primary and standby databases must share the same backup destination.
For backups in the Recovery Service, the primary database can be restored or recovered from the backups of either the standby database or the primary database. Similarly, the standby database can be restored or recovered from the backups of either the primary database or the standby database.
For backups in Object Storage, the primary and standby databases can only be restored or recovered using their respective backups.
The backup destination of the primary database and standby database in a Data Guard association must be the same. For example, if the backup destination of the primary database is Recovery Service, then the backup destination of the standby database must also be Recovery Service. Similarly, if the backup destination of the standby database is Recovery Service, then the backup destination of the primary database must also be Recovery Service.
The backup destination can be changed only after disabling the backup on either the primary or standby database in a Data Guard association. For example, if the backup destination of both the primary and standby databases is Object Storage and you want to change the backup destination of the primary database to Recovery Service, you must first disable the backup on the standby database.
If automatic backups are configured on the primary database, upon switchover, the backups will continue on the new standby database.
If automatic backups are configured on the standby database, upon failover, the backups will continue on the new primary database. However, the backups will be disabled on the new standby database.
Recovery Service supports multicloud Oracle Databases, such as Oracle Database@Azure, and provides the flexibility to store backups in the same cloud location where the source database resides.
Recovery Service creates protected databases and related backups in Oracle Cloud by default. You can optionally override this default behavior for your multicloud Oracle Databases such as Oracle Database@Azure.
If you enable the Store backups in the same cloud provider as the database option for a protection policy, then the policy-linked protected database and backups will be stored in the same cloud location where the Oracle Database is provisioned. For example, for Oracle Database@Azure, Recovery Service stores the associated protected database backups in Azure if you have selected the Store backups in the same cloud provider as the database option in the protection policy.
If you do not select the Store backups in the same cloud provider as the database for a protection policy, then the policy-linked protected database and backups will be stored in Oracle Cloud even if your Oracle Database is provisioned in a different cloud location.
With this enhancement, when the region is up, you can:
use an existing backup and restore it to create a database (out-of-place restore) either within the same availability domain or in a different availability domain across regions, regardless of whether the backup was created with backup destination Object Storage or Autonomous Recovery Service
restore a backup taken on either a database that was configured using host-based wallets (local wallet) or OCI Vault
With this enhancement to the Cost Analysis feature of the OCI Cost Management Service, you can view the attributed usage and cost for all the PDBs in a VM Cluster. This data will be available on the cost analysis dashboard and the reports.
Currently, you can only increase or decrease the size of the /u02 file system in the Guest VM. Now, using the OCI Console or API, you can increase the size of additional local file systems such as /, /u01, /tmp, /var, /var/log, /var/log/audit, and /home.
The ability to create a custom software image (Database and Grid Infrastructure) with all the required patches bundled together and certified in the customer environment will allow developers and database administrators to build an approved and reusable "gold image".
The serial console feature requires (at a minimum) Exadata System Software 23.1.13. Once the necessary software is installed via Quarterly Maintenance and a reboot of your VMs takes place, you will be able to use the new serial console feature.
You can create and delete serial console connections to your Oracle Exadata Database Service on Dedicated Infrastructure systems to diagnose and resolve VM guest operating system issues using an SSH connection in case standard SSH access to the VMs is not possible.
Requirements: Exadata System Software 23.1.13 is the minimum required version. Also, make sure to review all prerequisites stated below, including setting a password for either the opc or the root user. Failure to make necessary changes to meet these requirements in advance will result in the inability to urgently connect to the serial console when the need arises when the VM is not otherwise accessible.
Oracle Database 23ai is a regular production release available on Oracle Exadata Database Service on Dedicated Infrastructure (ExaDB-D). With this release, you can perform all the lifecycle operations on the 23ai databases.
With this enhancement, you can enable Unified Auditing during the creation of a database home, a feature available since Oracle Database version 12.1.
For Oracle Database versions lower than 12.1: You cannot use the Unified Auditing framework and should instead use the Traditional Audit, the legacy Oracle Database audit framework.
For Oracle Database versions 12.1 or higher: You can enable Unified Auditing from the OCI Console. For Oracle Database versions 12.1 or higher but lower than version 23ai, the Unified Auditing check box is not selected by default. However, it is selected by default for Oracle Database version 23ai.
Note
You cannot disable Unified Auditing after provisioning the Database Home.
Scale down your Exadata Infrastructure resources by changing your server count to a lower value than the current assignment.
Scaling down to a lower count is supported for both DB and Storage Servers.
Database servers will be removed if there are no VMs running on them.
Note
You will not be able to choose the DB Server to remove. This functionality will automatically remove Database Servers in which there are no VMs.
Storage server will be removed if the server has not been used to expand Exadata Infrastructure storage.
Remove a VM from a provisioned VM cluster in a non multi-VM-enabled infrastructure. The procedure is similar to terminating a VM from a VM Cluster in a multi-VM-enabled infrastructure.
The 'Add Capacity' step runs as part of the storage server scale-up workflow, creates disk groups, and rebalances data across all storage servers. For more information, see Scale VM Resources in Multi VM Enabled Infrastructure.
Enables customers to offload backups to the standby database with OCI Object Storage in a Data Guard environment thereby freeing up resources in the production database environment.
Allows customers to schedule automatic backups on the standby database in a Data
Guard environment and configure retention period and backup schedules.
Enables customers to create a database in another Availability Domain (AD) within
the same region from a backup of the standby database.
Allows customers to restore and recover a standby database using a backup of the
standby database.
Provides the flexibility to take backups only on the primary database, only on the
standby database, or both.
Allows customers to create a manual full backup of a standby database.
Enables customers to enable or disable backup on the standby database only if the
backup destination of the primary database is Object Storage.
Note
You cannot change the backup destination of the primary database to
Autonomous Recovery Service if the backup destination of the primary and standby
databases is Object Storage.
To change the backup destination of the primary
database to Autonomous Recovery Service, first, disable backup on the
standby database.
You cannot use standby-side backups to perform restore/recover operations on the
primary database.
Switchover scenarios:
If automatic backups was configured on the primary with backup
destination of Object Storage, upon switchover, the backups will
continue on the new standby database
If automatic backups was configured on the primary with backup
destination of Autonomous Recovery Service, upon switchover, backup and
restore will be disabled on the new standby database
If automatic backups was configured on the standby with backup
destination of Object Storage, upon switchover, the backups will
continue on the new primary database
Failover scenarios:
If automatic backups was configured on the primary with backup
destination of Object Storage or Autonomous Recovery Service, upon
failover the backups be disabled on the new Disabled Standby
database
If automatic backups was configured on the standby with backup
destination of Object Storage, upon failover the backups will continue
on the new primary database
You now have the ability to cancel an ongoing backup, allowing you to free up system
resources. You will no longer have to call the operations team to have this backup job
canceled.
As part of the Create Database workflow and independently (after the database has been
created), you may enable Automatic Backup and select the desired backup destination.
Depending on the backup destination selected, you may have one or more full backups and
several incremental backups. Once any of these backups have started, you will not have
the option to cancel that backup midway.
This feature allows you to cancel any running backup (automatic or standalone) from the
OCI console or via OCI API.
You can also:
Cancel a manual backup, which is triggered when you click the
Create backup button
This Console enhancement sets Autonomous Recovery Service as the default backup destination for automatic backups in all regions and includes default limits automatically without having to request them.
Exadata Fleet Update simplifies, standardizes, and enhances the Oracle
Database and Grid Infrastructure patching experience. Exadata Fleet Update achieves this
by grouping components based on the customers' business needs into collections that can
be patched as one entity within a given maintenance cycle.
Exadata Fleet Update brings this patching engine to OCI as a native cloud
service, accessible from the OCI Console, OCI API, and via the OCI CLI.
Exadata Fleet Update is available free of charge on Oracle’s Exadata Database
Service including Cloud@Customer (ExaDB-C@C) and Exadata Database Service on Dedicated
Infrastructure (ExaDB-D).
use an existing backup and restore it to create a database (out-of-place restore)
either within the same availability domain or in a different availability domain
within the same region, regardless of whether the backup was created with backup
destination Object Storage or Autonomous Recovery Service
restore a backup taken on either a database that was configured using host-based
wallets (local wallet) or OCI Vault
This feature enables cloud-only customers to download one-off patches from
the OCI console and API. There is no option to apply the downloaded patch via console
and API. To apply these patches, customers must log in to their VM and run the patch
apply utility.
Note
To be able to download interim software update, you should at least have
an ExaDB-D infrastructure provisioned.
Downloading one-off patches does not replace Database Software Image (DSI)
creation. Customers must continue to use Database Software Images (DSI) to build and
deploy their customized images.
Enabling Automatic Backup during the Create Database workflow or as a separate step
afterward starts the first full backup ("initial L0") immediately.
Similarly, for subsequent full backups (future L0) and daily incremental backups (L1),
you can specify a time window but cannot change the day of the week when these backups
must begin.
Future L0 and L1 backups will begin during the 2-hour scheduling window that the user
selects for the database during which the automatic backup process will begin. There are
12 scheduling windows to choose from, each starting at an even-numbered hour. For
example, one window runs from 4:00-6:00 AM, and the next from 6:00-8:00 AM. Backup jobs
do not necessarily complete within the scheduled window. If you do not specify a window,
the default 6-hour backup window of 00:00 to 06:00 is chosen. In this case, the time
zone corresponds to the region of the Exadata Cloud infrastructure instance.
Here are the current defaults for the backup destinations, Object Storage Service, and
Autonomous Recovery Service:
Initial full L0 backup: Immediate
Subsequent full L0 backups: Every Sunday
Daily incremental L1 backups: Every Monday - Saturday
With these enhanced controls, you can:
Aside from configuring the initial L0 backup to start immediately, you can also
specify whether you want the initial L0 backup to start immediately or according to
the L0 schedule.
Choose a time window for the future full backups to start.
Choose a time window for the incremental backups to start, which can be
different from the time window for the L0 backups.
The time windows
will remain the same, 2-hour scheduling windows and the default 6-hour
window.
Oracle Database Autonomous Recovery Service provides an optimized policy-driven automatic
backup and recovery system for the Exadata Database on Dedicated Infrastructure. It also
offers a real-time data protection feature that enables protected databases with zero
data loss recovery in the event of a database failure. Since Real-time data protection
is an extra cost option, you can choose to enable or disable it.
Security maintenance, performed alongside the quarterly maintenance, is
executed once a month and includes fixes for vulnerabilities with CVSS scores greater
than or equal to 7.
With the latest Release Update, you can now configure the database in a virtual machine
cluster to use Oracle Cloud Infrastructure (OCI) Identity and Access Management (IAM)
authentication and authorization to allow IAM users to access the database with IAM
credentials.
As of this release, IAM authentication and authorization:
will
be available on newly provisioned and existing the databases patched to 19.17.
This feature is not available on Oracle Database release 21c.
can not be used with databases configured with Data Guard.
Allow users to choose the private view and private zone while provisioning a new VM
cluster for ExaCS. All the underlying resources of the VCN, including those of ExaDB-D,
should be created in the same private zone. The private zones can be associated with
subnets inside the VCN. This configuration cannot be changed later.
Private DNS resolver is going to resolve queries in customer VCN and queries coming from
the on-premise networks. Ability to provide the DNS address and seed that into DB
resources using conditional forwarding, is provided by the private DNS feature. With a
private resolver, customers can resolve the A-record across different VCNs (with VCN
peering- local/remote).
The Exadata Cloud Infrastructure
Oracle-managed infrastructure maintenance now allows greater control and visibility
including:
Choice of rolling and non-rolling maintenance methods.
Ability to perform custom actions before maintenance on each
database server by having the automated maintenance wait before shutting down
VMs until the maintenance is resumed or the configured timeout is
reached.
Visibility into the database server update order.
Granular tracking of the maintenance progress at a component
level.
You can now enable Database Management for Pluggable Databases (PDBs) on
Oracle Exadata Database Service on Dedicated Infrastructure, and use Database Management
features for monitoring, performance management, and tuning.
Oracle Exadata Database on Dedicated Infrastructure now can accept Azure AD
tokens to access the database. Azure AD users can access the database directly using
their Azure AD token, and applications can use their service tokens to access the
database.
Azure AD integration will be available for databases patched to 19.17 and above. This
feature is not available on Oracle Database release 21c.
Release Date: Starting November 9, 2022 ( the release date varies by region)
Slice Exadata resources into multiple virtual machines. Define up to 8 multiple
virtual machine (VM) clusters on an Oracle Exadata Database Service on Dedicated
Infrastructure, and specify how the overall system resources are allocated to
them.
VM Cluster Node Subsetting enables you to allocate a subset of database servers to
new and existing VM clusters to enable maximum flexibility in the allocation of
compute (CPU, memory, local storage) resources.
Note
For existing Exadata Infrastructure, MultiVM will be enabled as part
of your next scheduled maintenance run after MultiVM migration on December 20,
2022. All newly provisioned Exadata Infrastructure after the release of MVM on
November 15, 2022, will have MultiVM enabled.
With this release Oracle will provide health metrics for databases and VM clusters in the
Oracle Cloud Infrastructure (OCI) console.
Note
When there is a network problem and Oracle Trace File Analyzer (TFA) is
unable to post metrics, TFA will wait for one hour before attempting
to retry posting the metrics. This is required to avoid creating a
backlog of metrics processing on TFA.
Potentially one hour of metrics will be lost between network restore and
the first metric posted.
Exadata Cloud Infrastructure
resources can now be tagged using Oracle Standard tags according to your organizational
scheme. By tagging resources, you can group them, manage costs, and gain insight into
how they are being used.
This feature extends the Database Service Events feature implementation that enables you
to get notified about health issues with your Oracle Databases or other components on
the Guest VM. With this enhancement, you can allow:
Oracle to proactively collect detailed health metrics for diagnosis and issue
resolution
Oracle to reactively collect Incident logs and trace files on demand for a
deeper diagnosis and issue resolution
Collecting Guest VM events, health metrics, incident logs, and trace files,
will help Oracle to enhance service operations as well as provide proactive support by
early detection and correlation.
You can now have the encryption keys used for the primary and standby databases to
be available in the primary and standby regions respectively so that it
provides protection against a single point of failure for the OCI Vault key.
This is possible if the keys are in OCI Virtual Private Vault. So,
cross-region Data Guard can be set up between two databases if their keys
are residing in a virtual private vault (VPV) and are managed by the OCI
Vault service.
With this enhancement, you can now concurrently create or terminate Oracle databases
even if the VM cluster is in the Updating state.
The number of databases that can be created on a cluster depends on the
available memory on the VMs. For each database, by default, 12.6 GB (7.6 GB for
SGA and 5 GB for PGA) is allocated if the VM has greater than 60 GB of memory.
If the VM has less than or equal to 60 GB, then 6.3 GB (3.8 GB for SGA and 2.5
GB for PGA) is allocated. Also, Grid Infrastructure and ASM consume some memory,
approximately 2 to 4 GB.
A database that is being created cannot be terminated. You can, however,
terminate other databases in the VM Cluster.
In addition to performing minor version updates to the Exadata VM Cluster
images, you can update to a new major version if the currently installed version is 19.2
or higher. For example, if the VM cluster is on version 20, then you can update it to
version 21.
This feature allows customers to use OCI Console or API/CLI/SDK/Terraform to
receive event notifications about health issues with your Oracle Databases or other
components on the Guest VM.
Customers currently have basic lifecycle management events like backup begin, backup end,
patching begin, etc. We are extending that capability to include a comprehensive set of
Database Service events to help customers troubleshoot issues.
Database Service Events monitor guest VM operations and conditions and
generate diagnostic notifications for customers by leveraging the existing OCI Events
service and Notification mechanisms in their tenancy. Customers can then create topics
and subscribe to these topics through email, functions, streams, etc. For more
information about using the Events Notification Service, see Notifications
Overview
Key Customer Benefits
Ability to receive notifications for Guest VM operations via an opt-in
mechanism.
Allows customers to proactively address issues before they may become serious.
OCI Console Experience
Customers can navigate to the VM Cluster details page from the OCI console menu by
selecting Oracle Database → Oracle Exadata Database Service
on Dedicated Infrastructure → a specific VM Cluster to enable Diagnostics
Notification for a VM Cluster.
Oracle Exadata Database Service on Dedicated Infrastructure (ExaDB-D): Now
allows you to create a database from backup, when the backup is of the database using
customer-managed encryption. This is in addition to the existing ability to create a
database from backup, when the backup is of the database using oracle-managed
encryption
Provision a DB Home using a major version and RU version of your choice.
While provisioning, if you opt to use Oracle Provided Database Software
Images as the image type, then you can use the Display all available
versions switch to choose from all available PSUs and RUs. The most recent
release for each major version is indicated with a latest label.
For the Oracle Database major version releases available in Oracle Cloud
Infrastructure, images are provided for the current version plus the three most recent
older versions (N through N - 3). For example, if an instance is using Oracle Database
19c, and the latest version of 19c offered is 19.8.0.0.0, images available for
provisioning are for versions 19.8.0.0.0, 19.7.0.0, 19.6.0.0 and 19.5.0.0.
Operations Insights now allows you to use the Capacity Planning and SQL
Warehouse functionality to gain insight into Oracle Databases deployed in Oracle Cloud
(Bare Metal, Virtual Machine VM, and Exadata Cloud Infrastructure).
You can now create and manage pluggable databases (PDBs) in Exadata Cloud Infrastructure using the OCI console and
APIs. See Create and Manage Exadata Pluggable Databases for details.
You can now specify the DB_UNIQUE_NAME value and the Oracle
SID prefix when creating a new Oracle Database in Exadata Cloud Infrastructure. You can also set these values when creating a standby
database in an Oracle Data Guard association. See the following topics for
instructions:
With elastic provisioning and expansion, you can dynamically increase your CPU and
storage capacity to meet your growing workload requirements.
Expand the infrastructure capacity on-demand by scaling up the infrastructure with
additional database or storage servers without being constrained by the standard
supported shapes. You can allocate CPU and storage capacity available on X8M and X9M
servers up to the system limits when you provision new VM Clusters on the
infrastructure, or to already deployed VM Clusters without disrupting the current
running workloads.
For more information, see:
To scale CPU cores in an Exadata Cloud Infrastructure cloud VM
cluster or DB system
To add compute and storage resources to a flexible cloud Exadata
infrastructure resource
Using the API to Manage Exadata Cloud Infrastructure
Instance
When provisioning a new Oracle Database or a new virtual machine or bare
metal DB system, the TDE wallet password parameter is now optional, and it is not used
if you configure an Exadata Cloud Infrastructure database
to use customer-managed keys with the OCI Vault service. For more information on
creating Oracle Databases and virtual machine DB systems, see the following topics in
the documentation:
For information on using the Vault service to store and manage encryption keys and other
secrets used by OCI resources, see the Vault service documentation.
The Exadata tab provides a unified view of Oracle Exadata hard disk and flash performance
statistics with deep insight into the health and performance of all components such as
the Oracle databases, Oracle Exadata storage cells, and Automatic Storage Management
(ASM). It is available for Exadata Cloud deployments.and external databases that use
Exadata infrastructure. For more information, see Using Performance Hub to Analyze Database Performance.
You can choose to specify up to 10 valid email addresses to which Oracle sends
maintenance notifications when updates are made to an Exadata infrastructure. The email
addresses you specify are used only for service-related operational issues. See Oracle-Managed Infrastructure Maintenance
Updates for more information.
You can now specify the Data Guard protection mode for Exadata Cloud Infrastructure instances and bare metal and
virtual machine DB systems. See the following topics for more information:
You can now configure Exadata infrastructure patching to take place in a non-rolling fashion across the database nodes. This option allows you to reduce the total time your system is undergoing quarterly maintenance, but does involve system downtime. See Oracle-Managed Infrastructure Maintenance Updates for more information.
Customer-managed keys for Exadata Cloud Infrastructure
is an encryption key management service that enables you to encrypt your
data using encryption keys that you control. You can use customer-managed
keys on databases you provision in Exadata Cloud Infrastructure that are enabled with Oracle Data Guard.
DomU OS Patching is a feature which enables ExaDB-D customers to upgrade the Exadata OS image on their domU nodes in an
automated manner from their OCI console and APIs. The following information explains
about a recent change in the feature that could not be added to the docs in time for
release, but will be added soon.
Rollback required if the patch fails.
On multi-node systems, if one of the nodes fails the patch, you must roll back all nodes
to get them all on the same version. Then run precheck, fix any problems, and run the
patch again.
Example: If you run precheck on Monday and all nodes pass, but do not apply the patch
until Wednesday, it is possible that one or more of the nodes may fail the patch because
of changes on the nodes or a maintenance conflict.
To prevent this from happening, Oracle recommends that you run precheck right before
applying the patch.
Oracle Cloud Infrastructure Vault service integration with Exadata Cloud Infrastructure enables database encryption
with customer-managed keys. For more information, see Customer-Managed Keys in Exadata Cloud
Service.
You can now upgrade Exadata Cloud Infrastructure databases to Oracle Database version 19c using the Oracle Cloud
Infrastructure Console or API. For information and instructions, see Upgrading Exadata Databases.
You can now create custom Oracle Database software images to use for
provisioning Database Homes and and patching databases in Exadata Cloud Infrastructure instances. For more information, see Oracle Database Software
Images.
You can now upgrade the grid infrastructure (GI) of an Exadata Cloud Infrastructure VM cluster using the
Console. For more information, see Upgrading Exadata Grid
Infrastructure.
You can now provision an Exadata Cloud Infrastructure instance using the flexible X8M shape. This shape allows you to
expand your system after provisioning, as your databases grow and you need more storage
servers, compute servers, or both. For more information, see Overview of X8M Scalable Exadata
Infrastructure.
You can now choose to use an existing Database Home when setting up a Data
Guard standby database in your Exadata Cloud Infrastructure instance. See Using Oracle Data Guard with Exadata
Cloud Service Instances for information on setting up Data Guard for your
Exadata databases.