O blog da AWS

Guia para o upgrade do Amazon RDS para Oracle de 11.2.0.4 para 19c

Por Jorge Rua, Gerente de Arquitetura de Soluções na AWS
Thiago Morais, Gerente de Arquitetura de Soluções na AWS

 

O Amazon Relational Database Service (Amazon RDS) para Oracle fornece versões mais recentes de bancos de dados para que você possa manter suas instâncias de banco de dados atualizadas. Essas versões podem incluir correções de bugs, melhorias de segurança e novas funcionalidades. Quando o Amazon RDS for Oracle oferece suporte a uma nova versão, você pode escolher como e quando atualizar suas instâncias de banco de dados. Como você já deve saber, o Amazon RDS para Oracle oferece suporte a dois tipos de upgrades: versão principal e versão secundária. Em geral, uma atualização da versão principal pode introduzir alterações que não são compatíveis com aplicações existentes. Por outro lado, uma atualização de versão secundária no Oracle geralmente inclui apenas alterações que são compatíveis com aplicações existentes. Em outras palavras, um upgrade de versão secundária aplica uma PSU (Oracle Database Patch Set Update) ou RU (Release Update) a uma versão principal. Por exemplo, a atualização de 11.2.0.4 para 19c (19.0.0.0) é uma atualização de versão principal, enquanto passar de 12.2.0.1.ru-2019-04.rur-2019-04.r1 para 12.2.0.1.ru-2019-07.rur-2019-07.r1 é considerada uma atualização de versão secundária.

Embora o Amazon RDS para Oracle permita a opção de automatizar a aplicação de patches, como patches de versão secundária na forma de atualização automática, a maioria das atualizações de patches — incluindo as atualizações de versão principais — são de responsabilidade do administrador de banco de dados. Portanto, é fundamental estar ciente de problemas comuns, etapas envolvidas, e práticas recomendadas para atualizar com o menor impacto em seus negócios.

Nesta postagem, analisamos a linha do tempo do Fim do Suporte (EOS) da versão 11.2.0.4 no Amazon RDS para Oracle, avaliando as opções de atualização de versão disponíveis para você e aprofundamos nas boas práticas recomendadas a serem seguidas durante o processo de atualização.

Esta publicação é relevante para administradores de banco de dados que executam suas instâncias do Amazon RDS para Oracle. A maioria das etapas pré e pós-upgrade descritos nessa publicação são diretrizes gerais da documentação de suporte e upgrade da Oracle que são relevantes para o Amazon RDS para Oracle. Esta publicação foi escrita considerando as várias cargas de trabalho no Amazon RDS para Oracle que podem ser afetadas pela atualização do banco de dados 11.2.0.4. Nem todas as diretrizes mencionadas aqui são relevantes para todos os clientes. Recomendamos que você use seu julgamento para ver qual deles é adequado para seu banco de dados com base em suas opções e parâmetros usados. O conhecimento prévio da administração do banco de dados Oracle e do ambiente deve ser usado para executar o upgrade.

 

Amazon RDS para Oracle: Linha do tempo do Fim do Suporte da versão 11.2.0.4

A Oracle anunciou a data final do suporte para o Oracle Database versão 11.2.0.4 como 31 de dezembro de 2020, após a qual o Oracle Support não lançará mais Atualizações Críticas de Patch para esta versão do banco de dados. O Amazon RDS para Oracle encerrará o suporte para o Oracle Database versão 11.2.0.4 Standard Edition 1 (SE1) para o modelo Licença Incluída (LI) em 31 de outubro de 2020. Para o modelo BYOL (Bring Your Own License), o Amazon RDS for Oracle encerrará o suporte para o Oracle Database versão 11.2.0.4 para todas as edições em 31 de dezembro de 2020.

