Neste pequeno post, gostaria de esclarecer um mal-entendido relacionado à análise de bancos de dados AWR que operam em Oracle Exadata. Há quase 10 anos, constantemente me deparo com a pergunta: qual é a contribuição do Exadata Software para o desempenho? Ou utilizando palavras recém-criadas: quanto uma base de dados "exadatiza" seu funcionamento?
Frequentemente, a essa pergunta correta, na minha opinião, é dada uma resposta incorreta com referência às estatísticas do AWR. Nela, é apresentado o método de espera do sistema, que considera o tempo de resposta como a soma do tempo de operação dos processadores (DB CPU) e o tempo de espera de várias classes.
Com o surgimento do Exadata, a estatística do AWR passou a incluir esperas de sistema específicas relacionadas ao funcionamento do Exadata Software. Normalmente, os nomes dessas esperas começam com a palavra “cell” (o servidor de armazenamento Exadata é chamado de célula), sendo mais comuns as esperas com nomes significativos como “cell smart table scan”, “cell multiblock physical read” e “cell single block physical read”.
Na maioria das vezes, a proporção dessas esperas do Exadata no tempo total de resposta é baixa, e, portanto, elas nem aparecem na seção Top10 Foreground Events by Total Wait Time (neste caso, é preciso procurá-las na seção Foreground Wait Events). Com grande dificuldade, encontramos um exemplo de AWR diário de nossos clientes, no qual as esperas do Exadata figuravam na seção Top10 e, no total, representaram cerca de 5%:
Evento
Esperas
Tempo Total de Espera (segundos)
Esperas Médias
% do tempo de DB
Classe de Espera
DB CPU
115.2K
70.4
SQL*Net mais dados do dblink
670,196
5471.5
8.16ms
3.3
Rede
cell single block physical read
5,661,452
3827.6
676.07us
2.3
Usuário I/O
Sync ASM rebalance
4,350,012
3481.3
800.30us
2.1
Outros
cell multiblock physical read
759,885
2252
2.96ms
1.4
Usuário I/O
direct path read
374,368
1811.3
4.84ms
1.1
Usuário I/O
SQL*Net mensagem do dblink
7,983
1725
216.08ms
1.1
Rede
cell smart table scan
1,007,520
1260.7
1.25ms
0.8
Usuário I/O
direct path read temp
520,211
808.4
1.55ms
0.5
Usuário I/O
enq: TM — contenção
652
795.8
1220.55ms
0.5
Aplicação
A partir de tais estatísticas do AWR, muitas conclusões incorretas são frequentemente tiradas:
1. A contribuição da mágica do Exadata para o desempenho do banco de dados não é alta — não ultrapassa 5%, e o banco de dados "exadatiza" mal.
2. Se esse banco de dados for transferido de Exadata para uma arquitetura clássica de "servidor + array", o desempenho mudará pouco. Pois mesmo que esse array se revele três vezes mais lento que o sistema de armazenamento Exadata (o que é quase impossível para arrays All Flash modernos), multiplicando 5% por três obteremos um aumento na proporção de esperas de entrada e saída para 15% — esse banco de dados certamente sobreviverá!
Ambas essas saídas são imprecisas e, além disso, distorcem a compreensão da ideia contida no Exadata Software. O Exadata não apenas proporciona uma entrada e saída rápida, mas funciona de maneira fundamentalmente diferente em comparação com a arquitetura clássica de "servidor + armazenamento". Se uma base de dados realmente 'exadatiza' - então a lógica SQL é transferida para o sistema de armazenamento. Storage servidores graças a uma série de mecanismos especiais (em primeiro lugar os Exadata Storage Indexes, mas não apenas) encontram os dados necessários e os enviam para os servidores DB. Eles fazem isso de forma bastante eficiente, portanto, a proporção de esperas características do Exadata no tempo de resposta geral é baixa.
Como essa proporção mudará fora do Exadata? Como isso afetará o desempenho da base de dados como um todo? O melhor jeito de responder a essas perguntas é através de testes. Por exemplo, a espera 'cell smart table scan' fora do Exadata pode se transformar em um pesado Table Full Scan, de modo que a entrada e saída consuma todo o tempo de resposta e o desempenho piore dramaticamente. É por isso que é incorreto, ao analisar o AWR, considerar a porcentagem total de esperas do Exadata como uma contribuição da sua mágica para o desempenho e, ainda mais, usar essa porcentagem para prever o desempenho fora do Exadata. Para entender o quanto o trabalho da base 'exadatiza', é necessário estudar as estatísticas da seção 'Instance Activity Stats' do AWR (onde há muitas estatísticas com nomes esclarecedores) e compará-las entre si.
E para entender como a base de dados se comportará fora do Exadata, a melhor maneira é fazer um clone da base a partir do backup na arquitetura alvo e analisar o desempenho desse clone sob carga. Normalmente, os proprietários do Exadata têm essa possibilidade.
Autor: Aleksey Struchenko, chefe da área de BD da 'Infossistemas Jet'
Fonte: habr.com
