As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Requisitos de recursos para a plataforma de destino

Recomendamos que você dimensione o ambiente de banco de dados de destino AWS com base na utilização do Exadata de origem, não na configuração. Muitos clientes compram sistemas Exadata com capacidade adicional para acomodar o crescimento previsto para os próximos três a cinco anos. Normalmente, quando as cargas de trabalho do Exadata são migradas AWS, menos recursos são implantados em comparação com a configuração do sistema Exadata de origem, portanto, é enganoso usar essa configuração original para prever os recursos da AWS.

Para estimar os recursos necessários na instância de destino, você pode usar as ferramentas discutidas na seção anterior, como AWR, visualizações de banco de dados, OEM e CellCli. Ativado AWS, você pode aumentar ou reduzir os recursos com mais facilidade em comparação com a plataforma Exadata de origem. As seções a seguir discutem as melhores práticas para estimar recursos como CPU, memória e IOPS para a plataforma de destino. Além disso, as equipes de contas e os especialistas em bancos de dados da AWS que têm ampla experiência em auxiliar clientes com suas migrações do Exadata podem ajudá-lo a dimensionar seu ambiente de destino. A AWS tem ferramentas internas que a equipe da conta da AWS pode usar para estimar os recursos necessários e dimensionar corretamente seu ambiente de destino na AWS.

Requisitos de CPU e memória

Ao migrar suas cargas de trabalho do Exadata para uma opção de implantação de banco de dados Oracle AWS, como o Amazon RDS for Oracle, você não deve basear os recursos da camada computacional (CPU e memória) somente nas estatísticas de utilização dos servidores de banco de dados Exadata. A carga de trabalho também se beneficia de recursos específicos do Exadata, como Smart Scan e índices de armazenamento, que transferem o processamento para as células de armazenamento e usam os recursos dos servidores de armazenamento. Portanto, você deve provisionar a camada de computação na instância de destino com recursos adicionais de CPU e memória com base no uso de recursos específicos do Exadata e no grau de otimização da carga de trabalho que pode ser possível durante a migração.

É difícil estimar com precisão os recursos adicionais de CPU necessários. Use os resultados da descoberta como ponto de partida para dimensionar o ambiente de destino. Para um cálculo aproximado, considere incluir uma vCPU adicional para cada 500 cargas de trabalho MBps do Smart Scan até o total de v CPUs necessário para a camada de computação.

Outra abordagem é considerar a utilização da CPU nos servidores de armazenamento. Você poderia adicionar cerca de 20% do total usado CPUs em servidores de armazenamento ao total v CPUs necessário para a camada de computação como ponto de partida. Você pode ajustar essa porcentagem com base no uso dos recursos do Exadata, conforme determinado por ferramentas como AWR e CellCli. Por exemplo, para uso baixo, você pode adicionar 10% para uso baixo, 20% para uso médio e 40% para uso alto. Se você utilizar um número total de 20 threads de CPU em todos os servidores de armazenamento e o uso dos recursos do Exadata for considerado médio, considere 4 v adicionais CPUs para compensar os recursos ausentes do Exadata no ambiente de destino.

Após essas estimativas iniciais, você também deve realizar testes de desempenho no ambiente de destino para determinar se precisa escalar os recursos alocados. Os testes de desempenho também podem revelar mais oportunidades de otimização da carga de trabalho que podem reduzir os recursos necessários.

Talvez seja necessário aumentar a alocação de memória para a instância Oracle para melhorar a taxa de acertos do cache e reduzir o I/O espaço ocupado. Sua plataforma Exadata de origem pode não ter memória suficiente para grandes alocações de SGA, especialmente em um cenário consolidado. Isso pode não causar problemas de desempenho no Exadata, porque I/O as operações geralmente são rápidas. Recomendamos que você comece com uma instância que ofereça suporte à seguinte alocação de memória:

