Documentación de Oracle Cloud Infrastructure

Oracle Exadata Database Service on Dedicated Infrastructure

Utilice la información de esta sección para resolver problemas comunes de Oracle Exadata Database Service on Dedicated Infrastructure.

Configuración automática de entrada de red para servicios de base de datos de Exadata

Puede conectar una máquina virtual de Microsoft Azure a un cluster de máquina virtual de Oracle Exadata si ambas están en la misma red virtual (VNet). La funcionalidad es automática y no requiere cambios adicionales en las reglas del grupo de seguridad de red (NSG). Si necesita conectar una máquina virtual de Microsoft Azure desde un VNet diferente al que se creó el cluster de VM de Oracle Exadata, un paso adicional para configurar las reglas de tráfico de NSG para permitir que el tráfico de la otra VNet fluya correctamente.

Por ejemplo, si tiene dos (2) VNets (A y B) con VNet A que sirve a la máquina virtual de Microsoft Azure y VNet B que sirve al cluster de VM de Oracle Exadata, debe agregar la dirección CIDR de VNet A a la tabla de rutas de NSG en OCI.

Tabla 1-3 Reglas de NSG de cliente por defecto

Dirección Origen o destino Protocolo Detalles Descripción

Dirección: salida

Sin estado: No

Tipo de destino: CIDR

Destino: 0.0.0.0/0

Todos los protocolos Permitir: todo el tráfico para todos los puertos Regla de salida de NSG por defecto

Dirección: entrada

Sin estado: No

Tipo de origen: CIDR

Origen: CIDR VNet de Microsoft Azure

TCP

Rango de puertos de origen: Todo

Rango de puertos de destino: todos

Permitir: tráfico TCP para puertos: todos

Ingrese todos los TCP de Microsoft Azure VNet.

Dirección: entrada

Sin estado: No

Tipo de origen: CIDR

Origen: CIDR AzureVNet de Microsoft

ICMP

Tipo: todos

Código: Todo

Permitir: tráfico ICMP para: todo

Ingrese todos los ICMP de Microsoft Azure VNet.

Tabla 1-4 Reglas de NSG de copia de seguridad por defecto

Dirección Origen o destino Protocolo Detalles Descripción

Dirección: salida

Sin estado: No

Tipo de destino: servicio

Destino: almacenamiento de objetos de OCI IAD

TCP

Rango de puertos de origen: Todo

Rango de puertos de destino: 443

Permitir: tráfico TCP para puertos: 443 HTTPS

Permite el acceso al almacenamiento de objetos.

Dirección: entrada

Sin estado: No

Tipo de origen: CIDR

Origen: 0.0.0.0/0

ICMP

Tipo: 3

Código: 4

Permite:tráfico de ICMP para: 3, 4 Destino no accesible: se requiere fragmentación y se había establecido no fragmentar

Permite mensajes de fragmentación de detección de MTU de ruta.

El nombre de dominio completo (FQDN) de DNS privado no puede contener más de cuatro (4) etiquetas para un cluster de VM de Oracle Exadata

Al crear un cluster de VM de Oracle Exadata, si selecciona una zona de DNS privada cuyo FQDN tiene más de 4 etiquetas (delimitado por un punto '.'), aparece el siguiente error. 

Error returned by CreateCloudVmCluster operation in Database service. (400, InvalidParameter, false) domain name cannot contain more than 4 labels
La solución alternativa es cambiar el nombre del DNS privado que causó el error o seleccionar un DNS privado diferente cuyo FQDN tiene cuatro (4) o menos etiquetas.

Oracle Exadata Database Service on Dedicated Infrastructure

Al crear un cluster de VM de Oracle Exadata, si selecciona una zona de DNS privada creada sin etiquetas, la etiqueta de OCI por defecto oracle-tags se genera automáticamente para el cluster de VM. Si el espacio de nombres de etiqueta no está autorizado en el arrendamiento de OCI, esto puede provocar un error. 