Todas as instâncias 11.2.0.4 SE1 LI serão atualizadas automaticamente para 19c a partir de 1º de novembro de 2020. Da mesma forma, as instâncias de BYOL 11.2.0.4 serão automaticamente atualizadas para 19c a partir de 1º de janeiro de 2021. Recomendamos que você atualize suas instâncias de banco de dados do Amazon RDS para Oracle da versão 11.2.0.4 para uma versão mais recente e valide suas aplicações antes que as atualizações automáticas comecem.

 

A tabela a seguir resume a linha do tempo para o Oracle 11.2.0.4 com SE1 com LI.

Datas Atividade
1 A partir de Agosto — 31 de outubro de 2020 Você pode atualizar instâncias de banco de dados 11.2.0.4 manualmente para a versão de sua escolha
2 Desde 1 de agosto de 2020 Você pode atualizar os snapshots 11.2.0.4 manualmente para a versão de sua escolha
3 Desde 1 de agosto de 2020 O Amazon RDS para Oracle desativou a criação de novas instâncias em 11.2.0.4 para LI
4 A partir 1 de novembro de 2020 O Amazon RDS para Oracle inicia upgrades automáticos de instâncias de banco de dados para 19c
5 A partir 1 de novembro de 2020 O Amazon RDS para Oracle iniciará upgrades automáticos para a versão 19c para qualquer instância de banco de dados restaurada a partir de snapshots

 

A tabela a seguir resume a linha do tempo do Oracle 11.2.0.4 no SE, SE1 e EE com BYOL.

Datas Atividade
1 A partir de Agosto — 31 de dezembro de 2020 Você pode atualizar instâncias de banco de dados 11.2.0.4 manualmente para a versão de sua escolha
2 1 de outubro de 2020 Você pode atualizar os snapshots 11.2.0.4 manualmente para a versão de sua escolha
3 1 de outubro de 2020 O Amazon RDS para Oracle desativa criação de novas instâncias com versão 11.2.0.4 utilizando BYOL
4 1 de janeiro de 2021 O Amazon RDS para Oracle inicia upgrades automáticos de instâncias de banco de dados para 19c
5 1 de janeiro de 2021 O Amazon RDS para Oracle inicia upgrades automáticos de instâncias de banco de dados restauradas de snapshots para 19c

 

Para obter mais informações sobre o EOS da versão 11.2.0.4 do Amazon RDS para Oracle, consulte Anúncio: Amazon RDS for Oracle — Linha do tempo do fim do suporte para versões principais 12.2.0.1 e 11.2.0.4 (em inglês).

 

Opções de upgrade de versão no Amazon RDS para Oracle

O Amazon RDS para Oracle oferece suporte aos seguintes principais caminhos de atualização de versão (na data desta publicação).

Versão Atual Caminho de atualização suportado
1 18.0.0.0 19.0.0.0
2 12.2.0.1 19.0.0.0 ,18.0.0.0
3 12.1.0.2 19.0.0.0 ,18.0.0.0, 12.2.0.1
4 11.2.0.4 19.0.0.0,18.0.0.0.0.2.0.1, 12.1.0.2.v5 e versões posteriores 12.1

 

Como parte da decisão para qual versão atualizar, você tem as seguintes opções:

  • 1.0.2 — O Suporte Estendido para o Oracle Database 12.1.0.2 (Terminal Patch Set) termina em 31 de julho de 2022. O Amazon RDS para Oracle planeja oferecer suporte ao Oracle Database 12.1.0.2 até 31 de julho de 2022.
  • 2.0.1 — O Suporte Limitado de Correção de Erros para o Oracle Database 12.2.0.1 termina em 31 de março de 2022. O Amazon RDS para Oracle planeja oferecer suporte ao Oracle Database 12.2.0.1 até 31 de março de 2022.
  • 18c — O suporte ao Oracle Database 18c termina em 8 de junho de 2021. O Amazon RDS para Oracle planeja oferecer suporte ao Oracle Database 18c até 8 de junho de 2021. (Não há Suporte Estendido para o Oracle Database 18c.)
  • 19c — O Suporte Premier para Oracle Database 19c termina em 30 de abril de 2024 e o Suporte Estendido termina em 30 de abril de 2027. O Amazon RDS para Oracle planeja oferecer suporte ao Oracle Database 19c até 30 de abril de 2027.

