Creating an Exadata Cloud Infrastructure Instance
This topic explains how to create an Oracle Exadata Cloud Infrastructure instance. It also describes how to configure required access to the Oracle Cloud Infrastructure Object Storage service and set up DNS.
When you create an Exadata Cloud Infrastructure instance using the Console or the API, the system is provisioned to support Oracle databases. Along with the Infrastructure, a VM cluster, an initial Database Home and database are created. You can create additional Database Homes and databases at any time by using the Console or the Oracle Cloud Infrastructure API. The service creates an initial database based on the options you provide and some default options described later in this topic.
- Resources to Be Created
- Prerequisites for Creating an Cloud Exadata Infrastructure Instance
You need a SSH key pair key and a Virtual Cloud Network (VCN) to create an infrastructure instance. - Default Options for the Initial Database
Default option simplify launching an Exadata Cloud Infrastructure instance in the Console and when using the API. - Using the Console to Create Infrastructure Resources
Console tasks required to create cloud resources
Resources to Be Created
You will provision Exadata Cloud Infrastructure infrastructure and VM cluster resources separately.
- Cloud Exadata infrastructure resource: The infrastructure resource is the top-level (parent) resource. At the infrastructure level, you control the number of database and storage servers. You also control Exadata system maintenance scheduling at the Exadata infrastructure level.
- Cloud VM cluster resource: The VM cluster is a child resource of the infrastructure resource, providing a link between your Exadata cloud infrastructure resource and Oracle Database. Networking, OCPU count, IORM ( see About IORM, and Oracle Grid Infrastructure are configured and managed at the VM cluster level. To create a cloud VM cluster, you must have an existing Cloud Exadata infrastructure resource to house the VM cluster.
- Exadata Cloud Infrastructure only supports using the new resource model (consisting of separate Exadata infrastructure and VM cluster resources) to provision Exadata Cloud Infrastructure instances, regardless of the hardware shape family you are choosing (X7, X8, X8M, or X9M). The DB system resource model and APIs are deprecated for Exadata Cloud Infrastructure.
- Multi-VM enabled Infrastructure supports the creation of up to 8 VM clusters in an Infrastructure. >> Exadata Infrastructures with X8M and above generation of DB Servers can support a maximum of 8 VM clusters across all DB Servers. Maximum number of clusters across the infrastructure depends on the resources available per DB server and is subject to the per DB Server maximum VM limit. For more information, see Overview of VM Cluster Node Subsetting.
- An Exadata Cloud Service Infrastructure instance that is NOT Multi-VM enabled supports only one cloud VM cluster
Parent topic: Creating an Exadata Cloud Infrastructure Instance
Prerequisites for Creating an Cloud Exadata Infrastructure Instance
You need a SSH key pair key and a Virtual Cloud Network (VCN) to create an infrastructure instance.
- The proper IAM policy is required to proceed. See Required IAM Policy for Exadata Cloud Infrastructure
-
The public key, in OpenSSH format, from the key pair that you plan to use for connecting to the system via SSH. A sample public key, abbreviated for readability, is shown below.
ssh-rsa AAAAB3NzaC1yc2EAAAABJQAA....lo/gKMLVM2xzc1xJr/Hc26biw3TXWGEakrK1OQ== rsa-key-20160304
For more information, see Managing Key Pairs on Linux Instances .
- A correctly configured virtual cloud network (VCN) to launch the system in. Its related networking resources (gateways, route tables, security lists, DNS, and so on) must also be configured as necessary for the system. For more information, see Network Setup for Exadata Cloud Infrastructure Instances .
Default Options for the Initial Database
Default option simplify launching an Exadata Cloud Infrastructure instance in the Console and when using the API.
The following default options are used for the initial database:
- Console Enabled: False
- Create Container Database: False for version 11.2.0.4 databases. Otherwise, true.
- Create Instance Only (for standby and migration): False
- Database Home ID: Creates a database home
- Database Language: AMERICAN
- Database Sizing Template: odb2
- Database Storage: Automatic Storage Management (ASM)
- Database Territory: AMERICA
- Database Unique Name: The user-specified database name and a system-generated suffix, for example, dbtst_phx1cs.
- PDB Admin Name: pdbuser (Not applicable for version 11.2.0.4 databases.)
Parent topic: Creating an Exadata Cloud Infrastructure Instance
Using the Console to Create Infrastructure Resources
Console tasks required to create cloud resources
- To create a Cloud Exadata infrastructure resource
- To create a cloud VM cluster resource
Create a VM cluster in an Exadata Cloud Infrastructure instance. - Configuring Network Resources for Recovery Service
Use an existing IP4-only subnet in the database VCN for Recovery Service operations. Define security rules to control the backup traffic between your database and Recovery Service. Finally, register the private subnet as a Recovery Service subnet. - Autonomous Recovery Service Checklist
Parent topic: Creating an Exadata Cloud Infrastructure Instance
To create a Cloud Exadata infrastructure resource
- Open the navigation menu. Click Oracle Database, then click Oracle Exadata Database Service on Dedicated Infrastructure
- Under Oracle Exadata Database Service on Dedicated Infrastructure, click Exadata Infrastructure.
- Click Create Exadata Cloud Infrastructure.
- Compartment: Select a compartment for the Exadata infrastructure.
- Display name: Enter a display name for the Exadata infrastructure. The name doesn't need to be unique. An Oracle Cloud Identifier (OCID) will uniquely identify the Cloud Exadata infrastructure resource. Avoid entering confidential information.
- Select an availability domain: The availability domain in which the Exadata infrastructure resides.
-
Select the Exadata Cloud Infrastructure model: Select either a fixed-shape system (quarter, half, or full rack X7-2 or X8-2 shapes), or a scalable system (X8M-2 or X9M-2).
X9M-2: If you select the flexible X9M-2 cloud infrastructure model, your initial Exadata Cloud Infrastructure instance can have a minimum of 2 database servers and 3 storage servers up to 32 database servers and 64 storage servers. After provisioning, you can scale the service instance as needed by adding additional storage servers, compute servers, or both.
X8M-2: If you select the flexible X8M-2 cloud infrastructure model, your initial Exadata Cloud Infrastructure instance can have a minimum of 2 database servers and 3 storage servers (the equivalents of an X8 quarter rack shape) up to 32 database servers and 64 storage servers. After provisioning, you can scale the service instance as needed by adding additional storage servers, compute servers, or both.
X7 and X8: If you select an X7 or X8 system, you are given the choice of provisioning a quarter, half, or full rack. See Exadata Shape Configuration for hardware and capacity details.
Exadata Base: The Exadata base shape comes in a single configuration, and provides an economical alternative to provisioning a quarter rack system. See Exadata Shape Configuration
- If you selected a flexible shape (X8M-2 or X9M-2) , specify the Compute and storage configuration. You can specify Database servers from minimum of 2 up to 32. You can specify Storage servers from minimum of 3 up to 64.
- Select the time zone: Choose one of :
- UTC
- Select another timezone
- (Browser detected) timezone
- In the Provide maintenance details pane.
The default values for Maintenance Method and Maintenance Schedule are shown. Click Edit Maintenance Preferences to change the values
In the Edit Maintenance Preferences dialog, under theConfigure maintenance method: Click one of Rolling or Non-rolling.- Rolling: By default, Exadata Infrastructure is updated in a rolling fashion, one server at a time with no downtime.
- Non-rolling: Update database and storage servers at the same time. The non-rolling maintenance method minimizes maintenance time but incurs full system downtime.
You can also select Enable custom action before performing maintenance on DB servers. Enable custom action only if you want to perform additional actions outside of Oracle’s purview. For maintenance configured with a rolling software update, enabling this option will force the maintenance run to wait for a custom action with a configured timeout before starting maintenance on each DB server. For maintenance configured with non-rolling software updates, the maintenance run will wait for a custom action with a configured timeout before starting maintenance across all DB servers. When the custom action is enabled the custom action timeout field appears.- Custom action timeout (in minutes): Timeout available to perform custom action before starting maintenance on the DB Servers.
Default: 30 minutes
Maximum: 120 minutes
In the Maintenance Schedule section keep the default setting of No preference to let the system assign a date and start time for infrastructure maintenance, or select Specify a Schedule
- Click the Specify a schedule radio button to choose your preferred month, week, weekday, and start time for infrastructure maintenance.
- Under Maintenance months, specify at least one month for
each quarter during which Exadata infrastructure maintenance will take
place. You can select more than one month per quarter. If you specify a long
lead time for advanced notification (for example, 4 weeks), then you may
want to specify two or three months per quarter during which maintenance
runs can occur. This will ensure that your maintenance updates are applied
in a timely manner after accounting for your required lead time. Lead time
is discussed in the following steps:
Note
For Exadata infrastructure resources in government regions, Oracle performs maintenance operations monthly. Enable maintenance operations for all months if your infrastructure is in a government region. - Under Week of the month, specify which week of the month maintenance will take place. Weeks start on the 1st, 8th, 15th, and 22nd days of the month, and have a duration of seven days. Weeks start and end based on calendar dates, not days of the week. Maintenance cannot be scheduled for the fifth week of months that contain more than 28 days.
- (Optional) Under Day of the week, specify the day of the week on which the maintenance will occur. If you do not specify a day of the week, then Oracle will run the maintenance update on a weekend day to minimize disruption.
- (Optional) Under Start hour, specify the hour during which the maintenance run will begin. If you do not specify a start hour, then Oracle will choose the least disruptive time to run the maintenance update.
- Under Lead Time, specify the number of weeks ahead of the maintenance event you would like to receive a notification message. Your lead time ensures that a newly released maintenance update is scheduled to account for your required period of advanced notification.
- Click Save Changes.
-
In the Provide maintenance details : Provide up to 10 unique maintenance contact email addresses. Click Add Contact.
In the Contact Email field, provide the email ID of a desired contact.Note
At least one Contact is required.Click Add Contact to add another contact.
-
Click Show Advanced Options to specify advanced options for the initial database.
In the Tags tab, you can add tags to the database. To apply a defined tag, you must have permissions 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.
-
Click Create Exadata Infrastructure. The Cloud Exadata infrastructure appears in the Exadata Infrastructure list with a status of Provisioning. The infrastructure's icon changes from yellow to green (or red to indicate errors).
WHAT NEXT?
After the Cloud Exadata infrastructure resource is successfully provisioned and in the Available status, you can create a cloud VM cluster as described in To create a cloud VM cluster resource on your infrastructure. You must provision both an infrastructure resource and a VM cluster before you can create your first database in the new Exadata Cloud Infrastructure instance.
Related Topics
Parent topic: Using the Console to Create Infrastructure Resources
To create a cloud VM cluster resource
Create a VM cluster in an Exadata Cloud Infrastructure instance.
To create a cloud VM cluster in an Exadata Cloud Infrastructure instance, you must have first created a Cloud Exadata infrastructure resource.
Multi-VM enabled Infrastructure will support creating multiple VM Clusters. Infrastructures created before the feature Create and Manage Multiple Virtual Machines per Exadata System (MultiVM) and VM Cluster Node Subsetting was released only support creating a single cloud VM cluster.
- Open the navigation menu. Click Oracle Database, then click Oracle Exadata Database Service on Dedicated Infrastructure
- Under Oracle Exadata Database
Service on Dedicated Infrastructure, click Exadata VM
Clusters.
Note
Multiple VM clusters may be created only in a Multi-VM enabled Infrastructure. - Click Create Exadata VM Cluster.
The Create Exadata VM Cluster page is displayed. Provide the required information to configure the VM cluster.
- Compartment: Select a compartment for the VM cluster resource.
- Display name: Enter a user-friendly display name for the VM cluster. The name doesn't need to be unique. An Oracle Cloud Identifier (OCID) will uniquely identify the DB system. Avoid entering confidential information.
- Select Exadata infrastructure: Select the infrastructure
resource that will contain the VM cluster. You must choose an infrastructure
resource that has enough resources to create a new VM cluster. Click
Change Compartment and pick a different compartment from
the one you are working in to view infrastructure resources in other
compartments.
Note
Multiple VM clusters may be created only in a Multi-VM enabled Infrastructure - Choose the Oracle Grid Infrastructure version: From the list, choose the Oracle Grid Infrastructure release (19c and 23ai) that you want to install on the VM cluster.
The Oracle Grid Infrastructure release determines the Oracle Database releases that can be supported on the VM cluster. You cannot run an Oracle Database release that is later than the Oracle Grid Infrastructure software release.
Note
Minimum requirements for provisioning a VM Cluster with Grid Infrastructure 23ai:- Exadata Guest VM running Exadata System Software 23.1.8
- Exadata Infrastructure running Exadata System Software 23.1.x
- Choose an Exadata image version:
- Exadata infrastructure with Oracle Linux 7 and Exadata image version 22.1.10.0.0.230422:
- The Change image button is not enabled.
- The Oracle Grid Infrastructure version defaults to 19.0.0.0.0.
- The Exadata guest version will be the same as that of the host OS.
- Exadata infrastructure with Oracle Linux 8 and Exadata image version 23.1.3.0.0.230613:
- The Exadata guest version defaults to the latest (23.1.3.0).
- The Oracle Grid Infrastructure version defaults to 19.0.0.0.0
- The Change image button is enabled.
- Click Change image.
The resulting Change image panel displays the list of available major versions of Exadata image (23.1.3.0 and 22.1.3.0).
The most recent release for each major version is indicated by "(latest)".
- Slide Display all available versions.
Six past versions including the latest versions of Exadata images 23.1.3.0 and 22.1.3.0 are displayed.
- Choose a version.
- Click Save Changes.
- Exadata infrastructure with Oracle Linux 7 and Exadata image version 22.1.10.0.0.230422:
- Configure the VM cluster: Specify the DB servers to used for
new VM cluster (by default all DB Servers are selected). Click Change DB
Servers to select from the available DB servers. In the
Resource allocation per VM pane:
- Specify the number of OCPU cores you want to allocate to each of the VM cluster's virtual machine compute nodes. Minimum is 2 OCPU per VM . The read-only Requested OCPU count for the Exadata VM cluster field displays the total number of OCPU cores you are allocating.
- Specify the Memory per VM to allocate to each VM. The minimum per VM is 30 GB.
- Specify the Local Storage per VM to allocate local storage to each VM. The minimum per VM is 60 GB.
Each time when you create a new VM cluster, the space remaining out of the total available space is utilized for the new VM cluster.
In addition to
/u02
, you can specify the size of additional local file systems.For more information and instructions to specify the size for each individual VM, see Introduction to Scale Up or Scale Down Operations.
- Click Show additional local file systems configuration options.
- Specify the size of
/
,/u01
,/tmp
,/var
,/var/log
,/var/log/audit
, and/home
file systems as needed.Note
- You can only expand these file systems and cannot reduce the size once expanded.
- Due to backup partitions and mirroring, the
/
and/var
file systems will consume twice the space they were allocated, which is indicated in the read-only Total allocated storage for / (GB) due to mirroring and Total allocated storage for /tmp (GB) due to mirroring fields.
- After creating the VM Cluster, check the Exadata Resources section on the Exadata Infrastructure Details page to check the file size allocated to the local storage (
/u02
) and local storage (additional file systems).
-
Configure Exadata storage: Specify the following:
- Specify the usable Exadata storage TB. Specify the storage in multiples of 1 TB. Minimum: 2 TB
- Allocate storage for Exadata sparse snapshots:
Select this configuration option if you intend to use
snapshot functionality within your VM cluster. If you select this
option, the SPARSE disk group is created, which enables you to use VM
cluster snapshot functionality for PDB sparse cloning. If you do not
select this option, the SPARSE disk group is not created and snapshot
functionality will not be available on any database deployments that are
created in the environment.
Note
The storage configuration option for sparse snapshots cannot be changed after VM cluster creation. -
Allocate storage for local backups: Select this
option if you intend to perform database backups to the local Exadata
storage within your Exadata Cloud Infrastructure instance. If you select this option, more space
is allocated to the RECO disk group, which is used to store backups on
Exadata storage. If you do not select this option, more space is
allocated to the DATA disk group, which enables you to store more
information in your databases.
Note
The storage configuration option for local backups cannot be changed after VM cluster creation.
- Add SSH key: Add the public key portion of each key pair you want to use for SSH access to the DB system:
- Generate SSH key pair (Default option) Select this radio button to generate an SSH keypair. Then in the dialog below click Save private key to download the key, and optionally click Save public key to download the key.
- Upload SSH key files: Select this radio button to browse or drag and drop .pub files.
- Paste SSH keys: Select this radio button to paste in individual public keys. To paste multiple keys, click + Another SSH Key, and supply a single key for each entry.
-
Configure the network settings: Specify the following:
Note
IP addresses (100.64.0.0/10) are used for Exadata Cloud Infrastructure X8M interconnect.- Virtual cloud network: The VCN in which you want to create the VM cluster. Click Change Compartment to select a VCN in a different compartment.
- Client subnet: The subnet to which the VM cluster should attach. Click Change Compartment to select a subnet in a different compartment.
Do not use a subnet that overlaps with 192.168.16.16/28, which is used by the Oracle Clusterware private interconnect on the database instance. Specifying an overlapping subnet causes the private interconnect to malfunction.
- Backup subnet: The subnet to use for the backup network, which is typically used to transport backup information to and from the Backup Destination, and for Data Guard replication. Click Change Compartment to select a subnet in a different compartment, if applicable.
Do not use a subnet that overlaps with 192.168.128.0/20. This restriction applies to both the client subnet and backup subnet.
If you plan to back up databases to Object Storage or Autonomous Recovery service, see the network prerequisites in Managing Exadata Database Backups.
Note
In case Autonomous Recovery Service is used, a new dedicated subnet is highly recommended. Review the network requirements and configurations required to backup your Oracle Cloud databases to Recovery Service. See, Configuring Network Resources for Recovery Service. -
Network Security Groups: Optionally, you can specify one or more network security groups (NSGs) for both the client and backup networks. NSGs function as virtual firewalls, allowing you to apply a set of ingress and egress security rules to your Exadata Cloud Infrastructure VM cluster. A maximum of five NSGs can be specified. For more information, see Network Security Groups and Network Setup for Exadata Cloud Infrastructure Instances.
Note that if you choose a subnet with a security list, the security rules for the VM cluster will be a union of the rules in the security list and the NSGs.
To use network security groups:
- Check the Use network security groups to control traffic check box. This box appears under both the selector for the client subnet and the backup subnet. You can apply NSGs to either the client or the backup network, or to both networks. Note that you must have a virtual cloud network selected to be able to assign NSGs to a network.
- Specify the NSG to use with the network. You might need to use more than one NSG. If you're not sure, contact your network administrator.
- To use additional NSGs with the network, click +;Another Network Security Group.
- To use private DNS
ServiceNote
A Private DNS must be configured before it can be selected. See Configure Private DNS- Check the Use private DNS Service check box.
- Select a private view. Click Change Compartment to select a private view in a different compartment.
- Select a private zone. Click Change Compartment to select a private zone in a different compartment.
- Hostname prefix: Your choice of hostname for the Exadata DB system. The host name must begin with an alphabetic character and can contain only alphanumeric characters and hyphens (-). The maximum number of characters allowed for an Exadata DB system is 12.
Caution:
The hostname must be unique within the subnet. If it is not unique, the VM cluster will fail to provision. - Host domain name: The domain name for the VM cluster. If the selected subnet uses the Oracle-provided Internet and VCN Resolver for DNS name resolution, this field displays the domain name for the subnet and it can't be changed. Otherwise, you can provide your choice of the domain name. Hyphens (-) are not permitted.
If you plan to store database backups in Object Storage or Autonomous Recovery service, Oracle recommends that you use a VCN Resolver for DNS name resolution for the client subnet because it automatically resolves the Swift endpoints used for backups.
- Host and domain URL: This read-only field combines the host and domain names to display the fully qualified domain name (FQDN) for the database. The maximum length is 63 characters.
- Choose a license type: The type of license you want to use for the VM cluster. Your choice affects metering for billing.
- License Included means the cost of the cloud service includes a license for the Database service.
- Bring Your Own License (BYOL) means you are an Oracle Database customer with an Unlimited License Agreement or Non-Unlimited License Agreement and want to use your license with Oracle Cloud Infrastructure. This removes the need for separate on-premises licenses and cloud licenses.
- Diagnostics Collection: By enabling diagnostics
collection and notifications, Oracle Cloud Operations and you will be able to
identify, investigate, track, and resolve guest VM issues quickly and effectively.
Subscribe to Events to get notified about resource state changes.
Note
You are opting in with the understanding that the above list of events (or metrics, log files) can change in the future. You can opt out of this feature at any time.- Enable Diagnostic Events: Allow Oracle to collect and publish critical, warning, error, and information events to me.
- Enable Health Monitoring: Allow Oracle to collect health metrics/events such as Oracle Database up/down, disk space usage, and so on, and share them with Oracle Cloud operations. You will also receive notification of some events.
- Enable Incident Logs and Trace Collection: Allow Oracle to collect incident logs and traces to enable fault diagnosis and issue resolution.
Note
You are opting in with the understanding that the above list of events (or metrics, log files) can change in the future. You can opt-out of this feature at any time.All three checkboxes are selected by default. You can leave the default settings as is or clear the checkboxes as needed. You can view the Diagnostic Collection settings on the VM Cluster Details page under General Information >> Diagnostics Collection.- Enabled: When you choose to collect diagnostics, health metrics, incident logs, and trace files (all three options).
- Disabled: When you choose not to collect diagnostics, health metrics, incident logs, and trace files (all three options).
- Partially Enabled: When you choose to collect diagnostics, health metrics, incident logs, and trace files ( one or two options).
- Click Show Advanced Options to specify advanced options for the VM cluster:
-
Time zone: This option is located in the Management tab. The default time zone for the DB system is UTC, but you can specify a different time zone. The time zone options are those supported in both the Java.util.TimeZone class and the Oracle Linux operating system. For more information, see DB System Time Zone .
Note
If you want to set a time zone other than UTC or the browser-detected time zone, and if you do not see the time zone you want, try selecting the Select another time zone, option, then selecting "Miscellaneous" in the Region or country list and searching the additional Time zone selections.
- SCAN Listener Port: This option is located in the Network tab. You can assign a SCAN listener port (TCP/IP) in the range between 1024 and 8999. The default is 1521
Note.
Manually changing the SCAN listener port of a VM cluster after provisioning using the backend software is not supported. This change can cause Data Guard provisioning to fail. - Tags: If you have permissions to create a resource, then you also have permissions to apply free-form tags to that resource. To apply a defined tag, you must have permissions to use the tag namespace. For more information about tagging, see Resource Tags. If you are not sure whether to apply tags, skip this option (you can apply tags later) or ask your administrator.
-
- Click Create Exadata VM Cluster.
WHAT NEXT?
After your VM cluster is successfully created and in the Available state, you can view the VM Cluster Details page by clicking the name of the VM cluster in the list of clusters. From the VM Cluster Details page, you can create your first database in the cluster by clicking Create Database.
Related Topics
- Network Security Groups
- Network Setup for Exadata Cloud Infrastructure Instances
- Security Lists
- Configure Private DNS
- DB System Time Zone
- Resource Tags
- To create a database in an existing Exadata Cloud Infrastructure instance
- Getting Started with Events
- Overview of Database Service Events
- Overview of Automatic Diagnostic Collection
Parent topic: Using the Console to Create Infrastructure Resources
Configuring Network Resources for Recovery Service
Use an existing IP4-only subnet in the database VCN for Recovery Service operations. Define security rules to control the backup traffic between your database and Recovery Service. Finally, register the private subnet as a Recovery Service subnet.
- About Using a Private Subnet for Recovery Service
Recovery Service uses a private subnet inside a virtual cloud network (VCN) where your database resides. The private subnet defines the network path for backups between your database and Recovery Service. - Review Networking Service Permissions to Configure a Subnet
Ensure that you have these Networking Service permissions required to create a subnet in the database VCN and to assign security rules for Recovery Service. - Review Subnet Size Requirements and Security Rules for Recovery Service Subnet
The security rules are necessary to allow backup traffic between a database and Recovery Service. - Create a Recovery Service Subnet in the Database VCN
Use the OCI Console to configure a private subnet for Recovery Service in your database virtual cloud network (VCN). - Register Recovery Service Subnet
After you have created a private subnet for Recovery Service in your database VCN, use this procedure to register the subnet in Recovery Service.
Parent topic: Using the Console to Create Infrastructure Resources
About Using a Private Subnet for Recovery Service
Recovery Service uses a private subnet inside a virtual cloud network (VCN) where your database resides. The private subnet defines the network path for backups between your database and Recovery Service.
Oracle recommends that your database VCN must have a single private subnet dedicated for backups to Recovery Service. Your Oracle Cloud database can reside in the same private subnet used by Recovery Service, or in a different subnet within the same VCN.
You can either create a private subnet or use a preexisting subnet in your database VCN. Oracle recommends that you use a subnet size of /24 (256 IP addresses).
Select an IPv4-only subnet for Recovery Service in your database VCN. Do not select an IPv6-enabled subnet as Recovery Service does not support using an IPv6-enabled subnet. See Creating a Subnet to learn more.
The database VCN requires security rules to allow backup traffic between your database and Recovery Service. Security rules must include stateful ingress rules to allow destination ports 8005 and 2484. You can use these Networking service features to implement security rules:
- Security Lists
A security list allows you to add security rules at the subnet level. In your database VCN, select the security list that is used for the Recovery Service subnet, and add the ingress rules to allow destination ports 8005 and 2484.
- Network Security Groups (NSG)Network security groups (NSG) enable granular control over security rules that apply to individual VNICs in a VCN. Recovery Service supports these options to configure security rules using NSGs:
- To implement network isolation, create one NSG for the database VNIC (add egress rules to allow ports 2484 and 8005) and a separate NSG for Recovery Service (add ingress rules to allow ports 2484 and 8005).
- Create and use a single NSG (with egress and ingress rules) for the database VNIC and Recovery Service.
If you have configured a security list and an NSG within your database VCN, then the rules defined in the NSGs takes precedence over the rules defined in a security list.
See Comparison of Security Lists and Network Security Groups to learn more.
After you create a private subnet in the database VCN, assign the security rules and then register the subnet as a Recovery Service subnet in Recovery Service. If you have created NSGs to implement security rules, then you must also ensure to associate the Recovery Service NSG with the Recovery Service subnet.
Oracle recommends using a private subnet for your backups. However, it is possible to use a public subnet.
Parent topic: Configuring Network Resources for Recovery Service
Review Networking Service Permissions to Configure a Subnet
Ensure that you have these Networking Service permissions required to create a subnet in the database VCN and to assign security rules for Recovery Service.
Table 4-6 Networking Service Permissions Required to Create a Private subnet and Configure Security Rules for Recovery Service
Operation | Required IAM Policies |
---|---|
Configure a private subnet in a database VCN |
|
Alternatively, you can create a policy that allows a specified group with broader access to networking components.
For example, use this policy to allow a NetworkAdmin
group to manage all networks in any compartment in a tenancy.
Example 4-1 Policy for Network Administrators
Allow group NetworkAdmin to manage virtual-network-family in tenancy
Parent topic: Configuring Network Resources for Recovery Service
Review Subnet Size Requirements and Security Rules for Recovery Service Subnet
The security rules are necessary to allow backup traffic between a database and Recovery Service.
Select an IPv4-only subnet for Recovery Service in your database VCN. Do not select an IPv6-enabled subnet as Recovery Service does not support using an IPv6-enabled subnet. See Creating a Subnet to learn more.
Table 4-7 Subnet size requirements and ingress rules for a private subnet used by Recovery Service
Item | Requirements |
---|---|
Minimum subnet size |
/24 (256 IP addresses) |
General ingress rule 1: Allow HTTPS traffic from Anywhere |
This rule allows backup traffic from your Oracle Cloud Infrastructure Database to Recovery Service.
|
General ingress rule 2: Allows SQLNet Traffic from Anywhere |
This rule allows recovery catalog connections and real-time data protection from your Oracle Cloud Infrastructure Database to Recovery Service.
|
If you use network security groups (NSG) to implement security rules or if your database VCN restricts network traffic between subnets, then ensure to add an egress rule for ports 2484 and 8005 from the database NSG or subnet to the Recovery Service NSG or subnet that you create.
Parent topic: Configuring Network Resources for Recovery Service
Create a Recovery Service Subnet in the Database VCN
Use the OCI Console to configure a private subnet for Recovery Service in your database virtual cloud network (VCN).
- In the navigation menu, select Networking, and then select Virtual cloud networks to display the Virtual Cloud Networks page.
- Select the VCN in which your database resides.
- Use these steps to create a Recovery Service subnet with a security list. If you choose to use network security groups, then proceed to step 4.
- Under Resources, select Security Lists.
- Select the security list that is used for the VCN.You must add two ingress rules to allow destination ports 8005 and 2484.
- Click Add Ingress Rules and add these details to set up a stateful ingress rule that allows HTTPS traffic from anywhere:
- Source Type: CIDR
- Source CIDR: Specify the CIDR of the VCN where the database resides.
- IP Protocol: TCP
- Source Port Range: All
- Destination Port Range: 8005
- Description: Specify an optional description of the ingress rule to help manage the security rules.
-
Click Add Ingress Rule and add these details to set up a stateful ingress rule that allows SQLNet traffic from anywhere:
- Source Type: CIDR
- Source CIDR: Specify the CIDR of the VCN where the database resides.
- IP Protocol: TCP.
- Source Port Range: All
- Destination Port Range: 2484.
- Description: Specify an optional description of the ingress rule to help manage the security rules.
Note
Select an IPv4-only subnet for Recovery Service in your database VCN. Do not select an IPv6-enabled subnet as Recovery Service does not support using an IPv6-enabled subnet. See Creating a Subnet to learn more.See: Review Subnet Size Requirements and Security Rules for Recovery Service Subnet for more information.
- In the Virtual Cloud Networks Details page, click Create Subnet.
- Create a private subnet or select a private subnet that already exists in the database VCN. Oracle recommends a subnet size of /24 (256 IP addresses) for the private subnet.
-
In the Subnet Details page, under Resources select Security Lists. Add the security list that includes the ingress rules to allow destination ports 8005 and 2484.
Note
If your database VCN restricts network traffic between subnets, then ensure to add an egress rule for ports 2484 and 8005 from the database subnet to the Recovery Service subnet that you create.
-
Use these steps to create a Recovery Service subnet with network security groups (NSG).
- Under Resources, select Network Security Groups.
- Click Create Network Security Group.Use one of these supported methods to configure security rules using NSGs:
- To implement network isolation, create one NSG for the database VNIC (add egress rules to allow ports 2484 and 8005) and a separate NSG for Recovery Service (add ingress rules to allow ports 2484 and 8005).
- Create and use a single NSG (with egress and ingress rules) for the database VNIC and Recovery Service.
Note
For additional configuration details, refer the relevant OCI Database Service documentation. - After you create the Recovery Service subnet in the database VCN, proceed to register the subnet as a Recovery Service subnet. Oracle recommends that you register a single Recovery Service subnet per VCN.If you have implemented security rules using NSGs, then you must also ensure to add the Recovery Service NSG to the Recovery Service subnet.
Parent topic: Configuring Network Resources for Recovery Service
Register Recovery Service Subnet
After you have created a private subnet for Recovery Service in your database VCN, use this procedure to register the subnet in Recovery Service.
Multiple protected databases can use the same Recovery Service subnet. In order to ensure that the required number of IP addresses are available to support the Recovery Service private endpoints, you can assign multiple subnets to a Recovery Service subnet that is used by more than one protected database.
Select an IPv4-only subnet for Recovery Service in your database VCN. Do not select an IPv6-enabled subnet as Recovery Service does not support using an IPv6-enabled subnet.Ensure that you have completed these prerequisite configuration tasks:
- Assign Policies to Allow Access to Recovery Service and Related Resources
- Create a Recovery Service Subnet in the Database VCN
- Log in to your OCI tenancy.
- In the navigation menu, click Oracle Database, and select Database Backups to display the Database Backups page.
- Click Recovery Service Subnets.
- In the Compartment field, select a compartment where you want to create the Recovery Service subnet.
- Click Register Recovery Service subnet, and specify the details.
- In the Name field, enter a name for the Recovery Service subnet.
- In the Compartment field, select the compartment where you want to create the Recovery Service subnet.
- In the Virtual cloud network field, select the database VCN.Click Change Compartment to select a VCN belonging to a different compartment.
- In the Subnet field, select a private subnet that you have configured for Recovery Service operations in your database VCN.Click Change Compartment to select a private subnet from a different compartment.
- (Optional) Click +Another Subnet to assign an additional subnet to the Recovery Service subnet.If a single subnet does not contain enough IP addresses to support the Recovery Service private endpoints, then you can assign multiple subnets.
- Click Show advanced options to configure these additional features.
- Network security groups
- Tags
If you have used a network security group (NSG) to implement security rules for Recovery Service in the database VCN, then you must add the Recovery Service NSG to the Recovery Service subnet. The Recovery Service NSG can reside in the same compartment or in a different compartment. However, the NSG must belong to the same VCN to which the specified subnet belongs.
- In the Network security groups section, select Use network security groups to control traffic.
- Select the Recovery Service NSG you have created in the database VCN.
- Click +Another network security group to associate multiple NSGs (maximum five).
- Click Register.
You can replace a subnet or add more subnets to support the required number of private endpoints.
-
Use these steps to update an existing Recovery Service subnet:
- In the Recovery Service subnet details page, under Resources, click Subnets.
- Click Add subnets and select the subnets you want to add.
- To replace an existing subnet, click the Action menu, and select Remove subnet. You can then add another subnet.
Note
A Recovery Service subnet must be associated with at least one subnet belonging to your database VCN. - Use these steps to manage the network security groups (NSGs) for an existing Recovery Service subnet:
- In the Network security groups section, click Add network security groups.
- Select and add the Recovery Service network security groups (maximum five).
- To remove an NSG, select the resource and click Remove.
Parent topic: Configuring Network Resources for Recovery Service
Autonomous Recovery Service Checklist
- Ensure that the Recovery Service Subnet Can Communicate with Oracle Services
The Recovery Service Subnet that you registered needs to communicate with the Recovery Service. - Ensure that Your Database Has TDE Fully Configured
When using the Autonomous Recovery Service, you must have your database fully TDE encrypted. - Turn Off Any Manual Operational Backups
In some cases, OCI users perform manual operational backups. These backups are run outside the standard tooling and support point-in-time recovery (non-KEEP backups).
Parent topic: Using the Console to Create Infrastructure Resources
Ensure that the Recovery Service Subnet Can Communicate with Oracle Services
The Recovery Service Subnet that you registered needs to communicate with the Recovery Service.
To access the service, the routing table for the private subnet needs to include "All IAD Services In Oracle Services Network".
For more information, see Private Access to Oracle Services.
Parent topic: Autonomous Recovery Service Checklist
Ensure that Your Database Has TDE Fully Configured
When using the Autonomous Recovery Service, you must have your database fully TDE encrypted.
For new databases that are born in the cloud, this should already be done. But if you creating a stub database in OCI and migrating a database to an Oracle Database Service from on-premises, or somewhere else, you might not meet all the criteria. For these databases you should verify that you meet the prerequisites for a backing up to the recovery service. I have a blog post you can find here that will outline what to check for with queries to execute.
- You need to have
WALLET_ROOT
configured in the database. If you are still usingsqlnet.ora
, you need to usedbaascli
to properly setWALLET_ROOT
for all databases that will be utilizing the Recovery Service.To enablewallet_root
SPFILE parameter for an existing database, run:dbaascli tde enableWalletRoot
For more information, see dbaascli tde enableWalletRoot.
Note
SettingENCRYPTION_WALLET_LOCATION
insqlnet.ora
is not supported and will be deprecated. - You need to have an encryption key set for the CDB and all PDBs in your database.
- ALL tablespaces must be TDE encrypted before executing your first backup.
Parent topic: Autonomous Recovery Service Checklist
Turn Off Any Manual Operational Backups
In some cases, OCI users perform manual operational backups. These backups are run outside the standard tooling and support point-in-time recovery (non-KEEP backups).
If you are running any of these types of operational backups, it is critical that you turn them off at this point. Running operational backups to two different locations can cause issues with both backups.
If you are using the tooling for object storage backups, and switch to the Recovery Service, the switchover will be automated by the tooling, and all of the previous backups will remain available.
Parent topic: Autonomous Recovery Service Checklist