Siga em frente. Análise

Transcrição

1 Análise Siga em frente Compreender os planos de execução do banco de dados é a chave para avaliar o potencial máximo de uma query SQL ou estimar com efetividade as necessidades de recursos futuros. por Markus Winand O plano de execução (muitas vezes chamado de plano de execução (de queries), contém a trajetória do banco de dados para executar uma instrução SQL. Por exemplo, os planos de execução fornecem informações sobre quais índices são usados, em qual ordem ocorre o acesso às diversas tabelas, e quais algoritmos são utilizados para as uniões de tabelas, classificação e operações de agrupamento de resultados. Cláusula SQL Select... From... Where... Otimizador Plano de Execução Engine de execução Resultados QTY PRICE DATE Fase: Preparação Fase: Execução Figura 1 Fases na execução SQL. O plano de execução corresponde aproximadamente ao bytecode em linguagens de script como Perl ou Python é usado internamente para executar instruções SQL. A criação de um plano de execução é, por vezes, também conhecida como uma compilação. No entanto, isso é mais comumente referido como a fase de preparação (figura 1). Como o componente de banco de dados correspondente é conhecido como o otimizador de query ou planejador, os termos otimizar e planejar também são comumente usados. Os planos de execução são, em primeiro lugar, um meio interno para um fim, mas os administradores ainda podem visualizá-las. Como o plano de execução representa processos em um nível semelhante de abstração como o SQL, podemos ler um plano de execução muito rapidamente e como é consistentemente formatado pelo banco de dados muitas vezes é até mais rápido do que a instrução SQL original. No entanto, a formatação do plano de execução só é uniforme para um único banco de dados. Não existe algo como um padrão de fornecedor independente. De fato, os planos de execução de um banco de dados MySQL parecem completamente diferentes de um plano para o SQL Server da Microsoft. Assim como são diferentes os métodos para exibir planos de execução. Embora seja suficiente no PostgreSQL e no MySQL preceder a instrução SQL com a palavra-chave explain, a Oracle usa o comando explain plan for em combinação com a chamada de função DBMS_ XPLAN.DISPLAY (quadro 1). Interfaces gráficas de usuário fornecem botões apropriados ou itens de menu para isso. Este artigo concentra-se no MySQL (embora as referências para outros produtos possam ser encontradas na Internet [1]). Mostraremos como o administrador pode recuperar os fatos mais importantes de um plano de execução e como evitar erros de interpretação típicos. Valor de custo O valor de custo é um ponto de referência usado pelo otimizador para identificar o melhor plano de execução para uma instrução SQL. Pode-se dizer que o valor de custo é uma escala para a velocidade de execução. O valor de custo só se aplica a uma instrução 66

2 Quadro 1: Plano de execução do Oracle 01 SQL> explain plan for > SELECT * 03 3> FROM sales s 04 4> JOIN employees e ON (s.employee_id = e.employee_id) 05 5> WHERE s.sale_date > trunc(sysdate) INTERVAL 6 MONTH 06 6> AND s.eur_value >= 10; 07 Explained SQL> select * from table(dbms_xplan.display ); Id Operation Name Bytes Cost SELECT STATEMENT 3130K * 1 HASH JOIN 3130K * 2 TABLE ACCESS BY INDEX ROWID SALES 566K * 3 INDEX RANGE SCAN SALES_DATE TABLE ACCESS FULL EMPLOYEES 9M Predicate Information (identified by operation id): access( S. EMPLOYEE_ID = E. EMPLOYEE_ID ) 25 2 filter5( S. EUR_VALUE >=10) 26 3 access6( S. SALE_DATE >TRUNC(SYSDATE@!) 27 INTERVAL YEAR(2) TO MONTH) 1 O comando explain plan for armazena apenas o plano de execução na PLAN_TABLE. 2 O pacote DBMS_XPLAN fornece algumas funções para a visualização de planos de execução. 3 A coluna ytes mostra a quantidade de dados processados por qualquer operação. Observe duas coisas: em primeiro lugar, esta é apenas uma estimativa pelo otimizador. Em segundo lugar, apenas algumas operações precisam fazer o cache desses dados. Neste exemplo, o HASH JOIN só precisa armazenar em cache a tabela menor (de 566k). 4 Os valores de custo são exibidos para cada sub-árvore do plano de execução. Os custos totais são exibidos no nível superior. 5 O atributo de filtro para a operação com ID de 2 (TABLE ACCESS BY INDEX ROWID) indica que a coluna EUR_VALUE não está no índice SALES_DATE (operação ID 3). 6 O atributo de acesso mostra que o índice só é usado de forma eficiente para a condição SALE_DATE. SQL sob certas condições, sendo uma delas o tamanho da tabela. Isso significa que o valor de custo, basicamente, não é adequado para comparar o desempenho de diferentes instruções SQL. No entanto, o valor de custo ainda pode fornecer uma ideia aproximada da velocidade de execução. Um valor na casa dos bilhões pode, portanto, permitir que o usuário inferfira em uma execução que demoraria uma eternidade. O valor de custo é apenas o indicador, não a causa, uma vez que não afeta a fase de execução. Algo semelhante se aplica ao propósito de otimizar as estatísticas. Como essas estatísticas são a base para o cálculo do valor de custo, atualizá-las também irá alterar o valor de custo. Apesar disso, a velocidade da query SQL não irá se alterar se o plano de execução permanecer inalterado isto é, se as mesmas operações ainda forem processadas na mesma ordem. Uso de índices Outra má interpretação dos planos de execução tem algo a ver com o uso de índices. As pessoas muitas vezes têm a ideia de que um índice irá acelerar a execução, por uma questão de princípio. Mas isso é apenas metade da verdade. Em alguns casos, um índice pode, na verdade, retardar a execução principalmente em queries que lêem uma parte relativamente grande da tabela. Usar um índice causaria muitas leituras em pequenos blocos de dados. Se, ao contrário, o banco de dados lê totalmente a tabela, ele pode solicitar grandes blocos de dados de uma só vez e, assim, reduzir o número de operações Linux Magazine #110 Abril de

3 Quadro 2: Plano de execução do SQL Serve Podemos usar o botão Display Estimated Execution Plan para visualizar o plano de execução. Passar o mouse sobre uma operação abre uma dica de ferramenta com informações adicionais. O valor de custo de cada operação aparece três vezes como custo de I/O, custo de CPU e custo total. Finalmente, o valor de custo para toda a sub-árvore é exibido. Os custos totais são encontrados na dica de ferramenta em nível superior. O filtro Predicate indica que a coluna EUR_VALUE não está em uma posição adequada do índice para uma utilização eficaz. O atributo de acesso (Seek Predicate) para acesso ao índice mostra que o índice só é usado de forma eficiente para a condição SALE_DATE. de leitura, o que gera melhor desempenho, pois tanto o rendimento como o IOPS (operações de Input/Output por segundo) são limitados em sistemas de armazenamento. Aliás, o valor de custo é usado para decidir se um índice é útil ou prejudicial: o banco de dados o utiliza para avaliar as variantes do plano de execução e selecionar aquela com o melhor valor de custo. O plano de execução não apenas revela qual índice é utilizado. Os planos de execução também revelam algo sobre a eficácia de acessar o índice, que em grande parte depende de quais partes da cláusula WHERE são cobertas pelo índice. Com alguns bancos de dados, podemos descobrir esta informação diretamente do plano de execução, analisando os atribuições de filtro. Se uma atribuição de filtro ocorre no acesso à tabela, isso pode indicar que a coluna em questão está em falta no índice (quadros 1 e 3). Atribuições de filtro para um acesso de índice também podem ser um sinal de ordem errada da coluna (como mostrado no quadro 2). A query só usa o índice de forma ideal se o atributo access ou seek predicate forem exibidos. Algo semelhante ocorre para filtrar e acessar atributos quando pesquisamos em uma lista telefônica impressa e só sabemos o último nome e o endereço da pessoa que estamos procurando. O primeiro passo (por exemplo, encontrar todas as entradas para Smith ) é concluído muito rapidamente. Devido à forma como a lista telefônica é ordenada, podemos navegar rapidamente para a frente e para trás até encontrar a seção Smith. Se analisarmos mais de perto, estamos realizando uma pesquisa binária, para a qual a sobrecarga só cresce logaritmicamente com o tamanho da lista telefônica. Em outras palavras, se o livro de telefone fosse 10 vezes maior, a busca não iria demorar 10 vezes mais tempo. Em um banco de dados, a condição Last Name= 'Smith' seria, portanto, um atributo de acesso. Depois de encontrar os Smiths, ainda precisamos encontrar um Smith específico usando o endereço conhecido; no entanto, sem um primeiro nome, não podemos continuar usando a ordenação da lista telefônica. A única opção é passar por todos os Smiths. Em um banco de dados, a condição seria, portanto, um atributo de filtro. O tempo de busca aumenta linearmente com o número de Smiths na base de dados. A diferença entre os atributos de acesso e filtro é muitas vezes subestimada, mas poderia muito bem ser considerada. A figura 2 mostra a diferença em termos de desempenho. Em um caso ideal por exemplo, se os atributos de acesso pudessem ser utilizados em tudo a velocidade poderia Qualidade do filtro Qualidade de acesso Tempo de resposta (segundos) Tamanho da tabela x3,000 linhas Figura 2 À medida em que o tamanho da tabela aumenta, a utilização ineficaz do índice torna-se óbvia. 68

4 Quadro 3: Plano de execução do PostgreSQL 01 postgres=# EXPLAIN 1 02 postgres # SELECT * 03 postgres # FROM sales s 04 postgres # JOIN employees e ON (s.employee_id = e.employee_id) 05 postgres # WHERE s.sale_date > CURRENT_DATE INTERVAL 6 MONTH 06 postgres # AND s.eur_value >= 10; QUERY PLAN Hash Join 2( cost= rows=59654 width=1286) 11 Hash Cond: (s.employee_id = e.employee_id) 12 > Index Scan using sale_date on sales s (cost= rows=59654 width=251) 13 Index Cond: (sale_date > (( now ::text)::date 6 mons ::interval month)) 14 Filter:3 (eur_value >= 10::numeric) 15 > Hash (cost= rows=10000 width=1035) 16 > Seq Scan on employees e (cost= rows=10000 width=1035) 1 Prefixar a query SQL com EXPLAIN exibe o plano de execução. 2 Os valores de custo são mostrados para cada sub-árvore do plano de execução. O PostgreSQL exibe dois valores: os custos de instalação e os custos totais. 3 O atributo de filtro no acesso ao índice no PostgreSQL indica que a coluna EUR_VALUE não existe no índice SALE_DATE. 4 Os valores de linha e largura na ramificação de hash da operação join indicam a quantidade de memória necessária e mostram que a exigência de armazenamento não só depende das linhas, mas também das colunas selecionadas - o comprimento da linha. Selecionar menos colunas reduz o requisito de memória. ainda permanecer quase constante (exibida em verde), apesar de uma tabela que cresce rapidamente. Quanto mais atributos de filtro forem usados, maior influência o tamanho da tabela terá sobre a velocidade (exibida em vermelho). Ou seja, atributos de filtro e de acesso permitem prever a velocidade para um volume de dados cada vez maior e, assim, identificar os problemas antes que eles aconteçam. A causa da enorme diferença de desempenho na figura, por sinal, é o resultado da troca da segunda e terceira colunas no índice. Uma abordagem holística é essencial na indexação de banco de dados. Em particular, mudar a ordem das colunas é perigoso porque pode tornar o índice inutilizável para outras instruções SQL. Mudanças de índice devem, portanto, ser testadas extensivamente, planejadas com cuidado e, claro, comunicadas ao fornecedor do aplicativo. Requisitos de memória Um fato menos conhecido, mas não menos útil, é que os planos de execução também podem dizer algo sobre o consumo de memória de uma query SQL ou seja, sobre a quantidade de RAM necessária para a execução. Para fazer isso, quebramos as operações apresentadas no plano de execução em duas categorias:» Aquelas que, geralmente, só possuem um pequeno consumo de memória (memory footprint) e» Aquelas que fazem o cache de resultados intermediários na memória e, portanto, possuem um consumo de memória potencialmente grande. No planejamento de recursos, obviamente só precisamos nos preocupar com a segunda categoria, que significa, principalmente, classificar e agrupar operações, mas também todas as operações que utilizam um algoritmo hash como o hash join. Embora os nomes dessas operações sejam diferentes nos vários produtos de banco de dados (quadro 4), as operações mais intensivas de memória geralmente são traídas pela classificação, grupo ou componente de hash em seus nomes. No entanto, também há casos especiais, tais como a operação SORT GROUP BY NOSORT no banco de dados Oracle, que não realiza uma classificação, mas uma pesquisa por grupo nos dados pré-classificados. O lado bom dos planos de execução é que eles mostram explicitamente as ordenações implícitas. Por exemplo, se combinarmos acidentalmente duas tabelas usando UNION, o plano Linux Magazine #110 Abril de

5 Quadro 4: Plano de execução do MySQL 01 sqyl> EXPLAIN 1 02 > SELECT * 03 > 04 FROM sales s 05 > 06 JOIN employees e ON (s.employee_id = e.employee_id) 07 > 08 WHERE s.sale_date > CURRENT_DATE INTERVAL 6 MONTH 09 > 10 AND s.eur_value >= 10; id table type key key_len rows Extra s range sale_date Using index condition; 15 Using where e ALL NULL NULL Using where; 17 Using join buffer (Block 18 Nested Loop) Prefixar a query SQL com EXPLAIN mostra o plano de execução. 2 Using where na coluna Extra indica que nem todas as condições podem ser resolvidas através do índice; no entanto, não é possível afirmar a partir do plano de execução quais são essas condições. 3 O MySQL usa um block nested loop join, que possui um requisito de memória semelhante ao do hash join. de execução também mostra a operação para a deduplicação dos resultados (com exceção do MySQL). No entanto, se pela natureza dos dados ocorrerem duplicações e, portanto, um UNION ALL for suficiente esta operação e seu consumo de memória relacionado desaparecerá. Da mesma forma, uma operação hash ou grupo correspondente são exibidos em um DISTINCT, e novamente este comportamento está associado a um determinado espaço de memória. Por outro lado, há também casos em que os bancos de dados não executam uma operação de classificação aparentemente necessária. Pode acontecer que, apesar de uma cláusula order by na consulta SQL, nenhuma operação de classificação ocorre no plano de execução. Este resultado é geralmente devido a uma indexação inteligente que assegura que o índice fornece os dados na ordem desejada. Esta técnica é frequentemente combinada com cláusulas limit ou top e, idealmente, dissocia quase completamente os requisitos de recursos do tamanho da tabela. Assim, a velocidade de uma query sem uma cláusula where pode realmente ser independente do tamanho da tabela, se as cláusulas order by e limit/top forem combinadas com um índice correspondente. Obviamente, não podemos ver essa otimização olhando para a própria query SQL, mas, no plano Gostou do artigo? Queremos ouvir sua opinião. Fale conosco em: cartas@linuxmagazine.com.br Este artigo no nosso site: Mais informações de execução, será possível identificar esta técnica pela ausência da operação de classificação. Conclusão Os administradores e desenvolvedores SQL precisam dominar os planos de execução, puramente por conta do que um plano de execução pode revelar sobre um banco de dados. O plano de execução é uma importante ferramenta que pode ajudá-lo a identificar e corrigir rapidamente as causas de problemas de desempenho de bancos de dados. n [1] Planos de execução: The Index Luke.com/sql/explain plan 70

6 Agora você tem o controle sobre o desempenho do seu negócio sempre à sua mão. O Intalio bpms é uma plataforma completa, inovadora e de código aberto para gerenciamento e automação de processos de negócios. Com mais de 1 milhão de downloads, o Intalio bpms é a única plataforma que segue 100% dos padrões e boas práticas de BPM, sendo referência no mercado com adoção em mais de empresas ao redor do mundo, nas quais otimiza recursos e maximiza resultados. Solução completa hospedada em nuvem (Cloud Computing) Saiba mais em: SOFTWARE Linux Magazine #110 Abril de