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á. # Estime o tamanho do mecanismo Amazon RDS para um banco de dados Oracle usando relatórios AWR *Abhishek Verma e Eduardo Valentim, Amazon Web Services* ## Resumo Quando você migra um banco de dados Oracle para o Amazon Relational Database Service (Amazon RDS) ou o Amazon Aurora, computar a CPU, a memória e o I/O disco do banco de dados de destino é um requisito fundamental. Você pode estimar a capacidade necessária do banco de dados de destino analisando os relatórios do Oracle Automatic Workload Repository (AWR). Esse padrão explica como usar relatórios AWR para estimar esses valores. O banco de dados Oracle de origem pode estar no local ou hospedado em uma instância do Amazon Elastic Compute Cloud (Amazon EC2), ou pode ser uma instância de banco de dados Amazon RDS for Oracle. O banco de dados de destino pode ser qualquer banco de dados Amazon RDS ou Aurora. **nota** As estimativas de capacidade serão mais precisas se o mecanismo de banco de dados de destino for o Oracle. Para outros bancos de dados do Amazon RDS, o tamanho do mecanismo pode variar devido às diferenças na arquitetura do banco de dados. Recomendamos que você execute o teste de desempenho antes de migrar seu banco de dados Oracle. ## Pré-requisitos e limitações **Pré-requisitos ** + Uma licença do Oracle Database Enterprise Edition e uma licença do Oracle Diagnostics Pack para baixar relatórios AWR. **Versões do produto** + Todas as edições do banco de dados do Oracle para versões 11g (versões 11.2.0.3.v1 e posteriores) e até 12.2 e 18c, 19c + Esse padrão não abrange o Oracle Engineered Systems ou o Oracle Cloud Infrastructure (OCI). ## Arquitetura **Pilha de tecnologia de origem** Um dos seguintes: + Um banco de dados Oracle on-premises + Um banco de dados Oracle em uma EC2 instância + Instância de banco de dados do Amazon RDS para Oracle **Pilha de tecnologias de destino** + Qualquer banco de dados Amazon RDS ou Amazon Aurora **Arquitetura de destino** Para obter informações sobre o processo completo de migração, consulte o padrão [Migrar um banco de dados Oracle para o Aurora PostgreSQL usando o AWS DMS e o AWS SCT](https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/migrate-an-oracle-database-to-aurora-postgresql-using-aws-dms-and-aws-sct.html). **Automação e escala** Se você tiver vários bancos de dados Oracle para migrar e quiser usar métricas de desempenho adicionais, poderá automatizar o processo seguindo as etapas descritas na postagem do blog [Instâncias do Amazon RDS do tamanho certo em escala com base nas métricas de desempenho da Oracle](https://aws.amazon.com/blogs/database/right-sizing-amazon-rds-instances-at-scale-based-on-oracle-performance-metrics/). ## Ferramentas + O [Oracle Automatic Workload Repository (AWR)](https://docs.oracle.com/en-us/iaas/performance-hub/doc/awr-report-ui.html) é um repositório incorporado aos bancos de dados Oracle. Ele coleta e armazena periodicamente a atividade do sistema e os dados da workload, que são então analisados pelo Automatic Database Diagnostic Monitor (ADDM). O AWR tira snapshots dos dados de desempenho do sistema periodicamente (por padrão, a cada 60 minutos) e armazena as informações (por padrão, até 8 dias).  Você pode usar visualizações e relatórios do AWR para analisar esses dados. ## Práticas recomendadas + Para calcular os requisitos de recursos para seu banco de dados de destino, você pode usar um único relatório AWR, vários relatórios AWR ou visualizações dinâmicas do AWR. Recomendamos que você use vários relatórios AWR durante o período de pico de carga para estimar os recursos necessários para lidar com esses picos de carga. Além disso, as exibições dinâmicas fornecem mais pontos de dados que ajudam a calcular os requisitos de recursos com mais precisão.  + Você deve estimar o IOPS somente para o banco de dados que planeja migrar, não para outros bancos de dados e processos que usam o disco. + Para calcular o quanto I/O está sendo usado pelo banco de dados, não use as informações na seção Perfil de carga do relatório AWR. Em vez disso, use a seção I/O Perfil, se estiver disponível, ou vá para a seção Estatísticas de atividade da instância e veja os valores totais das operações físicas de leitura e gravação. + Ao estimar a utilização da CPU, recomendamos que você use o método de métricas do banco de dados em vez das estatísticas do sistema operacional (SO), porque ele se baseia na CPU usada somente pelos bancos de dados. (As estatísticas do SO também incluem o uso da CPU por outros processos.) Você também deve verificar as recomendações relacionadas à CPU no relatório ADDM para melhorar o desempenho após a migração. + Considere os limites de taxa de I/O transferência ― taxa de transferência do Amazon Elastic Block Store (Amazon EBS) e taxa de transferência de rede ― para o tamanho específico da instância ao determinar o tipo certo de instância. + Execute o teste de desempenho antes da migração para validar o tamanho do mecanismos. ## Épicos ### Crie um relatório AWR | Tarefa | Description | Habilidades necessárias | | --- | --- | --- | | Ative o relatório AWR. | Para ativar o relatório, siga as instruções na [documentação da Oracle](https://docs.oracle.com/en/database/oracle/oracle-database/18/tgdba/gathering-database-statistics.html#GUID-26D359FA-F809-4444-907C-B5AFECD9AE29). | DBA | | Verifique o período de retenção. | Para verificar o período de retenção do relatório do AWR, use a consulta a seguir.
SQL> SELECT snap_interval,retention FROM dba_hist_wr_control;
| DBA | | Gere o snapshot. | Se o intervalo do snapshot do AWR não for granular o suficiente para capturar o pico da workload, você poderá gerar o relatório do AWR manualmente. Para gerar o snapshot manual do AWR, use a consulta a seguir.
SQL> EXEC dbms_workload_repository.create_snapshot;
| DBA | | Confira os snapshots recentes. | Para verificar snapshots recentes do AWR, use a consulta a seguir.
SQL> SELECT snap_id, to_char(begin_interval_time,'dd/MON/yy hh24:mi') Begin_Interval,
 to_char(end_interval_time,'dd/MON/yy hh24:mi') End_Interval
 FROM dba_hist_snapshot
 ORDER BY 1;