404 NotAuthorizedOrNotFound
La solución alternativa es agregar las siguientes políticas al arrendamiento de OCI:
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’

Diferencias de requisitos de dirección IP para Exadata Database Services

Hay diferencias entre los requisitos de dirección IP entre Oracle AI Database@Azure y Oracle Cloud Infrastructure (OCI).

En la documentación Requirements for IP Address Space, se deben tener en cuenta los siguientes cambios para Oracle AI Database@Azure.
  • Oracle AI Database@Azure solo soporta Exadata X9M. El resto de unidades no están soportadas.
  • Oracle AI Database@Azure reserva 13 direcciones IP para la subred del cliente frente a 3 para los requisitos de OCI.

Diferencias de la unidad de transmisión máxima (MTU) para Exadata Database Services

La unidad de transmisión máxima (MTU) es el tamaño de trama más grande (en bytes) que se puede enviar. Es una configuración configurable.

  • Tamaño de MTU por defecto de Azure = 1500 bytes
  • Tamaño de MTU por defecto de OCI = 9000 bytes

Debido a las diferencias en los tamaños de MTU por defecto, la detección de MTU de ruta (PMTUD) es necesaria para determinar la MTU adecuada entre los recursos de Azure y los servicios de OCI. Para que PMTUD funcione, los clientes deben permitir el código 4 del protocolo de mensajes de control de Internet (ICMP) tipo 3 en toda la pila de red. Desactivar ICMP por completo puede provocar problemas de conectividad.

Para obtener más información, consulte lo siguiente:

Limitación de zona de DNS privada para servicios de base de datos de Exadata

Al aprovisionar los servicios de base de datos de Exadata, una zona de DNS privada solo puede seleccionar zonas con cuatro etiquetas o menos.

Por ejemplo, se permite a.b.c.d, mientras que no se permite a.b.c.d.e.

Fallo de aprovisionamiento de cluster de VM de Oracle Exadata con error de autorización

El aprovisionamiento de un cluster de VM de Oracle Exadata falla con un error de autorización como se indica a continuación. 

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.
El fallo se produce porque el usuario que realiza la acción no tiene permisos de Azure para el recurso Microsoft.BareMetal/BareMetalConnections.
Solución Alternativa
  1. Asegúrese de que ninguna política de Azure asignada al usuario o la suscripción impide que el usuario realice la acción. Si el usuario tiene permisos específicos asignados directamente, agregue los siguientes recursos a la lista autorizada.
    • Microsoft.BareMetal/BareMetalConnections
    • Microsoft.Network/privateDnsZones
  2. Suprima el cluster de VM de Exadata con fallos de la interfaz de usuario de Azure.
  3. Espere 30 minutos para asegurarse de que el cluster de VM de Exadata ha terminado por completo tanto en Azure como en OCI. Este período de espera garantiza que todos los recursos dependientes también se supriman.
  4. Aprovisione el nuevo cluster de VM de Exadata.

No se puede suprimir la infraestructura de Exadata

Azure tiene un timeout de destino de hasta una (1) hora para la supresión de un cluster de VM de Exadata. Puede ocurrir que esta vez no sea suficiente para que todos los recursos dependientes de la infraestructura de Exadata se supriman por completo, en particular los recursos de red.

Azure puede cambiar el estado del cluster de VM de Exadata a TERMINATED, pero en OCI los recursos dependientes aún se pueden eliminar. En esta situación, si el cliente intenta suprimir la infraestructura de VM de Exadata Y la supresión del cluster de VM de Exa no ha finalizado en el lado de OCI, aparecerá el siguiente mensaje de error:
Cannot delete Exadata infrastructure. All associated VM clusters must be deleted before you delete the Exadata infrastructure. (Code: 400)
La solución alternativa es esperar hasta que todos los clusters de VM de Exadata asociados a la infraestructura de Exadata se hayan terminado correctamente en OCI.

El estado Escaling In Progress no se muestra para la base de datos conectable (PDB)

