Oracle SQL Developer é uma ferramenta que nos permite rodar consultas SQL, executando um plano de acesso. Plano este que possibilita fazer uma análise para melhorar o desempenho da consulta. Neste artigo vamos abordar os pontos que devem ser observados.
Abaixo temos a Imagem Oracle SQL Developer, onde passamos a consulta SQL a ser analisada.
Esta é uma consulta exemplo que permite trazer os dados cadastrais de um determinado cliente. Apartir dessa consulta iremos ilustrar uma análise, com objetivo de termos forma de melhorar o desempenho da mesma.
Pontos de Analise:
? Tempo de execução : Esse tempo de execução aparece sobre a toobar conforme a imagem abaixo : Esse tempo tem dois conceitos são eles :
Conceito Performático e Não Performático: Esse tempo pode ter o conceito de Performático, ou seja, de que a query está retornando a consulta em um tempo rápido dependendo de alguns pontos que devem ser compreendidos. Para uma consulta ser rápida, devem ser levados em consideração a quantidade de dados que estão nas tabelas e os relacionamentos que fazem a estrutura da query. Podemos ter uma consulta pesada que leva um retorno de 01 minuto e ser rápida, pois a mesma possui uma grande quantidade de dados nas tabelas e obedece aos relacionamentos, e uma consulta como essa que estamos exemplificando que tem um retorno de 5,595 segundos e não performática.
Em nosso exemplo vamos analisar o plano de acesso desta query e identificar os pontos a serem melhorados com o objetivo de buscar ao máximo de performance possível da mesma.
Imagem Tempo Execução
O tempo destacado acima foi o tempo gasto de retorno da consulta no banco. A partir desse tempo podemos então analisar nossa consulta. Em nosso exemplo , podemos analisar que é um tempo alto , que pode comprometer a performance dessa query no banco.
? Plano de Acesso : Para podermos visualizar o plano de execução da query , temos a opção Execute Explain Plan , localizado na barra de ferramentas do SQL Developer conforme a imagem abaixo:
Imagem Opção de Executar Plano Acesso
? Resultado do Plano Acesso : Na imagem a seguir temos o resultado do plano de acesso da query , onde podemos tomar algumas decisões. Neste caso temos um plano de execução com uma baixa performance.
Lembrando : O objetivo de nossa query é trazer os dados cadastrais de Cliente. Nessa nossa consulta estamos usando as tabelas :
Tbl_cliente : Permite trazer os dados dos clientes
Tbl_compra : Permite trazer os dados das compras dos clientes
Tbl_estoque : Permite trazer o estoque dos clientes
Tbl_fornecedor : Permite trazer o fornecedor dos produtos em estoque
Analisando este plano de acesso, podemos identificar que os relacionamentos entre as tabelas que estão em negritos precisam ser melhorados. Esses relacionamentos estão nos dizendo que nas tabelas estão ocorrendo:
? Table Access(Full) : Indica tabela está ocorrendo uma leitura em seus dados sem a utilização de índices. Desta forma o custo dessa consulta para o banco torna-se robusta dependendo das quantidades de registros que contém na mesma, aumentando o tempo de retorno como vimos na imagem de tempo de execução.
Dica : Quando temos um plano de acesso de uma query como a de nosso exemplo , que está indicando Table Access , devemos observar a quantidade itens que está na tabela . Pois é esse Table Access que é responsável por deixar a query com um tempo de execução alto (conforme a imagem de tempo de execução acima). Sempre quando houver um Table Access na sua consulta e a tabela a qual está ocorrendo esse Table Access possuir uma quantidade de registros superior a 2000 registros é interessante criar um índice para a tabela.
Imagem Plano Acesso Consulta SQL
Conclusão:
Devemos levar em consideração que para obtermos uma boa performance em nossas consultas, temos que garantir um relacionamento confiável, utilizando índices e evitando assim Table Access. Fica como uma dica que se a consulta está com um plano de execução sem ocorrer table acesss, mas está demorando obter o resultado, devido as tabelas possuir uma quantidade grande de itens, utilizamos então stored procedures no banco de dados. As stored procedures permitem manter o plano de execução (plano de acesso) em cache do banco. Desta forma ele é executado apartir do cachê do banco de dados, não gerando mais o plano de acesso e obtendo maior performance.
A dica para o próximo artigo construirmos uma stored procedures para banco de dados Sybase e Oracle, utilizando cursores e os conceitos de como garantir uma boa performance.
Disponibilidade da Ferramenta:
A ferramenta Oracle SQL Developer , utilizada nesse artigo pode ser obtida sua versão de teste pelo link http://www.oracle.com/technology/getting-started/sqldev.html .