Target memory required = larger of (8 GB per vCPUs required, two times the SGA+PGA allocation in the source)

SGA+PGA allocation = ~80% of available memory on the instance

Durante o teste de desempenho, você pode usar os recursos da Oracle, como consultoria de buffer pool, consultoria de metas de SGA e consultoria de memória PGA, para ajustar a alocação de SGA e PGA para atender aos requisitos de sua carga de trabalho.

A instância Amazon EC2 ou Amazon RDS deve ter CPU, memória e I/O recursos adequados para lidar com a carga de trabalho prevista do banco de dados. Recomendamos que você use uma classe de instância da geração atual para hospedar sua carga de trabalho. AWS Os tipos de instância da geração atual, como instâncias criadas no Nitro System, oferecem suporte a máquinas virtuais de hardware (HVMs). Para aproveitar as vantagens da rede aprimorada e do aumento da segurança, você pode usar o Amazon Machine Images (AMIs) para HVMs. Atualmente, o Amazon RDS for Oracle oferece suporte a até 128 vCPU e GBs 3.904 de memória. Consulte as classes de instância de banco de dados na documentação do Amazon RDS para obter informações sobre as especificações de hardware das classes de instância disponíveis para o Amazon RDS para Oracle. Consulte os tipos de instância da EC2 Amazon para obter uma lista EC2 de instâncias com detalhes dos recursos.

Requisitos de E/S

O uso de relatórios do AWR para estimar os requisitos de recursos exige familiaridade com os padrões de carga de trabalho para horários de pico, fora do pico e médios de carga. Para estimar os requisitos de IOPS para sua carga de trabalho com base em um relatório AWR coletado durante os períodos de pico, siga estas etapas:

As estatísticas do AWR (solicitações de leitura física, I/O solicitações de gravação I/O física, bytes de leitura física e bytes de gravação física) refletem as I/O atividades da carga de trabalho, excluindo a I/O contribuição de componentes que não são do aplicativo, como backup do RMAN e outros utilitários, como expdp ou sqlldr. Nesses casos, você pode considerar as estatísticas do AWR: solicitações de total de leitura física, I/O solicitações de total de gravação física, bytes totais de leitura física e bytes totais de gravação física para estimar IOPs os I/O requisitos de taxa de transferência.

Os bancos de dados executados no Exadata normalmente produzem centenas de milhares de IOPS e uma taxa de transferência muito alta (acima de 50 Gbps) devido aos fatores discutidos nas seções anteriores. No entanto, na maioria dos casos, as técnicas de ajuste e a otimização da carga de trabalho reduzem drasticamente o I/O espaço ocupado pela carga de trabalho.

Se I/O os requisitos forem muito altos, esteja ciente das limitações da Amazon EC2 e do Amazon RDS. Para uma alta taxa de transferência de volume do Amazon EBS, considere usar classes de EC2 instância da Amazon, como x2iedn, x2idn e r5b, que suportam até 260.000 IOPS com uma taxa de transferência de 10.000. MBps Consulte as instâncias otimizadas para Amazon EBS na EC2 documentação da Amazon para analisar o máximo de IOPS e a taxa de transferência suportados por várias instâncias. Para o Amazon RDS for Oracle, a classe de instância rb5 suporta até 256.000 IOPS com uma taxa de transferência de 4.000. MBps Consulte as classes de instância de banco de dados para analisar as instâncias otimizadas para Amazon EBS disponíveis para Amazon RDS for Oracle.

Você também deve entender como o IOPS e a taxa de transferência são medidos no caso de diferentes volumes do EBS que estão disponíveis para o ambiente de destino. Em alguns casos, o Amazon EBS divide ou mescla I/O as operações para maximizar a taxa de transferência. Para saber mais, consulte as características de E/S e o monitoramento na EC2 documentação da Amazon e Como otimizo o desempenho dos meus volumes de IOPS provisionados do Amazon EBS? no Centro de AWS Conhecimento.