1

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.

VENNAPUSA, Priya. Oracle Database 10g: SQL Tuning Workshop. Student Guide
Volume 1. Oracle University. 2004.

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.