Oracle Exadata Database Service on Dedicated Infrastructure
Use the information in this section to solve common issues of Oracle Exadata Database Service on Dedicated Infrastructure.
Automatic Network Ingress Configuration for Exadata Database Services
You can connect a Microsoft Azure VM to an Oracle Exadata VM Cluster if both are in the same virtual network (VNet). The functionality is automatic and requires no additional changes to network security group (NSG) rules. If you need to connect an Microsoft Azure VM from a different VNet than the one where the Oracle Exadata VM Cluster was created, an additional step to configure NSG traffic rules to allow the other VNet's traffic to flow properly.
As an example, if you have two (2) VNets (A and B) with VNet A serving the Microsoft Azure VM and VNet B serving the Oracle Exadata VM Cluster, you need to add VNet A's CIDR address to the NSG route table in OCI.
Table 1-3 Default Client NSG Rules
| Direction | Source or Destination | Protocol | Details | Description |
|---|---|---|---|---|
|
Direction: Egress Stateless: No |
Destination Type: CIDR Destination: 0.0.0.0/0 |
All Protocols | Allow: All traffic for all ports | Default NSG egress rule |
|
Direction: Ingress Stateless: No |
Source Type: CIDR Source: Microsoft Azure VNet CIDR |
TCP |
Source Port Range: All Destination Port Range: All Allow: TCP traffic for ports: All |
Ingress all TCP from Microsoft Azure VNet. |
|
Direction: Ingress Stateless: No |
Source Type: CIDR Source: Microsoft AzureVNet CIDR |
ICMP |
Type: All Code: All Allow: ICMP traffic for: All |
Ingress all ICMP from Microsoft Azure VNet. |
Table 1-4 Default Backup NSG Rules
| Direction | Source or Destination | Protocol | Details | Description |
|---|---|---|---|---|
|
Direction: Egress Stateless: No |
Destination Type: Service Destination: OCI IAD object storage |
TCP |
Source Port Range: All Destination Port Range: 443 Allow: TCP traffic for ports: 443 HTTPS |
Allows access to object storage. |
|
Direction: Ingress Stateless: No |
Source Type: CIDR Source: 0.0.0.0/0 |
ICMP |
Type: 3 Code: 4 Allow: ICMP traffic for: 3, 4 Destination Unreachable: Fragmentation Needed and Don't Fragment was Set |
Allows Path MTU Discovery fragmentation messages. |
Private DNS Fully-Qualified Domain Name (FQDN) Can't Contain More Than Four (4) Labels for an Oracle Exadata VM Cluster
When creating an Oracle Exadata VM Cluster, if you select a private DNS zone whose FQDN has more than 4 labels (delimited by a period '.'), you get the following error.
Error returned by CreateCloudVmCluster operation in Database service. (400, InvalidParameter, false) domain name cannot contain more than 4 labelsThe workaround is to rename the private DNS that caused the error, or select a different private DNS whose FQDN has four (4) or less labels.Oracle Exadata Database Service on Dedicated Infrastructure
When creating an Oracle Exadata VM Cluster, if you select a private DNS zone created without any tags, the default OCI tag oracle-tags is automatically generated for the VM cluster. If the tag namespace isn't authorized in the OCI tenancy, this might cause an error.
404 NotAuthorizedOrNotFoundThe workaround is to add the following policies to the OCI tenancy:Allow any user to use tag-namespaces in tenancy where request.principal.type = ‘multicloudlink’
Allow any user to manage tag-defaults in tenancy where request.principal.type = ‘multicloudlink’IP Address Requirement Differences for Exadata Database Services
There are IP address requirement differences between Oracle AI Database@Azure and Oracle Cloud Infrastructure (OCI).
- Oracle AI Database@Azure only supports Exadata X9M. All other shapes are unsupported.
- Oracle AI Database@Azure reserves 13 IP addresses for the client subnet versus 3 for OCI requirements.
Maximum Transmission Unit (MTU) Differences for Exadata Database Services
Maximum transmission unit (MTU) is the largest frame size (in bytes) that can be sent. It is a configurable setting.
- Azure default MTU size = 1500 bytes
- OCI default MTU size = 9000 bytes
Due to the differences in default MTU sizes, Path MTU Discovery (PMTUD) is required to determine the proper MTU between Azure resources and OCI services. For PMTUD to work, customers must allow Internet Control Message Protocol (ICMP) Type 3 code 4 on the entire network stack. Turning off ICMP completely can result in connectivity issues.
Private DNS Zone Limitation for Exadata Database Services
When provisioning Exadata Database Services, a private DNS zone can only select zones with four labels or less.
For example, a.b.c.d is allowed, while a.b.c.d.e is not allowed.
Oracle Exadata VM Cluster Provisioning Fails with Authorization Error
Provisioning an Oracle Exadata VM Cluster fails with an authorization error as follows.
Authorization Failed
The client <client_name> with object id <object_id> does not have authorization to perform action 'Oracle.Database/location/operationStatuses/read' over scope <scope_details> or scope is invalid. If access was recently granted, please refresh your credentials.The failure occurs because the user performing the action doesn't have Azure permissions for the Microsoft.BareMetal/BareMetalConnections resource.
- Ensure that no Azure policy assigned to the user or the subscription is preventing the user from performing the action. If the user has specific permissions assigned to them directly, add the following resources to the authorized list.
Microsoft.BareMetal/BareMetalConnectionsMicrosoft.Network/privateDnsZones
- Delete the failed Exadata VM Cluster from the Azure UI.
- Wait 30 minutes to ensure that the Exadata VM Cluster is fully terminated in both Azure and OCI. This wait period ensures that all dependent resources are also deleted.
- Provision your new Exadata VM Cluster.
Cannot Delete Exadata Infrastructure
Azure has a targeted timeout of up to one (1) hour for the deletion of an Exadata VM Cluster. It may happen that this time is not enough for all the dependent resources in Exadata Infrastructure to be totally deleted, in particular network resources.
Cannot delete Exadata infrastructure. All associated VM clusters must be deleted before you delete the Exadata infrastructure. (Code: 400)The workaround is to wait until all the Exadata VM Clusters associated with the Exadata Infrastructure have been successfully terminated in OCI.
Scaling In Progress" Status Doesn't Display for Pluggable Database (PDB)
Pluggable databases (PDBs) don't display a "Scaling in progress" status while a scaling operation is in progress.
Instead, the PDB status goes from "Accepted" to "Updating". No workaround available.
Oracle Exadata VM Cluster Provisioning Fails Because Number of Available IPs Reported by OCI and Azure Doesn't Match
Azure reports the wrong number of available IPs in the subnet, causing Oracle Exadata VM Cluster provisioning to fail. This causes the following error:
Error returned by CreateCloudVmCluster operation in Database service.(400, InvalidParameter, false) Cidr block of the subnet must have at least 11 ip addresses available.Verify the correct number of available IP addresses in the subnet using the OCI console. For more information, see Listing Private IP Addresses. The workaround is to reconfigure the subnet according to the prerequisites.
Metrics Reporting Losses in Microsoft Azure
If any exporter sends a metric that is older than 20 minutes, the agents drops it and customers lose that data.
- Certificates expired. Exporter cannot establish connection with agent and a backlog of metrics builds. After rotating to new certificates, the metrics are stale and because they are more than 20 minutes old, the agent drops the metrics and customers will see these metrics.
- Backlog: When the exporter, for any reason, develops a backlog that results in the exporter taking longer than usual to process the metrics, metric will be lost if they are received by the agent more than 20 minutes old.
Getting "ResourceMoveProviderValidationFailed" Error While Trying to Move OracleDB@Azure Resources to Another Resource Group
Moving Oracle AI Database@Azure resources is not currently supported using the resource move feature in Azure.
(Code: ResourceMoveProviderValidationFailed) Resource provider 'Oracle.Database' failed to process resource move validation for resource type '<RESOURCE_TYPE>'To address this issue and for more information, see the following article.
Unable to Create an Ingress NSG Rule Without Specifying the Source Port
To address this issue, complete the following steps:
- Use the value as "All" Ports in Network Security Groups (NSG) Rules.
- NSG Rules require you to define a port or port range when you use TCP or UDP. To allow all ports, you must select All Protocols instead of selecting TCP/UDP.
- Select the All Protocols option when you want to add a rule. This configuration enables all ports
(1-65535)across all protocols.
For more information, see the following documentation.
To manage NSG Rules, see Network Security Groups.
Getting "Error 403 Forbidden in CreateVcn Operation: Security Zone Violation" in Virtual Network Service
You can't create or modify this resource in this security zone' when Provisioning VM Cluster.
Review and Manage Security Zone Policies in OCI
Security Zones in OCI enforce strict security rules on compartments. Sometimes, policies like securityZonePolicyName = deny manage_virtual_network_resource can block you from creating or modifying networking resources.
Process steps to check and adjust Security Zones
- Open Security Zones: From the OCI Console, navigate to Identity & Security and then select Security Zones .
- Select Your Compartment: Choose the compartment or subcompartment you want to review.
- Review Policies:
- Check the list of enforced policies.
- Look for restrictions on networking resources.
- Remove Subcompartment (if needed): If the policy is too restrictive, remove the subcompartment from the security zone. For more information, see Removing a Subcompartment from a Security Zone|.
Failing to Receive Proper DNS Configuration
When deploying an Exadata VM Cluster in Oracle AI Database@Azure, the default domain names specified during provisioning are not being added to the /etc/hosts file on the VM servers in the cluster.
# domain domain 1.oraclevcn.com domain2.oraclevcn.com localdomain
nameserver 169.254.169.254
#### END Generated by Exadata ####Workaround: When creating the Exadata VM Cluster and intending to use the default managed DNS option, ensure that the Custom DNS option is left unchecked. For more information, see the Managed DNS section in the A-Team Chronicles Blog Post: Oracle Database@Azure DNS Options.
Alternatively, if you want to use a custom DNS setup, see the Custom FQDN section in the same blog post.
For additional details , see Oracle Database@Azure DNS Setup.
Unable to Provision X11M Infrastructure Using Terraform
A ‘shape is not supported’ error occurs when attempting to provision the Exadata Infrastructure X11M model using Terraform. However, provisioning the X11M model through the Azure Portal is successful, and X9M deployments using Terraform complete without issue.
- Database Server Type
- Storage Server Type
resource "azurerm_oracle_exadata_infrastructure" "example" {
name = "example-exadata-infra"
resource_group_name = azurerm_resource_group.example.name
location = azurerm_resource_group.example.location
zones = ["1"]
display_name = "example-exadata-infra"
storage_count = 3
compute_count = 2
shape = "Exadata.X11M"
database_server_type = "X11M"
storage_server_type = "X11M-HC"Exadata VM Cluster Provision Failed Due to Invalid Timezone
Getting the error VM_CLUSTER_CREATE_FAILED when provisioning an Exadata VM Cluster using Terraform due to an invalid timezone.
Error:
... (400, InvalidParameter, false) request.timeZone The time zone <TIMEZONE> is not valid.
Valid time zones are those supported in both the Java.util.TimeZone class and on the Linux
operating system. (opc-request-id: <OPC_REQUEST_ID>)- To view the list of valid timezones, see Exadata Timezone Settings .
- Ensure the correct timezone is defined in the Terraform code. For example:
body = { "properties": { ... "timeZone": "<TIMEZONE>",
Exadata VM Cluster Provisioning Fails Due to Long VNet Name
Provisioning an Exadata VM Cluster fails with the following error:
Error:
VM_CLUSTER_CREATE_FAILEDCause:
This error can occur if Azure Virtual Network (VNet) name exceeds 60 characters. When the VNet name is longer than 60 characters, the Azure Virtual Network Interface Card (VNIC) cannot be created because the VNIC has a maximum character limit of 80 characters.
Solution:
Ensure that the Azure VNet name does not exceed 60 characters before provisioning the Exadata VM Cluster. Rename the VNet to meet the character limit requirement, then retry the provisioning process.
Exadata VM Cluster Provisioning Fails Due to Domain Name Contains Non-Alphanumeric Characters
Provisioning an Exadata VM Cluster fails with the following error:
Error:
Error occurred when executing createVmCluster workflow: Error returned by
CreateCloudVmCluster operation in Database service.(400, InvalidParameter, false) Each domain
name label label can contain only letters and numbers. Cause:
The domain name specified in the Exadata VM Cluster provision request contains non-alphanumeric characters. The domain name must contain only letters and numbers.
Solution:
Ensure that the domain name contains only letters and numbers when provisioning Exadata VM Cluster(s).