Considerações sobre a migração homogênea do banco de dados

Esta seção discute as principais práticas recomendadas para migrações homogêneas. Ao migrar seu banco de dados do Exadata local para o Amazon RDS for Oracle ou Oracle no Amazon EC2, considere as diretrizes discutidas nas subseções a seguir.

Criptografia

A segurança dos dados é a principal prioridade em AWS. AWS implementou medidas contratuais, técnicas e organizacionais rigorosas para proteger a confidencialidade, integridade e disponibilidade dos clientes. Para bancos de dados, a criptografia é fundamental porque protege informações privadas e dados confidenciais. O Oracle no Amazon EC2 e o Amazon RDS for Oracle oferecem suporte a dois métodos de criptografia para dados em repouso:

• AWS Key Management Service (AWS KMS) para criptografar volumes do Amazon EBS.

• Oracle Advanced Security Option Transparent Data Encryption (TDE) para criptografar informações confidenciais armazenadas em arquivos de dados. O Oracle TDE exige uma licença Oracle.

Ambas as opções criptografam os dados do usuário no banco de dados Oracle e em todos os backups do banco de dados. A criptografia também é transparente para as declarações DML emitidas pelos aplicativos.

Para dados em trânsito, o Oracle no Amazon EC2 e o Amazon RDS for Oracle oferecem suporte ao Oracle Native Network Encryption (NNE). Para obter mais informações sobre o suporte ao NNE, consulte a documentação do Amazon RDS.

Particionamento de dados

Com o Oracle Partitioning, um único objeto lógico no banco de dados, como uma tabela ou um índice, é dividido em objetos físicos menores do banco de dados, o que ajuda a melhorar a capacidade de gerenciamento, o desempenho e a disponibilidade. O particionamento Oracle exige uma licença Oracle.

Se você tiver grandes cargas de trabalho de banco de dados, considere particionar suas tabelas. A remoção de partições permite que o otimizador de banco de dados Oracle analise FROM e WHERE use cláusulas em instruções SQL para eliminar partições desnecessárias ao criar a lista de acesso à partição. O Oracle Database executa operações somente nas partições que são relevantes para a instrução SQL, o que normalmente melhora o desempenho.

O particionamento também ajuda na disponibilidade. Se uma partição ficar off-line e uma instrução SQL não precisar da partição off-line para concluir uma operação, a instrução SQL será bem-sucedida. No entanto, se um bloco de dados for perdido em uma tabela do Oracle Database que não tenha sido particionada, a tabela inteira ficará indisponível até que a operação de restauração seja concluída.

Compactação de dados

Para compactação de dados, a Oracle oferece HCC e compressão avançada. A compactação avançada melhora o desempenho e reduz os custos de armazenamento ao reduzir o espaço de armazenamento do banco de dados para dados relacionais (tabelas), dados não estruturados (arquivos), índices, dados redo do Data Guard, dados de rede, backups do RMAN e outros tipos de dados. A compactação avançada também pode melhorar o desempenho dos componentes da infraestrutura do banco de dados, incluindo memória e largura de banda da rede.

De acordo com a documentação da Oracle, a compressão avançada tem uma taxa média de compressão de pelo menos 2x. Portanto, 100 GiB de dados normalmente podem residir em 50 GiB de espaço de armazenamento. Ao migrar seu banco de dados Oracle para AWS, você pode usar a compressão avançada no Amazon RDS para Oracle e Oracle no Amazon EC2, com bancos de dados OLTP e de armazenamento de dados. Você pode considerar usar a compressão avançada com seu banco de dados Oracle ativado AWS para melhorar o desempenho e reduzir os custos de armazenamento do Amazon EBS, mesmo que você não a tenha usado com o Exadata. A compressão avançada requer uma licença Oracle.

Estratégia de ILM

O Information Lifecycle Management (ILM) fornece processos, políticas e componentes que ajudam a gerenciar as informações em um banco de dados com base em sua frequência de uso. Ao migrar do Exadata para o Oracle em AWS, você deve determinar se pode limpar os dados antes ou depois de migrá-los para o. AWS AWS Ativado, você pode aplicar regras para manter os dados somente por um período específico. Você pode implementar o Oracle Partitioning e o Oracle Advanced Compression para configurar políticas de ciclo de vida de dados. Isso pode melhorar o desempenho e, ao mesmo tempo, manter somente os dados necessários para apoiar sua empresa.

Por exemplo, digamos que você tenha uma tabela que consome vários tebibytes de dados não compactados. Atualmente, você tem 12 anos de dados e deve mantê-los por 14 anos. Cerca de 90% de todas as consultas acessam dados com menos de dois anos. Normalmente, você compara o uso de dados mês a mês, trimestre a trimestre e ano a ano. Os dados não podem ser atualizados após 30 meses, mas às vezes você precisa acessar dados históricos de até 12 anos. Nesse caso, você pode considerar as seguintes políticas de ILM:

