Solucionar problemas de banco de dados do Amazon RDS Custom para Oracle

O modelo de responsabilidade compartilhada do RDS Custom fornece acesso ao nível de shell do SO e acesso pelo administrador do banco de dados. O RDS Custom executa recursos na sua conta, ao contrário do Amazon RDS, que executa recursos em uma conta do sistema. A extensão do acesso aumenta a responsabilidade. Nas seções a seguir, você vai aprender a solucionar problemas em instâncias de banco de dados do Amazon RDS Custom.

nota

Esta seção explica como solucionar problemas do RDS Custom para Oracle. Para solucionar problemas do RDS Custom para Oracle, consulte Solucionar problemas de banco de dados do Amazon RDS Custom para SQL Server.

Visualizar eventos personalizados do RDS Custom

O procedimento para visualizar eventos é o mesmo para instâncias de banco de dados do RDS Custom e do Amazon RDS. Para ter mais informações, consulte Visualizar eventos do Amazon RDS.

Para visualizar a notificação de eventos do RDS Custom utilizando a AWS CLI, execute o comando describe-events. O RDS Custom introduz vários novos eventos. As categorias dos eventos são as mesmas que as do Amazon RDS. Para visualizar a lista de eventos, consulte Categorias de eventos e mensagens de eventos do Amazon RDS.

O exemplo a seguir recupera detalhes dos eventos que ocorreram para a instância de banco de dados do RDS Custom especificada.

aws rds describe-events \
    --source-identifier my-custom-instance \
    --source-type db-instance

Assinar eventos do RDS Custom

O procedimento para assinar eventos é o mesmo para instâncias de banco de dados do RDS Custom e do Amazon RDS. Para ter mais informações, consulte Inscrever-se em notificações de eventos do Amazon RDS.

Para assinar a notificação de eventos do RDS Custom usando a CLI, execute o comando create-event-subscription. Inclua os seguintes parâmetros necessários:

• --subscription-name

• --sns-topic-arn

O exemplo a seguir cria uma assinatura para eventos de backup e recuperação para uma instância de banco de dados do RDS Custom na conta atual da AWS. As notificações são enviadas para um tópico do Amazon Simple Notification Service (Amazon SNS), especificado por --sns-topic-arn.

aws rds create-event-subscription \
    --subscription-name my-instance-events \
    --source-type db-instance \
    --event-categories '["backup","recovery"]' \
    --sns-topic-arn arn:aws:sns:us-east-1:123456789012:interesting-events

Solucionar problemas com a criação de uma versão de mecanismo personalizado para o RDS Custom for Oracle

Quando a criação da CEV falha, o RDS Custom emite RDS-EVENT-0198 com a mensagem Creation failed for custom engine version major-engine-version.cev_name e inclui detalhes sobre a falha. Por exemplo, o evento imprime arquivos ausentes.

A criação da CEV pode falhar devido aos seguintes problemas:

• O bucket do Amazon S3 que contém seus arquivos de instalação não está na mesma região da AWS que a CEV.

• Quando você solicita a criação da CEV em um Região da AWS pela primeira vez, o RDS Custom cria um bucket do S3 para armazenar recursos do RDS Custom (como artefatos de CEV, logs de AWS CloudTrail e logs de transações).

  A criação da CEV falhará se o RDS Custom não conseguir criar o bucket do S3. O autor da chamada não tem permissões do S3, conforme descrito em Etapa 5: Conceder as permissões necessárias ao usuário ou ao perfil do IAM, ou o número de buckets do S3 atingiu o limite.

• O autor da chamada não tem permissões para obter arquivos do bucket do S3 que contém os arquivos da mídia de instalação. Essas permissões estão descritas em Etapa 7: Adicionar permissões do IAM necessárias.

• Sua política do IAM tem uma condição aws:SourceIp. Certifique-se de seguir as recomendações em A AWS nega acesso à AWS com base no IP da fonte no Guia do usuário do AWS Identity and Access Management. Certifique-se também de que o autor da chamada tenha as permissões do S3 descritas em Etapa 5: Conceder as permissões necessárias ao usuário ou ao perfil do IAM.

