Solucionar problemas de banco de dados do Amazon RDS Custom - Amazon Relational Database Service

Solucionar problemas de banco de dados do Amazon RDS Custom

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.

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 obter 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

Assinatura de notificações de eventos do

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

Para assinar a notificação de eventos do RDS Custom utilizando 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 Conceder as permissões necessárias ao seu usuário 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 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 Conceder as permissões necessárias ao seu usuário 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.

Perímetro de suporte personalizado do RDS e configurações sem suporte

O RDS Custom fornece um recurso de monitoramento chamado de perímetro de suporte. O perímetro de suporte garante que a sua instância do RDS Custom utilize uma infraestrutura da AWS, um sistema operacional e um banco de dados com suporte.

O perímetro de suporte verifica se os requisitos listados em Corrigir configurações sem suporte foram atendidos. Se algum desses requisitos não for atendido, o RDS Custom considerará que a instância de banco de dados está fora do perímetro de suporte. O RDS Custom modificará o status da instância de banco de dados para unsupported-configuration e enviará notificações de eventos. Depois de corrigir os problemas de configuração, o RDS Custom modificará o status da instância de banco de dados para available.

O que acontece no estado unsupported-configuration

Enquanto a instância de banco de dados está no estado unsupported-configuration:

  • Não é possível modificá-la.

  • Não é possível obter snapshots de banco de dados.

  • Backups automatizados não são criados.

  • A automação do RDS Custom não substituirá a instância subjacente do Amazon EC2 se ela ficar prejudicada.

No entanto, a seguinte automação do RDS Custom continuará a ser executada:

  • O agente do RDS Custom monitora a instância de banco de dados e envia notificações ao perímetro de suporte sobre novas alterações.

  • O perímetro de suporte continua sendo executado e captura eventos de alteração referentes à instância de banco de dados. Esse processo tem dois objetivos:

    • Quando você corrige a configuração que fez com que a instância de banco de dados estivesse no estado unsupported-configuration, o perímetro de suporte pode retornar a instância de banco de dados ao estado available.

    • Se você fizer outras configurações sem suporte, o perímetro de suporte notificará sobre elas, para que você possa corrigi-las.

  • Os logs de redo ainda são arquivados e carregados no Amazon S3 para facilitar a recuperação em um ponto anterior no tempo (PITR). No entanto, observe o seguinte:

    • A PITR pode demorar muito tempo para restaurar completamente para uma nova instância de banco de dados. Isso acontece porque você não pode obter snapshots automatizados ou manuais enquanto a instância de banco de dados está no estado unsupported-configuration.

      A PITR precisa reproduzir mais logs de redo a partir do snapshot mais recente obtido antes da entrada da instância no estado unsupported-configuration.

    • Em alguns casos, a instância de banco de dados está no estado unsupported-configuration devido a alterações feitas que afetaram a funcionalidade de upload de logs de redo. Nesses casos, a PITR não pode restaurar a instância de banco de dados para a hora da última restauração possível.

Corrigir configurações sem suporte

É sua responsabilidade corrigir problemas de configuração que colocam sua instância de banco de dados do RDS Custom 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.

A tabela a seguir mostra descrições das notificações enviadas pelo perímetro de suporte e como corrigi-las. Essas notificações e o perímetro de suporte estão sujeitos a alterações.

Notificação Descrição Ação

Integridade do banco de dados:

  • É necessário recuperar manualmente o banco de dados na instância do EC2 [i-xxxxxxxxxxxxxxxxx].

  • A instância de banco de dados foi reiniciada.

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.

Faça login no host e verifique o estado do banco de dados.

ps -eo pid,state,command | grep smon

Reinicie a instância de banco de dados, se necessário, para executá-la novamente. Às vezes, é necessário reinicializar o host.

Após a reinicialização, 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.

Destino de atraso de arquivo do banco de dados (somente no RDS Custom for Oracle):

  • O parâmetro de banco de dados monitorado Archive Lag Target na instância do Amazon EC2 [i-xxxxxxxxxxxxxxxxx] mudou de [300] para [0].

  • A instância do RDS Custom está utilizando uma configuração sem suporte devido aos seguintes problemas [1]: (1) O parâmetro do banco de dados de destino de atraso de arquivo na instância do Amazon EC2 [i-xxxxxxxxxxxxxxxxx] está fora do intervalo desejado {"lowerbound":60,"upperbound":7200}.

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 possível da instância de banco de dados está dentro de limites razoáveis.

Faça login no host, conecte-se à instância de banco de dados e altere o parâmetro ARCHIVE_LAG_TARGET para um valor de 60 a 7200.

Por exemplo, utilize o comando SQL a seguir.

alter system set archive_lag_target=300 scope=both;

A instância de banco de dados ficará disponível dentro de 30 minutos.

