Artigos Banco de Dados Explain plan- Parte 3 - SQL Magazine 81
Demais posts desta série:
Explain plan -Parte 1
Explain plan -Parte 2
Artigo no estilo: Curso

De que se trata o artigo?

Este artigo trata dos conceitos envolvidos na análise de um plano de execução proveniente do comando explain plan em banco de dados relacionais. O plano de execução é a estratégia de acesso adotada pelo otimizador de consultas do banco de dados para que a mesma seja executada de maneira que obtenha a melhor performance possível.

Para que serve?

Esclarecer e desmistificar os mecanismos intrínsecos das etapas de elaboração do plano de execução, fazendo com que o DBA entenda o mecanismo de definição de estratégia de acesso e saiba como tirar proveito dela.

Em que situação o tema é útil?

Através da correta interpretação do plano é possível refinar e redirecionar a execução, e como consequência, atingir um melhor desempenho. O conhecimento e interpretação do plano de execução se torna particularmente útil na análise de consultas que apresentam performance insatisfatória para o sistema como um todo.

Nas edições passadas abordamos a interpretação de predicados, índices B-Tree, Bitmap, interação entre os recursos de hardware, transações e estratégias de acesso em tabelas e índices. Nesta última parte focaremos os seguintes tópicos:

· Estratégias de join (junção) entre tabelas:

o Nested Loops;

o Sort Merge Join;

o Hash Join.

Em toda modelagem de dados, a redundância de informações deve ser sumariamente descartada e, como consequência, novas tabelas acabam sendo criadas. Entretanto, no momento da recuperação ou consulta de informações, a junção entre estas tabelas que foram criadas no intuito de evitar redundância de informações acaba sendo inevitável.

E é justamente este tipo de junção entre tabelas que chamamos simplesmente de joins (significado em inglês para “junção”).

Junções entre tabelas normalmente “custam caro” para a execução no banco de dados e é justamente por esse motivo que devemos garantir que o otimizador utilize a melhor metodologia para traçar a melhor estratégia de acesso às tabelas envolvidas na(s) junção(ões) e esta melhor estratégia pode ser através da utilização de um Nested Loop, Sort Merge Join ou ainda um Hash Join.

Ao final de um breve ensaio decorrente dos conceitos mencionados serão finalmente demonstradas aplicações práticas em Oracle.

Estratégia de join entre tabelas

Como falado anteriormente, as junções entre tabelas são necessárias em casos onde as informações requeridas não se encontram em uma única tabela. Esta situação é extremamente comum e prevista nas regras de modelagem.

Em muitos casos, para que todas as informações referentes a um determinado contexto estejam na mesma tabela, muitos dados seriam redundantes no momento em que um valor deste contexto se altere. Posso exemplificar através de uma lista telefônica. É comum encontrarmos uma sessão em que se possa verificar todos os telefones e seus respectivos assinantes em uma determinada rua. Neste caso, o contexto é sempre o mesmo (assinantes que moram em uma determinada rua), porém os valores deste contexto se alteram (nome de cada assinante). Imagine se, em cada registro, fossem armazenadas as informações referentes à rua e ao assinante! Em uma rua em que houvesse 30 assinantes diferentes, a informação referente à rua estaria duplicada (exatamente 30 vezes). Para contornar esta situação, uma tabela contendo as informações da rua seria criada e uma junção será feita com a tabela contendo as informações referentes aos assinantes.

Estudo de caso

Neste artigo, para a nova série de exemplos foi incluída a tabela JOGADOR ao modelo que tenho usado no decorrer desta série. Nesta nova tabela, os jogadores de futebol são listados e a nacionalidade correspondente do atleta é definida através da coluna PAÍS_DO_JOGADOR. O índice B-Tree também foi criado utilizando como base a coluna PAÍS_DO_JOGADOR (Figura 1).

Tabela JOGADOR

Figura 1. Tabela JOGADOR incluindo suas respectivas nacionalidades e seu índice B-Tree por PAÍS_DO_JOGADOR.

Para recuperar a informação de cada jogador e a respectiva Confederação que o mesmo faz parte, é necessário fazer uma consulta ao banco de dados fazendo uso da técnica de junção entre as tabelas PAÍS e JOGADOR. Porém, além de mencionar as tabelas que farão parte da junção (tabelas definidas na cláusula FROM da consulta SQL), é necessário também utilizar uma técnica de junção no filtro da consulta (cláusula WHERE da consulta SQL).

A consulta SQL que retorna as informações referentes ao jogador e respectiva Confederação pode ser vista na Listagem 1 enquanto que o resultado desta mesma consulta SQL é apresentado na Figura 2. Já técnicas de junção podem ser consultadas na Nota DevMan 1.

Listagem 1. Consulta utilizando JOIN.

SELECT *
    FROM PAÍS, JOGADOR
    WHERE PAÍS.NOME_DO_PAÍS = JOGADOR.PAÍS_DO_JOGADOR

Resultado da consulta SQL

Figura 2. Resultado da consulta SQL da combinação das tabelas PAÍS e JOGADOR.

Nota DevMan 1. Cartesian join, Inner join, Left outer join/Right outer join, Full outer join, Semi join, Anti-join

Cartesian join:

Consiste na listagem da combinação de todas as linhas de duas tabelas (baseado no conceito de produto cartesiano).

...

Quer ler esse conteúdo completo? Tenha acesso completo