Recomendamos que você atualize suas instâncias de banco de dados 11.2.0.4 para 19c porque é a versão maior prazo de suporte

Ao atualizar qualquer software, verificar a compatibilidade da nova versão e seus recursos desempenha um papel crucial no sucesso geral da atualização. Versões e liberações do Oracle Database podem ter diferenças em como funcionam e interagem com aplicativos, o que pode resultar em problemas de compatibilidade. Embora a maneira como você interage com o Amazon RDS for Oracle permaneça a mesma do ponto de vista de atualização de versão principal, os recursos específicos do Oracle Database em versões principais podem mudar ou até se tornar obsoletos. Para obter mais informações sobre upgrades de versão principais, consulte Oracle Database Engine Release Notes (em inglês).

Tenha em mente o seguinte:

  • Não há suporte para downgrades de versões principais.
  • Um upgrade de versão principal do 11g para o 12c deve fazer upgrade para um Oracle Patch Set Update (PSU) lançado no mesmo mês ou posterior.

Por exemplo, há suporte para um upgrade de versão principal do Oracle versão 11.2.0.4.v14 para o Oracle versão 12.1.0.2.v11. No entanto, uma atualização de versão principal do Oracle versão 11.2.0.4.v14 para o Oracle versão 12.1.0.2.v9 não é suportada. Isso ocorre porque o Oracle versão 11.2.0.4.v14 foi lançado em outubro de 2017 e o Oracle versão 12.1.0.2.v9 foi lançado em julho de 2017. Para obter informações sobre a data de lançamento de cada PSU Oracle, consulte Notas de Versão do Mecanismo de Banco de Dados Oracle (em inglês).

 

Considerações sobre tempo de interrupção para uma atualização de versão principal

O Amazon RDS permite que você inicie manualmente uma atualização de versão principal modificando a instância de banco de dados — por meio do AWS Management Consoleda AWS Command Line Interface (AWS CLI) ou da API do Amazon RDS. Este é um upgrade in-loco e requer tempo de parada das aplicações durante o processo de upgrade. Em caso de problemas com a atualização, você pode restaurar o backup mais recente. A duração da interrupção varia de acordo com a versão principal e de acordo com a classe da instância de banco de dados. Você pode determinar o tempo exato que leva executando uma atualização de teste usando uma restauração de um snapshot do banco de dados de produção em um ambiente de pré-produção.

Se o método de upgrade usando a modificação da instancia de banco de dados que causa indisponibilidade não for adequado para sua aplicação, uma abordagem alternativa é usar replicação bidirecional com o AWS Database Migration Service (AWS DMS) ou o Oracle GoldenGate. Esse método pode fornecer o menor tempo de interrupção para a atualização. Esse método envolve a configuração da replicação lógica entre as instâncias de banco de dados de origem e destino (ambas em execução na mesma versão). Em seguida, você atualiza a instância de banco de dados de destino para 19c, deixando a origem para ser executada em 11.2.0.4. Quando o upgrade da instância de banco de dados de destino estiver concluído, você poderá apontar seu aplicativo para a instância de banco de dados de destino atualizada. Esse método, que usa replicação bidirecional entre as instâncias de banco de dados de origem e destino, também pode ser usado como um plano de fallback, caso o upgrade não seja satisfatório devido a incompatibilidades.

Esta publicação aborda o processo de atualização usando o método de alteração da instância de banco de dados. O método de replicação está fora do escopo deste postagem.

 

Como o Amazon RDS para Oracle realiza o upgrade de versão principal

Quando uma atualização de versão principal é executada a partir do console, na CLI da AWS ou na API do Amazon RDS, a atualização efetua as seguintes etapas:

  1. Tira um snapshot pré-upgrade (se configurado para backups). Você pode usar esse snapshot para reverter se necessário.
  2. Desliga a instância e a prepara para a atualização.
  3. Executa scripts de upgrade do Oracle.
  4. Tira um snapshot pós-atualização.

