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).

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)."

[...] continue lendo...

Explain plan- Parte 3 - SQL Magazine 81

Artigos relacionados