| DBA | ### Estime os I/O requisitos de disco | Tarefa | Description | Habilidades necessárias | | --- | --- | --- | | Escolha um método. | O IOPS é a medida padrão das operações de entrada e saída por segundo em um dispositivo de armazenamento e inclui operações de leitura e gravação. 
Se você estiver migrando um banco de dados local para a AWS, precisará determinar o pico de disco I/O usado pelo banco de dados. Você pode usar os seguintes métodos para estimar o disco do I/O seu banco de dados de destino:[See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/patterns/estimate-the-amazon-rds-engine-size-for-an-oracle-database-by-using-awr-reports.html)
As etapas a seguir descrevem esses quatro métodos. | DBA | | Opção 1: use o perfil de carga. | A tabela a seguir mostra um exemplo da seção Perfil de carga do relatório AWR.Para obter informações mais precisas, recomendamos que você use a opção 2 (perfis de E/S) ou a opção 3 (estatísticas de atividade da instância), em vez do perfil de carga.[See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/patterns/estimate-the-amazon-rds-engine-size-for-an-oracle-database-by-using-awr-reports.html)
Com base nessas informações, você pode calcular IOPs e gerar a taxa de transferência da seguinte forma:
*IOPS = Solicitações de leitura: \+ I/O Solicitações de gravação I/O = 3.586,8 \+ 574,7 = 4134,5*
*   Throughput = leitura física (blocos) \+ Gravação física (blocos) = 13.575,1 \+ 3.467,3 = 17.042,4*
Como o tamanho do bloco no Oracle é de 8 KB, você pode calcular a throughput total da seguinte forma:
*   A throughput total em MB é 17.042,4 \* 8 \* 1024/1024/1024 = 133,2 MB*Não use o perfil de carga para estimar o tamanho da instância. Não é tão preciso quanto as estatísticas ou os I/O perfis de atividades da instância. | DBA | | Opção 2: use estatísticas de atividade da instância. | Se você estiver usando uma versão do banco de dados Oracle anterior à 12c, poderá usar a seção Estatísticas de atividade da instância do relatório AWR para estimar o IOPS e a throughput. A tabela a seguir mostra um exemplo dessa seção.[See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/patterns/estimate-the-amazon-rds-engine-size-for-an-oracle-database-by-using-awr-reports.html)
Com base nessas informações, você pode calcular o total de IOPs e a throughput da seguinte forma:
*   IOPS total = 3.610,28 \+ 757,11 = 4.367*
*   Total de Mbps = 114.482.426,26 \+ 36.165.631,84 = 150.648.058,1/1024/1024 = 143 Mbps* | DBA | | Opção 3: usar I/O perfis. | No Oracle Database 12c, o relatório AWR inclui uma seção de I/O Perfis que apresenta todas as informações em uma única tabela e fornece dados mais precisos sobre o desempenho do banco de dados. A tabela a seguir mostra um exemplo dessa seção.[See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/patterns/estimate-the-amazon-rds-engine-size-for-an-oracle-database-by-using-awr-reports.html)
Essa tabela fornece os seguintes valores de throughput e IOPS total:
*   Throughput = 143 MBPS (da quinta linha, rotulada como Total, segunda coluna)*
*   IOPS = 4.367,4 (da primeira linha, chamada Total de solicitações, segunda coluna)* | DBA | | Opção 4: usar visualizações AWR. | Você pode ver as mesmas informações de IOPS e throughput usando visualizações do AWR. Para obter essas informações, use a seguinte consulta: 
break on report
 compute sum of Value on report
 select METRIC_NAME,avg(AVERAGE) as "Value"
 from dba_hist_sysmetric_summary
 where METRIC_NAME in ('Physical Read Total IO Requests Per Sec','Physical Write Total IO Requests Per Sec')
 group by metric_name;
