Documentación de Oracle Cloud Infrastructure

Solución de problemas y problemas conocidos de Exadata Database Services for Azure

Utilice la información de esta sección para resolver errores comunes y problemas de aprovisionamiento en los entornos de Oracle Database@Azure.

Los problemas tratados en esta guía no cubren problemas generales relacionados con la configuración, los valores y la configuración de la cuenta de Oracle Database@Azure. Para obtener más información sobre estos temas, consulte Visión general de Oracle Database@Azure.

Temas de solución de problemas

Problemas conocidos

Ceses y bloqueos de Microsoft Azure para servicios de base de datos de Exadata

Oracle recomienda eliminar todos los bloqueos de Microsoft Azure en los recursos de Oracle Database@Azure antes de terminar un recurso de Exadata Database Services.

Por ejemplo, si ha creado un punto final privado de Microsoft Azure, elimine primero ese recurso. Si tiene una política que impide la supresión de recursos bloqueados, el flujo de trabajo de Oracle Database@Azure fallará porque Oracle Database@Azure no puede suprimir el bloqueo.

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 '.'), obtendrá 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 es cambiar el nombre del DNS privado que causó el error o seleccionar un DNS privado diferente cuyo FQDN tenga cuatro (4) o menos etiquetas.

Error no autorizado cuando se utiliza DNS privado sin etiquetas para los servicios de base de datos de Exadata

Al crear un cluster de VM de Oracle Exadata, si selecciona una zona de DNS privada creada sin ninguna etiqueta, 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 consiste en 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 los servicios de base de datos de Exadata

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

En la documentación Requisitos para el espacio de direcciones IP, se deben tener en cuenta los siguientes cambios para Oracle Database@Azure.
  • Oracle Database@Azure solo soporta Exadata X9M. El resto de unidades no están soportadas.
  • Oracle Database@Azure reserva 13 direcciones IP para la subred del cliente, en lugar de 3 para los requisitos de OCI.

Diferencias máximas de la unidad de transmisión (MTU) para los servicios de base de datos de Exadata

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 predeterminado 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, se necesita la detección de MTU de ruta (PMTUD) para determinar la MTU adecuada entre los recursos de Azure y los servicios de OCI. Para que el 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. La desactivación completa de ICMP puede provocar problemas de conectividad.

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

Limitación de zona de DNS privado 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 a.b.c.d.e no se permite.

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

Puede conectar una VM de Microsoft Azure a un cluster de VM de Oracle Exadata si ambos 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 VM de Microsoft Azure desde una VM VNet diferente de la que se creó el cluster de VM de Oracle Exadata, un paso adicional para configurar 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 VM 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 del NSG en OCI.

Tabla 1-4 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

de 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 todo el TCP desde Microsoft Azure VNet.

Dirección: entrada

Sin estado: No

Tipo de origen: CIDR

Origen: CIDR AzureVNet de Microsoft

ICMP

Tipo: todos

Código: Todos

Permitir: tráfico ICMP para: todo

Ingrese todos los ICMP de Microsoft Azure VNet.

Tabla 1-5 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 IAD de OCI

TCP

Rango de puertos de origen: Todo

Rango de puertos de destino: 443

Permitir: tráfico TCP para puertos: HTTPS 443

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

Permitir: tráfico ICMP para: 3, 4 No se puede acceder a destino: se necesita fragmentación y se había definido no fragmentar

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

Las funciones de red avanzadas de Azure, que incluyen Azure Private Link, soporte para varios grupos de seguridad de red (NSG) e intercambio de tráfico de red virtual global (VNet), permiten el uso de subredes delegadas de Azure con clusters de VM de Oracle Exadata. Para obtener más información, consulte Planificación de red para Oracle Database@Azure.

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 de la siguiente manera: 

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 a la suscripción impida al usuario realizar la acción. Si el usuario tiene permisos específicos asignados directamente, agregue los siguientes recursos a la lista de autorizaciones.
    • 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 termina completamente en Azure y OCI. Este período de espera garantiza que también se supriman todos los recursos dependientes.
  4. Aprovisione el nuevo cluster de VM de Exadata.

No se puede suprimir la infraestructura de Exadata

Azure tiene un timeout objetivo de hasta una (1) hora para la supresión de un cluster de VM de Exadata. Puede suceder 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 pueden seguir eliminándose. 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 terminado en 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 "Escala en curso" 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 una operación de escala está en curso.

En su lugar, el estado de la PDB pasa de "Aceptada" a "Actualizando". Solución Alternativa no Disponible.

El aprovisionamiento de clusters de VM de Oracle Exadata falla porque el número de IP disponibles notificadas 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 del 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 de acuerdo con los requisitos previos.

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

Si un exportador envía una métrica con una antigüedad superior a 20 minutos, los agentes la eliminan 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.
  • Certificados vencidos. El exportador no puede establecer una conexión con el agente y una acumulación de compilaciones de métricas. Después de rotar a nuevos certificados, las métricas están anticuadas y, debido a que tienen más de 20 minutos de antigüedad, el agente elimina las métricas y los clientes verán estas métricas.
  • Atraso: Cuando el exportador, por cualquier razón, desarrolla un atraso que hace que el exportador tome más tiempo de lo habitual para procesar las métricas, la métrica se perderá si son recibidas por el agente con más de 20 minutos de antigüedad.
No se trata de una lista exhaustiva de ejemplos, sino de 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 Database@Azure no está soportado actualmente mediante la función de movimiento de recursos en Azure.

Al intentar mover un recurso de Oracle Database@Azure, aparece 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 las reglas de NSG, consulte la documentación.

Recurso de base de datos suprimido en Azure pero no en OCI

Cuando encuentre el problema de que el recurso de cluster de VM de Exadata se suprima en Azure pero no se elimine de OCI, cree una solicitud de soporte para solicitar un acceso temporal para suprimir el recurso.

Error:

DeleteCloudVmCluster operation is blocked for resources deployed at Azure. Please try this operation from Azure or contact support for further assistance.

Para solucionar este problema, consulte Creación de una solicitud de soporte para obtener información detallada.