Estime o tamanho do mecanismo Amazon RDS para um banco de dados Oracle usando relatórios AWR - Recomendações da AWS
ResumoPré-requisitos e limitaçõesArquiteturaFerramentasPráticas recomendadasÉpicosRecursos relacionados

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

Criado por Abhishek Verma (AWS) e Eduardo Valentim (AWS)

Ambiente: produção

Origem: banco de dados Oracle

Destino: Amazon RDS ou Amazon Aurora.

Tipo R: redefinir arquitetura

Workload: Oracle

Tecnologias: banco de dados; migração

Serviços da AWS: Amazon RDS; Amazon Aurora

Resumo

Quando você migra um banco de dados Oracle para o Amazon Relational Database Service (Amazon RDS) ou Amazon Aurora, computar a CPU, a memória e a E/S de disco para o 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 do Oracle de origem pode ser on-premises, uma instância do Amazon Elastic Compute Cloud (Amazon EC2), ou pode ser uma instância de banco de dados do Amazon RDS para Oracle. O banco de dados de destino pode ser qualquer banco de dados Amazon RDS ou Aurora.

Observação: 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 instância do EC2

  • Instância de banco de dados para o 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.

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.

Ferramentas

  • O Oracle Automatic Workload Repository (AWR) é 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 quanta E/S está sendo usada 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 Perfil de E/S, 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 throughput de E/S ― throughput do Amazon Elastic Block Store (Amazon EBS) e throughput 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

TarefaDescriçãoHabilidades necessárias

Ative o relatório AWR.

Para ativar o relatório, siga as instruções na documentação da Oracle.

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
TarefaDescriçãoHabilidades 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 on-premises para o AWS, precisará determinar o pico de E/S de disco usado pelo banco de dados. Você pode usar os seguintes métodos para estimar a E/S do disco para seu banco de dados de destino:

  • Seção de perfil de carga do relatório AWR

  • Seção Estatísticas de atividade da instância do relatório AWR (use esta seção para o Oracle Database 12c ou superior)

  • Seção Perfil de E/S do relatório AWR (use esta seção para versões do banco de dados Oracle anteriores à 12c)

  • Visualizações do AWR

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.

Importante: 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.

 

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

 

 

 

Com base nessas informações, você pode calcular o IOPs e throughput da seguinte forma:

IOPS = Solicitações de E/S de leitura: + Solicitações de E/S de gravaçã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 é 17042,4 * 8 * 1024/1024/1024 = 133,2 MB

Aviso: não use o perfil de carga para estimar o tamanho da instância. Ele não é tão preciso quanto as estatísticas de atividade da instância ou os perfis de E/S.

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.

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

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 = 4367

   Total de Mbps = 114.482.426,26 + 36.165.631,84 = 150648058,1/1024/1024 = 143 Mbps

DBA

Opção 3: usar perfis de E/S.

No banco de dados Oracle 12c, o relatório AWR inclui uma seção de Perfis de E/S 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.

 

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

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
TarefaDescriçãoHabilidades necessárias

Escolha um método.

Você pode estimar a CPU necessária para o banco de dados de destino de três maneiras:

  • Usando os núcleos reais disponíveis do processador

  • Usando os núcleos utilizados com base nas estatísticas do SO

  • Usando os núcleos utilizados com base nas estatísticas do banco de dados

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 vCPUs para um desempenho ideal da workload.

DBA

Opção 1: estimar os requisitos com base nos núcleos disponíveis.

Nos relatórios do AWR:

  • As CPUs se referem a CPUs lógicas e virtuais. 

  • Os núcleos são o número de processadores em um chipset físico de CPU. 

  • Um soquete é um dispositivo físico que conecta um chip a uma placa. Os processadores de vários núcleos têm soquetes com vários núcleos de CPU.

Você pode estimar os núcleos disponíveis de duas maneiras:

  • Usando os comandos de OS

  • Usando o relatório AWR

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

Observação: 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.

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

<DB_ID>

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)

<host_name>

Linux x86 de 64 bits

80

80

2

441,78

Neste exemplo, a contagem de CPUs é 80, o que indica que são CPUs lógicas (virtuais). 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.

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

 

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.

 

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)

 

 

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.

Nota: 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
TarefaDescriçãoHabilidades 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.

  1. Verifique as métricas na tabela de porcentagem de eficiência da instância. A tabela usa os seguintes termos:

    • A porcentagem de acertos no buffer é a porcentagem de vezes que um determinado bloco foi encontrado no cache do buffer em vez de realizar uma E/S física. Para um melhor desempenho, almeje 100 por cento. 

    • A porcentagem do buffer sem espera deve estar próxima de 100 por cento.

    • A porcentagem de Latch Hit deve estar próxima de 100 por cento. 

    • A porcentagem de CPU sem análise é a porcentagem do tempo de CPU gasto em atividades sem análise. Esse valor deve estar próximo de 100 por cento.

    Porcentagens de eficiência da instância (meta de 100%)

    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

    Porcentage 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

     

     

    Neste exemplo, todas as métricas parecem boas, então você pode usar a SGA e a PGA para o banco de dados existente como requisito de planejamento de capacidade.

  2. Verifique a seção de estatísticas de memória e calcule o SGA/PGA.

     

    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

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

Nota: 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
TarefaDescriçãoHabilidades 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:

  • 68 núcleos de CPU

  • 143 MBPS de throughput  

  • 4367 IOPS para E/S de disco

  • 464 GB de memória

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.

DBA

Recursos relacionados