Documentação do Oracle Cloud Infrastructure

Solução de Problemas e Problemas Conhecidos do Exadata Services for Azure

Use as informações desta seção para resolver erros comuns e problemas de provisionamento em seus ambientes do Oracle Database@Azure.

Os problemas abordados neste guia não abrangem problemas gerais relacionados à configuração, às definições e à configuração da conta do Oracle Database@Azure. Para obter mais informações sobre esses tópicos, consulte Visão Geral do Oracle Database@Azure.

Tópicos de Solução de Problemas

Problemas Conhecidos

Rescisões e Bloqueios do Microsoft Azure para Serviços Exadata

A Oracle aconselha a remoção de todos os bloqueios do Microsoft Azure nos recursos do Oracle Database@Azure antes de encerrar um recurso do Exadata Services.

Por exemplo, se você criou um ponto final privado do Microsoft Azure, remova esse recurso primeiro. Se você tiver uma política que impeça a exclusão de recursos bloqueados, o workflow do Oracle Database@Azure falhará porque o Oracle Database@Azure não pode excluir o bloqueio.

O FQDN (Nome de Domínio Totalmente Qualificado) do DNS Privado não Pode Conter Mais de Quatro (4) Labels para um Cluster de VMs do Oracle Exadata

Ao criar um Cluster de VMs do Oracle Exadata, se você selecionar uma zona de DNS privada cujo FQDN tenha mais de 4 labels (delimitados por um ponto '.'), receberá o seguinte erro: 

Error returned by CreateCloudVmCluster operation in Database service. (400, InvalidParameter, false) domain name cannot contain more than 4 labels
A solução alternativa é renomear o DNS privado que causou o erro ou selecionar outro DNS privado cujo FQDN tenha quatro (4) ou menos labels.

Erro Não Autorizado Quando o DNS Privado Sem Tags é Usado para Serviços Exadata

Ao criar um Cluster de VMs do Oracle Exadata, se você selecionar uma zona de DNS privada criada sem tags, a tag padrão do OCI oracle-tags será gerada automaticamente para o cluster de VMs. Se o namespace de tag não estiver autorizado na tenancy do OCI, isso poderá causar um erro. 

404 NotAuthorizedOrNotFound
A solução alternativa é adicionar as seguintes políticas à tenancy do 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’

Diferenças de Requisitos de Endereço IP para Serviços Exadata

Há diferenças de requisitos de endereço IP entre o Oracle Database@Azure e a Oracle Cloud Infrastructure (OCI).

Na documentação Requisitos para Espaço de Endereço IP, as alterações a seguir para o Oracle Database@Azure devem ser consideradas.
  • O Oracle Database@Azure só suporta o Exadata X9M. Todas as outras formas não são suportadas.
  • O Oracle Database@Azure reserva 13 endereços IP para a sub-rede do cliente versus 3 para requisitos do OCI.

Diferenças de MTU (Unidade Máxima de Transmissão) para Serviços Exadata

A unidade de transmissão máxima (MTU) é o maior tamanho de quadro (em bytes) que pode ser enviado. É uma configuração configurável.

  • Tamanho de MTU padrão do Azure = 1500 bytes
  • Tamanho de MTU padrão do OCI = 9000 bytes

Devido às diferenças nos tamanhos de MTU padrão, a PMTUD (Descoberta de MTU de Caminho) é necessária para determinar a MTU adequada entre os recursos do Azure e os serviços do OCI. Para que o PMTUD funcione, os clientes devem permitir o Internet Control Message Protocol (ICMP) Tipo 3 código 4 em toda a pilha de rede. Desativar o ICMP completamente pode resultar em problemas de conectividade.

Para obter mais informações, consulte:

Limitação de Zona de DNS Privada para Serviços Exadata

Ao provisionar o Exadata Services, uma zona de DNS privada só pode selecionar zonas com quatro labels ou menos.

Por exemplo, a.b.c.d é permitido, enquanto a.b.c.d.e não é permitido.

Configuração Automática de Entrada de Rede para Exadata Services

Você poderá conectar uma VM do Microsoft Azure a um Cluster de VMs do Oracle Exadata se ambos estiverem na mesma rede virtual (VNet). A funcionalidade é automática e não requer alterações adicionais nas regras do grupo de segurança de rede (NSG). Se você precisar conectar uma VM do Microsoft Azure de um VNet diferente daquele em que o Cluster de VMs do Oracle Exadata foi criado, uma etapa adicional para configurar regras de tráfego do NSG para permitir que o tráfego da outra VNet flua corretamente.

Como exemplo, se você tiver dois (2) VNets (A e B) com VNet A atendendo à VM do Microsoft Azure e VNet B atendendo ao Cluster de VMs do Oracle Exadata, será necessário adicionar o endereço CIDR da VNet A à tabela de roteamento do NSG no OCI.

Tabela 1-2 Regras Padrão do NSG do Cliente

Direção Origem ou Destino Protocolo Detalhes Descrição:

Direção: Saída

Sem Monitoramento de Estado: Não

Tipo de Destino: CIDR

Destino: 0.0.0.0/0

Todos os Protocolos Permitir: Todo tráfego em todas as portas Regra de saída NSG padrão

Direção: Entrada

Sem Monitoramento de Estado: Não

Tipo de Origem: CIDR

Origem: CIDR VNet do Microsoft Azure

TCP

Intervalo de Portas de Origem: Tudo