Modo de log de banco de dados (somente no RDS Custom for Oracle):

O modo de log monitorado do banco de dados na instância do Amazon EC2 [i-xxxxxxxxxxxxxxxxx] mudou de [ARCHIVELOG] para [NOARCHIVELOG].

O modo de log da instância de banco de dados deve ser definido como ARCHIVELOG.

Faça login no host e encerre a instância de banco de dados. É possível usar o seguinte comando SQL.

shutdown immediate;

O agente do RDS Custom reinicia a instância de banco de dados e define o modo de log como ARCHIVELOG.

A instância de banco de dados ficará disponível dentro de 30 minutos.

Status do agente do RDS Custom (RDS Custom for Oracle):

O estado monitorado do agente do RDS Custom na instância do EC2 [i-xxxxxxxxxxxxxxxxx] mudou de RUNNING para STOPPED.

O agente do RDS Custom sempre deve estar em execução. 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.

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.

Faça login no host e certifique-se de que o agente do RDS Custom esteja em execução.

É possível utilizar os seguintes comandos para localizar o status do agente.

ps -ef | grep RDSCustomAgent
pgrep java

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.

Status do agente do RDS Custom (RDS Custom for SQL Server):

A instância do RDS Custom está saindo do perímetro porque uma configuração sem suporte foi utilizada para o agente do RDS Custom.

O agente do RDS Custom sempre deve estar em execução.

O perímetro de suporte monitora o estado do processo do agente do RDS Custom no host a cada 1 minuto.

No RDS Custom for SQL Server, um agente interrompido é recuperado pelo serviço de monitoramento. A instância de banco de dados sairá do perímetro de suporte se o agente do RDS Custom estiver desinstalado.

Faça login no host e certifique-se de que o agente do RDS Custom esteja em execução.

É possível utilizar os seguintes comandos para localizar o status do agente.

$name = "RDSCustomAgent" $service = Get-Service $name Write-Host $service.Status

Se o status não for Running, é possível iniciar o serviço com o seguinte comando:

Start-Service $name

Status do agente AWS Systems Manager (SSM Agent) (RDS Custom for Oracle):

O agente AWS Systems Manager na instância do EC2 [i-xxxxxxxxxxxxxxxxx] está inacessível. Verifique se você configurou corretamente as permissões da rede, do agente e do IAM.

O agente SSM 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 estiver inativo e for reiniciado, o agente do RDS Custom publicará 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 obter mais informações, consulte Solucionar problemas com o SSM Agent.

Quando o SSM Agent estiver sendo executado novamente, o alarme mudará para o estado OK. Essa opção notifica o perímetro de suporte em que o agente está em execução.

Status do SSM Agent (RDS Custom for SQL Server):

A instância do RDS Custom está saindo do perímetro porque uma configuração sem suporte foi utilizada para o SSM Agent.

O agente SSM 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.

O perímetro de suporte monitora o estado do processo do SSM Agent no host a cada 1 minuto.

Para obter mais informações, consulte Solucionar problemas com o SSM Agent.

Configurações de sudo (somente no RDS Custom for Oracle):

As configurações de sudo na instância do EC2 [i-xxxxxxxxxxxxxxxxx] mudaram.

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.

Se a substituição não for bem-sucedida, será possível fazer login no host e investigar por que não há suporte para as alterações recentes nas configurações de sudo.

É possível usar o seguinte comando.

visudo -c -f /etc/sudoers.d/individual_sudo_files

Depois que o perímetro de suporte determina que as configurações de sudo têm suporte, a instância de banco de dados ficará disponível dentro de 30 minutos.

Volumes do Amazon Elastic Block Store (Amazon EBS):

RDS Custom for Oracle:

  • Os seguintes volumes do Amazon EBS estão anexados à instância do Amazon EC2 i-xxxxxxxxxxxxxxxxx]: [[vol-01234abcd56789ef0, vol-0def6789abcd01234]].

  • Os volumes originais do Amazon EBS anexados à instância do Amazon EC2 i-xxxxxxxxxxxxxxxxx] foram desanexados ou modificados. Não é possível anexar ou modificar os volumes iniciais do EBS anexados a uma instância RDS Custom.

RDS Custom for SQL Server:

  • A instância do RDS Custom está saindo do perímetro porque uma configuração sem suporte foi utilizada para metadados do volume do EBS.

O RDS Custom cria dois tipos de volume do EBS, além do volume raiz criado a partir da 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 são onde os arquivos do banco de dados estão localizados. As configurações de armazenamento que você definiu ao criar a instância de banco de dados são utilizadas para configurar os volumes de dados.