• Implemente compressão avançada. Aproveite o Oracle Heat Map e a Otimização Automática de Dados (ADO) com Compressão Avançada.

• Configure o particionamento por intervalo na coluna de data.

• Use uma função que elimine partições com mais de 14 anos mensalmente.

• Use espaços de tabela somente para leitura para armazenar dados com mais de 30 meses. O objetivo principal dos espaços de tabela somente para leitura é eliminar a necessidade de realizar backup e recuperação de grandes partes estáticas de um banco de dados (quando você usa o Oracle RMAN com o Oracle no Amazon EC2). Os espaços de tabela somente para leitura também fornecem uma forma de proteger dados históricos para que os usuários não possam modificá-los. Tornar um espaço de tabela somente para leitura impede atualizações em todas as tabelas no espaço de tabela, independentemente do nível de privilégio de atualização do usuário.

Os usuários geralmente armazenam dados ativos, dados acessados com pouca frequência e arquivam dados em um único banco de dados Oracle. Durante a migração do banco de dados Oracle para AWS, você pode migrar dados acessados com pouca frequência, dados históricos de auditoria e dados arquivados diretamente no Amazon S3 ou no Amazon S3 Glacier. Isso ajuda você a atender às suas necessidades de governança e conformidade para retenção de dados a longo prazo sem afetar o desempenho do banco de dados. Conforme os dados envelhecem no banco de dados relacional, eles podem ser arquivados no Amazon S3 ou no Amazon S3 Glacier. Você pode consultar facilmente os dados arquivados usando o Amazon Athena ou o Amazon S3 Glacier Select.

Integração OEM

Ao migrar suas cargas de trabalho da Oracle para AWS, talvez você queira implementar o Oracle Enterprise Manager (OEM) Cloud Control on. AWS O OEM é a plataforma de gerenciamento da Oracle que fornece uma interface única para gerenciar ambientes Oracle.

O Oracle no Amazon EC2 e o Amazon RDS for Oracle podem ser destinos para um ambiente OEM. O Oracle no Amazon EC2 segue o mesmo processo do Oracle no local para integração com o OEM. Para ativar o OEM no Amazon RDS for Oracle:

1. Faça login AWS Management Console e abra o console do Amazon RDS em https://console.aws.amazon.com/rds/.

2. No painel de navegação, escolha Grupos de opções.

3. Adicione a OEM_AGENT opção a um grupo de opções novo ou existente.

4. Adicione informações de configuração do OEM, incluindo o nome do host do servidor de gerenciamento OEM, a porta e a senha de registro do agente OEM.

O Amazon RDS for Oracle e o Oracle no Amazon EC2 também podem ser destinos para um ambiente OEM executado localmente. No entanto, isso exige que todas as portas OEM estejam acessíveis por meio do firewall.

CloudWatch Integração com a Amazon

A Amazon CloudWatch coleta dados operacionais e de monitoramento na forma de registros, métricas e eventos. Ele visualiza dados usando painéis automatizados que fornecem uma visão unificada dos AWS recursos, aplicativos e serviços executados no local AWS e no local. Bancos de dados Oracle hospedados no Amazon EC2 e no Amazon RDS for Oracle podem ser usados. CloudWatch

CloudWatch e o Amazon Simple Notification Service (Amazon SNS) são integrados para que você possa coletar, visualizar e analisar métricas para cada notificação ativa do Amazon SNS. Por exemplo, você pode definir um alarme para enviar uma notificação por e-mail ou SMS se uma ação específica, como uma mensagem de erro específica da Oracle no log de alertas do Oracle Database, ocorrer.

Para usar o CloudWatch Amazon SNS com o Oracle no Amazon EC2, você deve instalar CloudWatch um agente para enviar o registro de alertas, registros de auditoria, registros de rastreamento, registros de OEM e registros de ouvinte da Oracle. CloudWatch Se você implantar o Amazon RDS for Oracle, deverá modificar a instância Oracle para permitir que esses logs sejam enviados CloudWatch para. Para obter mais informações sobre CloudWatch integração, consulte Monitoramento de tópicos do Amazon SNS usando CloudWatch na documentação do Amazon SNS.

O Amazon RDS for Oracle também tem alarmes CloudWatch integrados para dezenas de eventos, incluindo utilização da CPU, número de conexões de banco de dados, memória disponível, espaço de armazenamento gratuito, IOPS de armazenamento, taxa de transferência de disco e atraso na replicação.

