Analisando Desempenho de Consultas Utilizando Oracle SQL Developer

Analisando Desempenho de Consultas Utilizando Oracle SQL Developer

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, na Figura 1 temos a imagem do 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. A partir dessa consulta iremos ilustrar uma análise com objetivo de termos forma de melhorar o desempenho desta consulta.

Figura 1: Oracle SQL Developer

Pontos de Analise

• Tempo de execução : Esse tempo de execução aparece sobre a toobar conforme a Figura 2.  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 a performance possível da mesma.

Figura 2: 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 Figura 3.

Figura 3: Opção de Executar Plano Acesso

• Resultado do Plano Acesso : Na Figura 4, 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 negrito precisam ser melhorados. Esses relacionamentos estão nos dizendo que nas tabelas estão ocorrendo.

• Table Access(Full): Indica a tabela que 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 Figura 2.

Dica: Quando temos um plano de acesso de uma query como a de nosso exemplo, que está indicando Table Access, devemos observar a quantidade de 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.

Figura 4: 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 para obter o resultado devido as tabelas possuírem 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 a partir 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