O perímetro de suporte monitora o seguinte:

  • Se os volumes iniciais do EBS criados com a instância de banco de dados ainda estão associados.

  • 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.

  • (RDS Custom for Oracle somente) Se nenhum volume adicional do EBS está vinculado à instância de banco de dados.

Se você desanexou quaisquer volumes iniciais do EBS, entre em contato com o AWS Support.

Se você tiver modificado o tipo de armazenamento, as IOPS provisionadas ou a taxa de transferência de armazenamento de um volume do EBS, reverta a modificação para o valor original.

Se você modificou o tamanho do armazenamento de um volume do EBS, entre em contato com o AWS Support.

(Somente no RDS Custom for Oracle) Se você tiver vinculado qualquer volume adicional do EBS, siga um destes procedimentos:

  • Desvincule os volumes adicionais do EBS da instância de banco de dados do RDS Custom.

  • Entre em contato com o AWS Support.

Instâncias otimizadas para EBS (somente no RDS Custom for Oracle):

O atributo otimizado para o EBS da instância do Amazon EC2 [i-xxxxxxxxxxxxxxxxx] mudou de [habilitado] para [desabilitado].

As instâncias do Amazon EC2 devem ser otimizadas para o EBS.

Se o atributo EBS-optimized estiver desativado (disabled), o perímetro de suporte não colocará a instância de banco de dados no estado unsupported-configuration.

Para ativar o atributo EBS-optimized:

  1. Pare a instância do EC2.

  2. Defina o atributo EBS-optimized como enabled.

  3. Inicie a instância do EC2.

  4. Remonte os volumes binários e de dados.

Status da instância do Amazon EC2:

  • O estado da instância do EC2 [i-xxxxxxxxxxxxxxxxx] mudou de [RUNNING] para [STOPPING].

  • A instância do Amazon EC2 [i-xxxxxxxxxxxxxxxxx] foi encerrada e não pode ser localizada. Exclua a instância do banco de dados para limpar recursos.

  • A instância do Amazon EC2 [i-xxxxxxxxxxxxxxxxx] foi interrompida. Inicie a instância e restaure a configuração do host. Para obter mais informações, consulte a documentação de solução de problemas.

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.

Se a instância do EC2 for interrompida, inicie-a e remonte os volumes binários e de dados.

No RDS Custom for Oracle, se a instância do EC2 for encerrada, exclua a instância de banco de dados do RDS Custom.

No RDS Custom for SQL Server, se a instância do EC2 for encerrada, o RDS Custom fará uma recuperação automatizada para provisionar uma nova instância do EC2.

Atributos da instância do Amazon EC2:

RDS Custom for Oracle:

  • Os atributos da instância do Amazon EC2 [i-xxxxxxxxxxxxxxxxx] mudaram.

RDS Custom for SQL Server:

  • A instância do RDS Custom está saindo do perímetro porque uma configuração sem suporte foi utilizada para os metadados da instância do EC2.

O perímetro de suporte monitora o tipo de instância da instância do EC2 em que a instância de banco de dados do RDS Custom está sendo executada. O tipo de instância do EC2 deve permanecer o mesmo de quando você o configura durante a criação da instância de banco de dados do RDS Custom.

Retorne o tipo de instância do EC2 de volta para o original utilizando o console do EC2 ou a CLI.

Para alterar o tipo de instância devido aos requisitos de escalabilidade, faça uma PITR e especifique o novo tipo e a classe de instância. No entanto, isso resulta em uma nova instância de banco de dados do RDS Custom com um novo host e nome de Sistema de Nomes de Domínio (DNS).

Função do Oracle Data Guard (somente no RDS Custom for Oracle):

  • A função da instância para a instância de banco de dadosmy-custom-instance foi alterada.

  • A função de banco de dados [LOGICAL STANDBY] não tem suporte. Valide a configuração do Oracle Data Guard para o banco de dados na instância do Amazon EC2 [i-xxxxxxxxxxxxxxxxx].

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.

Restaure a função de banco de dados do Oracle Data Guard para um valor com suporte.

Depois que o perímetro de suporte determinar que há suporte para a função de banco de dados, a instância de banco de dados do RDS Custom for Oracle ficará disponível dentro de 15 segundos.

Conexões de memória compartilhada (somente no RDS Custom for SQL Server):

A instância do RDS Custom está saindo do perímetro porque uma configuração sem suporte foi utilizada para o protocolo de memória compartilhada.

O agente do RDS Custom no host do EC2 se conecta ao SQL Server utilizando o protocolo de memória compartilhada.

Se esse protocolo estiver desativado (Enabled definido como No), o RDS Custom não poderá executar suas ações de gerenciamento e colocará a instância de banco de dados fora do perímetro de suporte.

Para retornar a instância de banco de dados do RDS Custom for SQL Server ao perímetro de suporte, ative o protocolo de memória compartilhada na página Protocol (Protocolo) da janela Shared Memory Properties (Propriedades da memória compartilhada), definindo Enabled como Yes.