Quando o Amazon RDS inicia a Etapa 1, o status da instância muda de Disponível para Upgrade. Após a Etapa 4, ele retorna para Disponível. O diagrama a seguir ilustra as etapas quando a chamada de CLI da AWS modify-db-instance é chamada.

 

 

Práticas recomendadas para o upgrade de versões principais

Nesta seção, aprofundamos as práticas recomendadas durante várias fases do processo de atualização: pré-atualização, atualização e pós-atualização.

O que discutiremos nas seções a seguir são as etapas comuns normalmente concluídas na maioria dos upgrades do Oracle Database. Para obter uma lista completa, consulte o Oracle Database Upgrade Guide (em inglês).

Fase de pré-atualização

A Oracle usa a seguinte terminologia ao atualizar para uma versão superior (ou upgrade de versão principal na terminologia do Amazon RDS):

  • Funcionalidades obsoletas— Funcionalidades que não estão mais sendo aprimoradas, mas ainda são suportadas durante toda a vida útil desta versão do Oracle Database.
  • Funcionalidade não suportadas— Aquelas que não são mais suportadas pela correção de bugs relacionados a essa funcionalidade. A Oracle pode optar por remover o código necessário da funcionalidade.

Quando indicado, uma funcionalidade obsoleta pode ser não suportada em uma versão principal futura. Ao passar por várias versões principais durante o processo de upgrade, é altamente recomendável consultar a documentação da Oracle para obter essas funcionalidades, opções e parâmetros obsoletos e não suportados nas versões intermediárias também. Para obter mais informações, consulte Behavior Changes, Deprecated and Desupported Features for Oracle Database.

Você deve considerar os seguintes fatores na fase de pré-atualização.

Considerações sobre o tempo de interrupção

Uma atualização típica com todas as opções possíveis no grupo de opções pode levar de 1 a 2 horas. Para reduzir o tempo de interrupção, considere o seguinte:

  • Faça um snapshot manual usando a CLI da AWS create-db-snapshotantes de iniciar a fase de upgrade. Isso acelera o tempo necessário para um snapshot de pré-atualização (que é automaticamente executado durante a fase de upgrade).
  • Se você estiver atualizando para o 19c, é recomendável converter todos os DBMS_JOBpara DBMS_SCHEDULER antes da atualização. Durante o upgrade, o Oracle tenta converter o DBMS_JOB em DBMS_SCHEDULER. Se você tiver um grande número de entradas DBMS_JOB a atualização leva mais tempo.
  • Certifique-se de que as trilhas de auditoria não são muito grandes. As verificações e upgrades pré-autalização podem levar mais tempo com trilhas de auditoria grandes.
  • Reúna estatísticas do otimizador antes da atualização usando Gather_dictionary_stats. Também reúna estatísticas fixas e de dicionário.
  • Remova as opções que não são usadas. É uma boa prática remover opções não utilizadas para acelerar as atualizações e resultar em menos problemas e conflitos ao passar de uma versão principal para outra.
  • Remova ou redefina parâmetros que não sejam usados pelos mesmos motivos anteriores.
  • Se necessário, talvez você também precise atualizar a classe de instância com base na opção da instância de destino. Para obter mais informações, consulte Suporte de classe de instância de banco de dados para Oracle.

Considerações Multi-AZ

Se sua instância de banco de dados estiver em uma implantação Multi-AZ, o Amazon RDS for Oracle atualizará ambas instancias simultaneamente.

Considerações sobre grupos de opções