• Os arquivos da mídia de instalação listados no manifesto da CEV não estão no bucket do S3.

• As somas de verificação SHA-256 dos arquivos de instalação são desconhecidas para o RDS Custom.

  Confirme se as somas de verificação SHA-256 dos arquivos fornecidos correspondem à soma de verificação SHA-256 no site da Oracle. Se as somas de verificação corresponderem, entre em contato com o AWS Support e forneça o nome da CEV com falha, o nome do arquivo e a soma de verificação.

• A versão do OPatch é compatível com seus arquivos de patch. Você pode receber a seguinte mensagem: OPatch is lower than minimum required version. Check that the version meets the requirements for all patches, and try again. Para aplicar um patch Oracle, você deve usar uma versão compatível do utilitário OPatch. É possível encontrar a versão necessária do utilitário Opatch no arquivo readme do patch. Baixe o utilitário OPatch mais recente do My Oracle Support e tente criar sua CEV novamente.

• Os patches especificados no manifesto da CEV estão na ordem incorreta.

É possível visualizar eventos do RDS no console do RDS (no painel de navegação, escolha Events) ou utilizando o comando AWS CLI da describe-events. A duração padrão é de 60 minutos. Se nenhum evento for retornado, especifique uma duração maior, como mostra o exemplo a seguir.

aws rds describe-events --duration 360

Atualmente, o serviço MediaImport, que importa arquivos do Amazon S3 para criar CEVs, não está integrado ao AWS CloudTrail. Portanto, se você ativar o registro de dados em log para o Amazon RDS no CloudTrail, as chamadas para o serviço MediaImport, como o evento CreateCustomDbEngineVersion não serão registradas.

Porém, é possível ver chamadas do gateway de API que acessa seu bucket do Amazon S3. Essas chamadas são provenientes do serviço MediaImport para o evento CreateCustomDbEngineVersion.

Corrigir configurações não compatíveis no RDS Custom para Oracle

Devido ao modelo de responsabilidade compartilhada, é sua responsabilidade corrigir problemas de configuração que colocam a instância de banco de dados do RDS Custom para Oracle no estado unsupported-configuration. Se o problema for com a infraestrutura da AWS, será possível utilizar o console ou a AWS CLI para corrigi-lo. Se o problema for com o sistema operacional ou a configuração do banco de dados, será possível fazer login no host para corrigi-lo.

nota

Esta seção explica como corrigir configurações não compatíveis no RDS Custom para Oracle. Para obter informações sobre o RDS Custom para SQL Server, consulte Corrigir configurações não compatíveis no RDS Custom para SQL Server.

A tabela a seguir apresenta a descrição de notificações e eventos que o perímetro de suporte envia e como corrigi-los. Essas notificações e o perímetro de suporte estão sujeitos a alterações. Para obter informações básicas sobre o perímetro de suporte, consultePerímetro de suporte do RDS Custom. Para obter informações sobre descrições de eventos, consulte Categorias de eventos e mensagens de eventos do Amazon RDS.