Reinicie o SQL Server depois de habilitar o protocolo.

Locais de arquivos de banco de dados (somente no RDS Custom for SQL Server):

A instância do RDS Custom está saindo do perímetro porque uma configuração sem suporte foi utilizada para a localização de arquivos de banco de dados.

Todos os arquivos de banco de dados do SQL Server são armazenados na unidade D: por padrão, no diretório D:\rdsdbdata\DATA.

Se você criar ou alterar o arquivo de banco de dados para estar em qualquer lugar que não seja a unidade D:, o RDS Custom colocará a instância de banco de dados fora do perímetro de suporte.

É altamente recomendável não salvar arquivos de banco de dados na unidade C:. Você poderá perder dados na unidade C: durante determinadas operações, como falhas de hardware. O armazenamento na unidade C: não oferece a mesma durabilidade da unidade D:, que é um volume do EBS.

Além disso, se arquivos de banco de dados não forem encontrados, o RDS Custom colocará a instância de banco de dados fora do perímetro de suporte.

Armazene todos os arquivos de banco de dados do RDS Custom for SQL Server na unidade D:.

Como o Amazon RDS Custom substitui um host afetado

Se o host do Amazon EC2 for afetado, o RDS Custom tentará reinicializá-lo. Se esse esforço falhar, o RDS Custom utilizará o mesmo recurso de parada e início incluído no Amazon EC2.

Interromper e iniciar o host

O RDS Custom executa automaticamente as seguintes etapas, sem a necessidade de intervenção do usuário:

  1. Interrompe o host do Amazon EC2.

    A instância do EC2 realiza um desligamento normal e encerra a execução. Todos os volumes do Amazon EBS permanecem associados à instância, e seus dados persistem. Todos os dados armazenados nos volumes do armazenamento de instâncias (sem suporte no RDS Custom) ou na RAM do computador host desaparecem.

    Para obter mais informações, consulte Interromper e iniciar a instância, no Guia do usuário do Amazon EC2 para instâncias Linux.

  2. Inicia o host do Amazon EC2.

    A instância do EC2 é migrada para um novo hardware de host subjacente. Em alguns casos, a instância de banco de dados do RDS Custom permanece no host original.

Efeitos da substituição do host

No RDS Custom, você tem controle total sobre o volume do dispositivo raiz e os volumes de armazenamento do Amazon EBS. O volume raiz pode conter dados e configurações importantes que você não quer perder.

O RDS Custom for Oracle retém todos os dados do banco de dados e do cliente após a operação, incluindo os dados de volume raiz. Nenhuma intervenção do usuário é necessária. No RDS Custom for SQL Server, os dados do banco de dados são retidos, mas todos os dados na unidade C:, incluindo dados do sistema operacional e do cliente, são perdidos.

Após o processo de substituição, o host do Amazon EC2 tem um novo endereço IP público. O host retém o seguinte:

  • ID da instância

  • Endereços IP privados

  • Endereços IP elásticos

  • Metadados da instância

  • Dados de volumes de armazenamento de dados

  • Dados do volume raiz (no RDS Custom for Oracle)

Práticas recomendadas para o Amazon EC2

O recurso de substituição de host do Amazon EC2 abrange a maioria dos cenários de comprometimento do Amazon EC2. Convém seguir estas práticas recomendadas:

  • Antes de alterar a configuração ou o sistema operacional, faça backup dos seus dados. Se o volume raiz ou o sistema operacional ficar corrompido, a substituição do host não conseguirá repará-lo. Suas únicas opções são restaurar de um snapshot do banco de dados ou recuperação em um ponto anterior no tempo.

  • Não pare ou encerre manualmente o host físico do Amazon EC2. Ambas as ações fazem com que a instância seja colocada fora do perímetro de suporte do RDS Custom.

  • (RDS Custom para SQL Server) Se você anexar volumes adicionais ao host do Amazon EC2, configure-os para remontagem após a reinicialização. Se o host estiver afetado, o RDS Custom poderá pará-lo e iniciá-lo automaticamente.

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 seguintes arquivos de log:

    • Todos os arquivos de log de saída de upgrade residem no diretório /tmp na instância de banco de dados.

    • Esses arquivos de log se chamam catupg*.log.

    • Um arquivo de saída primário /tmp/catupgrd0.log relata todos os erros e as etapas executadas.

    • O arquivo alert.log da instância de banco de dados está localizado no diretório /rdsdbdata/log/trace. Examine esse arquivo regularmente como prática recomendada.

  • 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

    A saída será semelhante à seguinte.

    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 mais informações, consulte Requisitos e limitações da promoção de réplicas.

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.