Faixa de Portas de Destino: Todas

Permitir: Tráfego TCP nas portas: Todas

Entrar em todos os TCP do Microsoft Azure VNet.

Direção: Entrada

Sem Monitoramento de Estado: Não

Tipo de Origem: CIDR

Origem: CIDR AzureVNet da Microsoft

ICMP

Tipo: Tudo

Código: Todos

Permitir: Tráfego ICMP para: Tudo

Faça entrada de todos os ICMP do Microsoft Azure VNet.

Tabela 1-3 Regras de NSG de Backup Padrão

Direção Origem ou Destino Protocolo Detalhes Descrição:

Direção: Saída

Sem Monitoramento de Estado: Não

Tipo de Destino: Serviço

Destino: Armazenamento de objetos do OCI IAD

TCP

Intervalo de Portas de Origem: Tudo

Faixa de Portas de Destino: 443

Permitir: tráfego TCP nas portas: 443 HTTPS

Permite acesso ao armazenamento de objetos.

Direção: Entrada

Sem Monitoramento de Estado: Não

Tipo de Origem: CIDR

Origem: 0.0.0.0/0

ICMP

Tipo: 3

Código: 4

Permitir: Tráfego de ICMP para: 3, 4 Destino Não Acessível: Fragmentação Necessária e Não Fragmentar Foi Definido

Permite mensagens de fragmentação de Descoberta de MTU do Caminho.

Falha no Provisionamento do Cluster de VMs do Oracle Exadata com Erro de Autorização

O provisionamento de um Cluster de VMs do Oracle Exadata falha com um erro de autorização da seguinte forma: 

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.
A falha ocorre porque o usuário que está executando a ação não tem permissões do Azure para o recurso Microsoft.BareMetal/BareMetalConnections.
Solução
  1. Certifique-se de que nenhuma política do Azure designada ao usuário ou à assinatura esteja impedindo que o usuário execute a ação. Se o usuário tiver permissões específicas atribuídas a ele diretamente, adicione os seguintes recursos à lista autorizada.
    • Microsoft.BareMetal/BareMetalConnections
    • Microsoft.Network/privateDnsZones
  2. Exclua o Cluster de VMs do Exadata com falha da IU do Azure.
  3. Aguarde 30 minutos para garantir que o Cluster de VMs do Exadata seja totalmente encerrado no Azure e no OCI. Esse período de espera garante que todos os recursos dependentes também sejam excluídos.
  4. Provisione seu novo Cluster de VMs do Exadata.

Não é possível excluir a infraestrutura Exadata

O Azure tem um timeout direcionado de até uma (1) hora para a exclusão de um Cluster de VMs do Exadata. Pode acontecer que esse tempo não seja suficiente para que todos os recursos dependentes no Exadata Infrastructure sejam totalmente excluídos, em particular os recursos de rede.

O Azure pode alterar o status do Cluster de VMs do Exadata para TERMINATED, mas no OCI os recursos dependentes ainda podem estar sendo removidos. Nessa situação, se o cliente tentar excluir a Infraestrutura de VM do Exadata E a exclusão do Cluster de VMs Exa não for concluída no lado do OCI, a seguinte mensagem de erro será exibida:
Cannot delete Exadata infrastructure. All associated VM clusters must be deleted before you delete the Exadata infrastructure. (Code: 400)
A solução alternativa é aguardar até que todos os Clusters de VMs do Exadata associados ao Exadata Infrastructure tenham sido encerrados com sucesso no OCI.

O Status "Dimensionamento em Andamento" Não É Exibido para o PDB (Banco de Dados Plugável)

Os bancos de dados plugáveis (PDBs) não exibem um status "Dimensionamento em andamento" enquanto uma operação de dimensionamento está em andamento.

Em vez disso, o status do PDB passa de "Aceito" para "Atualizando". Nenhuma solução alternativa disponível.

Falha no Provisionamento do Cluster de VMs do Oracle Exadata porque o Número de IPs Disponíveis Reportados pelo OCI e Azure Não Corresponde

O Azure informa o número errado de IPs disponíveis na sub-rede, fazendo com que o provisionamento do Cluster de VMs do Oracle Exadata falhe. Isso causa o seguinte erro: 

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 o número correto de endereços IP disponíveis na sub-rede usando a console do OCI. Para obter mais informações, consulte Listando Endereços IP Privados. A solução alternativa é reconfigurar a sub-rede de acordo com os pré-requisitos.

Perdas do Relatório de Métricas no Microsoft Azure

Se qualquer exportador enviar uma métrica com mais de 20 minutos, os agentes a eliminarão e os clientes perderão esses dados.

Este tempo limite de 20 minutos é uma limitação do Microsoft Azure e se aplica a qualquer exportador. Por exemplo, aqui estão alguns cenários em que as métricas podem ser perdidas.
  • Os certificados expiraram. O exportador não pode estabelecer conexão com o agente e um backlog de builds de métricas. Depois de alternar para novos certificados, as métricas ficam obsoletas e, como têm mais de 20 minutos, o agente elimina as métricas e os clientes verão essas métricas.
  • Backlog: Quando o exportador, por qualquer motivo, desenvolve um backlog que faz com que o exportador demore mais do que o habitual para processar as métricas, a métrica será perdida se for recebida pelo agente com mais de 20 minutos de idade.
Estes não são uma lista exaustiva de exemplos, mas destinam-se a fornecer contexto à perda de relatórios de métricas.