ID do evento	Configuração	Mensagem de evento do RDS	Ação
SP-O0000	Configuração manual incompatível	O status da instância de banco de dados do RDS Custom está definido como [Configuração incompatível] devido a: motivo.	Para resolver esse problema, crie um caso do AWS Support.
Recurso da AWS (infraestrutura)
SP-O1001	Volumes do Amazon Elastic Block Store (Amazon EBS)	Os seguintes volumes do EBS foram adicionados à instância do EC2 ec2_id: volume_id. Para resolver o problema, desanexe os volumes especificados da instância.	O RDS Custom cria dois tipos de volume do EBS, além do volume raiz criado com base na imagem de máquina da Amazon (AMI), e os associa à instância do EC2: O volume binário onde os binários do software de banco de dados estão localizados Os volumes de dados onde os arquivos do banco de dados estão localizados Ao criar a instância de banco de dados, as configurações de armazenamento que você especifica configuram os volumes de dados. O perímetro de suporte monitora o seguinte: Os volumes iniciais do EBS criados com a instância de banco de dados ainda estão associados à instância. Se os volumes iniciais do EBS ainda têm as mesmas configurações inicialmente definidas: tipo de armazenamento, tamanho, IOPS provisionadas e taxa de transferência de armazenamento. Nenhum outro volume do EBS está anexado à instância de banco de dados. Use o comando da CLI a seguir para comparar o tipo de volume dos detalhes do volume do EBS e os detalhes da instância de banco de dados do RDS Custom para Oracle: aws rds describe-db-instances \ --db-instance-identifier db-instance-name | grep StorageType
SP-O1002	Volumes do Amazon Elastic Block Store (Amazon EBS)	O volume do EBS volume_id foi desanexado da instância do EC2 [ec2_id]. Você não pode desanexar o volume original dessa instância. Para resolver o problema, anexe novamente o volume_id a ec2_id.	O RDS Custom cria dois tipos de volume do EBS, além do volume raiz criado com base na imagem de máquina da Amazon (AMI), e os associa à instância do EC2: O volume binário onde os binários do software de banco de dados estão localizados Os volumes de dados onde os arquivos do banco de dados estão localizados Ao criar a instância de banco de dados, as configurações de armazenamento que você especifica configuram os volumes de dados. O perímetro de suporte monitora o seguinte: Os volumes iniciais do EBS criados com a instância de banco de dados ainda estão associados à instância. Se os volumes iniciais do EBS ainda têm as mesmas configurações inicialmente definidas: tipo de armazenamento, tamanho, IOPS provisionadas e taxa de transferência de armazenamento. Nenhum outro volume do EBS está anexado à instância de banco de dados. Use o comando da CLI a seguir para comparar o tipo de volume dos detalhes do volume do EBS e os detalhes da instância de banco de dados do RDS Custom para Oracle: aws rds describe-db-instances \ --db-instance-identifier db-instance-name | grep StorageType
SP-O1003	Volumes do Amazon Elastic Block Store (Amazon EBS)	O volume original do EBS volume_id anexado à instância do EC2 ec2_id foi modificado da seguinte maneira: tamanho [X] para [Y], tipo [N] para [M] ou IOPS [J] para [K]. Para resolver o problema, reverta a modificação.	O RDS Custom cria dois tipos de volume do EBS, além do volume raiz criado com base na imagem de máquina da Amazon (AMI), e os associa à instância do EC2: O volume binário onde os binários do software de banco de dados estão localizados Os volumes de dados onde os arquivos do banco de dados estão localizados Ao criar a instância de banco de dados, as configurações de armazenamento que você especifica configuram os volumes de dados. O perímetro de suporte monitora o seguinte: Os volumes iniciais do EBS criados com a instância de banco de dados ainda estão associados à instância. Se os volumes iniciais do EBS ainda têm as mesmas configurações inicialmente definidas: tipo de armazenamento, tamanho, IOPS provisionadas e taxa de transferência de armazenamento. Nenhum outro volume do EBS está anexado à instância de banco de dados. Use o comando da CLI a seguir para comparar o tipo de volume dos detalhes do volume do EBS e os detalhes da instância de banco de dados do RDS Custom para Oracle: aws rds describe-db-instances \ --db-instance-identifier db-instance-name | grep StorageType
SP-O1004	Status da instância do Amazon EC2	A recuperação automatizada deixou a instância do EC2 [ec2_id] em um estado comprometido. Para resolver o problema, consulte SSolucionar problemas de falhas de recuperação da instância.	Para conferir o status de uma instância de banco de dados, use o console ou execute o seguinte comando AWS CLI: aws rds describe-db-instances \ --db-instance-identifier db-instance-name |grep DBInstanceStatus
SP-O1005	Atributos da instância do Amazon EC2	A instância do EC2 [ec2_id] foi modificada da seguinte maneira: o atributo [att1] mudou de [val-old] para [val-new], o atributo [att2] mudou de [val-old] para [val-new]. Para resolver o problema, reverta para o valor original.
SP-O1006	Status da instância do Amazon EC2	A instância do EC2 [ec2_id] foi encerrada ou não pode ser encontrada. Para resolver o problema, exclua instância de banco de dados do RDS Custom.	O perímetro de suporte monitora notificações de alteração de estado da instância do EC2. A instância do EC2 deve estar sempre em execução. Para excluir a instância de banco de dados Para conferir o status de uma instância de banco de dados, use o console ou execute o seguinte comando AWS CLI: aws rds describe-db-instances \ --db-instance-identifier db-instance-name |grep DBInstanceStatus Exclua a instância de banco de dados do RDS Custom para Oracle.
SP-O1007	Status da instância do Amazon EC2	A instância do EC2 [ec2_id] foi interrompida. Para resolver o problema, inicie a instância.	O perímetro de suporte monitora notificações de alteração de estado da instância do EC2. A instância do EC2 deve estar sempre em execução. Para reiniciar a instância de banco de dados Para conferir o status de uma instância de banco de dados, use o console ou execute o seguinte comando AWS CLI: aws rds describe-db-instances \ --db-instance-identifier db-instance-name |grep DBInstanceStatus Inicie a instância de banco de dados. Remonte os volumes binários e de dados.
Sistema operacional
SP-O2001	Status do agente do RDS Custom	O agente do RDS Custom não está sendo executado na instância do EC2 [ec2_id]. Verifique se o agente está sendo executado em [ec2_id].	No RDS Custom for Oracle, a instância de banco de dados sairá do perímetro de suporte se o agente do RDS Custom parar. O agente publica a métrica IamAlive para o Amazon CloudWatch a cada 30 segundos. Um alarme será acionado se a métrica não for publicada por 30 segundos. O perímetro de suporte também monitora o estado do processo do agente do RDS Custom no host a cada 30 minutos. Para reiniciar o agente do RDS Custom Faça login no host e verifique se o agente do RDS Custom esteja em execução. Execute o comando a seguir para encontrar o status do agente. service rdscustomagent status Use o comando a seguir para iniciar o agente. service rdscustomagent start Quando o agente do RDS Custom estiver sendo executado novamente, a métrica IamAlive será publicada no Amazon CloudWatch, e o alarme mudará para o estado OK. Essa opção notifica o perímetro de suporte em que o agente está em execução.
SP-O2002	Status do agente do AWS Systems Manager (agente do SSM)	O agente do Systems Manager na instância do EC2 [ec2_id] está inacessível. Verifique se você configurou corretamente as permissões da rede, do agente e do IAM.	O SSM Agent sempre deve estar em execução. O agente do RDS Custom é responsável por garantir que o agente do Systems Manager esteja em execução. Se o SSM Agent foi encerrado e, depois, reiniciado, o agente do RDS Custom publica uma métrica no CloudWatch. O agente do RDS Custom tem um alarme na métrica definido para acionamento quando tiver ocorrido uma reinicialização em cada um dos três minutos anteriores. O perímetro de suporte também monitora o estado do processo do SSM Agent no host a cada 30 minutos. Para ter mais informações, consulte Solucionar problemas com o SSM Agent.
SP-O2003	Status do agente do AWS Systems Manager (agente do SSM)	O agente do Systems Manager na instância do EC2 [ec2_id] travou várias vezes. Para ter mais informações, consulte a documentação de solução de problemas do SSM Agent.	Para ter mais informações, consulte Solucionar problemas com o SSM Agent.
SP-O2004	Fuso horário do SO	O fuso horário na instância do EC2 [ec2_id] foi alterado. Para resolver esse problema, reverta o fuso horário para a configuração anterior de [previous-time-zone]. Depois, use um grupo de opções do RDS para alterar o fuso horário.	A automação do RDS detectou que o fuso horário no host foi alterado sem o uso de um grupo de opções. Essa alteração em nível de host pode causar falhas na automação do RDS, portanto, a instância do EC2 é colocada no estado unsupported-configuration. Para corrigir a configuração do fuso horário Faça login no host do EC2 e verifique o fuso horário do sistema operacional da seguinte forma: timedatectl Pause a automação do RDS Custom. Para ter mais informações, consulte Pausar e retomar sua instância de banco de dados do RDS Custom. Interrompa a instância de banco de dados. Reverta a alteração de fuso horário no sistema operacional. Inicie a instância de banco de dados. Retome a automação do RDS Custom. A instância de banco de dados fica disponível em 30 minutos. Para não sair do perímetro no futuro, modifique o fuso horário por meio de um grupo de opções. Para ter mais informações, consulte Fuso horário da Oracle.
SP-O2005	Configurações de sudo	As configurações de sudo na instância do EC2 [ec2_id] não têm as permissões necessárias. Para resolver esse problema, reverta as alterações recentes nas configurações de sudo.	O perímetro de suporte monitora que certos usuários do sistema operacional têm permissão para executar determinados comandos por padrão. Ele monitora configurações de sudo em relação ao estado com suporte. Quando as configurações de sudo não têm suporte, o RDS Custom tenta substituí-las de volta ao estado anterior com suporte. Se isso for feito com sucesso, a seguinte notificação será enviada: O RDS Custom substituiu sua configuração com sucesso. Para investigar as alterações nas configurações de sudo Faça login no host. Execute o seguinte comando . visudo -c -f /etc/sudoers.d/individual_sudo_files Modifique as configurações de sudo conforme necessário. Depois que o perímetro de suporte determina que as configurações de sudo têm suporte, a instância de banco de dados do RDS Custom para Oracle fica disponível em até 30 minutos.
SP-O2006	Acessibilidade do bucket do S3	A automação personalizada do RDS não pode baixar arquivos do bucket do S3 na instância do EC2 [ec2_id]. Verifique a configuração de rede e certifique-se de que a instância permita conexões de e para o S3.
Database
SP-O3001	Destino de atraso de arquivo do banco de dados	O parâmetro ARCHIVE_LAG_TARGET na instância do EC2 [ec2_id] está fora do intervalo recomendado value_range. Para resolver o problema, defina o parâmetro como um valor dentro de value_range.	O perímetro de suporte monitora o parâmetro de banco de dados ARCHIVE_LAG_TARGET para verificar se a hora da última restauração da instância de banco de dados está dentro de limites razoáveis. Para alterar a meta de atraso para logs redo arquivados Faça login no host do EC2. Conectar-se à instância de banco de dados do RDS Custom para Oracle Altere o parâmetro ARCHIVE_LAG_TARGET para um valor de 60 a 7.200. Por exemplo, use a instrução SQL a seguir. ALTER SYSTEM SET ARCHIVE_LAG_TARGET=300 SCOPE=BOTH; A instância de banco de dados fica disponível em 30 minutos.
SP-O3002	Função do Oracle Data Guard	O perfil de banco de dados [role_name] não é compatível com o Oracle Data Guard na instância do EC2 [ec2_id]. Para resolver o problema, defina o parâmetro DATABASE_ROLE como PRIMARY ou PHYSICAL STANDBY.	O perímetro de suporte monitora a função de banco de dados atual a cada 15 segundos e envia uma notificação do CloudWatch quando ela tiver sido alterada. O parâmetro DATABASE_ROLE do Oracle Data Guard deve ser PRIMARY ou PHYSICAL STANDBY. Para restaurar o perfil de banco de dados do Oracle Data Guard para um valor compatível Verifique o perfil do Oracle Data Guard executando a seguinte instrução: SELECT DATABASE_ROLE FROM V$DATABASE; Se a instância de banco de dados for autônoma, use qualquer uma das instruções a seguir para alterá-la de volta para o perfil PRIMARY: ALTER DATABASE COMMIT TO SWITCHOVER PRIMARY; ALTER DATABASE ACTIVATE STANDBY DATABASE; Se a instância de banco de dados for uma réplica, use a seguinte instrução para alterá-la de volta para o perfil PHYSICAL STANDBY: ALTER DATABASE CONVERT TO PHYSICAL STANDBY; Depois que o perímetro de suporte determinar que a função de banco de dados é compatível, a instância de banco de dados do RDS Custom para Oracle ficará disponível em 15 segundos.
SP-O3003	Integridade do banco de dados	O processo SMON do banco de dados Oracle está em um estado zumbi. Para resolver o problema, recupere manualmente o banco de dados na instância do EC2 [ec2_id], abra o banco de dados e faça backup imediatamente. Se precisar de mais ajuda, entre em contato com o AWS Support.	O perímetro de suporte monitora o estado da instância de banco de dados. Ele também monitora quantas reinicializações ocorreram durante a hora anterior e ao longo do dia. Você é notificado quando a instância está em um estado em que ela ainda existe, mas não é possível interagir com ela. Para fazer com que o perímetro de suporte avalie o estado da instância Faça login no host e determine o estado do banco de dados. ps -eo pid,state,command | grep smon Se necessário, reinicie a instância de banco de dados. Se a reinicialização falhar, passe para a próxima etapa. Se necessário, reinicie o host do EC2. Após a reinicialização da instância de banco de dados, o agente do RDS Custom detecta que a instância de banco de dados não está mais em um estado sem resposta. Em seguida, ele notifica o perímetro de suporte para reavaliar o estado dessa instância.
SP-O3004	Modo de log de banco de dados	O modo de log de banco de dados na instância do EC2 [ec2_id] foi alterado para [value_b]. Para resolver o problema, defina o modo de log como [value_a].	Para alterar o modo de log da instância de banco de dados para ARCHIVELOG Faça login no host do EC2. Conecte-se ao banco de dados e execute a seguinte instrução: SELECT LOG_MODE FROM V$DATABASE; Ou é possível executar o seguinte comando no SQL*Plus: ARCHIVE LOG LIST Execute o comando do SQL*Plus a seguir para iniciar um desligamento consistente. SHUTDOWN IMMEDIATE O agente do RDS Custom reinicia automaticamente a instância de banco de dados e define o modo de log como ARCHIVELOG. A instância de banco de dados fica disponível em 30 minutos.
SP-O3005	Caminho inicial do Oracle	O início do Oracle na instância do EC2 [ec2_id] foi alterado para new_path. Para resolver o problema, reverta a configuração para old_path.
SP-O3006	Nome exclusivo do banco de dados	O nome exclusivo do banco de dados na instância do EC2 [ec2_id] foi alterado para new_value. Para resolver o problema, reverta o nome para old_value.	Para alterar o nome exclusivo do banco de dados da instância de banco de dados Faça login no host do EC2. Conecte-se ao banco de dados e execute a seguinte instrução: SELECT DB_UNIQUE_NAME FROM V$DATABASE; Especifique o nome exclusivo do banco de dados original usando o comando ALTER SYSTEM SET DB_UNIQUE_NAME. Execute a instrução SQL a seguir para iniciar um desligamento consistente. SHUTDOWN IMMEDIATE; O agente do RDS Custom reinicia automaticamente a instância de banco de dados e define o modo de log como ARCHIVELOG. A instância de banco de dados fica disponível em 30 minutos.

