![\"AWR:](\"\/wp-content\/uploads\/2020\/09\/b0ca997a4bd415723ae56c183e2dd42f.jpeg\")
<\/p>\nNeste pequeno post, gostaria de esclarecer um mal-entendido relacionado \u00e0 an\u00e1lise de bancos de dados AWR que operam em Oracle Exadata. H\u00e1 quase 10 anos, constantemente me deparo com a pergunta: qual \u00e9 a contribui\u00e7\u00e3o do Exadata Software para o desempenho? Ou utilizando palavras rec\u00e9m-criadas: quanto uma base de dados \"exadatiza\" seu funcionamento?<\/p>\n
<\/p>\n
Frequentemente, a essa pergunta correta, na minha opini\u00e3o, \u00e9 dada uma resposta incorreta com refer\u00eancia \u00e0s estat\u00edsticas do AWR. Nela, \u00e9 apresentado o m\u00e9todo de espera do sistema, que considera o tempo de resposta como a soma do tempo de opera\u00e7\u00e3o dos processadores (DB CPU) e o tempo de espera de v\u00e1rias classes.<\/p>\n
Com o surgimento do Exadata, a estat\u00edstica do AWR passou a incluir esperas de sistema espec\u00edficas relacionadas ao funcionamento do Exadata Software. Normalmente, os nomes dessas esperas come\u00e7am com a palavra \u201ccell\u201d (o servidor de armazenamento Exadata \u00e9 chamado de c\u00e9lula), sendo mais comuns as esperas com nomes significativos como \u201ccell smart table scan\u201d, \u201ccell multiblock physical read\u201d e \u201ccell single block physical read\u201d.<\/p>\n
Na maioria das vezes, a propor\u00e7\u00e3o dessas esperas do Exadata no tempo total de resposta \u00e9 baixa, e, portanto, elas nem aparecem na se\u00e7\u00e3o Top10 Foreground Events by Total Wait Time (neste caso, \u00e9 preciso procur\u00e1-las na se\u00e7\u00e3o Foreground Wait Events). Com grande dificuldade, encontramos um exemplo de AWR di\u00e1rio de nossos clientes, no qual as esperas do Exadata figuravam na se\u00e7\u00e3o Top10 e, no total, representaram cerca de 5%:<\/p>\n
Evento<\/strong><\/p>\n Esperas<\/strong><\/p>\n Tempo Total de Espera (segundos)<\/strong><\/p>\n Esperas M\u00e9dias<\/strong><\/p>\n % do tempo de DB<\/strong><\/p>\n Classe de Espera<\/strong><\/p>\n DB CPU<\/p>\n <\/p>\n 115.2K<\/p>\n <\/p>\n 70.4<\/p>\n <\/p>\n SQL*Net mais dados do dblink<\/p>\n 670,196<\/p>\n 5471.5<\/p>\n 8.16ms<\/p>\n 3.3<\/p>\n Rede<\/p>\n cell single block physical read<\/p>\n 5,661,452<\/p>\n 3827.6<\/p>\n 676.07us<\/p>\n 2.3<\/p>\n Usu\u00e1rio I\/O<\/p>\n Sync ASM rebalance<\/p>\n 4,350,012<\/p>\n 3481.3<\/p>\n 800.30us<\/p>\n 2.1<\/p>\n Outros<\/p>\n cell multiblock physical read<\/p>\n 759,885<\/p>\n 2252<\/p>\n 2.96ms<\/p>\n 1.4<\/p>\n Usu\u00e1rio I\/O<\/p>\n direct path read<\/p>\n 374,368<\/p>\n 1811.3<\/p>\n 4.84ms<\/p>\n 1.1<\/p>\n Usu\u00e1rio I\/O<\/p>\n SQL*Net mensagem do dblink<\/p>\n 7,983<\/p>\n 1725<\/p>\n 216.08ms<\/p>\n 1.1<\/p>\n Rede<\/p>\n cell smart table scan<\/p>\n 1,007,520<\/p>\n 1260.7<\/p>\n 1.25ms<\/p>\n 0.8<\/p>\n Usu\u00e1rio I\/O<\/p>\n direct path read temp<\/p>\n 520,211<\/p>\n 808.4<\/p>\n 1.55ms<\/p>\n 0.5<\/p>\n Usu\u00e1rio I\/O<\/p>\n enq: TM \u2014 conten\u00e7\u00e3o<\/p>\n 652<\/p>\n 795.8<\/p>\n 1220.55ms<\/p>\n 0.5<\/p>\n Aplica\u00e7\u00e3o<\/p>\n A partir de tais estat\u00edsticas do AWR, muitas conclus\u00f5es incorretas s\u00e3o frequentemente tiradas:<\/p>\n 1. A contribui\u00e7\u00e3o da magia Exadata para o desempenho do banco de dados \u00e9 baixa \u2014 n\u00e3o ultrapassa 5%, e o banco de dados \"exadatis\" mal.<\/p>\n 2. Se esse banco de dados for transferido do Exadata para uma arquitetura cl\u00e1ssica de \"servidor + array\", o desempenho n\u00e3o mudar\u00e1 muito. Porque mesmo que esse array seja tr\u00eas vezes mais lento que o sistema de armazenamento Exadata (o que \u00e9 pouco prov\u00e1vel para arrays All Flash modernos), multiplicando 5% por tr\u00eas, teremos um aumento na parte de espera de I\/O para 15% \u2014 um banco de dados certamente suportar\u00e1 isso!<\/p>\n Ambas essas sa\u00eddas s\u00e3o imprecisas e, al\u00e9m disso, distorcem a compreens\u00e3o da ideia contida no Exadata Software. O Exadata n\u00e3o apenas proporciona uma entrada e sa\u00edda r\u00e1pida, mas funciona de maneira fundamentalmente diferente em compara\u00e7\u00e3o com a arquitetura cl\u00e1ssica de \"servidor + armazenamento\". Se uma base de dados realmente 'exadatiza' - ent\u00e3o a l\u00f3gica SQL \u00e9 transferida para o sistema de armazenamento. Storage servidores<\/a> gra\u00e7as a uma s\u00e9rie de mecanismos especiais (em primeiro lugar os Exadata Storage Indexes, mas n\u00e3o apenas) encontram os dados necess\u00e1rios e os enviam para os servidores DB. Eles fazem isso de forma bastante eficiente, portanto, a propor\u00e7\u00e3o de esperas caracter\u00edsticas do Exadata no tempo de resposta geral \u00e9 baixa. <\/p>\n Como essa propor\u00e7\u00e3o mudar\u00e1 fora do Exadata? Como isso afetar\u00e1 o desempenho da base de dados como um todo? O melhor jeito de responder a essas perguntas \u00e9 atrav\u00e9s 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\u00edda consuma todo o tempo de resposta e o desempenho piore dramaticamente. \u00c9 por isso que \u00e9 incorreto, ao analisar o AWR, considerar a porcentagem total de esperas do Exadata como uma contribui\u00e7\u00e3o da sua m\u00e1gica 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', \u00e9 necess\u00e1rio estudar as estat\u00edsticas da se\u00e7\u00e3o 'Instance Activity Stats' do AWR (onde h\u00e1 muitas estat\u00edsticas com nomes esclarecedores) e compar\u00e1-las entre si.<\/p>\n E para entender como a base de dados se comportar\u00e1 fora do Exadata, a melhor maneira \u00e9 fazer um clone da base a partir do backup na arquitetura alvo e analisar o desempenho desse clone sob carga. Normalmente, os propriet\u00e1rios do Exadata t\u00eam essa possibilidade.<\/p>\n