Considere o seguinte para grupos de opções:

  • Por padrão, quando um sistema é atualizado para a próxima versão principal superior, o Amazon RDS para Oracle escolhe o grupo de opções padrão se o novo grupo de opções personalizadas correspondente para a versão de destino não for escolhido. Por exemplo, ao atualizar de 11.2.0.4 para 19c, você deve criar um novo grupo de opções compatível com a nova versão 19c com o mesmo conjunto de opções da versão 11.2.0.4, e usá-lo durante o processo de atualização. Você também deve considerar fatores como o upgrade do APEX, cuja atualização deve ser tratada separadamente para acelerar a atualização. Isso também se aplica aos agentes OEM. Em alguns casos, as opções são desinstaladas e reinstaladas à medida que você move de uma versão para outra. Por exemplo, o SQLT é reinstalado, o que exclui quaisquer metadados antigos armazenados pela opção.
  • Ao escolher a versão do agente OEM, considere a compatibilidade com o OMS.
  • Observe o grupo de opções e a VPC. Se uma instância de banco de dados estiver em uma VPC, o grupo de opções associado à instância será vinculado a essa VPC. Isso significa que você não pode usar o grupo de opções atribuído a uma instância de banco de dados se tentar restaurar a instância para uma VPC diferente ou uma plataforma diferente (por exemplo, quando você usa a opção OEM).
  • Quando você atualiza uma versão principal, entenda as alterações que o Oracle faz nas opções nessa alteração. Por exemplo, a Oracle removeu o suporte da opção Multimedia na 19c. No entanto, ele separou a funcionalidade MDSYS em uma opção separada chamada Locator. A Oracle também recomenda que você passe do Locator para Spatial e Graph antes da atualização. Toda a funcionalidade MDSYS está disponível com Spatial e Graph. Então, quando você atualiza para 19c e instala o Spatial e Graph, todos as stored procedures funcionam normalmente. Para obter mais informações, consulte o artigo 1 do “My Oracle Support” para obter mais informações.
  • O pacote PL/SQL DBMS_XMLQUERYestá obsoleto no Oracle Database 18c. Em vez disso, a Oracle recomenda o uso do DBMS_XMLGEN .

Considerações sobre grupos de parâmetros

Se você associar um novo parameter group a uma instância de banco de dados, reinicialize o banco de dados após a conclusão da atualização. Se você precisar reinicializar a instância para aplicar as alterações do parameter group, o status do parameter group da instância mostrará pending-reboot. Você pode exibir o status do parameter group de uma instância no console ou usando um comando describe como describe-db-instances.

A funcionalidade continuous_mine do pacote do LogMiner DBMS_LOGMNR.START_LOGMNR está obsoleta. Ele foi removido no Oracle Database 12c Release 2 (12.2). Não há funcionalidade de substituição. A Oracle não forneceu nenhuma alternativa para isso. Se você usar isso, precisará abordá-lo de uma maneira diferente, como o AWS DMS ou o Oracle GoldenGate.

Considerações de segurança

Seguem-se algumas considerações de segurança importantes:

  • Por padrão, as contas Oracle que não tiveram suas senhas redefinidas antes da atualização (que estão definidas como status EXPIRED) e que também estão definidas como status LOCKED são definidas como NO AUTHENTICATION após a conclusão da atualização. Portanto, pós-atualização, qualquer conta com uma senha definida como padrão, bloqueada e expirada perde o método de autenticação. Embora possa ser revertida, é recomendável validar a força da senha antes da atualização e bloqueá-la.
  • Verifique as contas que usam a versão de senha que não diferencia maiúsculas e minúsculas. Faça login no SQL*Plus como um usuário administrativo e insira a seguinte consulta SQL. Se houver versões 10g, consulte a documentação do Oracle para corrigir versões do 10g ou contas de usuário com LOCKEDapós a conclusão do upgrade:

SELECT USERNAME, PASSWORD_VERSIONS FROM DB_USERS;

  • Certifique-se de que não tem o parâmetro obsoleto SEC_CASE_SENTITIVE_LOGONdefinido como FALSE.
  • A partir do Oracle 12c, a Oracle usa o Oracle Real Application Security (ORAS) para armazenar políticas de segurança Oracle. Antes de atualizar um banco de dados 11g para o Oracle Database 19c, você deve deletar todas as atribuições de segurança de dados definidas no 11g. Após a atualização, talvez seja necessário definir novamente as funções de segurança de dados. Se ele for atualizado sem executar essa ação, qualquer diretiva de segurança de dados que inclua uma função de segurança de dados se tornará inválida no novo banco de dados 19c.