Solucionar problemas de upgrade do RDS Custom para Oracle

O upgrade de uma instância do RDS Custom para Oracle pode falhar. Veja a seguir técnicas que podem ser utilizadas durante upgrades de instâncias de banco de dados do RDS Custom para Oracle:

• Examine os arquivos de log de saída de atualização no diretório /tmp na instância de banco de dados. Os nomes dos logs dependem da versão do mecanismo de banco de dados. Por exemplo, você pode ver logs que contêm as strings catupgrd ou catup.

• Examine o arquivo alert.log localizado no diretório /rdsdbdata/log/trace.

• Execute o seguinte comando da grep no diretório root para acompanhar o processo de upgrade do SO. Esse comando mostra onde os arquivos de log estão sendo gravados e determina o estado do processo de upgrade.

  ps -aux | grep upg

  Veja a seguir um exemplo de saída.

  root     18884  0.0  0.0 235428  8172 ?        S<   17:03   0:00 /usr/bin/sudo -u rdsdb /rdsdbbin/scripts/oracle-control ORCL op_apply_upgrade_sh RDS-UPGRADE/2.upgrade.sh
  rdsdb    18886  0.0  0.0 153968 12164 ?        S<   17:03   0:00 /usr/bin/perl -T -w /rdsdbbin/scripts/oracle-control ORCL op_apply_upgrade_sh RDS-UPGRADE/2.upgrade.sh
  rdsdb    18887  0.0  0.0 113196  3032 ?        S<   17:03   0:00 /bin/sh /rdsdbbin/oracle/rdbms/admin/RDS-UPGRADE/2.upgrade.sh
  rdsdb    18900  0.0  0.0 113196  1812 ?        S<   17:03   0:00 /bin/sh /rdsdbbin/oracle/rdbms/admin/RDS-UPGRADE/2.upgrade.sh
  rdsdb    18901  0.1  0.0 167652 20620 ?        S<   17:03   0:07 /rdsdbbin/oracle/perl/bin/perl catctl.pl -n 4 -d /rdsdbbin/oracle/rdbms/admin -l /tmp catupgrd.sql
  root     29944  0.0  0.0 112724  2316 pts/0    S+   18:43   0:00 grep --color=auto upg