Las bases de datos de conexión (PDB) no muestran el estado "Escala en curso" mientras hay una operación de escala en curso.

En su lugar, el estado de la PDB pasa de "Aceptada" a "Actualizando". No hay ninguna solución alternativa disponible.

El aprovisionamiento de clusters de VM de Oracle Exadata falla porque el número de IP disponibles informadas por OCI y Azure no coincide

Azure informa el número incorrecto de IP disponibles en la subred, lo que provoca que falle el aprovisionamiento de cluster de VM de Oracle Exadata. Esto provoca el siguiente 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.
Verifique el número correcto de direcciones IP disponibles en la subred mediante la consola de OCI. Para obtener más información, consulte Listado de direcciones IP privadas. La solución alternativa es volver a configurar la subred según los requisitos previos.

Pérdidas de informes de métricas en Microsoft Azure

Si algún exportador envía una métrica que tiene más de 20 minutos, los agentes la borran y los clientes pierden esos datos.

Este tiempo de espera de 20 minutos es una limitación de Microsoft Azure y se aplica a cualquier exportador. Por ejemplo, aquí hay algunos escenarios en los que se pueden perder métricas.
  • Los certificados han caducado. El exportador no puede establecer conexión con el agente y una acumulación de métricas. Después de rotar a nuevos certificados, las métricas están anticuadas y, dado que tienen más de 20 minutos de antigüedad, el agente borra las métricas y los clientes verán estas métricas.
  • Atrasos: Cuando el exportador, por cualquier motivo, desarrolla un atraso que hace que el exportador tarde más de lo habitual en procesar las métricas, la métrica se perderá si son recibidas por el agente con más de 20 minutos de antigüedad.
Estas no son una lista exhaustiva de ejemplos, pero están destinadas a proporcionar contexto a las métricas que informan de pérdidas.

Error al obtener "ResourceMoveProviderValidationFailed" al intentar mover recursos OracleDB@Azure a otro grupo de recursos

El movimiento de recursos de Oracle AI Database@Azure no está soportado actualmente mediante la función de movimiento de recursos en Azure.

Al intentar mover un recurso de Oracle AI Database@Azure, obtiene el siguiente error:
(Code: ResourceMoveProviderValidationFailed) Resource provider 'Oracle.Database' failed to process resource move validation for resource type '<RESOURCE_TYPE>'

Para solucionar este problema y obtener más información, consulte el siguiente artículo.

No se ha podido crear una regla de NSG de entrada sin especificar el puerto de origen

Para solucionar este problema, complete los pasos siguientes:

  • Utilice el valor como "Todos" los puertos en las reglas de grupos de seguridad de red (NSG).
  • Las reglas de NSG requieren que defina un puerto o un rango de puertos cuando utilice TCP o UDP. Para permitir todos los puertos, debe seleccionar Todos los protocolos en lugar de seleccionar TCP/UDP.
  • Seleccione la opción Todos los protocolos cuando desee agregar una regla. Esta configuración activa todos los puertos (1-65535) en todos los protocolos.

Para obtener más información, consulte la siguiente documentación.

Para gestionar reglas de NSG, consulte Grupos de seguridad de red.

Obtención del "Error 403 Prohibido en la Operación CreateVcn: Infracción de Zona de Seguridad" en el Servicio de Red Virtual

No puede crear ni modificar este recurso en esta zona de seguridad al aprovisionar el cluster de VM.

Revisión y gestión de políticas de zonas de seguridad en OCI

Las zonas de seguridad de OCI aplican reglas de seguridad estrictas en los compartimentos. A veces, políticas como securityZonePolicyName = denegar manage_virtual_network_resource pueden impedir que cree o modifique recursos de red.