| DBA | |   | Por Segundo | Por Transação | Por Executivo | Por Chamada | | --- |--- |--- |--- |--- | | **Tempo(s) de banco de dados:** | 26,6 | 0.2 | 0,00 | 0,02 | | **CPU(s) de banco de dados:** | 18,0 | 0.1 | 0,00 | 0,01 | | **CPU(s) de fundo:** | 0.2 | 0.0 | 0,00 | 0,00 | | **Tamanho do redo (bytes):** | 2.458.539,9 | 17.097,5 |   |   | | **Leitura lógica (blocos):** | 3.371.931,5 | 23.449,6 |   |   | | **Bloquear alterações:** | 21.643,5 | 150,5 |   |   | | **Leitura física (blocos):** | 13.575,1 | 94,4 |   |   | | **Gravação física (blocos):** | 3.467,3 | 24,1 |   |   | | **Leia as solicitações de IO:** | 3.586,8 | 24,9 |   |   | | **Solicitações de gravação:** | 574,7 | 4,0 |   |   | | **IO de leitura (MB):** | 106.1 | 0.7 |   |   | | **Escreva IO (MB):** | 27.1 | 0.2 |   |   | | **Linhas de verificação de mensagens instantâneas:** | 0.0 | 0.0 |   |   | | **Mensagem instantânea de leitura lógica da sessão:** |   |   |   |   | | **Chamadas de usuários** | 1.245,7 | 8.7 |   |   | | **Análises (SQL):** | 4.626,2 | 32.2 |   |   | | **Análises físicas (SQL):** | 8.9 | 0.1 |   |   | | **Área de trabalho SQL (MB):** | 824,9 | 5.7 |   |   | | **Log on:** | 1,7 | 0.0 |   |   | | **Executa (SQL):** | 136.656,5 | 950,4 |   |   | | **Reversões:** | 22,9 | 0.2 |   |   | | **Transações:** | 143,8 |   |   |   | | Estatística | Total | por Segundo | por Trans | | --- |--- |--- |--- | | **leitura física total de solicitações de E/S** | 2.547.333.217 | 3.610,28 | 25.11 | | **total de bytes de leitura física** | 80.776.296.124.928 | 114.482.426,26 | 796.149,98 | | **gravação física total de solicitações de E/S** | 534.198.208 | 757,11 | 5.27 | | **total de bytes de gravação física** | 25.517.678.849.024 | 36.165.631,84 | 251.508,18 | |   | Leitura \+ gravação por segundo | Leituras por Segundo | Gravações por Segundo | | --- |--- |--- |--- | | **Total de solicitações:** | 4.367,4 | 3.610,3 | 757,1 | | **Solicitações de banco de dados:** | 4.161,5 | 3.586,8 | 574,7 | | **Solicitações otimizadas:** | 0.0 | 0.0 | 0.0 | | **Solicitações para refazer:** | 179,3 | 2.8 | 176,6 | | **Total (MB):** | 143,7 | 109.2 | 34,5 | | **Banco de dados (MB):** | 133.1 | 106.1 | 27.1 | | **Total otimizado (MB):** | 0.0 | 0.0 | 0.0 | | **Refazer (MB):** | 7.6 | 2.7 | 4,9 | | **Banco de dados (blocos):** | 17.042,4 | 13.575,1 | 3.467,3 | | **Por meio do Buffer de Cache (blocos):** | 5.898,5 | 5.360,9 | 537,6 | | **Direto (blocos):** | 11.143,9 | 8.214,2 | 2.929,7 | ### Estime os requisitos de CPU | Tarefa | Description | Habilidades necessárias | | --- | --- | --- | | Escolha um método. | Você pode estimar a CPU necessária para o banco de dados de destino de três maneiras:[See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/patterns/estimate-the-amazon-rds-engine-size-for-an-oracle-database-by-using-awr-reports.html)
Se você estiver analisando núcleos utilizados, recomendamos usar o método de métricas do banco de dados em vez das estatísticas do SO, pois ele se baseia na CPU usada somente pelos bancos de dados que você planeja migrar. (As estatísticas do SO também incluem o uso da CPU por outros processos.) Você também deve verificar as recomendações relacionadas à CPU no relatório ADDM para melhorar o desempenho após a migração.
Você também pode estimar os requisitos com base na geração da CPU. Se você estiver usando diferentes gerações de CPU, poderá estimar a CPU necessária do banco de dados de destino seguindo as instruções no whitepaper [Desmistificando o número de v CPUs para um desempenho ideal da carga de](https://d1.awsstatic.com/whitepapers/Demystifying_vCPUs.df200b766578b75009ad8d15c72e493d6408c68a.pdf) trabalho. | DBA | | Opção 1: estimar os requisitos com base nos núcleos disponíveis. | Nos relatórios do AWR:[See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/patterns/estimate-the-amazon-rds-engine-size-for-an-oracle-database-by-using-awr-reports.html)
Você pode estimar os núcleos disponíveis de duas maneiras:[See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/patterns/estimate-the-amazon-rds-engine-size-for-an-oracle-database-by-using-awr-reports.html)
**Para estimar os núcleos disponíveis usando comandos do sistema operacional**
Use o comando a seguir para contar os núcleos no processador.
$ cat /proc/cpuinfo |grep "cpu cores"|uniq
cpu cores    : 4
cat /proc/cpuinfo | egrep "core id|physical id" | tr -d "\n" | sed s/physical/\\nphysical/g | grep -v ^$ | sort | uniq | wc -l

Use o comando a seguir para contar os soquetes no processador.
grep "physical id" /proc/cpuinfo | sort -u
  physical id     : 0
  physical id     : 1
  Não recomendamos o uso de comandos do sistema operacional, como **nmon** e **sar**, para extrair a utilização da CPU. Isso ocorre porque esses cálculos incluem a utilização da CPU por outros processos e podem não refletir a CPU real usada pelo banco de dados.
**Para estimar os núcleos disponíveis usando o relatório AWR**
Você também pode derivar a utilização da CPU na primeira seção do relatório AWR. Veja um trecho do relatório.[See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/patterns/estimate-the-amazon-rds-engine-size-for-an-oracle-database-by-using-awr-reports.html)
Neste exemplo, a CPUs contagem é 80, o que indica que elas são lógicas (virtuais) CPUs. Você também pode ver que essa configuração tem dois soquetes, um processador físico em cada soquete (para um total de dois processadores físicos) e 40 núcleos para cada processador ou soquete físico.  | DBA | | Opção 2: estimar a utilização da CPU usando estatísticas do sistema operacional. | Você pode verificar as estatísticas de uso da CPU do sistema operacional diretamente no sistema operacional (usando **sar** ou outro utilitário do SO host) ou revisando os valores de IDLE/ (IDLE\+BUSY) na seção Estatísticas do sistema operacional do relatório AWR. Você pode ver os segundos de CPU consumidos diretamente de **v$osstat**. Os relatórios AWR e Statspack também mostram esses dados na seção Estatísticas do sistema operacional.
Se houver vários bancos de dados na mesma caixa, todos eles terão os mesmos valores de **v$osstat** para BUSY\_TIME.[See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/patterns/estimate-the-amazon-rds-engine-size-for-an-oracle-database-by-using-awr-reports.html)
Se não houver outros grandes consumidores de CPU no sistema, use a fórmula a seguir para calcular a porcentagem de utilização da CPU:
*   Utilização = Tempo de ocupação/Tempo total*
*   Tempo ocupado = requisitos = v$OSStat.BUSY\_TIME*
*   C = Tempo total (ocupado \+ ocioso)*
*   C = capacidade = v$ostat.BUSY\_TIME \+ v$ostat.IDLE\_TIME*
*   Utilização = BUSY\_TIME/(BUSY\_TIME \+ IDLE\_TIME)*
*      = -1.305.569.937/(1.305.569.937 \+ 4.312.718.839)*
*      = 23% utilizados* | DBA | | Opção 3: estimar a utilização da CPU usando métricas de banco de dados. | Se vários bancos de dados estiverem em execução no sistema, você poderá usar as métricas do banco de dados que aparecem no início do relatório.[See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/patterns/estimate-the-amazon-rds-engine-size-for-an-oracle-database-by-using-awr-reports.html)
Para obter métricas de utilização da CPU, use esta fórmula:
*   Uso da CPU do banco de dados (porcentagem da energia da CPU disponível) = tempo de CPU/NUM\_CPUS/tempo decorrido*
onde o uso da CPU é descrito pelo *tempo da CPU* e representa o tempo gasto na CPU, não o tempo de espera pela CPU. Esse cálculo resulta em:
*   = 312.625,40/11.759,64/80 = 33% da CPU está sendo usada*
*   Número de núcleos (33%) \* 80 = 26,4 núcleos*
*   Total de núcleos = 26,4 \* (120%) = 31,68 núcleos*
Você pode usar o maior desses dois valores para calcular a utilização da CPU da instância de banco de dados Amazon RDS ou Aurora.No IBM AIX, a utilização calculada não corresponde aos valores do sistema operacional ou do banco de dados. Esses valores coincidem em outros sistemas operacionais. | DBA | | Nome do banco de dados | ID do banco de dados | Instância | Insira um número | Horário de início | Versão | RAC | | --- |--- |--- |--- |--- |--- |--- | | XXXX | | XXXX | 1 | 05 de setembro de 2020 23:09 | 12.1.0.2.0 | NÃO | | **Nome do host** | **Plataforma** | **CPUs** | **Núcleos** | **Soquetes** | **Memória (GB)** | | | Linux x86 de 64 bits | 80 | 80 | 2 | 441,78 | | Estatística | Valor | Valor final | | --- |--- |--- | | **FREE\_MEMORY\_BYTES** | 6.810.677.248 | 12.280.799.232 | | **INACTIVE\_MEMORY\_BYTES** | 175.627.333.632 | 160.380.653.568 | | **SWAP\_FREE\_BYTES** | 17.145.614.336 | 17.145.872.384 | | **BUSY\_TIME** | 1.305.569.937 |   | | **IDLE\_TIME** | 4.312.718.839 |   | | **IOWAIT\_TIME** | 53.417.174 |   | | **NICE\_TIME** | 29.815 |   | | **SYS\_TIME** | 148.567.570 |   | | **USER\_TIME** | 1.146.918.783 |   | | **LOAD** | 25 | 29 | | **VM\_EM\_BYTES** | 593.920 |   | | **VM\_OUT\_BYTES** | 327.680 |   | | **PHYSICAL\_MEMORY\_BYTES** | 474.362.417.152 |   | | **NUM\_CPUS** | 80 |   | | **NUM\_CPU\_NÚCLEOS** | 80 |   | | **NUM\_CPU\_SOCKETS** | 2 |   | | **GLOBAL\_RECEIVE\_SIZE\_MAX** | 4.194.304 |   | | **GLOBAL\_SEND\_SIZE\_MAX** | 2.097.152 |   | | **TCP\_RECEIVE\_SIZE\_DEFAULT** | 87.380 |   | | **TCP\_RECEIVE\_SIZE\_MAX** | 6.291.456 |   | | **TCP\_RECEIVE\_SIZE\_MIN** | 4.096 |   | | **TCP\_SEND\_SIZE\_DEFAULT** | 16.384 |   | | **TCP\_SEND\_SIZE\_MAX** | 4.194.304 |   | | **TCP\_SEND\_SIZE\_MIN** | 4.096 |   | |   | Snap Id | Tempo do snap | Sessões | Cursores/Sessão | | --- |--- |--- |--- |--- | | **Comece o Snap:** | 18462 | 28-Set-20 09:00:42 | 1226 | 35,8 | | **Fim do Snap:** | 18546 | 06-Out-20 13:00:20 | 1876 | 41.1 | | **Decorrido:** |   | 11.759,64 (minutos) |   |   | | **Tempo de banco de dados:** |   | 312.625,40 (minutos) |   |   | ### Estime os requisitos de memória | Tarefa | Description | Habilidades necessárias | | --- | --- | --- | | Estime os requisitos de memória usando estatísticas de memória. | Você pode usar o relatório AWR para calcular a memória do banco de dados de origem e combiná-la com o banco de dados de destino. Você também deve verificar o desempenho do banco de dados existente e reduzir seus requisitos de memória para economizar custos ou aumentar seus requisitos para melhorar o desempenho. Isso requer uma análise detalhada do tempo de resposta do AWR e do Acordo de Serviço (SLA) (SLA) do aplicativo. Use a soma do uso da área global do sistema Oracle (SGA) e da área global do programa (PGA) como a utilização de memória estimada para o Oracle. Adicione 20% a mais para o sistema operacional para determinar um requisito de tamanho de memória alvo. Para o Oracle RAC, use a soma da utilização estimada da memória em todos os nós do RAC e reduza a memória total, pois ela está armazenada em blocos comuns.[See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/patterns/estimate-the-amazon-rds-engine-size-for-an-oracle-database-by-using-awr-reports.html)
*Memória total da instância em uso = SGA \+ PGA = 220 GB \+ 45 GB = 265 GB*
Adicionar 20% do buffer:
*Memória total da instância = 1,2 \* 265 GB = 318 GB*
Como a SGA e a PGA representam 70% da memória do host, o requisito total de memória é: 
*Memória total do host = 318/0,7 = 464 GB*Quando você migra para o Amazon RDS para Oracle, a PGA e a SGA são pré-calculadas com base em uma fórmula predefinida. Certifique-se de que os valores pré-calculados estejam próximos às suas estimativas. | DBA | | Porcentagem de buffer sem espera: | 99,99 | NoWait % de refazer: | 100,00 | | --- |--- |--- |--- | | **% de impacto no buffer:** | 99,84 | **Porcentagem de classificação na memória:** | 100,00 | | **Porcentagem de acertos na bibliotecas** | 748,77 | **Porcentagem de análise flexível**: | 99,81 | | **Porcentagem de executar para analisar:** | 96,61 | **Porcentagem de latch hit:** | 100,00 | | **Porcentagem de análise de CPU para análise decorrida:** | 72,73 | **Porcentagem de CPU sem análise:** | 99,21 | | **Porcentagem de acertos de flash cache:** | 0,00 |   |   | |   | Início | Fim | | --- |--- |--- | | **Memória do host (MB):** | 452.387,3 | 452.387,3 | | **Uso da SGA (MB):** | 220.544,0 | 220.544,0 | | **Uso do PGA (MB):** | 36.874,9 | 45.270,0 | ### Determine o tipo de instância de banco de dados do banco de dados de destino | Tarefa | Description | Habilidades necessárias | | --- | --- | --- | | Determine o tipo de instância de banco de dados com base nas estimativas de E/S de disco, CPU e memória. | Com base nas estimativas das etapas anteriores, a capacidade do banco de dados Amazon RDS ou Aurora de destino deve ser:[See the AWS documentation website for more details](http://docs.aws.amazon.com/pt_br/prescriptive-guidance/latest/patterns/estimate-the-amazon-rds-engine-size-for-an-oracle-database-by-using-awr-reports.html)
No banco de dados Amazon RDS ou Aurora de destino, você pode mapear esses valores para o tipo de instância db.r5.16xlarge, que tem uma capacidade de 32 núcleos, 512 GB de RAM e 13.600 Mbps de throughput. Para obter mais informações, consulte a postagem no blog da AWS. Use o [tamanho certo de instâncias do Amazon RDS em uma escala com base nas métricas de desempenho da Oracle](https://aws.amazon.com/blogs/database/right-sizing-amazon-rds-instances-at-scale-based-on-oracle-performance-metrics/). | DBA | ## Recursos relacionados + [Classe de instância de banco de dados Aurora (documentação](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/Concepts.DBInstanceClass.html) do Amazon Aurora) + [armazenamento de instância de banco de dados do Amazon RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/CHAP_Storage.html) (documentação do Amazon RDS) + [Ferramenta AWS Miner](https://github.com/tmuth/AWR-Miner/blob/master/release/5.0.8/AWR-Miner-capture-5.0.8/awr_miner.sql) (GitHub repositório)