• Execute a seguinte consulta SQL para verificar o estado atual dos componentes e localizar a versão do banco de dados e as opções instaladas na instância de banco de dados.

  SET LINESIZE 180
  COLUMN COMP_ID FORMAT A15
  COLUMN COMP_NAME FORMAT A40 TRUNC
  COLUMN STATUS FORMAT A15 TRUNC
  SELECT COMP_ID, COMP_NAME, VERSION, STATUS FROM DBA_REGISTRY ORDER BY 1;

  A saída será semelhante à seguinte.

  COMP_NAME                                STATUS               PROCEDURE
  ---------------------------------------- -------------------- --------------------------------------------------
  Oracle Database Catalog Views            VALID                DBMS_REGISTRY_SYS.VALIDATE_CATALOG
  Oracle Database Packages and Types       VALID                DBMS_REGISTRY_SYS.VALIDATE_CATPROC
  Oracle Text                              VALID                VALIDATE_CONTEXT
  Oracle XML Database                      VALID                DBMS_REGXDB.VALIDATEXDB
  
  4 rows selected.

• Execute a seguinte consulta SQL para verificar se há objetos inválidos que possam interferir no processo de upgrade.

  SET PAGES 1000 LINES 2000
  COL OBJECT FOR A40
  SELECT SUBSTR(OWNER,1,12) OWNER,
         SUBSTR(OBJECT_NAME,1,30) OBJECT,
         SUBSTR(OBJECT_TYPE,1,30) TYPE, STATUS,
         CREATED
  FROM   DBA_OBJECTS 
  WHERE  STATUS <>'VALID' 
  AND    OWNER IN ('SYS','SYSTEM','RDSADMIN','XDB');