Considerações gerais

Finalmente, você deve considerar os seguintes pontos gerais:

  • Ao atualizar para o 19c, recomendamos que você examine a capacidade provisionada e veja se ela será atendida. Dependendo da classe de instância em que o banco de dados 11g está sendo executado, talvez seja necessário dimensionar a computação para uma geração mais recente da classe de instância. Para obter mais informações, consulte Suporte a classes de instância de banco de dados para Oracle. Isso também pode ser uma oportunidade para avaliar instâncias reservadas do Amazon RDS e você pode querer comprar novas concessões para sua versão antes de realizar a atualização.
  • Certifique-se de que nenhum objeto é inválido antes de atualizar. É uma boa prática manter uma lista de todos os objetos com sua respectiva contagem, tipo e status antes da atualização e compará-la após a atualização.
  • Faça um backup das estatísticas do otimizador para todos os esquemas usando o pacote DBMS_STATS.
  • Colete snapshots AWR ou Statspack antes da atualização. Estes são utilizados durante a validação de desempenho pós-atualização. Mesmo que você tenha feito isso no ambiente de pré-produção, é uma boa prática fazer essa comparação na produção.
  • Se você também tiver uma tarefa de manutenção de banco de dados, como adicionar partições, é melhor executá-las antes de atualizar.
  • Desative jobs de banco de dados agendados ou cron jobs.
  • Recomenda-se desativar quaisquer triggers DDL personalizadas antes da atualização e reativá-las após a atualização.
  • Se você estiver usando views materializadas (MV), verifique o status de todos as MVs antes da atualização. Verifique o tamanho dos registros MV. Se for diferente de zero, resolva-os para se certificar de que estão todos sincronizados. Recomenda-se aguardar até que todos os MVs tenham concluído a atualização. Certifique-se de que todos os objetos que fazem referência a bancos de dados remotos em links de banco de dados estejam acessíveis para reduzir o tempo gasto em timeouts Para obter mais informações, consulte “My Oracle support” Doc ID 1406586.1. Para clientes com licença incluída, crie um caso de suporte.
  • Revise todos os parâmetros ocultos e verifique se eles foram modificados ou removidos para atender à versão de destino. Inclua todos os recursos afetados por esses parâmetros como parte dos testes funcionais e de desempenho no ambiente de pré-produção.

 

Fase de atualização

Depois de concluir as verificações de pré-atualização com êxito, você pode passar para a fase de atualização. Se sua instância estiver usando configurações personalizadas de grupo de opções ou grupo de parâmetros, você deve especificar novas opções e grupos de parâmetros para que a atualização seja realizada junto com quaisquer outros atributos adicionais.

Quando você atualiza sua instância de banco de dados 11.2.0.4 SE1 para 19c, por padrão, ela o leva ao SE2 no 19c.

Nesta seção, discutimos como executar o upgrade no console ou por meio da CLI da AWS.

Para atualizar a versão de uma instância de banco de dados no console, execute as seguintes etapas:

  1. No console do Amazon RDS, escolha Databases.
  2. Escolha a instância de banco de dados que você deseja atualizar.
  3. Escolha Modify.
  4. Para License Model, escolha o tipo de licença desejado. Para a DB engine version, escolha a nova versão.

 

 

  1. Escolha Continuee verifique o resumo das modificações.
  2. Para aplicar as alterações imediatamente, escolha Apply Immediately.
    Escolher essa opção pode causar uma interrupção em alguns casos. Para obter mais informações, consulte Usando a Configuração Aplicar Imediatamente. Caso contrário, você pode fazer com que a atualização ocorra na próxima janela de manutenção semanal.
  3. Na página de confirmação, revise suas alterações e escolha Modify DB Instance para salvar suas alterações.