A maioria dos usuários migra do Exadata localmente para AWS continuar usando o OEM e também se integrar CloudWatch com seus bancos de dados Oracle na AWS.

Estatísticas do otimizador de banco de dados

As estatísticas do Oracle Database Optimizer fornecem informações sobre o banco de dados e suas tabelas, colunas, índices e o sistema. O otimizador usa essas informações para estimar o número de linhas e bytes que são recuperados de uma tabela, partição ou índice para uma consulta, estimar o custo do acesso e escolher o plano de execução SQL que tem o menor custo.

Se você restaurar um banco de dados local do Exadata no Amazon EC2 por meio do Oracle RMAN, a Oracle fornecerá automaticamente estatísticas que refletem o ambiente do Exadata. Assim que você restaurar os bancos de dados do Exadata no Amazon EC2 ou a carga inicial for concluída no Amazon RDS for Oracle, é uma boa prática coletar estatísticas o mais rápido possível. Isso pode ser feito executando o pacote Oracle DBMS_STATS.

Configurações do AWR

O Oracle Automatic Workload Repository (AWR) armazena estatísticas relacionadas ao desempenho de um banco de dados Oracle. Por padrão, o Oracle Database gera instantâneos uma vez a cada hora e os retém por 8 dias. Você pode criar ou eliminar manualmente os instantâneos e modificar as configurações dos instantâneos.

Para bancos de dados Oracle de produção, você deve aumentar o período de retenção do AWR para 60 ou 90 dias e reduzir o intervalo do AWR para 15 ou 30 minutos. Essas configurações oferecem suporte a month-over-month comparações e fornecem mais granularidade quando você visualiza dados AWR. Essas mudanças consomem um espaço de banco de dados relativamente pequeno (medido em gibibytes) e oferecem os benefícios de um histórico adicional. Para definir o período de retenção do AWR para 60 dias e o intervalo do AWR para 15 minutos, execute o seguinte comando (os valores dos parâmetros estão em minutos):

BEGIN
DBMS_WORKLOAD_REPOSITORY.modify_snapshot_settings
        (interval => 15,
         retention => 86400   
        );
END;
/ 

Se você migrar seu banco de dados local do Exadata para o Oracle no Amazon EC2 usando o Oracle RMAN ou o Oracle Data Guard, deverá descartar os snapshots do AWR capturados enquanto o banco de dados estava sendo executado no Exadata. Para fazer isso, use o DBMS_WORKLOAD_REPOSITORY.DROP_SNAPSHOT_RANGE procedimento ativado AWS.

Considerações sobre o Oracle RAC

Por padrão, o Exadata usa o Oracle Real Application Clusters (RAC), que permitem que você execute um único banco de dados Oracle em vários servidores para maximizar a disponibilidade e permitir a escalabilidade horizontal. O Oracle RAC usa armazenamento compartilhado. A menor oferta do Exadata inclui dois nós que são configurados usando o Oracle RAC.

Se você tiver uma exigência de RPO de zero e uma exigência de RTO de dois minutos ou menos, você pode implementar o Amazon RDS for Oracle com o Multi-AZ. Essa configuração fornece um compromisso mensal de disponibilidade de 99,95%, o que é equivalente ou melhor do que qualquer banco de dados de nuvem Oracle gerenciado do setor, incluindo bancos de dados Oracle gerenciados que usam o Oracle RAC.

Além disso, o Oracle no Amazon EC2 permite que você implemente um banco de dados altamente disponível usando muitos dos componentes da Oracle Maximum Availability Architecture (MAA). Esses componentes incluem, mas não estão limitados a, Active Data Guard, RMAN, Flashback Technologies, Edition-Based Redefinition e. GoldenGate

Também há várias alternativas para implementar o Oracle RAC em. AWS Para saber mais sobre as opções de RAC AWS, recomendamos que você entre em contato com a equipe da sua AWS conta.

Práticas recomendadas adicionais para migrações homogêneas

Os desenvolvedores geralmente ignoram as técnicas de ajuste de SQL e as melhores práticas quando implementam o Exadata. O Exadata oculta muitos problemas de design, portanto, as instruções SQL podem ser implantadas na produção sem avaliar seus planos de execução ou o consumo de recursos, pois são concluídas dentro de prazos aceitáveis. Siga essas práticas adicionais ao migrar seu banco de dados local do Exadata para o Oracle em. AWS

• Aplique o Oracle Release Update (RU) ou Release Update Revision (RUR) mais recente.

• Certifique-se de que o parâmetro de COMPATIBLE inicialização contenha somente três níveis (por exemplo, 19.0.0). Se uma atualização ocorrer após a migração para AWS, verifique se esse parâmetro foi modificado durante o processo de atualização.