Pasos de proceso para comprobar y ajustar zonas de seguridad

  1. Abrir zonas de seguridad: en la consola de OCI, vaya a Identidad y seguridad y, a continuación, seleccione Zonas de seguridad.
  2. Seleccionar el compartimento: seleccione el compartimento o subcompartimento que desea revisar.
  3. Revisión de Políticas:
    1. Compruebe la lista de políticas aplicadas.
    2. Busque restricciones en los recursos de red.
  4. Eliminar subcompartimento (si es necesario): si la política es demasiado restrictiva, elimine el subcompartimento de la zona de seguridad. Para obtener más información, consulte Removing a Subcompartment from a Security Zone|.

Error al recibir la configuración de DNS correcta

Al desplegar un cluster de VM de Exadata en Oracle AI Database@Azure, los nombres de dominio por defecto especificados durante el aprovisionamiento no se agregan al archivo /etc/hosts en los servidores de VM del cluster.

Error:
# domain domain 1.oraclevcn.com domain2.oraclevcn.com localdomain
nameserver 169.254.169.254
#### END Generated by Exadata ####

Solución alternativa: al crear el cluster de VM de Exadata y al intentar utilizar la opción de DNS gestionado por defecto, asegúrese de que la opción de DNS personalizado no esté marcada. Para obtener más información, consulte la sección DNS gestionado en la publicación del blog Crónicas del equipo A: Opciones de DNS de Oracle Database@Azure.

Como alternativa, si desea utilizar una configuración de DNS personalizada, consulte la sección FQDN personalizado en la misma publicación de blog.

Para obtener más información, consulte Configuración de DNS de Oracle Database@Azure.

No se ha podido aprovisionar la infraestructura X11M mediante Terraform

Se produce un error 'la unidad no está soportada' al intentar aprovisionar el modelo X11M de la infraestructura de Exadata mediante Terraform. Sin embargo, el aprovisionamiento del modelo X11M a través del portal de Azure se realiza correctamente y los despliegues de X9M mediante Terraform se completan sin problemas.

Solución: el soporte para el modelo X11M en Terraform se lanzó oficialmente el 10 de julio de 2025. Hay dos campos adicionales necesarios al aprovisionar X11M:
  • Tipo de Servidor de Base de Datos
  • Tipo de Servidor de Almacenamiento
Por ejemplo:
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"

Fallo de aprovisionamiento de cluster de VM de Exadata debido a una zona horaria no válida

Obtención del error VM_CLUSTER_CREATE_FAILED al aprovisionar un cluster de VM de Exadata mediante Terraform debido a una zona horaria no válida.

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>)
Solución:
  1. Para ver la lista de zonas horarias válidas, consulte Configuración de zona horaria de Exadata.
  2. Asegúrese de que la zona horaria correcta está definida en el código de Terraform. Por ejemplo:
    
body = {
 "properties": {
     ...
     "timeZone": "<TIMEZONE>",

Fallo de aprovisionamiento de cluster de VM de Exadata debido a un nombre VNet largo

Fallo al aprovisionar un cluster de VM de Exadata con el siguiente error:

Error:

VM_CLUSTER_CREATE_FAILED

Causa:

Este error se puede producir si el nombre de la red virtual de Azure (VNet) supera los 60 caracteres. Cuando el nombre VNet tiene más de 60 caracteres, no se puede crear la tarjeta de interfaz de red virtual (VNIC) de Azure porque la VNIC tiene un límite máximo de 80 caracteres.

Solución:

Asegúrese de que el nombre VNet de Azure no supere los 60 caracteres antes de aprovisionar el cluster de VM de Exadata. Cambie el nombre de VNet para que cumpla el requisito de límite de caracteres y, a continuación, vuelva a intentar el proceso de aprovisionamiento.

Fallo de aprovisionamiento de cluster de VM de Exadata debido a que el nombre de dominio contiene caracteres no alfanuméricos

Fallo al aprovisionar un cluster de VM de Exadata con el siguiente 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.

Causa:

El nombre de dominio especificado en la solicitud de aprovisionamiento de cluster de VM de Exadata contiene caracteres no alfanuméricos. El nombre de dominio debe contener solo letras y números.

Solución:

Asegúrese de que el nombre de dominio solo contenga letras y números al aprovisionar clusters de VM de Exadata.