Para executar um upgrade de versão principal em sua próxima janela de manutenção usando o comando modify-db-instance do CLI da AWS, insira o seguinte código:

 

aws rds modify-db-instance \ 
--db-instance-identifier mydbinstance \
--engine-version new_version \
--allow-major-version-upgrade \
--no-apply-immediately

 

Para obter informações sobre versões válidas, use o comando describe-db-engine-versions da CLI da AWS.

Se você tiver várias instâncias, poderá usar a CLI da AWS combinada com um script de shell para atualizar várias instâncias. Para obter mais informações sobre como atualizar o mecanismo de banco de dados do Amazon RDS for Oracle, consulte Upgrade the Oracle DB Engine (em inglês).

 

Fase pós-atualização

Após a fase de atualização, você pode concluir as seguintes verificações e etapas de pós-atualização:

  1. Como mencionado na seção de fase de pré-atualização é necessário verificar objetos com status INVALIDe corrigi-los antes de testar mais. Este também é um bom momento para comparar o relatório/lista (com a contagem de objetos e status) coletados durante a fase de pré-atualização.
  2. Se o Amazon RDS for Oracle for usado como um catálogo RMAN, atualize o catálogo de recuperação do RMAN. Use o comando UPGRADE CATALOG para atualizar o esquema do catálogo de recuperação do RMAN de uma versão mais antiga para a versão exigida pelo cliente RMAN.
  3. Conclua as seguintes etapas de conectividade do cliente:
    A) Certifique-se de definir ORACLE_HOME, PATH, LD_LIBRARY_PATH, LIBPATH, e os demais parametros como para 19.x no diretório home do client.
    B) Faça as alterações apropriadas no orae sqlnet.ora no lado do client e incorpore as alterações relacionadas ao 19c ou ao novo endpoint se estiver testando em uma nova instância do RDS restaurada a partir da produção.
    C) Teste a conectividade do client. Com base na versão de destino identificada do driver, execute um teste de regressão. Tenha em mente que há casos em que a escolha da versão JDBC pode afetar o desempenho e alterar o processo do plano de otimização.
  4. Se você usou o pacote DBSM_STATSpara exportar as estatísticas do otimizador conforme mencionado nas tarefas de pré-atualização, atualize a tabela de estatísticas (usando UPGRADE_STAT_TABLE) onde as estatísticas do otimizador foram copiadas antes da atualização. Em seguida, restaure estatísticas e execute testes de desempenho.
  5. Se você tiver links de banco de dados para outras instâncias de banco de dados do Amazon RDS para Oracle ou outras instâncias Oracle no Amazon Elastic Compute Cloud (Amazon EC2), é recomendável testá-las do ponto de vista de funcionalidade e desempenho após o upgrade.
  6. Se você tiver algum job agendado no Amazon CloudWatch ou no cron, verifique se eles estão ativados e ainda podem se conectar ao banco de dados após a atualização e executar sem problemas.
  7. Certifique-se também de ativar qualquer DDL ou triggers de sistema desativados como parte da verificação de pré-atualização.

Certifique-se de ter espaço livre suficiente no tablespace SYSTEM  e SYSAUX . É recomendável ter um espaço adicional de 1 a 2 GB em cada tablespace.

  1. Valide seus aplicativos em relação ao banco de dados atualizado. É vital que você observe as principais instruções SQL (via AWR ou Statspack) e verifique se elas estão usando os planos desejados.
  2. Após a atualização, se as instruções SQL funcionarem mal devido à alteração nos planos do otimizador 19c, você poderá usar OPTIMIZER_FEATURES_ENABLEEsse parâmetro pode ser alterado no nível da sessão e no nível do sistema. Por exemplo, se você atualizar seu banco de dados da versão 11.2 para a versão 19c, mas quiser manter o comportamento do otimizador da versão 11.2, poderá fazê-lo definindo esse parâmetro como 11.2.0.4. Posteriormente, você pode tentar os aprimoramentos introduzidos nas versões até e inclusive a versão 19c definindo o parâmetro como 19.0.0.
  3. Se você tiver um processo automatizado de backup e restauração, recuperação de desastres ou procedimentos de atualização de produção para não-produção, recomendamos que você os teste. Você precisa testar qualquer processo que interage com outros bancos de dados que podem ou não estar no mesmo nível.

 

