Com esta breve postagem gostaria de dissipar um mal-entendido relacionado à análise de bancos de dados AWR executados no Oracle Exadata. Há quase 10 anos, tenho me deparado constantemente com a pergunta: qual a contribuição do Exadata Software para a produtividade? Ou usando palavras recém-cunhadas: quão “especializado” é o trabalho de um determinado banco de dados?
Muitas vezes esta pergunta correta, na minha opinião, é respondida incorretamente com referência às estatísticas AWR. Apresenta o método de espera do sistema, que trata o tempo de resposta como a soma do tempo de operação dos processadores (CPUs do banco de dados) e o tempo de espera das diversas classes.
Com o advento do Exadata, expectativas específicas do sistema relacionadas à operação do Exadata Software apareceram nas estatísticas do AWR. Via de regra, os nomes dessas esperas começam com a palavra “célula” (o servidor Exadata Storage é chamado de célula), das quais as mais comuns são esperas com os nomes autoexplicativos “cell smart table scan”, “cell multiblock leitura física” e “leitura física de bloco único de célula”.
Na maioria dos casos, a participação dessas esperas do Exadata no tempo total de resposta é pequena e, portanto, elas nem sequer se enquadram na seção Top10 Foreground Events by Total Wait Time (neste caso, você precisa procurá-las na seção Foreground Wait Seção Eventos). Com grande dificuldade, encontramos um exemplo de AWR diário de nossos clientes, em que as expectativas do Exadata foram incluídas na seção Top10 e no total somaram cerca de 5%:
Evento
Espera
Tempo total de espera (seg)
Média de espera
% tempo do banco de dados
Aula de espera
CPU do banco de dados
115.2K
70.4
SQL*Net mais dados do dblink
670,196
5471.5
8.16ms
3.3
Network
leitura física de bloco único de célula
5,661,452
3827.6
676.07us
2.3
E/S do usuário
Sincronizar reequilíbrio ASM
4,350,012
3481.3
800.30us
2.1
Outros
leitura física multibloco de célula
759,885
2252
2.96ms
1.4
E/S do usuário
leitura de caminho direto
374,368
1811.3
4.84ms
1.1
E/S do usuário
Mensagem SQL*Net do dblink
7,983
1725
216.08ms
1.1
Network
varredura de tabela inteligente de células
1,007,520
1260.7
1.25ms
0.8
E/S do usuário
temperatura de leitura de caminho direto
520,211
808.4
1.55ms
0.5
E/S do usuário
enq: TM - contenção
652
795.8
1220.55ms
0.5
Aplicação
As seguintes conclusões são frequentemente tiradas dessas estatísticas AWR:
1. A contribuição da magia do Exadata para o desempenho do banco de dados não é alta - não excede 5% e o banco de dados “exadatiza” mal.
2. Se esse banco de dados for transferido do Exadata para a arquitetura clássica “servidor + array”, o desempenho não mudará muito. Porque mesmo que esse array seja três vezes mais lento que o sistema de armazenamento Exadata (o que dificilmente é possível para arrays All Flash modernos), multiplicando 5% por três, obteremos um aumento na parcela de esperas de E/S para 15%. - o banco de dados certamente sobreviverá a isso!
Ambas as conclusões são imprecisas e, além disso, distorcem a compreensão da ideia por trás do Exadata Software. O Exadata não fornece apenas E/S rápida, ele funciona de maneira fundamentalmente diferente em comparação com a arquitetura clássica de servidor + array. Se a operação do banco de dados for realmente “exadaptada”, então a lógica SQL é transferida para o sistema de armazenamento. Os servidores de armazenamento, graças a uma série de mecanismos especiais (principalmente Exadata Storage Indexes, mas não apenas), encontram eles próprios os dados necessários e enviam o banco de dados aos servidores. Eles fazem isso com bastante eficiência, de modo que a parcela de esperas típicas do Exadata no tempo total de resposta é pequena.
Como esse compartilhamento mudará fora do Exadata? Como isso afetará o desempenho do banco de dados como um todo? Os testes responderão melhor a essas perguntas. Por exemplo, esperar por uma “varredura inteligente de tabela de células” fora do Exadata pode se transformar em uma varredura completa de tabela tão pesada que a E/S ocupa todo o tempo de resposta e o desempenho diminui drasticamente. É por isso que é errado, ao analisar o AWR, considerar a porcentagem total das expectativas do Exadata como a contribuição de sua mágica para o desempenho e, mais ainda, usar essa porcentagem para prever o desempenho fora do Exadata. Para entender o quão “exato” é o trabalho do banco de dados, você precisa estudar as estatísticas AWR da seção “Estatísticas de atividades de instância” (há muitas estatísticas com nomes autoexplicativos) e compará-las entre si.
E para entender como será um banco de dados fora do Exadata, é melhor fazer um clone do banco de dados a partir de um backup na arquitetura de destino e analisar o desempenho desse clone sob carga. Os proprietários do Exadata, via de regra, têm essa oportunidade.
Autor: Alexey Struchenko, chefe do departamento de banco de dados da Jet Infosystems
Fonte: habr.com