• Considere armazenar em cache os números de sequência para minimizar a E/S. O valor padrão é 20. Se houver armazenamento insuficiente de números de sequência, pode ocorrer contenção, o que aparecerá como um aumento nos tempos de serviço do DML.

• Se você usar sequências, valide os valores da sequência no banco de dados de origem (Exadata no local) para evitar a inconsistência da sequência.

• Se o pool de conexões não for implementado na camada do aplicativo ou se o número de camadas do aplicativo resultar em um número muito grande de conexões de banco de dados, considere implementar o Oracle Database Resident Connection Pooling (DRCP). Esse recurso manipula os recursos de memória e computação no servidor de banco de dados de forma eficiente.

• Considere usar HugePages. A Oracle recomenda que você use o padrão HugePages para Linux. A ativação HugePages possibilita que o sistema operacional ofereça suporte a páginas de memória maiores que o padrão (geralmente 4 KB). Usar tamanhos de página muito grandes pode melhorar o desempenho do sistema, reduzindo a quantidade de recursos do sistema necessários para acessar as entradas da tabela de páginas.

• Se o banco de dados Oracle ativado AWS tiver links de banco de dados, confirme se os parâmetros de OPEN_LINKS_PER_INSTANCE inicialização OPEN_LINKS e não estão definidos com o valor padrão (4). Se esse valor for muito baixo, as instruções SQL que têm links de banco de dados começam a entrar na fila quando o valor máximo é atingido, o que afeta negativamente o desempenho.

• Talvez a carga inicial de dados não possa ser transmitida pela rede. Por exemplo, teoricamente, são necessários pelo menos nove dias sem interrupções para transferir 100 TiB em um link de 1 Gbps. Uma abordagem melhor seria usar um AWS Snow Familydispositivo para o qual migrar o banco de dados. AWS

• Remova todos os parâmetros ocultos específicos do Exadata (consulte a Nota 1274318.1 do Oracle MOS). Esses parâmetros ocultos de inicialização do Exadata não devem ser ativados. AWS Eles podem causar instabilidade, problemas de desempenho, corrupção e falhas.

• Tente resolver todos os objetos SYSTEM inválidos SYS e não válidos depois de migrar os dados para o Oracle em. AWS

• Considere armazenar em cache tabelas estáticas e acessadas com frequência na Área Global do Sistema Oracle (SGA).

• Escolha instâncias otimizadas para memória com configurações maiores do Oracle SGA para mitigar o desafio da ativação adicional de E/S. AWS Você pode usar o relatório Oracle SGA Advisory durante o teste de carga na instância de destino para encontrar a configuração ideal do Oracle SGA.

• Crie índices em tabelas que lidam com muitas varreduras completas de tabelas. A V$SEGMENT_STATISTICS exibição lista os segmentos candidatos.

• Identifique as principais consultas que consomem muitos recursos e otimize-as para melhores planos de execução. O Oracle SQL Tuning Advisor, licenciado sob o Oracle Tuning Pack, pode ser útil para o ajuste automático de SQL. Em alguns casos, talvez seja necessário reescrever consultas ou dividir uma consulta complexa em partes menores.

• Considere implementar soluções de armazenamento em cache, como Amazon ElastiCache e Amazon RDS, para réplicas de leitura do Oracle, como o Oracle Active Data Guard, para atender cargas de trabalho somente para leitura.

• Treine seus desenvolvedores em técnicas de otimização de consultas e crie procedimentos operacionais padrão para avaliar as consultas antes que elas sejam implantadas na produção.

• Certifique-se de que a contagem de objetos do banco de dados AWS seja a mesma do banco de dados local do Exadata. Valide tabelas, índices, procedimentos, acionadores, funções, pacotes, restrições e outros objetos.

• Considere modificações no aplicativo, se possível. (Em alguns casos, os aplicativos não podem ser modificados como acontece com os aplicativos ISV empacotados.) Evite chamadas desnecessárias e tente reduzir a frequência das chamadas necessárias. Tente minimizar o volume de dados recuperado pelas instruções SQL. Certifique-se de que a frequência de confirmação seja apropriada para a lógica de negócios, mas não excessiva. Tente melhorar o uso do cache no nível do aplicativo.

• O banco de dados deve residir em uma nuvem privada virtual privada (VPC) ativada. AWS Restrinja o acesso à rede para tráfego de entrada e saída a um modelo de privilégio mínimo. A origem do grupo de segurança deve se referir a um grupo de segurança na AWS conta, nas listas de prefixos ou em um conjunto específico de endereços IP (usando o formato x.x.x.x/32). A fonte do grupo de segurança não deve usar CIDR e os grupos de segurança não devem ser acessíveis na Internet pública (0.0.0.0/0).