Problemas conhecidos

Recomendamos que você atualize os snapshots manuais que pretende reter por mais tempo, incluindo os snapshots feitos usando o AWS Backup ou quaisquer produtos de parceiros de terceiros. Por exemplo, se você usou o AWS Backup e o backup foi migrado para o Glacier com base no ciclo de vida definido no AWS Backup, quando o backup é restaurado, a primeira coisa que o RDS faz é forçar o upgrade para uma das versões compatíveis e, em seguida, concluir a restauração. Se você quiser mantê-lo como uma cópia da versão antiga (por exemplo, se o banco de dados estiver suportando uma versão antiga de um aplicativo de terceiros), você deve planejar fazer um backup usando ferramentas Oracle nativas, como exportação de data pump ou RMAN. Também mantenha as incompatibilidades de versão em mente.

Depois de atualizar o banco de dados, se você tiver problemas de conectividade, como “ORA-28040: No matching authentication protocol”, talvez seja necessário atualizar a versão do cliente ou o driver JDBC. Em geral, é melhor corresponder às versões cliente e servidor. A melhor versão de cliente para a versão de banco de dados 19c seria o cliente 19c. No entanto, os clientes 11.2.0.4 também são suportados em 19c. Recomendamos testar esta combinação. Consulte o documento “My Oracle Support” 207303.1.

 

Testando o upgrade de sua instância de banco de dados Amazon RDS para Oracle

Antes de atualizar o banco de dados de produção para uma nova versão principal, você deve validar seus aplicativos em relação à nova versão em um ambiente de pré-produção. Este ensaio do processo de atualização também permite que você avalie o tempo necessário para executar esta atualização de versão principal.

O diagrama a seguir ilustra as etapas para testar sua atualização.

 

 

O processo inclui as seguintes etapas:

  1. Faça um snapshot da instância de banco de dados existente usando a chamada de CLI da AWS create-db-snapshot.
  2. Restaure o DB snapshot usando a chamada de CLI da AWS restore-db-instance-from-db-snapshotpara criar uma instância de banco de dados de teste na mesma versão.
  3. Execute a chamada de CLI da AWS modify-db-instancena instância de banco de dados de teste para atualizá-la para a nova versão principal.
  4. Quando a atualização estiver concluída, você poderá validar seu aplicativo em relação à instância de banco de dados de teste.
  5. Após a conclusão do teste, você pode agendar e executar a atualização do banco de dados de produção.

 

Considerações adicionais

O Amazon RDS para Oracle oferece suporte ao recurso de réplicas de leitura para as versões 12.1.0.2 e posteriores. Se você atualizar seu banco de dados de 11.2.0.4 para uma versão superior, talvez você queira avaliar o recurso de réplicas de leitura e determinar se seu aplicativo requer recuperação de desastres entre regiões e escalabilidade de leitura. Para obter mais informações, consulte Recuperação de desastres gerenciada e farm de leitores gerenciados com o Amazon RDS para Oracle usando o Oracle Active Data Guard.

Como parte da atualização para o 19c, você também pode usar opções como OLAP e Oracle Label Security.

 

Conclusão

Nesta publicação, analisamos a linha do tempo do Fim do Suporte da versão 11.2.0.4 no Amazon RDS para Oracle, estudamos as opções de upgrade de versão disponíveis para você e abordamos as práticas recomendadas durante as fases do processo de upgrade.

 


Sobre os autores

Jorge Rua é Gerente de Arquitetura de Soluções na Amazon Web Services e lidera o SQUAD de migração de banco de dados.

 

 

 

 

Thiago Morais é Gerente de Arquitetura de Soluções na Amazon Web Services e lidera o SQUAD de migração de banco de dados.