Solucionar problemas de promoção de réplicas no RDS Custom para Oracle

Você pode promover réplicas gerenciadas do Oracle no RDS Custom para Oracle usando o console, o comando promote-read-replica do AWS CLI ou a API do PromoteReadReplica. Se você excluir sua instância de banco de dados primária e todas as réplicas estiverem íntegras, o RDS Custom para Oracle promoverá automaticamente suas réplicas gerenciadas a instâncias autônomas. Se uma réplica tiver pausado a automação ou estiver fora do perímetro de suporte, corrija a réplica para que o RDS Custom possa promovê-la automaticamente. Para ter mais informações, consulte Limitações da promoção de réplicas para RDS Custom para Oracle.

O fluxo de trabalho de promoção de réplicas pode ficar travado na seguinte situação:

• A instância de banco de dados primária está no estado STORAGE_FULL.

• O banco de dados primário não pode arquivar todos os logs de redo online.

• Existe uma lacuna entre os arquivos de log de redo arquivados na réplica do Oracle e no banco de dados primário.

Para responder ao fluxo de trabalho travado, conclua as etapas a seguir:

1. Sincronize a lacuna de logs de redo na réplica da instância de banco de dados Oracle.

2. Force a promoção de sua réplica de leitura para o log de redo mais recente aplicado. Execute os seguintes comandos no SQL*Plus:

   ALTER DATABASE ACTIVATE STANDBY DATABASE;
   SHUTDOWN IMMEDIATE
   STARTUP

3. Entre em contato com o AWS Support e solicite que a instância de banco de dados passe para o status disponível.