Analista de Sistemas e Especialista em Banco de Dados e Business Intelligence
(breno.m.souza@gmail.com). 2 DBA, Mestre em informtica e Professor do Centro Universitrio Newton Paiva (iremar.prof@uol.com.br).
OTIMIZAO DE CONSULTAS NO SGBD ORACLE 11G
BRENO MARCELO DE SOUZA 1
IREMAR NUNES DE LIMA 2
Resumo: Este artigo apresenta diversas tcnicas e ferramentas para otimizar consultas SQL no Sistema Gerenciador de Banco de Dados ORACLE 11g. Palavras-chave: Banco de Dados, Otimizao, SQL, Oracle 11g.
1.0 INTRODUO Um fator muito importante para garantir a continuidade do negcio das empresas nos dias atuais sua capacidade de analisar, planejar e reagir com rapidez s mudanas ocorridas no mercado. Para isso, importante que as organizaes disponham cada vez mais de informaes para o auxlio tomada de decises, otimizando seus processos. No ambiente competitivo em que as empresas esto inseridas, onde a globalizao vem derrubando barreiras comerciais, extrair e inserir informaes confiveis e em menor tempo possvel passa a ser recomendvel para aquelas empresas que buscam permanecer no mercado. Neste contexto, indicada a aplicao de novas tcnicas e a sua necessidade comea a ser sentida a partir do momento em que as empresas adotam uma postura de trabalho mais voltada gesto da informao. Dessa forma, a otimizao de um sistema de banco de dados se faz necessria pelo fato de estar fortemente ligada ao tempo de resposta e,
2
conseqentemente, o elemento mais perceptvel ao usurio final. Sabe-se que muito dos gargalos em um sistema de banco de dados derivam de consultas ou modelo de dados mal estruturado. O objetivo desse trabalho demonstrar que mesmo um SGBD de grande porte como Oracle 11g, que utiliza mecanismos de otimizao automtica, pode escolher planos de execuo para sentenas SQL que no sejam as melhores. As consultas podem ser melhoradas com a aplicao manual de tcnicas que possibilitem um desempenho maior com menor custo, provendo s empresas a capacidade de extrarem as informaes mais rpidas do banco de dados, independente da ferramenta ou do grau de complexidade exigido nas consultas. O restante do artigo est organizado da seguinte forma: na seo 2 sero apresentadas algumas caractersticas da linguagem SQL. Na seo 3 ser abordado o Oracle 11g, descrevendo sua arquitetura e os componentes envolvidos na execuo da instruo SQL, explicando o plano de execuo e estatstica. Na seo 4 mostrar as tcnicas de boa prtica na otimizao de instruo SQL, focando em modelagem de dados, variveis bind, ndices e ajuste de SQL. Na seo 5 apresentada a concluso deste trabalho.
2.0 CARACTERSTICAS DA LINGUAGEM SQL SQL (Structured Query Language) uma linguagem de alto nvel para manipulao de dados dentro do modelo relacional. de tal ordem sua importncia para a indstria dos bancos de dados relacionais que ela acabou por se tornar o mecanismo mais popular de acesso aos grandes bancos de dados cliente/servidor. A linguagem SQL dividida em cinco tipos de instrues, descritas a seguir (PRICE, 2009): 3
Data Query Language (DQL): recuperam linhas armazenadas nas tabelas do banco de dados e representada pela instruo Select. Data Manipulation Language (DML): modificam o contedo das tabelas. Existem trs instrues DML: Insert, Delete e Update. Data Definition Language (DDL): definem as estruturas de dados, como as tabelas, que compem um banco de dados. Existem cinco tipos bsicos de instrues DDL : Create, Alter, Drop, Rename e Truncate. Transaction Control - (TC): registram permanentemente as alteraes feitas em linhas ou desfazem essas alteraes. Existem trs instrues TC: Commit, Rollback e Savepoint. Data Control Language (DCL): alteram as permisses nas estruturas de banco de dados. Existem duas instrues DCL: Grant, Revoke.
3.0 ARQUITETURA DO ORACLE 11G O conhecimento da arquitetura interna do SGBD ORACLE importante para a compreenso das tcnicas de otimizao do produto. O SGBD Oracle composto de duas entidades: o banco de dados e a instncia. O banco de dados formado por arquivos no disco, ou seja, a estrutura fsica. J a instncia formada por estruturas de memria e os processos. No processo de inicializao, a instncia criada e inicializada primeiro que o Banco de Dados. Eles so separados, porm conectados. Segundo WATSON (2010), uma instncia Oracle composta por um bloco de memria compartilhada conhecida como rea global de sistema (SGA), e uma rea de memria no compartilhvel associado a cada processo do servidor, conhecida com rea global de programa (PGA). 4
A PGA o buffer de memria que contm dados e algumas informaes de controle de uma sesso de um usurio. Dentro da PGA existem 2 estruturas : uma contendo variveis de sesso e outras informaes, outra contendo dados sobre a sesso do usurio, tais como reas privadas SQL. J a estrutura de dados da SGA composta por: O cache de buffer do banco de dados: concentra todos os blocos lidos para aumentar a velocidade de leitura evitando I/O. O Redo log buffer: contm informaes o suficiente para refazer o banco de dados. uma rea de segurana, tudo gravado l independente de Commit. uma rea que pode causar problemas de performance. O shared pool: uma rea de cache especializada em armazenar os seguintes dados em cache: cdigo PLSQL compilado, planos de execuo, dicionrio de dados, permisses e etc... Um large pool: uma rea opcional que, se criada, ser usada automaticamente por vrios processos que ocupariam a memria do shared pool. Ela destinada a I/O, backup e restore. Um J ava pool: uma rea destinada para executar procedures java armazenada no banco de dados. Sem ela a Console no inicia. Um Streams pool: uma rea destinada extrair vetores de alterao do redo log,e a partir deles, reconstri as instrues que foram executadas ou instrues que teriam o mesmo efeito. As estruturas fsicas que compem um banco de dados Oracle so : Data File : so os arquivos de dados armazenados. Redo Log File: guardam informaes para restaurar o banco de dados. 5
Control File: armazenam informaes sobre as estruturas fsicas do banco de dados (nome, checkpoints, informaes sobre backups, localizao fsica,...). Todos os data files e redo log files so identificados no control file, bem como o nome do banco de dados. 3.1 Componentes Envolvidos na Execuo da Instruo SQL. Quando submetemos um comando de SQL para o banco de dados, quatro etapas so realizadas para a implementao do comando: Parse, Bind (opcional), Execute e Fetch. A forma como estes componentes interagem entre si ilustrada pela Figura 1.
Figura 01: Fluxo de execuo de uma consulta SQL Fonte: http://www.cs.tau.ac.il/~boim/courses/databases2011/slides/moreinfo/SQL%20tuning.pdf
Prepare (Parse) Durante a fase prepare, a instruo SQL enviada pelo usurio para o servidor de banco de dados para ser analisada. Em seguida, carregada na rea de compartilhamento do SQL. Este processo de anlise e preparao do SQL consiste em: Validao da sintaxe do comando SQL. Pesquisa a existncia do comando em memria o Oracle verifica se o comando de SQL que est sendo analisado j foi submetido anteriormente e se o resultado desta submisso ainda est em memria. Caso o comando seja encontrado, significa que 6
o plano de execuo j est traado, no havendo necessidade de refazermos esta ao; sendo assim, ser iniciada a fase EXECUTE. Pesquisa o dicionrio de dados - caso o comando de SQL no seja encontrado na memria, o Oracle verifica no dicionrio de dados se existem as tabelas e colunas mencionadas no comando e se as permisses para acesso aos objetos desejados so suficientes. Construo do plano de execuo aps a pesquisa no dicionrio de dados o otimizador poder traar um caminho de acesso para cada tabela presente no comando, montando um plano de execuo para obteno e/ou atualizao dos dados do comando SQL submetido. Alocao da memria com o plano traado, o Oracle inclui este plano na memria para que sua execuo seja possvel e para permitir que este plano seja reaproveitado por outro comando idntico ao atual. A fase de anlise executada apenas uma vez, independentemente da qualidade de vezes que a instruo executada, desde que a instruo analisada esteja na rea de compartilhamento do SQL. Bind (Variveis de Ligao) opcional, caso haja utilizao de variveis na consulta SQL. Com uso de variveis bind para representar valores de coluna, pode-se garantir que uma instruo seja idntica, ocorrendo a reutilizao de uma instruo SQL j armazenada em memria, e a reduo do tempo de execuo, pois o plano de execuo j est traado, no havendo necessidade de refazer o parse. Execute Nesta fase, o servidor de banco de dados j detm todos os recursos e informaes necessrias para executar a instruo e aplicar o plano de execuo, podendo fazer leituras 7
fsicas ou lgicas. Caso a instruo seja um comando select ou insert, nenhuma linha precisa ser bloqueada, j que nenhum dado est sendo alterado. Caso a instruo seja update, delete, select for update ou with lock, todas as linhas afetadas pela instruo so bloqueadas, impedindo que outros usurios alterem-nas at o prximo commit, rollback ou savepoint da transao, garantindo assim, a integridade do dado. Fetch Nesta fase, as linhas que satisfizerem ao resultado de uma consulta so recuperadas e enviadas para a aplicao que as requisitou. 3.2 Plano de Execuo O software de banco de dados Oracle usa um subsistema conhecido como Otimizador para gerar o caminho mais eficiente para acessar os dados armazenados nas tabelas. O caminho gerado pelo otimizador conhecido como plano de execuo. Para executar um comando SQL (DML), o Oracle pode ter de executar diversos passos. Cada um destes passos pode recuperar, fisicamente, linhas das tabelas referenciadas no comando. Para cada tabela envolvida no comando SQL haver um caminho de acesso para obteno dos dados daquela tabela, que apresentado abaixo: Full table scans L todos blocos da tabela usada para armazenar linha. Faz I/O multiblocos. Pode ser causado por: falta de ndice, pouca seletividade das colunas e em tabelas pequenas, mesmo com ndice. Row ID Scans Acessa linha e reconhece o RowID , que so pseudocolunas que retorna o endereo da linha. Acesso pela chave ( PK ). 8
Melhor forma de acesso aos dados, pois so identificadores nicos para linhas em uma tabela. Index Scan Acesso aos dados usando-se um ndice. Principais tipos de ndices existentes no Oracle: Index J oin: J oin entre ndices. Unique Scan: PK ( a =10 ) o acesso a um ndice B-Tree sobre colunas nicas (primary keys ou uniques) para recuperao do RowId de um registro. Range Scan: por faixa ( a >10 <20 ) ou quando no se tem chave nica Full-scan: quando ordena pelo campo indexado Fast-Full scan: sem garantia de ordem Nested Loop Joins Para cada linha da tabela externa, faz uma busca na tabela mais interna. Hash Joins Aplicar o algoritmo de hash join em um inner join de duas relaes funciona da seguinte maneira: primeiro, preparada uma hash para a relao menor, aplicando uma funo hash para cada linha , na columa a ser usada no join. Ento, a relao maior escaneada, em busca das linhas relevantes, procurando pela hash table. Usado com INNER J OIN, OUTER J OIN. Na juno hash (hash join), a fonte de dados interna colocada em uma tabela hash, utilizando a chave da juno. Cada registro da fonte de dados externa tambm colocada na tabela hash, gerando os registros que atendem juno. Caso o nmero de registros da fonte de dados interna seja muito grande, so criadas parties, contendo apenas parte dos registros. Cada registro da fonte de dados externa ser colocado na tabela hash a fim de verificar os registros que 9
atendem as condies de juno. Este procedimento realizado para cada registro da fonte de dados externa. O custo do hash join pode ser obtido pela expresso (custo de acesso da fonte externa * nmero de parties) +custo de acesso da fonte interna. Quando h relacionamento entre duas tabelas, utilizando full-table-scan. Sort-Merg Joins Usado quando no se tem ndices. Cada uma das tabelas ou conjuntos resultados ou j deve estar ordenado. A partir disto, realizado o percurso balanceado de ambas as tabelas. Normalmente o hash join possui desempenho superior, mas o sort merge join particularmente til em junes por desigualdade ( <>, <, >, <=, >=, like, etc.). 3.3 Estatstica Nos dias de hoje os bancos de dados Oracle vivem e respiram estatsticas (FREEMAN,2009). O otimizador recolhe os dados estatsticos sobre a base de dados e objetos no banco de dados. Essas estatsticas so utilizadas pelo otimizador para escolher o melhor plano de execuo de cada comando SQL. Para diagnosticar problemas de desempenho com eficincia, a estatstica deve estar disponvel. O Oracle gera muitos tipos de estatsticas, como: estatstica de tabelas, colunas, ndices e sistema. A partir da verso 10g, j era possvel recolher automaticamente as estatstica, algo que antes era feito manualmente, reduzindo com isto significativamente as chances de algum objeto ficar sem estatsticas ou com as mesmas obsoletas causando algum problema no plano de execuo. Porm em alguns casos, se faz necessrio a coleta manual, como por exemplo, em tabelas que so modificadas em operaes com volume de dados muito 10
grande e so acessadas de forma significativa. J o Oracle 11g oferece novas funes associada s estatsticas, como: estatsticas pendentes e publicadas, recuperando estatsticas anteriores e estatsticas estendidas (FREEMAN,2009). As estatsticas pendentes e publicadas oferece a opo de publicar estatsticas aps a sua coleo, sendo o comportamento padro, ou voc pode ter estatsticas recm coletadas salvas em um estado pendente (FREEMAN,2009). Para determinar se o banco de dados ir publicar as estatsticas quando elas so coletadas ou se elas sero mantidas em um estado pendente, voc dever usar a funo dbms_stats.get_prefs, retornando TRUE as estatsticas sero publicadas automaticamente ou FALSE elas no sero publicadas, sendo valor default TRUE. Se voc determinar no publicar a estatstica pendente, basta remov-las atravs do procedimento dbms_stats.delete_pending_stats, tendo a opo de remover a estatstica pendente do banco inteiro ou somente de um esquema ou de um objeto especifico em um esquema. E para determinar se uma estatstica pendente ser ou no publicada, o mesmo poder ser feito atravs do procedimento dbms_stats.set_schema_prefs para esquema ou dbms_stats.set_table_prefs para uma tabela, acrescentando a opo FALSE ou TRUE. E o procedimento dbms_stats.publish_pending_stats ira publicar todas as estatsticas pendentes marcadas para publicar, podendo fazer isso para um banco inteiro, ou para uma esquema ou at mesmo um objeto especifico em um esquema. (FREEMAN,2009). Uma das vantagens da coleta e publicao, que permite uma coleta quando o sistema menos usado, por exemplo, noite e as publicando pela tarde. Se acontecer algo errado, basta restaurar a estatstica antiga, e ainda, se voc quiser testar as estatsticas coletadas antes de public-las, existe um parmetro optimizer_use_pending_statistics, que far que o otimizador sempre use as estatsticas pendentes se houver em vez das estticas publicadas. Caso no haja estticas pendentes o otimizador ir usar as publicadas, e se houver algum 11
problema basta mudar esse parmetros para o otimizador usar as estatsticas publicadas, sendo essa opo bastante til para testar como o sistema vai reagir as novas estatsticas. J recuperando estatsticas anteriores o Oracle 11g permite que voc restaure verses anteriores de estatsticas, atravs de vrios procedimentos no pacote dbms_stats, com base em um timestamp especifico. O Oracle ir administrar o repositrio de estatsticas histricas, removendo a estatsticas antigas regularmente, de modo padro a cada 31 dias (FREEMAN, 2009). As estatsticas estendidas fornecem a habilidade para juntar estatsticas adicionais, como as estatsticas de mltiplas colunas e estticas de expresso (FREEMAN, 2009). Antes do Oracle 11g, no existia estatsticas de mltiplas colunas no havendo modo algum para compreender a relao dos dados dentro de mltiplas colunas de uma clusula where. Agora com as estatsticas de mltiplas colunas podemos fornecer ao Oracle uma melhor informao para que ele possa saber que essas colunas so agrupadas em conjunto, e para que possa gerar um plano de execuo que reflita mais precisamente a realidade da consulta (FREEMAN, 2009). J as estatsticas de expresso permitem incluir funes como predicativo na clusula where, e determinar a seletividade dessa funo. Lembrando que essa estatstica no pode ser aplicada se voc tiver um ndice baseado na funo dessa estatstica de expresso que voc est querendo criar (FREEMAN, 2009). Teste cuidadosamente todas as funes novas e certifique-se que elas estejam funcionando, da maneira que voc espere que elas funcionem antes de aplic-las no banco de produo.
4.0 Tcnicas de Otimizao de Instrues SQL A otimizao o processo de escolha do modo mais eficiente para a execuo de um comando SQL. 12
Podem existir diferentes formas para o Oracle executar um comando SQL: de acordo com a ordem em que as tabelas ou ndices sofrero acesso, de acordo com as restries estabelecidas, de acordo com a quantidade de linhas das tabelas envolvidas, de acordo com os ndices disponveis, etc. De acordo com VENNAPUSA (2004), so vrios os fatores que podem influenciar no custo e velocidade das consultas SQL: criao e deleo de ndices, alterao de parmetros, remodelagem fsica de tabelas, gerao de estatsticas, reescrita de cdigos SQL, entre outros. No existindo uma frmula precisa para aumento de desempenho (VENNAPUSA, 2004). As consultas so objetos de constantes revises e otimizaes, visto que o ponto crucial em um sistema de banco de dados, pois constituem a maior parte das transaes envolvidas em uma aplicao. 4.1 Modelagem de Dados A modelagem de dados importante para o sucesso da aplicao. Isto deve ser feito de uma maneira eficiente e precisa para representar a regra de negcio. Deve-se aplicar esforos para modelagem das entidades de maior impacto, ou seja, as utilizadas com maior frequncia. Utilizar ferramentas de modelagem pode ajudar nas definies dos modelos e agilizar na definio dos prottipos (VENNAPUSA, 2004). Normalizando tabelas, evitam-se duplicaes de registros, pelo menos at a terceira forma normal. Quando os dados so normalizados, voc tem uma imagem clara das chaves e relacionamentos, tornando mais fcil realizar a prxima etapa de criao de tabelas, constraints e ndice. Um bom modelo, em ltima analise, significa que as suas transaes sero interpretadas de modo mais eficiente (VENNAPUSA, 2004). 4.2 Variveis Bind 13
Toda instruo SQL submetida ao banco de dados Oracle colocada em cache. Uma instruo SQL colocada no cache reutilizada se uma instruo idntica enviada para o banco de dados. Quando ocorre a reutilizao de uma instruo, o tempo de execuo reduzido, pois o plano de execuo j est traado, no havendo necessidade de refazer o Parse. Entretanto, a instruo SQL deve ser absolutamente idntica para ser reutilizada. Isso significa que: Todos os caracteres na instruo SQL devem ser iguais. Todas as letras na instruo SQL devem ter a mesma caixa. Todos os espaos na instruo SQL devem ser iguais. Voc pode garantir que uma instruo seja idntica utilizando variveis bind para representar valores de coluna. Elas funcionam como parmetros em instrues SQL, possibilitando a atribuio de valores dinmicos nos comandos SELEC, UPDATE, DELETE e INSERT. Com a utilizao de variveis Bind o Oracle faz o reuso de instruo SQL j armazenada em memria. Dessa forma, variveis bind servem de ponte para a execuo de uma instruo SQL, j preparada na memria do servidor, onde so enviadas apenas os valores nela contido. 4.3 ndices A criao de ndices deve ser avaliada de acordo com a frequncia de uso de determinados dados e tabelas. Um ndice pode ser um instrumento chave para atender aos objetivos da otimizao. Entretanto, o mesmo pode ser capaz de interferir no desempenho de forma negativa. Uma boa regra geral segundo PRICE (2009) : crie um ndice quando uma consulta recuperar at 10% do total de linhas em uma tabela. Isso significa, que o critrio para a escolha de ndices a seletividade, portanto quando maior for a seletividade melhor ser o ndice. Uma coluna que contm valor exclusivo para cada linha (por exemplo, um nmero de CPF), um atributo candidato indexao. 14
Assim, os ndices so criados com intuito de eliminar a leitura de toda a tabela na inteno de encontrar o registro, mas cuidado, possuir mais ndices em uma tabela no significa que as consultas sero aceleradas. Cada operao DML que seja submetida a commit em uma tabela com ndices significa que os ndices devem ser atualizados. Quando mais ndices associados a uma tabela voc tiver, maior ser o esforo realizado pelo Oracle para atualizar todos os ndices aps uma instruo DML. O Oracle possui diversos tipos de ndices, como os normais (rvore B-Tree a mais utilizada), ndices Bitmap que armazenam os rowids juntamente com um valor chave em formatos de bits, ndices particionados, ndices baseados em funes, ndices de chaves reversas e ndices IOT. 4.4 Ajuste de SQL Segundo PRICE (2009), uma das principais vantagens da linguagem SQL que voc no precisa dizer ao banco de dados exatamente como ele deve obter os dados solicitados. Basta executar uma consulta especificando as informaes desejadas e o software de banco de dados descobre a melhor maneira de obt-las. Atravs do estudo do desempenho e otimizao de consultas SQL, procuramos minimizar o tempo de resposta do servidor de banco de dados, podendo s vezes, diminuir o tempo de execuo de suas consultas. A seguir sero apresentadas algumas boas prticas na escrita da instruo SQL, buscando a melhoria do desempenho dessas instrues. Evite utilizar Select *, pois quando voc faz isso, o Oracle tem que ir no Dicionrio de dados, ler a tabela DBA_TABLE_COLUMN para saber quais colunas pertencem essa tabela e retornar as informaes, causando um trabalho adicional desnecessrio, alm de ler a pgina de dados de cada linha para obter os valores dos atributos que no fazem parte do ndice (VENNAPUSA, 2004). 15
Use referncia de coluna totalmente qualificada ao fazer joins, pois economiza tempo ao gerenciador para localizar a tabela que pertence o campo (PRICE , 2009). Exemplo: Select p.name, pt.name, p.description, p.price From products p, product_types pt Where p.product_type_id=pt.product_type_id And p.product_id=1;
Use expresses case, em vez de vrias consultas, quando precisar efetuar muitos clculos nas mesmas linhas em uma tabela (PRICE , 2009). Exemplo:
Select Count(Case When price <13 then 1 else null end) Low, Count(Case When price between 13 and 15 then 1 else null end) med, Count(Case When price >15 then 1 Else null end) high From products; Use Exists em vez de IN. O Exists verifica apenas a existncia da linha, enquanto o IN verifica valores reais. Normalmente o Exists oferece melhor desempenho do que IN com subconsultas. Porm, se voc utilizar IN em uma subconsulta e comparar o campo pesquisado dentro da subconsulta, o IN oferece melhor desempenho que o Exists (PRICE ,2009). Exemplo: Select a.product_id,a.name From products a Where a.product_id in (select b.product_id From purchases b Where a.product_id=b.product_id);
Se a Aplicao valida a entrada nos campos, retirar as Constraints de Check na tabela, pois economiza tempo para o gerenciador e evita o consumo de recurso desnecessrio, pois no haver necessidade de consulta ao dicionrio de dados, para validar a entrada (VENNAPUSA, 2004). 16
Evitar a utilizao de %TYPE, pois o Oracle ter que consultar no dicionrio de dados o tipo dessa coluna e retornar a informao, causando um trabalho adicional desnecessrio (VENNAPUSA, 2004). Evitar a utilizao de operadores como NOT, NOT EXISTS, NOT LIKE, NOT IN, LIKE %X ou <>. Nesses casos o ndice no utilizado, pois a pesquisa no pode ser limitada, sendo necessrio avaliar todas as linhas (PRICE,2009). Utilizao de HINTS, que tem o como principio, passar dicas para o otimizador influenciando na escolha do plano de execuo. A dica correta pode melhorar o desempenho de uma instruo SQL. Voc pode verificar se uma dica foi eficiente avaliando o plano de execuo de uma instruo SQL com ou sem Dica (PRICE, 2009).
Evitar o uso de funes na clausula WHERE, pois aumenta o tempo de execuo das Instrues SQL. Toda vez que houver uma funo na coluna, o ndice no ser usado (PRICE, 2009). Exemplo: Use:
Where NOME=upper(breno);
Ao invs de:
Where lower(NOME)=breno; Ideal: Where NOME=BRENO;
Evitar fazer comparaes com dados incompatveis. O Oracle converte automaticamente os campos char e number, mas para isso consumido recurso desnecessrio, pois o mesmo ter que consultar no dicionrio de dados o tipo da 17
coluna e tentar fazer o converso utilizando os comandos To_char(), To_Number() (VENNAPUSA, 2004). Na clausula Where, sempre que for possvel escolher os campos que fazem parte da chave primria. E sempre colocar as condies mais restritivas por ultimo na clausula Where, pois a maioria dos otimizadores l uma consulta da parte inferior da clausula Where para cima (PRICE, 2009). Usar UNION ALL em vez de UNION quando for possvel, pois o UNION ALL obtm todas as linhas recuperadas por duas consultas, incluindo as linhas duplicadas se houver. J UNION remove as linhas duplicadas se houver, degradando o desempenho da consulta, pois mesmo no havendo linhas duplicadas ele ir verificar (PRICE, 2009).
5.0 CONCLUSO A otimizao de um sistema no banco de dados deve ser considerado desde o inicio do projeto (modelagem do banco de dados), com intuito de conseguir resultados mais satisfatrios, evitando retrabalho futuro com correo de problemas que inviabilizem o desempenho esperado, sabendo-se que muito dos gargalos em um sistema de banco de dados derivam de consultas ou modelo de dados mal estruturados. Existem muitos fatores que podem influenciar o problema de desempenho, existindo casos complexos que fogem a regra mesmo utilizando todas as tcnicas e recursos disponveis, tornando o processo de otimizao de consultas uma tarefa no muito fcil. No entanto, apesar dos grandes progressos do Oracle 11g j realizou, utilizando mecanismos de otimizao automtica e novas funes de estatsticas, ele pode escolher planos de execuo para sentena SQL que no sejam as melhores e que no satisfaam a nossa expectativa, porm quem detm o conhecimento da informao ainda o analista e as decises de acesso so de responsabilidade de quem est programando, tornando-se 18
necessrio o conhecimento de acessos aos dados da Oracle e como influenci-lo obtendo comandos SQL mais eficientes. O processo de otimizao algo que deve ser constante e implantado de forma proativa, pois pequenos ajustes acarretam grandes saltos de desempenho, entretanto, todas as alteraes devem ser premeditadas de modo a no prejudicar outros aspectos do sistema.
19
REFERNCIAS PRICE, J ason. Oracle Database 11g SQL: Domine SQL E PL/SQL no banco de dados Oracle.Traduo J oo Eduardo Nbrega Tortello. Porto Alegre,RS: Bookman, 2009.
WATSON, J ohn. OCA Oracle Database 11g: Administrao I. Traduo Altair Caldas Dias de Moraes. Porto Alegre,RS: Bookman, 2010.
VALIATI, Pedro. ndices no Oracle Parte I: Conceito. Revista SQL Magazine. Edio 36, 2006.
FREEMAN, Robert G. Oracle Database 11g : Novos Recursos. Traduo Arcanjo Miguel. Rio de J aneiro, RJ : Alta Books, 2009.
RANCONI, Vincius. O otimizador do Oracle para desenvolvedores. Disponvel em <http://www.linhadecodigo.com.br/Artigo.aspx?id=724>Acessado em: 28 mar. 2011.
DORNELAS Carlos Alberto. SQL Structured Query Language, 2008. Disponvel em <http://www.cadcobol.com/sql_hist.htm>. Acesso em: 22 fev. 2011.