Tuning de Banco de Dados

Procedimentos do
administrador, focando o
desempenho dos
gerenciadores de banco
de dados (SGBD)
Resumir os principais procedimentos de um profissional de Administrao de
Banco de Dados (DBA), visando manter um bom desempenho do gerenciador
de dados e, desta maneira, preservar os processos de uma organizao.
Introduo
Cada vez mais as organizaes dependem de sua Tecnologia de Informao para o andamento
dos seus processos. Desta maneira, o desempenho da infraestrutura de TI, particularmente dos
gerenciadores de banco de dados, se torna crucial neste cenrio.
Os profissionais de administrao de banco de dados devem definir uma srie de processos
para garantir este desempenho. Segue a diante um resumo destes procedimentos que devem ser
definidos para que os gerenciadores de banco de dados possam ter um desempenho satisfatrio e,
desta maneira, preservar os processos das organizaes.
Avaliao da infraestrutura
A avaliao da infraestrutura de TI, incluindo servidores, redes, desktops etc, so de extrema

importncia para o bom desempenho do ambiente computacional.
Particularmente, para os gerenciadores de banco de dados so necessrios servidores com

capacidade de processamento, memria e operaes de entrada e sada compatveis.
Os processos de avaliao da infraestrutura devero ser contnuos, visto que a necessidade de
hardware e software costuma ser crescentes ao longo do tempo.
De nada adianta fazer um bom trabalho de monitoramento do desempenho nos gerenciadores
de banco de dados e a infraestrutura no atender a demanda que os SGBD necessitam para um bom
trabalho.
Implementar ferramentas
de suporte para avaliao
A avaliao do desempenho de um Sistema Gerenciador de Banco de Dados (SGBD) no

poder ser um processo pontual. Ela dever ser feita ao longo do tempo, acompanhando as
mudanas de desempenho, registrando-as por meio de relatrios estatsticos, grficos etc. Este
procedimento se torna invivel caso seja feita de forma manual.
As ferramentas de avaliao e monitoramento tm condies no somente de automatizar
alguns desses processos e facilitar a vida do DBA, mas tambm de registrar o resultado dessas
avaliaes podendo ser consultadas posteriormente para anlise e tomada de decises.
Manter bem definidos os objetos fsicos

e lgicos
Os SGBD tm como caracterstica a distribuio lgica de seus objetos dentro de tablespaces.

...
... Como forma de melhorar o seu desempenho, podemos distribuir esses objetos como tabelas,
ndices, views etc em tablespaces diferentes e, desta maneira, proporcionando leituras mais
eficientes nos servidores a fim de evitar a sobrecarga de leitura e gravao em uma nica
tablespace, por exemplo.
Manter uma boa sintonia

com as atividades do desenvolvedor
de aplicativos
A maioria dos problemas de desempenho ligados aos bancos de dados oriunda das aplicaes
que o utilizam. Sendo assim, o analista e o programador devero ter conhecimentos dos processos
que podem melhorar ou piorar o seu desempenho. Cabe ao DBA transmitir esses conhecimentos aos
profissionais ligados ao desenvolvimento de sistemas, pois os problemas podero ser tratados de
forma proativa, evitando, assim, manutenes futuras.
Definir e gerenciar os perfis

de acesso dos usurios
Cabe ao administrador definir a poltica de segurana aos dados da organizao garantindo que
os usurios acessem somente as informaes necessrias para os seus processos, evitando
desperdcio no uso e manipulao.
Desta maneira, ele estar assegurando o uso eficiente das informaes e garantindo um bom
desempenho do gerenciador de banco de dados e na segurana no manuseio das informaes.
Com a implantao desta poltica de segurana o administrador poder controlar possveis
tentativas de violaes e roubo de informaes e tambm aes mal intencionadas por parte dos
usurios.
Acompanhar o comportamento
dos gerenciadores de banco de dados
Com o uso de ferramentas de monitoramento dos gerenciadores de banco de dados, o

administrador poder identificar comportamentos no padres no manuseio das informaes,
possveis desvios no seu manuseio e detectar o crescimento inesperado das informaes no banco
de dados. Com isso, ele deve tomar medidas necessrias de ajuste nos espaos fsicos e lgicos
ocupados pelo BD.
Este monitoramento dever ser feito diariamente, semanalmente, mensalmente, e por todo o
tempo de uso do BD, pois situaes atpicas podem aparecer a qualquer momento e quanto mais
rpido forem detectadas essas mudanas, mais rpido podero ser tomadas medidas de ajustes no
ambiente.
Outro aspecto a ser considerado em relao aos gerenciadores de banco de dados que eles
possuem um conjunto de tabelas utilizadas para o gerenciamento do ambiente e para a tomada de
deciso do otimizador. Essas tabelas esto localizadas no dicionrio de dados.
Entre as informaes contidas nelas, existe uma srie de estatsticas tanto dos objetos como
das aplicaes que acessam o banco de dados. O otimizador utiliza as informaes dessas
estatsticas para escolher o melhor caminho a ser feito por um comando SQL quando ele for
executado.
Algumas das informaes dessas estatsticas so atualizadas automaticamente pelo
gerenciador e outras tm que ser feitas por meios de comandos, por exemplo, a quantidade de
fragmentao de um objeto.
Cabe ao administrador manter essas estatsticas atualizadas para que o otimizador sempre
tome as melhores decises a respeito do caminho a ser utilizado por um comando SQL e tambm
para uma avaliao precisa das condies de desempenho de um SGBD.
Treinamento e apoio para analistas

e programadores
O administrador de banco de dados tem a responsabilidade pelo desempenho de todos os

profissionais envolvidos no desenvolvimento das aplicaes como os analistas e programadores.
Desta maneira, fica a seu encargo prover todo o apoio e treinamento a esses profissionais para que
eles faam o uso eficiente.
Tambm faz parte das medidas de apoio a avaliao dos comandos de acesso e manipulao
dos bancos de dados envolvidas nas aplicaes antes delas irem para a produo.
Neste contexto o administrador poder avaliar os comandos das aplicaes submetendo-os,
como exemplo, ao comando EXPLAIN PLAN do SQL, pois ele ir fornecer uma srie de informaes a
respeito do comando como, seu custo, quantidade de linhas a serem processadas, se estar
utilizando o ndice ou no e outras informaes necessrias para a anlise.
Desta maneira, a administrador poder avaliar com preciso se o comando SQL a ser utilizado
nas aplicaes o far de maneira eficiente ou no.
Planejamento, implantao
e acompanhamento dos procedimentos de backup e
recovery
Um dos processos mais importantes definido pelo administrador a poltica de backup e

recuperao dos bancos de dados, pois ela que ir definir tanto o aspecto da disponibilidade das
informaes para os usurios e a poltica de segurana na recuperao das informaes em caso de
perda ou alguma manipulao indevida.
Neste processo dever ser definido, por exemplo, quanto tempo o banco de dados poder ficar
indisponvel para o usurio, quanto tempo as informaes devero estar disponveis no banco, se um
ano, cinco anos, etc. Estas questes iro definir a poltica de backup e recuperao de dados que o
administrador dever implementar.
A poltica dever ter controle de qualidade rigoroso e processos bem definidos em relao ao
armazenamento das mdias, vida til, ambiente onde elas sero guardadas, quem ir manipul-las,
testes de recuperao de dados, entre outros.
Agora que voc j estudou esta aula, resolva os exerccios e verifique seu conhecimento. Caso fique alguma dvida, leve a questo ao
Frum e divida com seus colegas e professor.
Referncias
BOSCATTO, R.; DAMINELLO, M.R. Instituto municipal ensino superior de So Caetano do Sul, 1999.
BRYLA, B.; Loney, K. Oracle Data Base 10g manual do DBA. So Paulo: Campus, 2005.
CARATTI, R. Ajustes de Desempenho em "Consultas Simples" na SQL, SQL Magazine 11, 2004.
Disponvel em: www.devmedia.com.br. Acesso em: 22 jan. 2013.
JARKE, M.; KOCH, J. Query optimization in database system. ACM computing servers, 1984.
KOCK, G.; KEVIN, L. Oracle 8: The complete reference. Oracle Press, 1997.
MORELLI, Eduardo Terra. Oracle 9i Fundamental: SQL, PL/SQL e Administrao. So Paulo: rica,
2012.
NIEMIEC, Richard J. Oracle Database 10g performance tuning tips & techniques. New York:
McGraw-Hill, 2007.
ORACLE Database Performance Tuning Guide, Copyright 2000, 2011, Oracle and/or its affiliates.
All rights reserved. Disponvel em: docs.oracle.com. Acesso em 21 jan. 2013.
PARRA, L.S. (2005). Tuning de Desempenho em Banco de Dados. Londrina-UEL Universidade
Estadual de Londrina. Dissertao de Mestrado. Disponvel em: www2.dc.uel.br. Acesso em 21 jan.
2013.
PATTERSON, D. A; Gibson, G; Katz, R.H; A case for redundant arrays of inexpensive disks (RAID).
Proc. ACM Conf. on management of data, 1988.
SILVA, Robson S. Oracle Database 10g. Express Edition. So Paulo: rica, 2007.
Aumentando o
desempenho de uma
aplicao por meio de
processos de refinamento
do ambiente onde ser
utilizada a linguagem SQL
do banco de dados
Resumir o ambiente onde devero ser utilizados os comandos SQL de uma
aplicao para manipulao dos bancos de dados relacionais, identificando os
principais processos a serem considerados, visando melhoria do
desempenho dessas aplicaes.
Introduo
O processo de aperfeioamento de um comando SQL dever ser feito bem antes de estar em
fase de produo, ou seja, dever ser visto inicialmente pelos programadores e analistas que esto
projetando a aplicao. Para isto se faz necessrio o treinamento destes profissionais para que eles
tenham conhecimento dos fatores que podero influenciar o desempenho de uma aplicao.
Aps eles elaborarem a aplicao, devero passar por um processo de avaliao para verificar
se esto atendendo requisitos de qualidade neste aspecto.
A anlise proativa sobre o desempenho do sistema a abordagem mais eficiente e evita esse
cenrio. Para que isso seja possvel, preciso que os executivos da empresa colaborem com os
projetistas, no sentido de estabelecer metas justificveis de desempenho, fixando expectativas reais
desde o incio. (CARATTI, 2004).
O tipo de aplicao tambm um fator importante nesta anlise, pois uma aplicao OLTP (On
Line Transaction Process) se caracteriza por ser uma aplicao com muitos I/O (Input/Output), ou
seja, atua nos processos empresariais como compras, vendas, produo, pagamentos, recebimentos
etc, e fazem gravao no banco de dados destas informaes.
Por outro lado, existem as aplicaes de data warehouse que se caracterizam por serem
aplicaes que manipulam uma quantidade muito grande de dados e que costumam ter consultas
SQL bastante complexas.
Faremos agora uma anlise de cada um desses processos:
Processos avaliando as regras de negcio
Esses processos devero avaliar aspectos ligados aos negcios do ambiente como nmero de
usurios envolvidos na aplicao, tempos de resposta permitidos para cada aplicao, entre outros.
Alm disso, eles visam ajustar necessidades dos usurios s de informaes no banco de dados.
Por exemplo, o caso de um usurio que necessita de informaes comerciais dos ltimos cinco
anos, obtida de um dia para outro ou precisa da informao naquele momento. No caso de poder
obter a informao no dia seguinte, a informao poder ficar em um banco de dados de histrico e
no no de informaes correntes do dia a dia.
Desta maneira, o administrador poder separar estas informaes e tornar o BD mais eficiente
para as operaes rotineiras, deixando as histricas em outro ambiente ou tablespace, por exemplo.
Processos avaliando o projeto dos dados do banco de dados
Todo projeto de desenvolvimento de um banco de dados comea com a fase de modelagem, e

as fases de normalizao. Nesta fase, caso seja possvel, dever ter a participao de um
administrador de banco de dados, pois alm de considerar a questo de negcios do banco, ir
tambm considerar aspectos de desempenho.
Um banco de dados mal modelado ir gerar problemas de desempenho por todo o tempo de
uso deles, independentemente das aplicaes serem desenvolvidas de maneira eficiente ou no. O
ideal que o processo de modelagem considere pelo menos at a Terceira Forma Normal (3FN).
Processos avaliando o projeto das aplicaes
Um dos principais fatores que influenciam o desempenho das aplicaes o uso de ndices nas
pesquisas dos dados.
Toda vez que o SGBD detecta que existe um ndice em uma pesquisa, ele no far a varredura
de uma tabela, e ir buscar a informao diretamente no ndice correspondente.
Portanto, os processos de avaliao das necessidades de ndices nas aplicaes so de
extrema importncia e levaro a um ganho de desempenho significativo. Entretanto, no podemos
esquecer que o SGBD mantm uma integridade entre os dados das tabelas e os seus ndices, ou
seja, toda vez que houver uma atualizao em uma coluna indexada ele tambm far a atualizao
nos ndices correspondentes.
Desta maneira, as aplicaes que fazem muitas atualizaes nos dados tambm a faro muitas
nos ndices. Sendo assim, elas devero ser avaliadas, e se deve verificar a possibilidade delas serem
executadas em horrios pr-determinados, para que o desempenho do ambiente no seja afetado.
Processos avaliando as operaes do Sistema Gerenciador

do Banco de Dados (SGBD)
Esses processos devero considerar aspectos como o uso do banco de dados de maneira
eficiente, ou seja, devem-se evitar comandos SQL complexos dentro das aplicaes, pois muito
mais eficiente para o gerenciador processar mais comandos simples do que um nico comando SQL
complexo.
Tambm das aplicaes irem para a produo, interessante fazer sua avaliao, por exemplo,
por intermdio do comando explain plan que fornece uma srie de informao a respeito do
comando como se usam ndices ou no, quantidades de linhas processadas, custo, entre outras.
Comandos SQL que ordenam as linhas (order by, group by) devem ser evitados e usados
somente em caso de extrema necessidade, pois toda vez que houver um comando destes o
gerenciador ir trazer as linhas da tabela correspondente para a memria e depois ir classific-las e
normalmente desconsidera o uso de ndices. Outro aspecto a ser evitado nos comandos SQL a
comparao de dados incompatveis, ou seja, compara campos numricos com campos
alfanumricos, por exemplo.
Toda vez que o gerenciador identificar uma situao, dessas ele ir fazer a converso de um
dos campos para que os dois tenham as mesmas especificaes e, desta maneira, poder afetar o
desempenho do comando e da aplicao.
Processos avaliando a memria utilizada pelo SGBD
A quantidade de memria a ser fornecida para o SGBD tambm pode afetar o seu
desempenho, ou seja, se fornecemos pouca memria, ele no conseguir trazer todos os objetos
para a memria quando necessitar, s ir trazer o que couber na memria. Em seguida, ele utiliza,
libera e vai buscar outro objeto provocando muitas atividades de swap no sistema operacional.
Entretanto, a memria do servidor no somente do gerenciador, pois tambm tem que ser
dividida com o sistema operacional, ou seja, tambm no adianta fornecermos uma quantidade
excessiva de memria para o gerenciador e deixarmos o sistema operacional com memria
insuficiente.
Os processos ligados alocao de memria devero fazer uma anlise e identificar a
quantidade precisa tanto para o gerenciador como para o sistema operacional. No caso do
gerenciador devero ser avaliados os parmetros de shared pool, bufffer cache, log buffer, entre
outros.
Processos avaliando as operaes de I/O (input/output) de

dados
necessrio existir processos para avaliar as entradas e sadas das aplicaes, pois este um
item que poder afetar o desempenho dos gerenciadores de banco de dados. Dever ser evitado
rodar outras aplicaes nos servidores de banco de dados, pois, assim, far concorrncia com as
operaes do gerenciador.
Outro aspecto importante a diviso dos objetos do banco em unidades de discos separadas
como tabelas em uma e ndices em outra, como exemplo, e, desta maneira, evitar o gargalo em uma
nica unidade.
A questo da fragmentao dos objetos como tabelas, ndices e tablespaces tambm dever
ser levada em considerao, pois isto costuma degradar o desempenho nas leituras e gravao das
informaes no meio fsico.
Processos avaliando a alocao dos recursos do banco de

dados
Uma caracterstica importante dos gerenciadores de banco de dados que eles no permitem
que dois usurios acessem a mesma informao para atualizao ao mesmo tempo.
Para isto eles dispem de um mecanismo de trava (Locks) para os dados assim que o primeiro
usurio os requisita para atualizao. Essa trava s encerrada assim que a aplicao conclui o seu
servio, ou seja, assim que a sesso relativa aplicao se encerra, tanto de maneira satisfatria
(commit) ou insatisfatria (rollback).
tarefa do administrador de banco de dados avaliar se essas aplicaes esto solicitando os
dados necessrios para atualizao, ou seja, evitar travar dados desnecessrios para a aplicao e
prejudicar o desempenho da aplicao e do ambiente. Os gerenciadores podem travar tanto algumas
linhas de uma tabela como uma tabela inteira, dependendo da necessidade das aplicaes.
Depois de rever o contedo desta aula, solucione os exerccios de mltipla escolha propostos. Lembre-se de que voc poder postar
suas dvidas no Frum e ter auxlio de seus colegas e professor.
Referncias
Disponvel em:www.devmedia.com.br. Acesso em: 22 jan. 2013.
JARKE, M.; KOCH, J. Query optimization in database system. ACM computing servers, 1984.
2012.
McGraw-Hill, 2007.
PATTERSON, D. A; Gibson, G; Katz, R.H; A case for redundant arrays of inexpensive disks (RAID).
Proc. ACM Conf. on management of data, 1988.
SILVA, Robson S. Oracle Database 10g. Express Edition. So Paulo: rica, 2007.
Avaliao do desempenho
das consultas SQL
utilizadas nas aplicaes
Dar uma viso dos principais cuidados a serem tomados na elaborao dos
comandos SQL utilizados em uma aplicao, para que eles acessem os dados
dos BD de forma eficiente e da melhor maneira possvel sem comprometer o
desempenho da aplicao e o ambiente do BD como um todo.
Introduo
Existe uma srie de cuidados a serem tomados na elaborao de um comando SQL de acesso e
manipulao das informaes nos banco de dados. No filtro desses acessos, devero ser tomados
cuidados para que ele no faa varredura nas informaes das tabelas, pois isso se torna oneroso
para o gerenciador, particularmente em tabelas com um nmero muito grande de linhas.
Outro aspecto a ser considerado nesses filtros de acesso que devemos fornecer um maior
nmero possvel de informaes para pesquisa, pois quanto menos informaes fornecermos, mais
trabalho o gerenciador ir ter para conseguir buscar aquilo que pedimos e, consequentemente, pior
ser o desempenho da aplicao e do ambiente.
Vejamos uma descrio desses cuidados.
Quantidade de informaes fornecidas na clusula Where
Os filtros de pesquisa dos comandos de acesso aos bancos de dados SQL devero receber
informaes da forma mais precisa possvel para encontrar o que esta procurando, pois quanto
menos informaes forem fornecidas, mais trabalho o gerenciador ter para encontrar o dado
procurado e, desta maneira, poder prejudicar o desempenho da aplicao e tambm do ambiente
como um todo.
Vamos considerar os trs exemplos de filtro de pesquisa a seguir:
Cenrio 1 -... WHERE endereo LIKE ?Rua%? AND nome LIKE ?Joao%?
Cenrio 2 -... WHERE nome <> ?Pedro?
Cenrio 3 -... WHERE codigo = 5
No caso dos cenrios 1 e 2 o gerenciador dever fazer uma busca em toda a tabela, pois no
sabe exatamente o que procurar. No caso do cenrio 3 o gerenciador sabe exatamente o que
procurar, e a pesquisa ser mais eficiente, pois alm de ter informao precisa, ainda poder utilizar
um ndice, caso exista.
Desta maneira, fica claro que os filtros de pesquisa devero ter, na medida do possvel,
informaes cada vez mais precisas, pois iro proporcionar um bom desempenho na aplicao que
utiliza o cdigo SQL e no ambiente.
Consultas simples envolvendo uma pequena quantidade de

dados e com filtros simples
Quanto mais simples for o comando SQL mais facilmente o otimizador ir atender a
necessidade da aplicao e do usurio, pois comandos que manipulam muitas linhas e com
consultas altamente complexas iro gerar um trabalho para o otimizador resolver, o que poder
afetar o desempenho do comando e do ambiente.
O ideal ao invs de se fazer um comando SQL complexo deve-se fazer mais de um comando
SQL simples, pois, assim, o BD ter um desempenho melhor.
Desempenho dos tipos de operadores de comparao
O desempenho de um comando SQL depende, entre outros fatores, do filtro de pesquisa na

clusula Where quando se est buscando alguma informao.
Quanto mais exatas forem as informaes passadas neste filtro de pesquisa, melhor ser o
desempenho do comando SQL no acesso aos dados. Esta exatido diretamente ligada ao tipo de
operador utilizado no filtro de pesquisa de um comando SQL.
Existe um quadro que informa a pontuao relativa ao desempenho de cada tipo de operador
em um filtro de pesquisa; quanto maior a pontuao melhor ser o desempenho no uso deste
operador.
Tipo de operador no filtro Pontuao relativo ao desempenho
=
10
>
>=
<
<=
LIKE
<>
Podemos concluir de acordo com o quadro que o operador igual (=) o que oferece a maior
preciso ao ser utilizado em um filtro de busca. Por outro lado, o pior operador a ser utilizado em
termos de desempenho o operador diference (<>), no qual seu uso dever ser evitado.
Tipo de operador no filtro Pontuao relativo ao desempenho

=
10
>
>=
<
<=
LIKE
<>
Podemos concluir de acordo com o quadro que o operador igual (=) o que oferece a maior
preciso ao ser utilizado em um filtro de busca. Por outro lado, o pior operador a ser utilizado em
termos de desempenho o operador diference (<>), no qual seu uso dever ser evitado.
Ordem das colunas em uma expresso no filtro de pesquisa
As colunas envolvidas em um filtro de pesquisa devero estar, caso seja possvel, na mesma
ordem que se encontram nas respectivas tabelas dos BD e tambm, caso exista a mesma coluna
sendo referenciada mais de uma vez no filtro, ela dever estar junta, pois o otimizador do BD ir
fazer isto na hora que a pesquisa for feita.
No caso de j podermos colocar as colunas nesta ordem iremos poupar o otimizador desta
tarefa e naturalmente teremos um ganho de desempenho.
O modelo a seguir mostra um exemplo desta pesquisa em que as expresses da clusula
Where j esto com as colunas na ordem ideal, ou seja, na mesma ordem em que foram criadas no
BD.
SELECT * FROM Clientes
WHERE codigo = 20 and
AND Vendas = 5000.00
AND nome = ?Joo?
AND descontos < 2.000,00
AND juros > descontos
Avaliao de letras maisculas e minsculas
Uma questo importante no ambiente e que acaba interferindo no desempenho dos comandos
SQL so as letras maisculas ou minsculas, pois os gerenciadores tratam de maneira diferente cada
uma dessas letras. Para que esta questo no afete o desempenho das pesquisas, devemos definir o
ambiente com um dos dois tipos de letras e deixarmos como padro.
No momento da pesquisa podemos alterar o formato para o padro que precisarmos,

entretanto, a converso se torna onerosa, pois deveremos usar funes para esta converso, ou
seja, UPPER para a converso maiscula e LOWER para a converso minscula.
Essas ou outras funes acabam desconsiderando os ndices, caso eles existam, portanto,
devero ser utilizadas somente em caso de necessidade e no como um procedimento corriqueiro.
Desta maneira, um padro definido para todo o ambiente e respeitado por todos melhora o
desempenho consideravelmente.
Uso de funes nas pesquisas dos comandos SQL
As funes tm um poder muito grande na manipulao dos dados nos comandos SQL,
entretanto, elas normalmente no consideram os ndices para as colunas, caso existam, no momento
da pesquisa.
Desta maneira, seu uso dever ser feito somente no caso de grande necessidade, pois se de
um lado ela oferece flexibilidade, por outro lado, afeta o desempenho do comando SQL.
Ordem dos operadores e operando nos filtros
Assim como nas linguagens de programao, a ordem das perguntas sempre respeitam o
operador na esquerda e o a direita, separados pelos operadores lgicos.
Se esta ordem no for respeitada, entretanto, os comandos SQL devero aceitar como vlido o
comando, porm o otimizador ir fazer as alteraes necessrias colocando na ordem padro.
J que ele ir alterar a ordem devemos, portanto, manter o formato padro, a fim de evitar um
trabalho a mais para o otimizador, afetando o desempenho do comando SQL.
Vejamos o exemplo a seguir:
20.00 = vendas alterado para: vendas = 20.00
WHERE vendas 40,00 = - comisso
alterado para: Comisso = - vendas+40,00
Operadores AND e OR envolvidos nos comandos SQL
Os operadores AND e OR de um comando SQL obedecem a um critrio na avaliao quando

so executados pelo gerenciador, ou seja, no caso do operador AND ele testa a primeira condio, no
caso dela ser verdadeira ele vai testar a segunda condio. J no caso da segunda ser verdadeira ele
vai testar a terceira condio, e assim por diante. Desta maneira, se a primeira condio for falsa o
gerenciador nem ir testar a segunda condio.
Aproveitando esta lgica, deveremos colocar a condio menos provvel primeiro, pois, se a
condio for falsa, ele nem ir testar a segunda condio, ganhando em desempenho.
Como exemplo deste conceito pode ilustrar:
Where comisso = 0 and vendas > 1000.00
Considerando que a condio de comisso = 0 a menos provvel.
No caso do operador OR, ele testa a primeira condio, se for verdadeira ele nem vai testar a
segunda condio, ou seja, s vai testar a segunda condio caso a primeira seja falsa, e s vai
testar a terceira caso a segunda seja falsa.
Aproveitando essa lgica, deveremos colocar a condio mais provvel primeiro, pois se a
condio for verdadeira ele nem ir testar a segunda, ganhando em desempenho.
Como exemplo desse conceito, pode-se ilustrar:
Where vendas > 1000.00 OR comisso = 0 OR lucro > 1.000,00
Considerando que a condio de vendas > 1000.00 a mais provvel.
Agrupamento de colunas iguais no uso do OR em um

comando SQL
Quando temos vrios operando com uma mesma coluna em um comando SQL o ideal que as
operaes com a mesma coluna estejam juntas, pois o gerenciador ir ler a coluna uma nica vez e,
assim, estar ajudando no desempenho do comando SQL e do ambiente.
Considerando o exemplo a seguir, podemos ver:

Where codigo = 10 OR
vendas > 1000.00 OR
codigo = 20
Dever ser colocada na seguinte ordem:
Where codigo = 10 OR
codigo = 20 OR
vendas > 1000.00
Operador de desigualdade NOT
Sempre que possvel a utilizao da expresso NOT dever ser evitada, pois em uma pesquisa
na qual se informa o que no se quer o gerenciador ir fazer uma varredura nas linhas de uma
tabela, podendo afetar a performance da aplicao.
Sempre que possvel a pergunta dever ser feita pela expresso verdadeira e no pela
expresso falsa.
Vejamos no seguinte exemplo:
... WHERE NOT (vendas > 100.00)
Dever ser substituda por
... WHERE vendas <= 100.00
Referncias
JARKE, M.; KOCH, J. Query optimization in database system, ACM computing servers, 1984.
2012.
McGraw-Hill, 2007.
PATTERSON, D. A; Gibson, G; Katz, R.H. A case for redundant arrays of inexpensive disks (RAID),
1988.
SILVA, Robson S. Oracle Database 10g Express Edition. So Paulo: rica, 2007.
Avaliao dos
mecanismos de travas
(Locks) dos SGBD nas
atualizaes das
informaes
Observar os procedimentos adotados pelos gerenciadores de banco de dados
nos processos de consulta e atualizao das informaes, considerando a
concorrncia dos usurios dessas.
Introduo
A concorrncia pelas informaes armazenadas nos bancos de dados cada vez maior, visto
que quase todos os processos das organizaes dependem das informaes para serem realizados.
Como exemplos, podemos citar a internet como um meio para as organizaes realizarem as
operaes de vendas de seus produtos. Desta maneira, a necessidade pelas informaes vem sendo
cada vez maior e isto dever ser controlado para que elas tenham a sua integridade mantida.
Neste cenrio, os SGBD desenvolveram um mecanismo para garantir que a mesma informao
no seja atualizada por mais de um usurio ao mesmo tempo, conhecido como travas ou locks. A
partir do momento que um determinado usurio solicita uma informao para atualizao o
gerenciador de banco de dados a bloqueia para outros usurios at que o processo de atualizao do
primeiro usurio seja concludo.
Locks dos gerenciadores de banco de dados
O conceito de lock consiste de manter um dado locado por uma seo, ou seja, um usurio que
acessou a informao para atualizao ate que a seo seja concluda com sucesso (commit) ou sem
sucesso (rollback).
Estrutura do lock no SGBD Oracle
A estrutura do lock do SGBD Oracle bastante eficiente e sofisticada, chegando a ser melhor
que os demais gerenciadores como o DB2 e SQL-Server.
O gerenciamento do lock do Oracle feito totalmente no cabealho do bloco em que reside o
registro, enquanto que os demais gerenciadores de BD, como o DB2, feito por um gerenciador de
locks, ou seja, o lock manager.
Esta estrutura mais eficiente, pois como o gerenciamento feito no prprio cabealho do
registro evita possveis gargalos no caso de grandes atualizaes no banco de dados.
Existem duas estruturas de locks feitos pelos gerenciadores de banco de dados, ou seja, os
locks para tratamento de linhas e os locks para tratamento de tabelas.
Locks para tratamento de linhas
Este tipo de lock utilizado quando necessitamos fazer uma atualizao em uma ou mais
linhas da tabela.
A partir do momento que estas linhas esto sendo atualizados pelo gerenciador, os demais
usurios que necessitarem de uma atualizao no conseguiro at que a seo relativa a esta
atualizao esteja encerrada, quer seja a atualizao com sucesso (commit) ou no tenha sucesso
na atualizao (rollback).
Evidentemente essas linhas, enquanto atualizadas, podero ser consultadas por outros
usurios ou processos sem nenhum problema, e tambm podero ser atualizadas outras linhas por
outros usurios.
Em relao ao desempenho da aplicao e ao ambiente, o ideal que ela faa bloqueio
somente nas linhas necessrias que sero atualizadas e preferencialmente faa o bloqueio na hora
que ela for atualizada, evitando, assim, o bloqueio de linhas por um longo tempo.
Locks para tratamento de tabelas
Este tipo de lock utilizado quando necessitamos fazer uma atualizao em uma tabela inteira.
Quando este tipo de lock solicitado, o gerenciador faz cpia da tabela na memria para
providenciar as alteraes e a bloqueia para que ningum faa alteraes em suas linhas enquanto a
tabela estiver sendo atualizada.
Aplicaes que fazem bloqueio em uma tabela inteira devero ser executadas em horrios prdeterminados a fim de evitar problemas de desempenho no ambiente, ou seja, enquanto esta
aplicao estiver bloqueando a tabela toda nenhuma outra aplicao ir conseguir atualizar outra
linha desta tabela, somente ir consulta-las.

A tabela que gerencia os locks do ambiente no caso do gerenciador Oracle a tabela V$LOCK.
No caso especfico do gerenciador Oracle existe vrios tipos de locks, cada um com caractersticas
diferentes. Os tipos de locks do Oracle so descritos a seguir:
Row Share (RS)
Este tipo de lock tem como principal caracterstica o bloqueio das linhas antes de fazer as
alteraes, ou seja, possui linhas locadas, mas ainda no efetuou a alterao nelas.
Em termos de desempenho no a melhor soluo, pois se forem alocadas muitas linhas, elas
ficaro indisponveis para outros usurios enquanto suas alteraes no forem concludas.
Os comandos que solicitam este tipo de lock so:

SELECT...... FROM nome_tabela FOR UPDATE
LOCK TABLE nome_tabela IN ROW SHARE MODE
Row Exclusive (RX)
Este tipo de lock tem como principal caracterstica o bloqueio das linhas no momento em que
forem alteradas, ou seja, possui linhas locadas, e as alteraes esto sendo feitas. mais eficiente
em termos de desempenho, pois as linhas so bloqueadas somente no momento da alterao, com o
tempo de bloqueio menor.
Em termos de desempenho, o comando SQL que ir fazer as alteraes deve ser eficiente para
efetuar o bloqueio somente nas linhas que sero alteradas e no bloquear linhas que no sofrero
alteraes, evitando desperdcio de recursos.
Os comandos que solicitam este tipo de lock so:
INSER INTO nome_tabela
UPDATE nome_tabela
DELETE FROM nome_tabela
LOCK TABLE nome_tabela IN ROW EXCLUSIVE MODE
Share (S)
Este tipo de lock tem como principal caracterstica permitir que mais de uma seo possa obter
o lock de uma tabela, entretanto, o gerenciador somente ir fazer os comandos DML de uma seo
por vez, ou seja, quando uma seo encerra, normal ou anormalmente, que o gerenciador efetua
os comandos DML das demais sees.
O comando que solicita este tipo de lock :

LOCK TABLE nome_tabela IN SHARE MODE
Share Row Exclusive (SSX)
Este tipo de lock tem como principal caracterstica permitir que somente uma seo possa
obter o lock de uma tabela, ou seja, um pouco mais restritivo que o locks. Ele permite tambm o
bloqueio de algumas linhas, entretanto, somente os comandos DML aps encerrar a seo da tabela.
LOCK TABLE nome_tabela IN SHARE ROW EXCLUSIVE MODE
Exclusive (X)
Este tipo de lock tem como principal caracterstica ser o mais poderoso de restrio entre todos
os outros, pois permite que as outras sees acessem as linhas somente para consultas.
Outra caracterstica importante deste tipo de lock que ele pode ser aplicado somente para o
bloqueio de linhas, ou seja, quando uma linha estiver travada nenhuma aplicao poder emitir um
comando DML para ela at que seo se encerre normalmente (Commit) ou anormalmente
(Rollback).
Este tipo de lock obtido automaticamente por meio dos comandos Insert, Update e Delete.
LOCK ROW EXCLUSIVE MODE
Dead lock
Quando dois ou mais usurios esto esperando por acesso a dados que um usurio bloqueou
para o outro conhecido como um dead lock ou impasse.
Quando ocorre este conflito, as transaes deixam de ir em frente, pois elas ficam presas.
Nestes casos, os SGBD quebram o impasse, forando uma ou mais transaes a serem desfeitas.
Se o bloqueio padro dos SGBD so substitudos em qualquer nvel, o administrador de banco
de dados ou o desenvolvedor do aplicativo deve garantir que os procedimentos de bloqueio devam

funcionar corretamente, dando garantia da integridade e simultaneidade dos dados.
Concluso
O bloqueio ou locks uma parte muito importante de qualquer sistema de base de dados. O
mais interessante utilizar o bloqueio implcito dos sistemas gerenciadores.
Caso muito necessrio, deve-se usar o bloqueio manual, pois utilizando os bloqueios implcitos
os gerenciadores garantem a maior consistncia, integridade e simultaneidade dos dados.
Referncias
BRYLA, B.; Loney, K.Oracle Data Base 10g manual do DBA.So Paulo: Campus, 2005.
JARKE, M.; KOCH, J.Query optimization in database systemACM computing servers, 1984.
2012.
NIEMIEC, Richard J. Oracle Database 10g performance tuning tips & techniquesNew York: McGrawHill, 2007.
1988.
BAM, A. Oracle Locks Parte 1. SQL Magazine.Dev Media, 313, 2005. Disponvel em:
www.devmedia.com.br. Acesso em: 22 jan. 2013.
CARATTI, R. Ajustes de Desempenho em "Consultas Simples" na SQL,SQL Magazine 11,2004.
ORACLE.Database Performance Tuning Guide,Copyright 2000, 2011, Oracle and/or its affiliates.
Disponvel em: docs.oracle.com. Acesso em 21 jan. 2013.
2013.
Criando um cenrio e
simulando o mecanismo
de trava (lock) do
gerenciador de banco de
dados Oracle e os
mecanismos de
identificao e remoo,
atravs dos comandos
apropriados
Praticar a simulao do mecanismo de trava (lock) do Oracle, identificando os
objetos geradores e os que foram prejudicados pelo lock gerado, removendo
esta trava por meio da eliminao utilizando comandos apropriados.
Introduo
A eficincia do ambiente dos bancos de dados depende da utilizao dos recursos, portanto,
tarefa do administrador torn-los o mais disponvel possvel para que os processos de negcios no
sejam prejudicados.
Bloqueios do gerenciador de banco de dados Oracle
Os processos de identificao das travas (locks) devero ser feitos de maneira eficiente para
que os recursos sejam utilizados da melhor maneira possvel.
Cabe ao administrador, por meio de comandos, identificar essas travas, com mecanismos
eficientes buscar qual a seo que est causando a trava e qual a que esta sendo prejudicada.
Existem dois tipos de bloqueis do gerenciador de banco de dados. Primeiro, temos o bloqueio
explcito, ou seja, feito pelo prprio administrador quando quer fazer uma manuteno em algum
objeto do banco de dados e feito por meio dos comandos lock table.
Existe tambm o bloqueio implcito que o prprio sistema gerenciador de banco de dados
cria quando emitimos um comando DML, ou seja, INSERT, UPDATE ou DELETE. Este bloqueio
somente liberado quando emitido um comando com a efetivao da seo (commit) ou caso ela
no tenha ocorrido com sucesso (rollback).
Uma vez identificados s respectivas sees, deve-se tomar medidas para eliminar o impasse
por meio da remoo das sees que esto sendo prejudicadas.
Vale ressaltar que a maioria dos problemas de trava resolvida pelo prprio gerenciador pelo
mecanismo de filas do Oracle e demais gerenciadores. Entretanto, muito importante uma anlise
proativa do administrador de banco de dados nas aplicaes para que este problema no venha
ocorrer, analisando as aplicaes e identificando aquelas que bloqueiam os recursos do gerenciador
por um longo perodo de tempo.
Caso existam estas aplicaes, os desenvolvedores devero ser orientados para aplicar o
mecanismo de efetivao (commit) para que os recursos sejam liberados o mais rpido possvel.
A seguir faremos uma simulao do mecanismo de trava do Oracle; em seguida, utilizaremos

os comandos para identificao e, posteriormente, faremos a eliminao desta situao, por vrios
passos.
Passo 1: criar um perfil para usurio, restringindo-o para usar uma seo por vez no Oracle,
atravs do usurio system.
O contedo desta pgina requer uma verso mais recente do Adobe Flash Player.
Passo 2: criar um primeiro usurio para ser utilizado na simulao.
Content on this page requires a newer version of Adobe Flash Player.
Passo 3: criar um segundo usurio para ser utilizado na simulao.
Passo 4: dar autorizao para os usurios isi_simulacao_01 e usu_simulacao_02 criar tabelas e

se conectar no Oracle.
Passo 5: conectar-nos ao usurio usu_simulacao_01 e criar uma tabela cliente para simular a
trava e inserir 2 linhas. Finalmente, devemos efetivar as implementaes.
Passo 6: uma vez criada a tabela cliente pelo primeiro usurio, devemos dar permisso de
update na respectiva tabela para o segundo usurio.
Passo 7: ainda no primeiro usurio devemos fazer uma atualizao na tabela cliente para
poder simular a situao de trava pelo Oracle.
Passo 8: abrir uma nova seo com o usurio usu_simulacao_02 e fazermos uma mesma
atualizao no mesmo cliente.
Para fazermos o update, temos que informar o usurio em que foi criada a tabela cliente, pois
ela no foi criada por este usurio.
Percebemos que neste momento o gerenciador Oracle mostra a trava (lock) feita no cliente
com o CNPJ igual a 67890120002132, pois o mesmo cliente est sendo atualizado pelo usurio
usu_simulacao_01 e a seo ainda no foi finalizada (commit). Neste caso a seo do usurio
usu_simulacao_02 fica aguardando a atualizao feita na seo do usurio usu_simulacao_01 ser
concluda, ou seja, alguma emisso do comando commit.
Passo 9: uma vez criada a trava pelo Oracle devemos agora identificar qual a seo que est
causando o impasse para, posteriormente, eliminarmos.
Para isso, devemos voltar a seo do administrador, ou seja, system.
Passo 10: podemos identificar tambm qual a seo que esta causando o impasse, por meio
da seguinte consulta:
Passo 11: podemos tambm identificar que objeto est causando o lock:
O objeto causador do lock a tabela CLIENTE.
Passo 12: identificar qual a seo que est aguardando a soluo do impasse.
Passo 13: podemos tambm identificar a seo que causou o lock e a seo que esta
aguardando a liberao do lock por meio de um join.
Passo 14: como podemos resolver os conflitos de locks

Os conflitos de lock podero ser resolvidos ou pela emisso de um commit na seo que esta
causando o lock ou por meio do trmino da respectiva seo.
A emisso desse commit poder ser feita caso o usurio encerre a aplicao que esta utilizando
a seo.O encerramento da seo poder ser feito tambm, de maneira mais dramtica, pelo
comando KILL do Oracle.
Primeiro, temos que encontrar o identificador e o serial number da seo que esta causando o
lock, por meio do seguinte comando:
Posteriormente, eliminamos a seo que esta causando o lock, por meio do comando a seguir:
Referncias
2012.
McGraw-Hill, 2007.
1988.
BAM, A. Oracle Locks Parte 1. SQL Magazine. Dev Media, 313, 2005. Disponvel em:
ORACLE. Database Performance Tuning Guide, Copyright 2000, 2011, Oracle and/or its affiliates.
Disponvel em: http://docs.oracle.com. Acesso em 21 jan. 2013.
2013.
SOARES, F. Conflitos de Bloqueios, Blog de Flvio Soares, 2009. Disponvel em:
http://profissionaloracle.com.br. Acesso em: 22 jan. 2013.
Fazendo um estudo da
estrutura fsica e lgica
do gerenciador de banco
de dados Oracle
Detalhar a estrutura fsica e lgica do gerenciador de banco de dados Oracle
para que todos tenham uma viso do funcionamento desta estrutura.
Introduo
Os gerenciadores de banco de dados, particularmente do Oracle, tm uma estrutura bastante

complexa para o seu funcionamento, a qual se torna necessria para que eles tenham um
desempenho aceitvel nas questes de segurana, concorrncia, armazenamento, integridade e
principalmente de performance.
Esta estrutura abrange aspectos de armazenamento fsico atravs dos data files do sistema
operacional e armazenamento lgico por meio de tablespaces, segmentos, extents e blocos de
dados Oracle.
Os quadros a seguir nos do uma viso grfica destas estruturas.
Estrutura fsica e lgica do banco de dados Oracle
Estrutura fsica
Estrutura Fsica do Banco de Dados Oracle. Objetivo: Mostrar os arquivos que compe a estrutura fsica do gerenciador de banco de dados
Oracle.
Composta pelos arquivos que so estabelecidos no servidor por ocasio da instalao do
Oracle. Esta estrutura est sempre no ar, ou seja, disponvel para uso.
Os arquivos que fazem parte da estrutura fsica do Oracle so os seguintes:
Data files
Esses arquivos compem os arquivos de dados do Oracle e so responsveis por guardar todas
as informaes que so alimentadas pelos usurios, as estruturas dos objetos do banco de dados,
como tabelas, ndices, views, etc. e tambm os objetos que fazem parte do controle do gerenciador
como o dicionrio de dados.
Eles devero ter seu crescimento gerenciado e controlado e tambm podem ter um
crescimento automtico, dependendo dos parmetros informados.
Alm disso, os arquivos devero fazer parte de um nico banco de dados, ou seja, cada BD
devero ter os seus prprios Data Files.
Redo log files
Esses arquivos contm o registro de todo o histrico ocorrido no BD referente a alteraes, ou

seja, todas as mudanas feitas nos dados do banco de dados so registradas neste arquivo como
data, hora, usurio, informao alterada, etc.
Eles so extremamente importantes, pois iro servir nos processos de recuperao do BD, ou
seja, quando houver um problema e ele necessitar de uma recuperao nas suas informaes, esses
arquivos sero utilizados, pois as alteraes contidas nestes arquivos so aplicadas em cima do
ltimo backup e, desta maneira, podemos recuperar o banco no momento em que houve a falha.
Um BD necessita de pelo menos dois arquivos de redo, podendo ter mais arquivos dependo da
necessidade.
Control files
Esses arquivos contm todas as informaes que so utilizadas para avaliao da integridade
do BD. O processo de avaliao da integridade do banco de dados feito durante todo o tempo em
que a instncia estiver no ar, e no somente quando o banco de dados inicializado.
Todas as informaes necessrias para avaliao desta integridade esto contidas nestes
arquivos, como localizao, algoritmos de avaliao de integridade, entre outras.
Parameter file
Este arquivo tem como objetivo identificar todos os parmetros dimensionados para o banco de
dados instalados, desde parmetros envolvendo a estrutura fsica dos arquivos, como control files e
redo log files e tambm parmetros de dimensionamento da instncia na memria, como SGA, etc.
Password File
Este arquivo contm a senha dos usurios administrador do banco e tem, entre outros
objetivos, a ativao e desativao de uma instncia do gerenciador Oracle.
Archived log files
Este arquivo tem como objetivo armazenar as informaes dos redo log files do gerenciador
Oracle. Toda vez que um arquivo do redo enche, as informaes so transferidas para este arquivo
de maneira offline e o gerenciador continua gravando as alteraes que ocorrem no BD outro
arquivo de redo.
Desta maneira, as informaes podem ser guardadas, caso seja necessrio sua utilizao em
um processo de recuperao do BD.
Estrutura lgica
Estrutura lgica do Banco de Dados Oracle. Objetivo: Mostrar a relao entre a estrutura fsica e lgica do banco de dados Oracle.
Esta estrutura tem como caracterstica uma viso lgica para o armazenamento de dados no
banco de dados. Ela composta de tablespaces, segmentos, extenses e blocos de dados.
A estrutura lgica permite uma maior eficincia e flexibilidade no armazenamento das
informaes, pois possvel juntar vrios arquivos de uma estrutura fsica em uma nica estrutura
lgica. Alm do mais, o controle do consumo dos espaos mais eficiente por meio da estrutura
lgica.
A relao a seguinte:
Um BD dever ser armazenado em uma estrutura lgica conhecida como tablespaces.

Um tablespace dever fazer parte de um nico banco de dados.
A relao entre os tablespaces e os data file da estrutura fsica que um tablespace poder ser
formado com um ou mais data files.
Cada tablespace poder ser formado com um ou mais segmentos.
Cada segmento poder ser formado com um ou mais extents.
Cada extent poder ser formado com um ou mais blocos de dados Oracle.
Cada bloco de dados Oracle poder ser formado com um ou mais blocos do sistema operacional. No
caso da estrutura fsica um data file poder ser composto por um ou mais blocos do sistema
operacional.
No caso da estrutura fsica um data file poder ser composto por um ou mais blocos do sistema
operacional.
Os arquivos que compe a estrutura lgica so os seguintes:
Tablespaces
Consistem de uma viso lgica do espao a ser utilizado pelos BD nos data files da estrutura
fsica.
Segmentos
So pores menores das tablespaces utilizados pelos BD. Podero ser armazenados objetos
especficos dos bancos de dados em segmentos separados, como segmento de dados, ndices,
rollback, etc.
Existem tambm os segmentos de undo utilizados nos processos de recuperao de dados do
banco.
Extents
Extents so grupos de blocos Oracle adjacentes, ou seja, juntos. So utilizados no processo de

alocao de espaos para o banco de dados, ou seja, quando o BD criado so alocados alguns
extents para o banco, e medida que ele vai precisando de mais espaos, so alocados novos
segmentos.
Blocos de dados Oracle
Os blocos de dados Oracle a menor unidade de armazenamento do banco de dados e tm

valores mltiplos dos blocos de dados do sistema operacional. A relao entre os blocos de dados
Oracle e os do sistema operacional definida por ocasio da instalao do gerenciador do banco de
dados.
Referncias
BAM, A. Oracle Locks Parte 1. SQL Magazine. Dev Media, 313, 2005. Disponvel
em:www.devmedia.com.br. Acesso em: 22 jan. 2013.
2012.
McGraw-Hill, 2007.
2013.
1988.
profissionaloracle.com.br. Acesso em: 22 jan. 2013.
Fazendo um estudo da
estrutura de memria do
dados Oracle
Detalhar a estrutura de memria do gerenciador de banco de dados Oracle,
para que todos tenham uma viso do funcionamento do banco.
Estrutura de memria do banco

de dados Oracle
Estrutura de memria compartilhada
Composta pelos arquivos que so carregados na memria formando a instncia do Oracle, a

estrutura est no ar somente quando o Oracle inicializado.
Os dados dos arquivos da estrutura fsica s podem ser manuseados por meio desta estrutura,
ou seja, pelas sesses criadas na instncia pelos usurios.
Os arquivos que fazem parte desta estrutura so os seguintes:
Para visualizarvisualizar a estrutura de memria do Banco de Dados Oracle clique no boto abaixo.
Instncia
A instncia se compe de toda a estrutura de memria criada quando o BD colocado no ar

bem como de uma SGA (System Global rea ou rea Global do Sistema) e tambm dos processos de
segundo plano ou processos background.
O banco de dados somente poder ser acessado por meio da instncia.
SGA (System Global rea)
rea utilizada para armazenar informaes que sero utilizadas pelos usurios do banco de
dados. Entre essas informaes, podemos identificar os ltimos comandos SQL e blocos PLSQL
utilizados e validados.
Tambm existem os buffers onde so armazenados blocos de dados enquanto eles esto sendo
processados. Os buffers contendo o histrico das alteraes do banco (REDO) tambm fazem parte
desta estrutura.
Shared pool
Local onde so guardados os ltimos comandos SQL e blocos PLSQL utilizados nas sees
anteriores e que j foram validados.
Caso estes comandos venham a serem utilizados novamente eles no precisam ser validados,
pois o gerenciador busca o comando desta rea, valida a autorizao do usurio e executa
novamente.
Tambm so guardadas neste local as estruturas dos objetos (tabelas, ndices, etc.) utilizados
na validao dos comandos.
Esta estrutura subdividida nas reas de library cache e data dictionary cache.
Library cache: local onde so guardados os comandos SQL e PLSQL utilizados mais
recentemente. Caso eles venham a ser utilizados novamente, no precisam ser validados.
Data dictionary cache: local onde so guardadas as estruturas dos objetos utilizadas na
validao dos comandos SQL e PLSQL.
Redo log buffer: local onde so guardadas todas as alteraes feitas no banco de dados
antes de serem enviadas para os redo log files.
Java pool: neste local ficam armazenadas todas as rotinas do gerenciador desenvolvidas em
java, ou seja, quando estas rotinas forem acionadas para execuo, as classes necessrias so
extradas deste local.
Processos de segundo plano (processos background)
Esses processos so rotinas desenvolvidas pela Oracle para controlar e executar atividades
distintas, como gravaes e leituras nos data files, gerenciamento da integridade do banco de dados,
entre outras.
Esses processos so carregados para a memria medida que o gerenciador precisar destas
funes. Os processos do segundo plano so os seguintes:

Data base writer (DBWO): tem como objetivo a transferncia dos dados do data buffer
cache para os data files e vice-versa.Tambm gerencia a necessidade de limpeza do data buffer
cache para liberar espaos para novas leituras para a memria.
Log writer (LGWR): objetiva a transferncia dos dados do redo log buffer para os arquivos de
redo log.Tambm gerencia a necessidade de limpeza do buffer de redo para liberar espaos para
novas gravaes.
System Monitor (Monitor de Sistemas SMON): tem como objetivo verificar durante todo
o tempo, desde quando ele aberto, a integridade dos dados e arquivos do BD, e em caso de perda
desta integridade, ele tenta fazer sua recuperao com base nos backups e arquivos de redo.
Process Monitor (Monitor de Processos PMON): objetiva identificar processos que
falharam anteriormente quando o banco de dados colocado no ar. No caso de identificar estes
processos, ele efetua a limpeza dos dados deste processo, e tambm desfaz (rollback) todas as
alteraes feitas por ele, voltando ao estgio inicial. Desta maneira, o gerenciador garante que o
processo vai at o final com o sucesso das alteraes (commit), ou o processo volta ao seu estgio
inicial desfazendo todas as alteraes feitas (rollback).
Checkpoint Process (CKPT): tem como objetivo gravar as informaes de controle e nos
data file sempre que ocorrer a transferncia dos dados do data buffer cache para estes, por ocasio
de um commit. Esta gravao poder ser feita vrias vezes ao longo de uma seo garantindo seu
retorno no ponto de gravao, caso ela no tenha sido concluda com sucesso. Desta maneira, evitase voltar desde o incio da seo no caso de algum problema com a transao.
Esses checkpoints podero ser emitidos pelo gerenciador de tempos em tempos e por uma
aplicao em um momento especfico, dependendo da necessidade.
Archiver (ARCN): objetiva fazer a transferncia dos registros de redo dos redo log files para
os archived log files e vice-versa, de maneira offline. Tambm tem a responsabilidade de
gerenciador os arquivos archived gravados e lidos posteriormente no caso do processo de uma
recuperao (recovery) do BD.
Estrutura de memria do usurio (PGA Program Global rea): esta estrutura de
memria criada pelo processo servidor para cada seo do usurio quando ele se conecta ao
banco de dados, ou seja, quando aberta uma nova seo do usurio. Ela liberada quando o
usurio encerra a aplicao ou quando a seo finalizada.
Existe uma estrutura de memria PGA para cada usurio.
Os componentes da PGA so os seguintes:
rea de classificao Esta rea utilizada para quando o processo necessita efetuar uma classificao atravs do
order by ou group by em um comando SQL, e caso esta classificao seja feita na memria.
Informaes dos privilgios dos usurios Nesta rea so carregados todos os privilgios definidos para os
usurios, ou seja, de sistema e de objetos. Toda vez que um comando SQL validado, uma das validaes no sentido de
verificar se o usurio que est tentando executar um comando SQL tem privilgios para tal.
Controle do cursor Toda vez que um usurio efetua a seleo de dados nas tabelas, e nesta seleo vem mais de
uma linha a bloco PLSQL tem que fazer isto por meio do uso de cursores. Nesta rea ficam registradas todas as
informaes da situao do cursor, utilizado na seo como: status de abertura e fechamento, posio em que linha lida
encontra etc.
Referncias
2012.
McGraw-Hill, 2007.
1988.
BAM, A. Oracle Locks Parte 1. SQL Magazine. Dev Media, 313, 2005.Disponvel em:
www.devmedia.com.br. Acesso em: 22 de jan. de 2013.
BCARATTI, R. Ajustes de Desempenho em "Consultas Simples" na SQL, SQL Magazine 11,
2004.Disponvel em: www.devmedia.com.br. Acesso em: 22 de jan. de 2013.
ORACLE. Database Performance Tuning Guide, Copyright 2000, 2011, Oracle and/or its
affiliates.Disponvel em: http://docs.oracle.com. Acesso em: 21 de jan. de 2013.
Estadual de Londrina. Dissertao de Mestrado.Disponvel em: www2.dc.uel.br. Acesso em: 21 de
jan. de 2013.
profissionaloracle.com.br. Acesso em: 22 de jan. de 2013.
Avaliando os recursos
destinados para a
estrutura de memria do
dados Oracle
Analisar os recursos de memria destinados aos objetos do banco de dados
Oracle, verificando se esto adequados para o bom desempenho do banco.
Introduo
Os objetos do gerenciador de Banco de Dados Oracle quando so carregados na memria, pois

eles necessitam de espaos na memria para poderem cumprir o seu papel. Ocorre que se este
espao alocado na memria no adequado, o gerenciador no consegue carregar todos os objetos
no momento em que necessita. Desta maneira, ele vai trazendo esses objetos medida que os
espaos so disponibilizados e poder haver perda de desempenho.
Dentre esses objetos podemos citar os comandos SQL e blocos PLSQL que so guardados na
Shared Pool, as estruturas dos objetos para validao dos comandos SQL e os processos de segundo
plano ou processos background que tm como responsabilidades a avaliao da integridade do
banco, entre outras. Esses espaos na memria podero ser consultados por meio das views de
estatsticas e se eles no estiverem adequados, podero ser ajustados por parmetros estticos ou
dinmicos.
Parmetros de instncia
O tamanho definido para a SGA (System Global rea) tem uma influncia no seu desempenho,
pois se ela for muito pequena o gerenciador no consegue trazer todos os objetos para a memria
por ocasio da criao da instncia. Por outro lado, se tiver uma rea muito alm do que necessita,
poder comprometer o espao de memria para o sistema operacional e a criao dos processos do
servidor criados para cada seo do usurio ou PGA (Program Global rea).
Esse espao poder ser ajustado de acordo com parmetros que podero ser dinmicos, ou
seja, que podem ser passados sem tirar o banco de dados do ar, ou estticos, ou seja, existe a
necessidade de tirar a instncia do ar para valer.
O espao adequado para a SGA dever ser avaliado pelo administrador de banco de dados,
quer seja por meio de assistentes disponveis a partir da verso 10g, ou de consultas estatsticas em
views disponveis no dicionrio de dados.
Um exemplo da consulta do tamanho real da SGA poder ser feito por meio das informaes
disponveis na views V$SGASTAT disponvel no quadro a seguir.
Tamanho real da SGA de uma instncia Oracle
Legenda: Tamanho real da SGA de uma instncia Oracle

Objetivo: Identificar o Tamanho Real da SGA de uma instncia.
O tamanho limite da memria disponvel para a SGA dever ser definida com base no
parmetro SGA_MAX_SIZE, de acordo com o quadro a seguir.
Tamanho limite da SGA de uma instncia Oracle
Legenda: Tamanho mximo permitido para a SGA de uma instncia Oracle. Objetivo: Definir o tamanho mximo permitido
para a SGA em uma instncia Oracle.
Uma avaliao a ser feita na memria alocada para a SGA e por meio da comparao do
tamanho real utilizado e o tamanho limite disponvel no seguinte quadro.
O tamanho real nunca ir exceder o tamanho limite
Se o tamanho real est prximo ou igual ao limite significa que a quantidade limite disponvel
poder estar insuficiente e dever ser avaliada, pois isto um sintoma de que poder afetar o
desempenho do gerenciador.
Por outro lado, se o tamanho real est muito abaixo do limite definido tambm pode indicar
que a memria est muito grande, necessitando ser avaliada, pois a quantidade de memria
desperdiada poder faltar para o sistema operacional e para alocao das sees na PGA.
No caso deste parmetro no ter sido configurado, o gerenciador ir assumir o valor padro
definido nos parmetros de inicializao do banco de dados.
Todos os valores definidos de alocao de memria na SGA sero definidos em grnulos que
so blocos de aproximadamente 4M os quais podero variar dependendo do sistema operacional,
alm de poderem ser configurados, por meio de parmetros.
Os valores dos grnulos utilizados podero ser consultados, de acordo com o quadro a seguir
Valores dos grnulos definidos para alocao de memria
Legenda: Valores dos grnulos definidos para alocao de memria em uma instncia. Objetivo: Definir o tamanho mnimo
em grnulos quando so alocados espaos de memria para o banco de dados Oracle.
Esses grnulos podero variar dependendo do sistema operacional e tambm podero ser
configurados, de acordo com parmetros. Uma vez definido um valor para o grnulo, toda vez que
formos alocar memria para a SGA o gerenciador ir alocar valores mltiplos do valor do grnulo.
Outra rea da memria que tem que ser gerenciada o pool compartilhado ou shared pool,
pois esta rea compe a SGA. Nela ficam localizados os objetos que so utilizados por todos os
usurios autorizados para esta instncia, por exemplo os comandos SQL, blocos PLSQL, estruturas
dos objetos para avaliao dos comandos SQL emitidos, etc.
Existe um parmetro que define o tamanho limite de espao para esta rea conhecido como
SHARED_POOL_SIZE. Ele poder ser visualizado e alterado dinamicamente, como mostrado no
quadro a seguir. Para alter-lo, no existe a necessidade de tirar do ar a instncia.
Visualizao e alterao do parmetro de tamanho da

shared pool
Legenda: Visualizao e alterao do parmetro da shared pool de uma instncia. Objetivo: Visualizar o tamanho definido
para a shared pool de uma instncia e posteriormente alterar este valor para um novo tamanho.
Outro aspecto a ser considerado no pool compartilhado que ele tem uma srie de reas de
controle na memria que o gerenciador utiliza, entretanto, no temos nenhum controle sobre estas
reas. Elas podero ser visualizadas por meioi de consultas na view V$SGASTAT, como mostrado no
quadro a diante.
Parmetros definidos para a shared pool e seus tamanhos
Legenda: Parmetros definidos para a shared pool e seus respectivos tamanhos. Objetivo: Identificar todos os parmetros
definidos para a shared pool que o Oracle utiliza, bem como o tamanho de cada um.
Dentro da estrutura do pool compartilhado existem algumas reas de devem ser destacadas,
dentre essas reas podemos citar:
Cache do dicionrio de dados
Esta rea armazena os objetos utilizados para avaliar os o comandos SQL, e o seu
dimensionamento correto tem uma importncia significativa no desempenho dos gerenciadores, pois
quanto mais objeto estiver armazenado, menos buscas desses sero necessrias para avaliar os
comandos SQL que foram utilizados na instncia.
Historic session active
Esta rea tambm tem uma importncia grande no desempenho dos gerenciadores de banco
de dados, pois ela armazena as informaes histricas das sesses dos usurios, e utilizada para
fazer diagnsticos dos problemas das sesses. Quanto mais informao histrica tiver de uma seo
mais rpida dever ser o diagnstico das solues e desta maneira o desempenho do ambiente ser
beneficiada.
O tamanho desta rea poder ser visualizado por meio da consulta na view V$SGASTAT, como
mostrado no quadro a seguir.
Informaes histricas das sees dos usurios
Legenda: Informaes histricas das sees dos usurios. Objetivo: Identificar o tamanho definido na shared pool para o
armazenamento de informaes histricas das sees dos usurios.
Existe uma maneira de saber o tamanho ideal do pool compartilhado. Para isso, primeiro,
temos que saber se o parmetro de estatstica da instncia est habilitado, ou seja, se est com o
valor typical, por meio da consulta a seguir.
Identificao da habilitao do parmetro de estatsticas
Legenda: Identificao da habilitao do parmetro de estatsticas.

Objetivo: Identificar se o parmetro de estatsticas do Oracle esta habilitado, ou seja, se esta armazenando informaes de
estatsticas no dicionrio de dados.
Para isso, primeiro temos que saber se o parmetro de estatstica da instncia esta habilitado,
ou seja, esta com o valor typical, por meio da seguinte consulta.
Posteriormente, consultamos a view v$shared_pool_advice, pela consulta a seguir:
Avaliao do tamanho ideal

da shared pool
Avaliao do tamanho ideal para a shared pool.Objetivo: Avaliar o tamanho ideal a ser definido para a shared pool para que
o Oracle tenha um desempenho aceitvel.
De acordo com a consulta anterior, o tempo economizado caso o tamanho do pool

compartilhado o mesmo se tivssemos 132MB de memria, ao invs dos 172MB utilizado
atualmente, ou seja, 2409 milissegundos. Podemos reduzir, portanto, o espao do pool
compartilhado de 172 MB para 132 MB e no perderamos nada em termos de desempenho do
gerenciador do BD.
Referncias
2012.
McGraw-Hill, 2007.
1988.
em:www.devmedia.com.br. Acesso em: 25 de nov de 2010.
Disponvel em: www.devmedia.com.br.Acesso em: 22 jan. 2013.
em:docs.oracle.com. Acesso em 21 jan. 2013.
Analisando a alocao de
memria utilizada por
uma instncia do banco
de dados Oracle, por meio
de consultas estatsticas
nas views do dicionrio de
dados
Analisar a alocao de memria ocupada por uma instncia do gerenciador de
banco de dados Oracle por meio de consultas e anlise de tabelas de
estatsticas localizadas no dicionrio de dados.
Introduo

complexa para o seu funcionamento. A estrutura de memria um componente extremamente
importante na sua anlise da performance. Ela ter influncia em questes como segurana,
concorrncia, armazenamento, integridade e principalmente de desempenho.
A estrutura abrange reas de memria compartilhada para processamentos dos dados dos
comandos SQL, avaliao dos comandos SQL e tambm rea individual alocada para cada seo do
usurio.
Estatsticas de desempenho do banco de dados Oracle
O gerenciador de banco de dados Oracle permite medir um grande nmero de estatsticas

sobre dados de sua utilizao. Desta maneira, possvel criar processos de obteno destes dados e
fazer comparaes ao longo do perodo para avaliar o comportamento do Oracle, e, assim, avaliar o
seu desempenho de maneira pr-ativa.
Estas estatsticas tambm permitem avaliar se determinados procedimentos de ajustes foram

suficientes para melhorar ou piorar desempenho do Oracle.
Importante observar que as estatsticas a seguir mostram valores estticos em um
determinado momento e para fazer um uso eficinte destas informaes necessrio um estudo ao
longo do tempo.
Dentre as principais informaes analisadas nas estatsticas abaixo podemos destacar a
quantidade de memria utilizada no data buffer cache, shared pool,etc.
As principais estatticas avaliadas neste estudo so:
Buffer cache hit ratio
Representa a porcentagem de pginas de dados que o Oracle mantm em memria, ou seja, a

taxa de sucesso de busca das pginas na memria e no no disco para que o desempenho seja
ainda maior. O software de busca do Oracle procura as pginas de dados a partir da memria e no
do disco.
A consulta que fornece esta porcentagem mostrada no quadro abaixo:
Taxa de sucesso do buffer cache
A taxa de sucesso do buffer cache uma medida da proporo de pedidos de dados que foram
encontrados na memria do buffer cache.
Quantos maiores forem os ndices de acessos na memria, melhor ser para o desempenho do
Oracle, pois se os dados no esto na memria tero que ser lidos do disco e o sistema operacional
ter que fazer operao de I/O em disco. Desta maneira, o aumento do tamanho do buffer ir
proporcionar uma taxa maior de sucesso.
O uso de memria adicional poder ser uma soluo eficiente para que mais dados fiquem
armazenados na memria, pois uma paginao da SGA se torna desastrosa para o desempenho do
gerenciador.
O parmetro que dimensiona o espao do buffer cache o DB_BLOCK_BUFFERS que poder ser
alterado por meio dos parmetros do arquivo de inicializao do Oracle init.ora.
Dictionary cache hit ratio
Representa a porcentagem de sucesso na solicitao dos dados do dicionrio de dados que j

esto disponveis na memria.
A consulta que fornece esta porcentagem mostrada no seguinte quadro:
Taxa de sucesso do cache do dicionrio
A taxa de sucesso do cache do dicionrio uma medida da proporo de pedidos de

informaes do dicionrio de dados, o conjunto de tabelas de dados e as vises que contm
informaes de referncia sobre esse, suas estruturas, e seus usurios.
Quantos maiores forem os ndices de acessos no dicionrio de dados, melhor ser para o
desempenho do Oracle, pois se os dados dos objetos no esto na memria, eles tero que ser lidos
do disco e o sistema operacional ter que fazer operao de I/O em disco. Desta maneira, o aumento
do tamanho do buffer ir proporcionar uma taxa maior de sucesso. Entretanto, o BD deve chegar a
um "estado estacionrio", em que os dados do dicionrio mais utilizados esto no cache.
O parmetro que dimensiona o espao do buffer cache o SHARED_POOL_SIZE que poder ser
alterado por meio dos parmetros do arquivo de inicializao do Oracle init.ora.
Library cache hit ratio
Representa a porcentagem de sucesso na solicitao dos dados do library cache que j esto
disponveis na memria.
A consulta que fornece esta porcentagem mostrada no quadro a seguir:
Taxa de sucesso da library cache
A taxa de sucesso da library cache uma medida da proporo dos comandos SQL e blocos
PLSQL que j foram validados e esto na memria para serem utilizados.
Quantos maiores forem os ndices de acessos dessas informaes, melhor ser para o
desempenho do Oracle, pois os dados que j esto na memria no tero que ser validados
novamente, no precisaro ser lidos do disco e o sistema operacional no ter que fazer operao de
I/O em disco. Com isso, o aumento do tamanho desta rea ir proporcionar uma taxa maior de
sucesso.
O parmetro que dimensiona o espao do shared pool o SHARED_POOL_RELOADS, que
poder ser alterado por meio dos parmetros do arquivo de inicializao do Oracle init.ora.
Shared pool free
Representa a porcentagem da memria da shared pool no utilizada. A consulta que fornece

esta porcentagem mostrada no quadro a seguir.
Porcentagem da shared pool no utilizada.
Se uma grande proporo do pool compartilhado est sempre livre, provvel que o tamanho
do pool compartilhado possa ser reduzido. Baixos valores livres no so um motivo de preocupao,
a menos que outros fatores tambm indiquem problemas, por exemplo, uma baixa taxa de pesquisa
no dicionrio que j est na memria ou grande proporo de recargas ocorrendo.
O parmetro que dimensiona o espao para rea de classificao o SHARED_POOL_SIZE, que
poder ser alterado por meio dos parmetros do arquivo de inicializao do Oracle init.ora.
Referncias
Disponvel em: http://docs.oracle.com. Acesso em 21 jan. 2013.
2013.
http://profissionaloracle.com.br. Acesso em: 22 jan. 2013.
Analisando o desempenho
dos comandos SQL do
Banco de Dados Oracle
atravs de consultas
estatsticas nas views do
dicionrio de dados
Analisar o desempenho dos comandos SQL atravs de consultas e anlise de
tabelas de estatsticas localizadas no dicionrio de dados. Este estudo se torna
importante dentro de processos de anlise do desempenho dos mesmos.
Introduo

complexa para o seu funcionamento.
O desempenho das consultas e comandos SQL um componente extremamente importante na
anlise do desempenho do Oracle.
Estes comandos tm influncias em questes como segurana, concorrncia, armazenamento,
integridade e, principalmente, de desempenho.
Estes comandos podero ser avaliados em questes como quantidades de leituras no data file,
leituras lgicas, classificao de dados em memrias ou em discos, varreduras de tabelas em discos
ou em memria, etc.
Estatsticas de desempenho do banco de dados Oracle
O gerenciador de banco de dados Oracle permite medir um grande nmero de estatsticas

sobre dados de sua utilizao.
Desta maneira, possvel criar processos de obteno destes dados e fazer comparaes ao
longo do perodo para avaliar o comportamento do Oracle e, portanto, avaliar o seu desempenho de
maneira prativa.
Estas estatsticas tambm permitem avaliar se determinados procedimentos de ajustes foram
suficientes para melhorar ou piorar desempenho do Oracle.
importante observar que as estatsticas a seguir mostram valores estticos em determinado
momento e, para fazer um uso eficiente destas informaes, necessrio um estudo ao longo do
tempo.
Dentre as principais informaes analisadas nas estatsticas a seguir, podemos destacar a
quantidade de buscas de informaes nos data files, quantidades de leituras lgicas e fsicas, etc.
Sort in Memory
Representa a porcentagem dos dados classificados na memria em relao aos discos.

Identificar a porcentagem de dados classificados na memria

em relao aos discos.
Porcentagem de dados classificados na memria.
Esta uma proporo dos dados, cuja classificao ocorre dentro da memria em vez de no
disco, sendo que quando a classificao feita no disco, o gerenciador faz uso de uma tabela
temporria.
O tamanho mximo do tipo da rea na memria que ir ocorrer a classificao definido pelo
tamanho da rea de classificao, que est dentro da PGA utilizada.
Cada processo da Oracle que ir classificar, ir alocar essa quantidade de memria, embora
no seja necessrio tudo isso. O uso de memria para esse fim reduz a disponibilidade da SGA.
O parmetro que dimensiona o espao para rea de classificao o parmetro
SORT_AREA_SIZE, que poder ser alterado atravs dos parmetros do arquivo de inicializao do
Oracle init.ora.
Short/Total Table Scans
Representa a porcentagem de pesquisa fazendo varredura em tabelas pequenas em relao ao

total das tabelas.
Identificar a porcentagem de pesquisas em tabelas

pequenas em relao ao total de tabelas, pois quanto maior
melhor a performance do banco
Porcentagem de pesquisa em tabelas curtas em relao ao total de tabelas.
Esta a proporo de varreduras de tabelas pequenas que est ocorrendo em relao ao total
de tabelas. Tabelas pequenas podem ser pesquisadas na sua totalidade pelo Oracle quando este
mais rpido do que usando um ndice.
Varreduras de tabelas grandes geralmente so ruins para o desempenho do ambiente.
Levantamento das cinco instrues mais frequentemente

utilizadas
Representa o levantamento das cinco instrues mais utilizadas na instncia.

A consulta que fornece este levantamento mostrada no quadro a seguir:
Identificar as cinco instrues SQL mais utilizadas no

ambiente e posteriormente fazer uma anlise do
desempenho delas.
Levantamento das cinco instrues mais utilizadas.
Este levantamento se torna importante para a avaliao do desempenho do ambiente, pois se

estes comandos so muito frequentemente utilizados, devem ser avaliados nas questes de
desempenho, como varredura em tabelas, utilizao ou no de um ndice, quantidade de linhas
carregadas na memria e tambm o custo definido pelo otimizador do Oracle.
Levantamento das cinco instrues que exigem mais leituras

de discos quando so solicitadas a sua execuo pelas
aplicaes dos usurios
Representa o levantamento das cinco instrues que mais fazem leituras em discos quando so
utilizadas pelas aplicaes dos usurios.
Identificar as cinco instrues SQL que mais utilizam leituras

em discos para fazer uma anlise das necessidades destas
leituras.
Levantamento das cinco instrues SQL que mais utilizam leituras de discos.
Este levantamento se torna importante para a avaliao do desempenho do ambiente, pois

como elas faro muitas leituras em discos, naturalmente isto ir afetar o desempenho do ambiente.
Dever ser avaliada, nestes comandos, a quantidade de linhas que eles esto processando e
verificar se realmente esta quantidade necessria, se pode ser reduzida esta quantidade, pois,
quanto mais linhas o comando processar, mais leituras em discos ele far.
Levantamento das cinco instrues que exigem mais leituras
lgicas
Representa o levantamento das cinco instrues que mais fazem leituras lgicas no buffer de
memria.
Identificar as cinco instrues SQL que mais utilizam leituras

Lgicas para fazer uma anlise das necessidades destas
leituras.
Levantamento das cinco instrues SQL que mais utilizam leituras lgicas.
Este levantamento se torna importante para a avaliao do desempenho do ambiente, pois

quanto mais leituras lgicas o comando tiver que fazer na aplicao, mais demorado ser o tempo
de concluso, e pior ser a performance da aplicao e do ambiente.
Dever ser avaliada nestes comandos se a quantidade de leituras lgicas que esto sendo
feitas na atividade realmente necessria ou se pode ser reduzida.
Referncias
KOCK, G.; KEVIN, L. Oracle 8: The complete reference Oracle Press, 1997.
2012.
McGraw-Hill, 2007.
PATTERSON, D. A; Gibson, G; Katz, R.H; A case for redundant arrays of inexpensive disks (RAID),
1988.
Estadual de Londrina. Dissertao de Mestrado. Disponvel em: www2.dc.uel.br . Acesso em 21
jan. 2013.
______. Tamanho Ideal para Shared Pool, Blog de Flvio Soares, 2010. Disponvel em:
Conceitos de ndices e os
seus impactos no
desempenho do Oracle
Apresentar uma viso detalhada dos conceitos e funcionamentos dos ndices
no gerenciador de banco de dados Oracle, pois tm uma influncia decisiva na
performance do banco e do ambiente.
Introduo

complexa para o seu funcionamento.
Quando submetemos um comando de seleo de dados para o gerenciador (select), ele dever
definir, atravs do otimizador, qual o melhor caminho para trazer os dados selecionados pelo
comando.
Uma soluo rotineira o gerenciador fazer uma busca na tabela, realizando uma varredura,
sendo isto ruim para o desempenho da aplicao e do ambiente.
Entretanto, os gerenciadores tm uma soluo mais eficiente para a busca das informaes
atravs da criao de ndices, ou seja, o ndice uma tabela em que os dados esto organizados na
mesma ordem de pesquisa do comando SQL.
Desta maneira, o gerenciador vai direto aos dados a serem selecionados, eliminando a
necessidade de varredura das tabelas, melhorando o desempenho da aplicao e do ambiente.
ndices
Conceitos Gerais
Os ndices tm como caractersticas terem os dados organizados na mesma ordem de pesquisa

dos comandos SQL e, desta maneira, permitem o acesso direto a uma ou mais linhas de uma tabela.
A classificao dos dados nos ndices chamada de classificao lgica e est ligada s
necessidades da aplicao, enquanto a classificao dos dados nas tabelas chamada de
classificao fsica, ou seja, como os dados so organizados fisicamente.
Tipos de ndices
ndice de uma nica coluna So compostos de uma nica coluna como chave do ndice.
ndices concatenados So compostos de duas ou mais colunas como chave do ndice, sendo que o nmero
mximo de colunas em um ndice 32 (Exemplo: estado, cidade).
ndices exclusivos So ndices sem valores duplicados correspondentes na tabela principal (CNPJ), desta maneira,
cada linha do ndice dever apontar para uma nica linha da tabela principal.
ndices no exclusivos Cada linha poder apontar para vrias linhas da tabela.
ndices baseado em funes Esses ndices so criados quando temos a necessidade de usar funes nos filtros
de pesquisa, pois desta maneira ao invs do gerenciador criar a funo no momento da pesquisa mesma j esta criada
por ocasio da criao do ndice.A criao de funes no momento da pesquisa costuma degradar bastante o desempenho
da aplicao e do ambiente, principalmente se esta funo for muito utilizada pelas aplicaes.Comando SQL para a
criao de um ndice baseado em funes:
Exemplo de consulta utilizando o ndice anterior:
ndices particionados e no particionados
So ndices utilizados por tabelas muito grandes, ou seja, podem ser definidos e propagados
para vrias tablespaces e, desta maneira, reduzir o gargalo nas pesquisas, garantindo um
desempenho melhor para a aplicao e o ambiente que dele se utiliza.
So utilizados em tabelas particionadas, garantindo uma melhor escalabilidade e capacidade

de crescimento dos objetos e, tambm, um melhor gerenciamento do ambiente.
Sintaxe do comando para criao de um ndice:
No qual:
PCTFREE: o espao reservado em cada bloco (em porcentagem do espao total menos o
cabealho do bloco) durante a criao para acomodar novas entradas de ndice.
LOGGING: especifica que a todas as operaes efetuadas no ndice sero registradas no arquivo de
redo log (essa a opo default).
NOLOGGING: especifica que a todas as operaes efetuadas no ndice no sero registradas no
arquivo de redo log.

NOSORT: especifica que as linhas sejam armazenadas no banco de dados em ordem crescente e,
portanto, que o servidor Oracle no precisa classificar as linhas durante a criao do ndice.
Exemplo de comando para criao de um ndice:
Consideraes sobre os ndices
Os ndices melhoram consideravelmente o desempenho das consultas SQL, ou seja, os

comandos select indo direto na informao do ndice e, desta maneira, evitando varredura nas
tabelas.
Por outro lado, os ndices acabam prejudicando os comandos SQL de atualizao das
informaes, ou seja, os comandos insert, update e delete, pois o gerenciador, alm de atualizar os
dados nas tabelas com essas operaes, ainda ir atualizar os valores correspondentes nos ndices,
garantindo assim a integridade dos dados das tabelas e dos ndices.
Os ndices e tabelas devero ser criados em tablespaces diferentes, garantindo, assim, um
melhor desempenho nas leituras e gravaes das informaes nos servidores, pois estar evitando
gargalos nas transferncias de dados dos servidores.
Na carga de grandes dados nas tabelas, devero ser desabilitadas a opo logging, evitando,
desta maneira, grandes quantidades de gravaes no arquivo de log, sendo que, caso tenha algum
problema no ndice, ele poder ser criado novamente.
Alterando os parmetros
definidos no ndice
Todos os parmetros definidos na criao do ndice podero ser alterados posteriormente,

atravs do comando Alter Index.
Sintaxe do comando para criao de um ndice:
Alocando e desalocando espao dos ndices
Uma vez criado um ndice com determinado espao alocado, poder ser necessrio,
posteriormente, um aumento deste espao em funo do crescimento da tabela relacionada a ele.
Sintaxe do comando para alocao do espao:
Numa situao oposta, poder ser necessria uma liberao de um espao alocado e no
utilizado pelos ndices.
Sintaxe do comando para liberao do espao:
Recriando ndices
Existem algumas situaes em que haver a necessidade de recriao do ndice, ou seja,

eliminar o ndice atual e cria-lo novamente. Dentre elas, podemos destacar:
O ndice precisa ser transferido de uma tablespace para outra, visando a uma melhoria de
desempenho do ambiente.
Mudana do tipo do ndice.
Reorganizao do ndice atravs do comando Alter Table Move Tablespace. Quando um novo ndice
criado, ocorre o seguinte:
O novo ndice criado ir se basear nos dados existentes na tabela correspondente.

A classificao do novo ndice se baseia na classificao do ndice existente e, desta maneira, tem
um desempenho melhor.
O ndice antigo eliminado somente depois que o novo criado e, desta maneira, no interfere nas
aplicaes que utilizam o ndice.
Dever ter espao suficiente para os dois ndices, ou seja, o novo e o atual.
Recriando ndices online
Os ndices podero ser recriados de maneira online, ou seja, com aplicaes acessando e
atualizado os dados da tabela correspondente simultaneamente, entretanto, se a tabela for muito
grande, poder ser uma operao demorada e afetar o desempenho das aplicaes que executam
comandos DML.
Sintaxe do comando para recriao de ndices online:
Eliminando ndices
Uma vez no necessitando mais de um ndice, ele dever ser eliminado. Este procedimento se
torna necessrio para que o gerenciador no gaste tempo em ficar atualizando-o por ocasio dos
comandos DML na tabela correspondente.
Situaes em que dever ser eliminado:
Assim que as aplicaes no precisarem mais dele.

Antes de uma atividade de carga de grande volume em uma tabela, pois, nesta situao, dever
ser eliminado e criado aps a carga dela, com base nos novos dados da tabela.
Em caso de falha da instncia.
Quando estiver danificado. Sintaxe do comando para eliminao do ndice:
Pesquisando informaes dos ndices atravs do dicionrio

de dados
Existem algumas tabelas do dicionrio de dados que fornecem informaes dos ndices, sendo
que as duas principais so a tabela DBA_INDEXES, que contm informaes de todos os ndices
criados no banco, e a tabela DBA_IND_COLUMNS, que fornece informaes sobre as colunas que
compe os ndices.
Principais colunas das duas tabelas:
Referncias
2012.
McGraw-Hill, 2007.
1988.
Disponvel em: www.docs.oracle.com. Acesso em: 21 jan. 2013.
Estadual de Londrina. Dissertao de Mestrado. Disponvel em: www2.dc.uel.br. Acesso em: 21
jan. 2013.
www.profissionaloracle.com.br. Acesso em: 22 jan. 2013.
Criao de um cenrio
para avaliao do
desempenho dos ndices
nas consultas ao banco
de dados
Estudar detalhando do desempenho dos ndices nas consultas aos dados do
Banco de Dados.
Introduo
Quando executamos um comando SQL para seleo de dados no banco o otimizador do

gerenciador ir verificar o melhor caminho para quando o comando for executado, ou seja,
consumindo o menor recurso possvel e dentro do melhor desempenho.
Este melhor caminho passa pelo uso ou no dos ndices nos filtros de pesquisa, pois se no
houver ndice o otimizador ir optar por fazer uma varredura total na tabela para encontrar uma
determinada informao.
No caso de haver um ndice o gerenciador poder optar pelo seu uso e, desta maneira, ir direto
aos dados a serem selecionados, eliminando a necessidade de varredura das tabelas, melhorando o
desempenho da aplicao e do ambiente.
Entretanto, existem algumas regras para o gerenciador optar pelo uso dos ndices e tambm
situaes que ele desconsidera o seu uso. A anlise destas condies, e as situaes em que o
gerenciador poder optar ou no pelo uso dos ndices veremos a seguir nas simulaes.
Criao do ambiente para anlise das situaes
Para fazermos as simulaes sobre o uso ou no dos ndices pelas consultas, primeiramente,
devemos criar um ambiente no banco de dados seguindo alguns passos:
Passo 01: devemos nos conectar no banco de dados como administrador atravs do comando
a seguir:
Usurio: system
Senha: manager
Passo 02: uma vez conectado no usurio administrador do banco dever ser criado um usurio
para fazermos as simulaes, pelo seguinte comando, o qual dever ser substitudo o nome_usuario
por um usurio especfico e a senha_usuario por uma senha especfica.
Passo 03: dever ser dada uma autorizao para o usurio criado se conectar ao banco de
dados, por meio do comando a seguir:
Passo 04: dever ser dada uma autorizao para o usurio criado usar os recursos do banco,
por meio do comando:
Passo 05: devero ser criadas duas tabelas para podermos fazer as simulaes, e que neste
caso criaremos as tabelas cliente e ttulos, por meio dos seguintes comandos:
Passo 06: uma vez criadas as tabelas cliente e ttulo, deveram ser inseridas linhas nas duas
tabelas, de acordo com os comandos a seguir:
Passo 07: uma vez inseridas as linhas nas duas tabelas deveremos fazer uma carga de
100.000 linhas na tabela cliente, via PLSQL. Para fazermos as simulaes com a tabela cliente, pelo
bloco PLSQL descrito a seguir:
Passo 08: uma vez feita uma carga de 100.000 linhas na tabela cliente devemos avaliar o
caminho criado pelo otimizador para as seguintes condies:
Primeira Simulao
Dever ser criado o plano de acesso na tabela PLAN TABLE utilizando a clusula between como
filtro de pesquisa, atravs do comando abaixo:
Posteriormente dever ser consultado o plano criado, atravs do comando abaixo:
De acordo com este resultado o gerenciador do BD ir fazer uma varredura na tabela cliente
quando for executar o comando SQL, entretanto como a tabela esta um pouco cheia ver que o
custo ser alto porque no tem um ndice para ser utilizado na pesquisa.
Segunda Simulao
Dever ser criado o plano de acesso na tabela PLAN TABLE utilizando o operador ?=? como
Posteriormente dever ser consultado o plano criado, atravs do comando abaixo:
O plano de acesso criado utilizando o operador ?<>? ir trazer o seguinte resultado:
Legenda: Plano de acesso da terceira simulao do passo 8. Objetivo: Identificar o caminho proposto pelo simulador
utilizando o operador ?<>? como filtro de pesquisa.
quando for executar o comando SQL, entretanto como a tabela esta um pouco cheia ver que o
custo ser alto porque no tem um ndice para ser utilizado na pesquisa.
Terceira Simulao
Dever ser criado o plano de acesso na tabela PLAN TABLE utilizando o operador ?<>? como
Posteriormente dever ser consultado o plano criado, atravs do comando a seguir:
O plano de acesso criado utilizando o operador ?<>? ir trazer o seguinte resultado:
utilizando o operador ?<>? como filtro de pesquisa.
quando for executar o comando SQL descrito no comando Explain Plan.
Comparando com as duas simulaes acima iremos perceber que o comando SQL quando for
executar ir consumir mais memria atravs de uma necessidade maior de bytes e linhas na
memria do que as duas simulaes anteriores, pois como o operador diferente o otimizador ter
que compara com todas as linhas selecionadas para identificar os valores selecionados.
Passo 09: agora deveremos criar um ndice para a tabela cliente para avaliarmos o
comportamento do otimizador para as mesmas simulaes feitas anteriormente, pelo comando:
Passo 10: uma vez criado um ndice na tabela cliente devemos avaliar o caminho criado pelo
otimizador para as condies a seguir:
Primeira simulao
Dever ser criado o plano de acesso na tabela PLAN TABLE utilizando a clusula between como
filtro de pesquisa, por meio do comando:
Posteriormente, dever ser consultado o plano criado, por meio do comando:
O plano de acesso criado utilizando a clausula between do passo 10 ir trazer o seguinte

resultado:
Legenda: Plano de acesso da primeira simulao do passo 10. Objetivo: Identificar o caminho proposto pelo simulador
utilizando a clusula between como filtro de pesquisa, sendo que existe um ndice para este filtro.
De acordo com este resultado o gerenciador do BD passar a utilizar o ndice no filtro de

pesquisa quando for executar o comando SQL. Desta maneira, o custo ser consideravelmente
menor, bem como a quantidade de linhas carregadas na memria.
Segunda simulao
Dever ser criado o plano de acesso na tabela PLAN TABLE utilizando o operador ?=? como
filtro de pesquisa, por meio do seguinte comando:
Posteriormente, dever ser consultado o plano criado, pelo comando a seguir:
O plano de acesso criado utilizando operador ?=? do passo 10 ir trazer o seguinte resultado:
Legenda: Plano de acesso da segunda simulao do passo 10. Objetivo: Identificar o caminho proposto pelo simulador
utilizando o operador ?=? como filtro de pesquisa, sendo que existe um ndice para este filtro.
De acordo com este resultado o gerenciador do BD passar a utilizar o ndice no filtro de

pesquisa quando for executar o comando SQL. Desta maneira, o custo tambm ser
consideravelmente menor, bem como a quantidade de linhas carregadas na memria.
Terceira simulao
Dever ser criado o plano de acesso na tabela PLAN TABLE utilizando o operador ?<>? como
filtro de pesquisa, por meio do seguinte comando:
Posteriormente, dever ser consultado o plano criado, pelo comando a seguir:
O plano de acesso criado utilizando o operador ?<>? do passo 10 ir trazer o seguinte

resultado:
utilizando o operador ?<>? como filtro de pesquisa, sendo que existe um ndice para este filtro.
De acordo com ele, o gerenciador do BD ir fazer uma varredura na tabela cliente quando for
executar o comando SQL descrito no comando Explain Plan, ou seja, o otimizador no ir considerar
o ndice definido para a coluna. Neste cenrio podemos concluir que o operador ?<>? um dos
piores operadores a ser utilizado nos comandos SQL em termos de desempenho, pois ele no leva
em conta o ndice criado para a coluna e ainda faz uma varredura na tabela. Alm disso, ocupa
bastante memria por meio das linhas e bytes carregados nela.
Referncias
2012.
McGraw-Hill, 2007.
1988.
2013.
Avaliao de hints (dicas)

para o otimizador do
Oracle
Fazer um estudo detalhado das dicas (hints) que podem ser passadas para o
otimizador, a fim de que ele tome uma deciso no caminho a ser percorrido
pelo gerenciador quando for executar um comando SQL.
Introduo
O otimizador tem a responsabilidade de escolher o melhor caminho a ser percorrido quando for
executar um comando de seleo de dados, ou seja, se deve utilizar o ndice nesse caminho ou no.
Entretanto, ele poder no escolher o melhor caminho, porque para optar, faz uma srie de
anlises no ambiente, principalmente em algumas estatsticas contidas no dicionrio de dados.
Para resolver este problema, o gerenciador oferece a possibilidade dos usurios passarem
algumas dicas (hints) para ele informando um determinado caminho que considera como melhor.
Nesse caso, o otimizador acaba acatando a dica e desconsidera a soluo dele. Entretanto, vale
lembrar que o otimizador, para escolher esse caminho, baseia-se em uma srie de informaes que
o usurio comum no tem e, dessa forma, tem que se tomar muito cuidado ao sugeri-lo.
Tipos de hints
O gerenciador de banco de dados Oracle possui uma srie de hints para ser utilizado em
diferentes situaes, sendo que, dependendo da dica informada, o Oracle poder ter um bom ganho
de desempenho.
Uma relao completa dos hints disponveis poder ser encontrada no Database
Administrator?s Guide.
Agrupamento de hints
Os hints podero ser agrupados de acordo com as caractersticas de cada um. Dentre esses
grupos podemos destacar:
Essas hints so utilizadas pelo otimizador para influenciar no mtodo de acesso dos dados, ou
seja, como uma consulta poder ser feita. Elas podem dizer, por exemplo, se o otimizador dever
usar ou no um ndice em uma pesquisa de dados e como eles devero ser utilizados.
Entre essas hints podemos destacar: AND_EQUAL, INDEX_ASC, CLUSTER, INDEX_JOIN,
INDEX_DESC, INDEX_COMBINE, INDEX_FFS,NO_INDEX, RPWID, FULL, HASH, INDEX.
Essas hints so utilizadas nos Data Warehouse e podero tratar as tabelas fatos e dimenses,
ou seja, sugere que uma tabela seja tratada como tabela fato ou o contrrio, sugere que uma tabela
seja tratada como dimenso. A hint pode tornar mais eficiente as junes de mais de uma tabela
fato.
Entre essas hints podemos destacar: FACT, NO_FACT, NO_MERGE, NOREWRITE, STAR,
USE_CONCAT, REWRITE, STAR_TRANSFORMATION, MERGE, NO_EXPAND.
Essas hints so utilizadas nas operaes de juno de tabelas, estabelecendo mecanismos de

juno mais eficientes, dependendo das condies oferecidas, podendo sugerir operaes como
Hash ou Merge.
Entre essas hints podemos destacar: HASH_SJ, LEADING, NL_AJ, NL_SJ ORDERED,PUSH_SUBQ,
USE_NL, MERGE_AJ, MERGE_SL,USE_HASH, USE_MERGE, DRIVING_SITE, HASH_AJ.
Essas hints so utilizadas nos bancos de dados instalados usando a opo de paralelismo, ou
seja, identifica e sugere que as tabelas trabalhem na modalidade paralela, obtendo um melhor
desempenho nos joins de consultas.
Entre essas hints podemos destacar: NOPARALLEL_INDEX, PARALLEL_INDEX, NOPARALLEL,
PQ_DISTRIBUTE, PARALLEL.
Outros tipos de hints utilizadas nas quries do banco de

dados
Essas hints tm como destaque o aproveitamento das caches de memria, ou seja, identifica
consultas mais usadas recentemente para serem utilizadas ou no.
Entre essas hints podemos destacar: CACHE, CURSOR_SHARING_EXACT, NOAPPEND,
NO_UNNEST, NOCACHE, UNNEST, NO_PUSH_PRED, APPEND, PUSH_PRED, ORDERED_PREDICATES.
Relao de hints que so mais utilizadas pelas aplicaes
Abaixo h uma relao das hints mais utilizadas pelas aplicaes, bem como a sua definio e
um exemplo de uso.
Para os exemplos abaixo ser utilizada a tabela clientes com as colunas nome_cliente e
vendas_cliente.
Primeira hint: FIRST_ROWS
Serve para o otimizador forar o uso do ndice. Nesse caso, ele obter a primeira linha ou as N
linhas citadas de maneira mais rpida.
Exemplo: SELECT /*+first_rows(200)*/ nome_cliente, vendas_cliente FROM clientes.
Segunda Hint: ALL_ROWS
Serve para forar uma varredura na tabela das 150 primeiras linhas, pois em muitos casos isso
se torna mais eficiente do que a leitura atravs de ndices.
Exemplo: SELECT /*+all_rows(150)*/ nome_cliente, vendas_cliente FROM clientes.
Terceira Hint: FULL_ROWS
Serve para forar uma varredura total na tabela, pois em muitos casos isso se torna mais
eficiente do que a leitura atravs de ndices.
Exemplo: SELECT /*+full_rows(clientes)*/ nome_cliente, vendas_cliente FROM clientes.
Quarta Hint: INDEX
Serve para forar o uso de um ndice em uma pesquisa. Vale lembrar que nem sempre isso
pode melhorar o desempenho de uma consulta.
Exemplo: SELECT /*+index*/ nome_cliente, vendas_cliente
FROM clientes WHERE vendas BETWEEN 1000 and 2000.
Observao: quando no informarmos nenhum ndice, o gerenciador Oracle analisa todos e

escolhe um ou mais que ir melhorar o desempenho da consulta e, nesse caso, no far uma
varredura na tabela.
Exemplo: com o uso da hint index informando um ndice a ser utilizado.
SELECT /*+index(vendas_idx clientes)*/ nome_cliente, vendas_cliente FROM clientes WHERE
vendas BETWEEN 1000 and 2000.
Quinta Hint: NO_INDEX
Serve para forar o no uso de um determinado ndice em uma pesquisa. Vale lembrar que
nem sempre o no uso do ndice pode melhorar o desempenho de uma consulta.
Exemplo: SELECT /*+no_index (cliente vendas_idx)*/ nome_cliente, vendas_cliente, FROM
clientes WHERE vendas BETWEEN 1000 and 2000.
Sexta Hint: INDEX_JOIN
Serve para mesclar mais de um ndice em uma tabela por ocasio de uma consulta, sendo que,
nesse caso, os ndices devero ser da mesma tabela.
Na consulta seguinte, utilizou-se os ndices vendas_idx e lucro_idx da tabela cliente.
Exemplo: SELECT /*+index_join (cliente vendas_idx, lucro_idx)*/ nome_cliente,
vendas_cliente , FROM clientes WHERE vendas BETWEEN 1000 and 2000 and lucro BETWEEN 500
and 1000.
Stima Hint: AND_EQUAL
Serve para utilizar todos os ndices especificados na consulta e no somente para escolher o
melhor. Na consulta a seguir estar informando e utilizando os ndices vendas_idx e lucro_idx da
tabela cliente.
Exemplo: SELECT /*+AND_EQUAL (cliente vendas_idx, lucro_idx)*/ nome_cliente,
vendas_cliente.
FROM clientes WHERE vendas BETWEEN 1000 and 2000 and
lucro BETWEEN 500 and 1000.
Oitava Hint: INDEX_COMBINE
Serve para utilizar vrios ndices do tipo bitmap especificados para uma nica tabela na
consulta e no somente para escolher o melhor.
Na consulta seguinte estar informando e utilizando os ndices bitmap vendas_idx e lucro_idx
da tabela cliente.
Exemplo: SELECT /*+index_combine (cliente vendas_idx, lucro_idx)*/ nome_cliente,
vendas_cliente FROM clientes.
Nona Hint: INDEX_FFS
Serve para fazer uma varredura completa no ndice e no utilizar a tabela correspondente. Essa
hint dever ser utilizada quando todas as informaes da consulta estiverem no ndice, no
necessitando buscar informaes na tabela correspondente.
Na consulta abaixo estar informando o ndice vendas_idx da tabela cliente.
Exemplo:
SELECT /*+index_ffs (cliente vendas_idx)*/ vendas_cliente
FROM clientes Where vendas_cliente between 100 and 1000.
Referncias
KOCK, G.; KEVIN, L. Oracle 8: The complete reference Oracle Press, 1997.
2012.
McGraw-Hill, 2007.
PATTERSON, D. A; Gibson, G; Katz, R.H; A case for redundant arrays of inexpensive disks (RAID),
1988.
www.devmedia.com.br . Acesso em: 29 jan. 2013.
ORACLE Database Performance Tuning Guide, Copyright 2000, 2011, Oracle and/or its affiliates.
All rights reserved. Disponvel em: docs.oracle.com. Acesso em 29 jan. 2013.
2013.
profissionaloracle.com.br . Acesso em: 29 jan. 2013.
SOARES F. Tamanho Ideal para Shared Pool, Blog de Flvio Soares, 2010. Disponvel
em:profissionaloracle.com.br. Acesso em: 29 jan. 2013.
Fragmentao dos ndices

Avaliar os impactos da fragmentao dos ndices no desempenho das
aplicaes envolvendo banco de dados e tambm o ambiente em que eles
esto inseridos.
Introduo
Os objetos do banco de dados, como tabelas e ndices, entre outros, vo sofrendo manutenes
ao longo do tempo. medida que estes objetos vo sofrendo modificaes em suas linhas, ou seja,
novas linhas inseridas, alm das linhas excludas ou modificadas, costumam ficar em locais fsicos
diferentes daqueles em que foram alocadas originalmente.
Para essas linhas que ficam em locais fsicos diferentes, os gerenciadores criam endereos
apontando para os locais nos quais elas deveriam estar fisicamente. Desta maneira, tais locais no
so aproveitados e fica um vazio nos objetos destas linhas, ou seja, em suas tabelas e ndices.
Este vazio chamado de fragmentao e quanto maior for esta fragmentao, pior ser o
desempenho das aplicaes que manipulam estes objetos e, consequentemente, pior o desempenho
do ambiente de maneira geral.
responsabilidade do administrador de banco de dados identificar e eliminar essas
fragmentaes o mais rpido possvel.
Conceitos e caractersticas da fragmentao dos ndices
Conceituando melhor, a fragmentao a distribuio das informaes em blocos no

contguos dentro do banco de dados. Desta maneira, a leitura destes blocos no poder ser feita de
maneira linear e sequencial, pois o gerenciador ter que pegar o endereo de uma linha ou bloco,
por exemplo, ir buscar os dados neste endereo e voltar a ler as linhas seguintes de maneira
sequencial e contnua.
Neste cenrio, podemos dizer que bem mais rpido ler 200 blocos de dados que esto
fisicamente localizados de maneira contnua do que 40 blocos esparsos no banco de dados, maneira
na qual teramos que buscar o endereo de cada um desses blocos, para ento buscar os dados
nestes endereos.
Dentre os tipos de fragmentao que envolvem ndices e tabelas, tem-se a fragmentao por
bloco, ou seja, quando as linhas so eliminadas em uma tabela deixam um buraco no somente nos
blocos de dados das tabelas, mas tambm nos blocos de dados dos ndices, respectivamente.
Este tipo de fragmentao est ligado aos parmetros PCTFREE e PCTUSED, sendo que podero
ser ajustados para minimizar a fragmentao das tabelas e, desta maneira, evitar impactos de
desempenho nos respectivos objetos. Uma das maneiras de resolver o problema de fragmentao
dos ndices atravs de sua reconstruo com o parmetro REBUILD do comando ALTER INDEX ou
sua reorganizao com o parmetro REORGANIZE tambm do comando ALTER INDEX.
Uma das maneiras de resolver o problema de fragmentao dos ndices atravs de sua
reconstruo com o parmetro REBUILD do comando ALTER INDEX ou sua reorganizao com o
parmetro REORGANIZE tambm do comando ALTER INDEX.
Uma questo importante no processo de reconstruo de um ndice (REBUILD) que o
gerenciador de banco de dados primeiro cria um novo ndice e somente depois elimina o ndice velho
para que as aplicaes no tenham nenhum impacto enquanto eles esto sendo reconstrudos.
Como consequncia disto, no devemos esquecer que temos que ter espao suficiente nas
tablespaces para os dois ndices ao mesmo tempo, pois se no for assim, o gerenciador no far a
reconstruo.
Entretanto, este procedimento resolve somente o problema dos ndices, mas no resolve o
problema da fragmentao das tabelas.
Para resolver tal problema e, tambm, dos seus ndices correspondentes, a sugesto no
sentido de exportar os dados das tabelas, eliminar o objeto, cria-lo posteriormente e finalmente fazer
a importao de seus dados.
Porm, nem sempre temos tempo suficiente para fazermos isto em um banco de dados muito
grande que poder ficar indisponvel por poucas horas em uma semana ou mesmo em determinado
perodo.
Tambm teremos que identificar quais tabelas esto fragmentadas e precisam de processos de
desfragmentao.
O correto nesta situao criarmos vrias rotinas de identificao e eliminao de
fragmentao e executarmos cada uma delas em momento apropriado, sem prejudicar os usurios e
o ambiente como um todo.
Tambm se poderiam criar rotinas de armazenamento da fragmentao dos ndices em tabelas
prprias durante a semana e nos finais de semana executar rotinas de eliminao de fragmentao
para aqueles objetos que estiverem fragmentados.
Outra questo importante na eliminao da fragmentao dos ndices identificar o momento
certo para fazer isto, pois o processo de desfragmentao acaba tendo um custo em termos de
disponibilidade do banco de dados.
Com a porcentagem de fragmentao entre 5 e 30%, aconselhvel de se fazer somente a
reorganizao do banco de dados (REORGANIZE) e somente acima dessa faixa necessria a
reconstruo (REBUILD). Neste caso, com porcentagem de fragmentao em menos de 5, no se
deve fazer a desfragmentao, pois o custo do processo acaba sendo maior do que o benefcio de se
ter o ndice desfragmentado.
Consequncias da fragmentao
A fragmentao em decorrncia das operaes DML (incluso, alterao e excluso) nas

tabelas pode gerar uma srie de consequncias caso no seja controlada e eliminada. Dentre esses
problemas, podemos citar:
Lentido nas aplicaes que manipulam os objetos vinculados a ela e tambm no ambiente em
geral.
Aumento do tempo para a realizao das transaes dos respectivos objetos.
Aumento dos bloqueios (LOCKS) nas tabelas com fragmentao alta.
Aumento do custo do processamento das transaes envolvendo os processos administrativos.
Aumento do espao alocado pelos objetos, gerando um crescimento no tamanho dos arquivos
envolvidos.
Aumento dos arquivos de backups.
Aumento do tempo para os backups e recuperao dos objetos em que a fragmentao est alta.
Cuidados a serem tomados para evitar a fragmentao
Os arquivos que faro parte do banco de dados devero ser dimensionados para o maior valor
possvel, ou seja, deve-se trabalhar com o cenrio de eles terem sua capacidade mxima de
armazenamento. Alm disso, interessante que tenham uma margem de crescimento atravs de
parmetros, para se ter espao suficiente em caso de crescimento alm do planejado.
necessria uma avaliao dos espaos ocupados pelos arquivos de maneira contnua para
verificar se eles no esto sub ou superdimensionados.
Seria interessante uma separao dos arquivos de dados e ndices em filegroups diferentes a
fim de se evitar sobrecarga de armazenamento e, tambm, de utilizao durante as operaes dos
objetos do banco de dados.
As tarefas de manuteno de espaos dos ndices e de reorganizao desses espaos devem
ter manuteno permanente, atravs de processos de identificao e eliminao de fragmentao,
evitando, assim, seu crescimento.
Todas as instrues de manuteno de dados de tabelas devero ser seguidas da instruo de
UPDATE STATISTICS para que o dicionrio seja atualizado com as informaes dos objetos e, desta
maneira, o otimizador ir escolher sempre o melhor caminho para a execuo dos comandos DML.
Como identificar ndices fragmentados
A fragmentao dos ndices poder ser identificada pelo seguinte mtodo:

Primeiro deveremos atualizar a tabela INDEX_STATS do dicionrio de dados com as
informaes do ndice atravs do comando:
VALIDATE INDEX nome_do_indice
Posteriormente, poderemos pesquisar a porcentagem de fragmentao do ndice na respectiva
tabela atravs do comando. Comando para pesquisar a porcentagem de fragmentao do ndice:
No exemplo, o ndice Cliente_idx est fragmentado em 70%.

Para eliminar a fragmentao do ndice, poder ser feita sua reconstruo atravs do comando:
ALTER INDEX cliente_idx REBUILD:
Referncias
2012.
McGraw-Hill, 2007.
1988.
www.devmedia.com.br . Acesso em: 22 jan. 2013.
Disponvel em: www.devmedia.com.br . Acesso em: 22 jan. 2013.
Disponvel em:docs.oracle.com. Acesso em 21 jan. 2013.
2013.
Cenrio para avaliao da

fragmentao de ndices
Realizar uma avaliao detalhada da fragmentao dos ndices atravs da
criao de um cenrio para simulao da fragmentao, sua identificao e
posterior eliminao.
Introduo
O cenrio mostrado a seguir dever mostrar a identificao desta fragmentao e os
procedimentos para a eliminar tanto dos ndices quanto das tabelas.
Este cenrio ser composto de passos a serem seguidos para simular a fragmentao.
Cenrio da fragmentao
Para fazermos as simulaes para a criao e eliminao da fragmentao, primeiramente

devemos criar um ambiente no banco de dados atravs dos passos a seguir:
Passo 01: Primeiramente devemos nos conectar ao banco de dados como Administrador,
atravs do comando a seguir:
Usurio: system
Senha: manager
Passo 02: Uma vez conectado neste usurio, dever ser criado um usurio para fazermos as
simulaes atravs do comando a seguir, sendo que dever ser substitudo o nome_usuario por um
usurio especfico e a senha_usuario por uma senha especfica.

CREATE USER nome_usuario IDENTIFIED BY senha_usuario
Passo 03: Dever ser dada uma autorizao para o usurio criado se conectar ao banco de
dados, atravs do comando a seguir:
GRANT connect TO nome_usuario;
Passo 04: Dever ser dada uma autorizao para o usurio criado usar os recursos do banco,
GRANT resource TO nome_usuario;
Passo 05: Dever ser criada uma tabela para podermos fazer as simulaes. Neste caso,
criaremos a tabela Cliente atravs do comando a seguir:
CREATE TABLE cliente
(nome varchar2(15), endereco varchar2(30),
estado varchar2(02), cep varchar2(08),
vendas number(13,2), juros_vendas number(13,2),
codigo number(07), primary key (cdigo), data_nasc date,
parcelas number(05), status varchar2(01),
valor_nota number(13,2), emissao_nota date);
Passo 06: Uma vez criada a tabela Cliente, dever ser criado um ndice, atravs dos comandos
a seguir:
CREATE INDEX vendas_idx
ON cliente (vendas);
Passo 07: Uma vez criada a tabela Cliente, devero ser inseridas linhas na tabela, de acordo
com os comandos a seguir:
INSERT INTO cliente
VALUES ('MARIA', 'Rua dos trilhos','SP','03040010', 7500.00,750.00,00020,
'10-10-58' ,5,'A',2000.00,'29-09-05');
INSERT INTO cliente
VALUES ('ANTONIO',?Rua Matilde','SP','07050001', 5000.00, 500.00,00010,
'08-08-60',8,'A',3000.00,'01-10-05');
INSERT INTO cliente
VALUES ('ITAMAR', 'Av. Emilio Ribas','SP','07050001', 6000.00,600.00,00030,
'01-01-80',10,'I',1000.00,'01-04-05');
Passo 08: Agora, vamos fazer uma carga grande na tabela Cliente, sendo que, para isto,
iremos primeiro criar uma sequence para ser usada no cdigo do cliente, ou seja, na sua respectiva
chave primria atravs do comando a seguir: Nota: Comearemos a sequence com o nmero 40,
pois j existem, na tabela, os clientes com os cdigos de 10 a 30
CREATE SEQUENCE sequencia_cliente START WITH 40;
Passo 09: Agora sim iremos fazer uma carga de 100.000 linhas na tabela Cliente utilizando a
sequence criada anteriormente, atravs do bloco PLSQL descrito a seguir:
DECLARE
contador integer; v_vendas number(13,2):=10.00;
BEGIN
contador := 1;
WHILE contador <= 100000 LOOP
insert into cliente values ('cliente x', 'rua x','SP',
'01000000',v_vendas,100.00,
sequencia_cliente.nextval,
sysdate,10,'A',1000.00,sysdate);
contador := contador + 1;
v_vendas:= v_vendas + 10.00;
END LOOP;
END;
Passo 10: Uma vez feita a carga na tabela, avaliaremos a porcentagem de fragmentao,
sendo que primeiro devemos validar o ndice junto tabela INDEX_STATS de acordo com o comando
a seguir:
VALIDATE INDEX vendas_idx
Passo 11: Agora, vamos consultar a porcentagem de fragmentao do ndice VENDAS_idx, de
acordo com o comando a seguir:
SELECT name, del_lf_rows, lf_rows
ROUND((del_lf_rows / lf_rows + 0.00000000001) * 100)
"Percentual Fragmentado"
FROM index_stats;
Resultado:
Apesar de haver 100003 linhas na tabela Cliente e nenhuma manuteno em seus dados, no
temos nenhuma fragmentao no respectivo ndice, ou seja, porcentagem de fragmentao igual a
zero.
Passo 12: Agora vamos apagar da tabela Cliente todas as 100.000 linhas inseridas com do
bloco PLSQL, atravs do comando a seguir:
DELETE FROM cliente WHERE codigo > 30;
Passo 13: Uma vez apagadas da tabela Cliente as 100.000 linhas, novamente avaliaremos a
porcentagem de fragmentao, sendo que primeiro devemos validar o ndice junto tabela
INDEX_STATS, de acordo com o comando a seguir:
Passo 14: Agora vamos consultar a porcentagem de fragmentao do ndice VENDAS_idx, de
Desta vez, gerou-se uma fragmentao de 100% na tabela e no seu respectivo ndice, pois
foram apagadas quase todas as linhas da tabela.
Passo 15: Agora vamos eliminar a fragmentao do ndice VENDAS_IDX atravs de sua
reconstruo, de acordo com o comando a seguir:
ALTER INDEX vendas_idx REBUILD;
Passo 16: Uma vez reconstrudo o ndice novamente, avaliaremos a porcentagem de
fragmentao, sendo que primeiro devemos validar o ndice junto tabela INDEX_STATS, de acordo
com o comando a seguir:
O comando REBUILD eliminou a fragmentao somente do ndice com sua reconstruo,

entretanto a tabela correspondente ao ndice ainda se encontra fragmentada. Vamos agora eliminar
a fragmentao da tabela e do ndice atravs de exportao e importao dos dados dos objetos da
tabela.
Passo 18: Primeiramente, devemos identificar qual tabela est associada ao ndice
fragmentado, de acordo com o comando a seguir:
SELECT table_name FROM dba_indexes WHER

UPPER (index_name) = 'VENDAS_IDX';
Passo 19: Para eliminar a fragmentao da tabela Cliente e do ndice vendas_idx, deve-se
fazer a exportao da tabela, de acordo com o comando a seguir:
C> EXP usuario/senha file=?c:\backup\cliente_exp.dmp?
TABLES=(cliente) ROWS=y
Este comando esta sendo executado na raiz do sistema operacional Windows "C>"?, atravs da
linha de comando. Entretanto, ele poder ser feito atravs de alguma opo grfica, caso o usurio
tenha esta opo disponvel. Antes, dever ser criada uma pasta backup no drive disponvel do
sistema operacional para que seja criado o arquivo de exportao "cliente_exp".
Passo 20: Caso a exportao tenha sido executada com sucesso, dever ser apagado o objeto
cliente, atravs do ambiente do banco de dados Oracle, de acordo com o comando a seguir:
DROP TABLE cliente;
Passo 21: Agora, deve-se voltar ao mesmo ambiente em que foi feita a exportao do objeto e
deve-se fazer sua importao, de acordo com o comando a seguir:
C> IMP usuario/senha file=?c:\backup\cliente_exp.dmp?
Passo 22: Uma vez feita a importao do objeto, deve-se avaliar novamente a fragmentao
do ndice e, desta vez, veremos que no s a fragmentao do ndice foi eliminada, mas tambm a
do objeto correspondente, sendo que primeiro devemos validar o ndice junto tabela INDEX_STATS,
de acordo com o comando a seguir:
SITES
Referncias
2012.
McGraw-Hill, 2007.
1988.
Fragmentao de tabelas
e tablespaces
Avaliar detalhadamente a fragmentao das tabelas e das tablespaces em
que elas se localizam, considerando seus impactos nas aplicaes e no banco
de dados e tambm o ambiente eu que esto inseridos.
Introduo
Os objetos do banco de dados como usurios, tabelas, ndices, entre outros, vo sofrendo
manutenes ao longo do tempo. medida que estes objetos vo sofrendo modificaes em suas
linhas (linhas inseridas ou excludas ou modificadas), costumam ficar em locais fsicos diferentes
daqueles em que foram alocadas originalmente.
Para essas linhas, os gerenciadores criam endereos apontando para os locais de onde elas
deveriam estar fisicamente. Desta maneira, tais lugares no so aproveitados e fica um vazio nos
objetos destas linhas, ou seja, em suas tabelas e ndices. Este vazio chamado de fragmentao e
quanto maior for, pior ser o desempenho das aplicaes que manipulam estes objetos e,
consequentemente, pior para o desempenho do ambiente de maneira geral.
Essas fragmentaes podero ser de tabelas, ndices e tambm de tablespaces e acabam
afetando todos os objetos contidos nelas, como tabelas, ndices, usurios, entre outros. de
responsabilidade do administrador de BD identificar e eliminar essas fragmentaes o mais rpido
quando possvel.
O cenrio a seguir d uma viso detalhada de como identific-la e elimin-la, posteriormente.
Caractersticas gerais
Antes do comearmos com os conceitos envolvendo a fragmentao das tablespaces e das

tabelas muito importante conhecermos o conceito de HWM (High Water Mark), ou marcad?gua.
A HWM um indicador para o gerenciador de banco de dados do limite que uma tabela j
ocupou do seu espao fsico, ou seja: a quantidade mxima de blocos que a tabela estar
utilizando. Na verdade, indica os blocos que uma tabela sempre utilizou e os blocos que ela nunca
utilizou.
Este valor sempre redimensionado em funo das linhas que a tabela recebe, ou seja, toda
vez que a tabela aumentada esta marca redimensionada pela necessidade de novos blocos,
utilizando o parmetro DB_BLOCK_SIZE e descobrindo o novo tamanho fsico da tabela.
Existem outros fatores que iro influenciar no tamanho fsico das tabelas ou HWM, como se as
tablespaces em que elas esto localizadas esto sendo gerenciadas localmente ou pelo dicionrio de
dados, do tamanho dos EXTENTS iniciais, dos EXTENTS utilizados no aumento das tablespaces e da
quantidade de blocos que um EXTENT pode suportar.
Este indicador importante porque o gerenciador sempre ir ler todos os blocos at essa
marca em caso de uma leitura total da tabela e se existir muitos blocos vazios o desempenho do
gerenciador ir ser degradado. Os blocos vazios que existirem at esta marca o que chamamos de
fragmentao e dever ser gerenciado e eliminado.
Nas verses mais antigas do Oracle podamos eliminar esta fragmentao de trs maneiras:
pela exportao, eliminao do objeto e posterior importao. Tambm possvel utilizando o
comando alter table com o parmetro move movimentando a tabela de uma tablespace para
outra. Ou quando uma tabela ocupa uma tablespace com autogerenciamento de espao, ou seja,
com o parmetro de espao auto segment space management pode-se utilizar a opo shrink
para eliminar os espaos no utilizados, por meio do comando: alter table nome_tabela shrink
space compact.
Esta opo quando utilizada produz uma melhoria considervel no desempenho dos comandos
SQL e tambm reduz a fragmentao do BD. Para que ela possa ser utilizada, dever ser configurado
o parmetro compatible com valor maior que 10.0.0 por meio do arquivo de parmetros spfile, pelo
comando:
Aps a execuo, dever ser reiniciada a instncia do banco. A opo shrink poder ser
aplicada na reorganizao dos espaos das tabelas, ndices, views, lob, etc.
Antes de executarmos esta opo devemos habilitar a reorganizao dos espaos por este
parmetro por meio do comando:
Este parmetro possui algumas opes, ou seja:

Sem nenhuma opo podemos reduzir os segmentos da tabela e tambm sua marca-d?gua
(HWM), por meio do comando:
Opo COMPACT neste caso reduz os segmentos da tabela, mas no reduz sua marca-d?gua,
Opo CASCADE neste caso reduz os segmentos da tabela, sua marca-d?gua e todos os
ndices relacionados, por meio do comando:
Existe tambm a opo que reduz os segmentos dos ndices somente, por meio do comando:
A opo shrink efetua lock exclusivo no objeto que est reorganizando os espaos. Assim, seria
interessante executar esta opo em horrios pr-determinados para no afetar o ambiente e os
comandos SQL executados pelas aplicaes.
Toda vez que o espao de uma tabela reorganizado dentro de um tablespace,
posteriormente, deve-se calcular novamente sua marca-d?gua, ou seja, o seu HWM. Isto feito pelo
comando ALTER TABLE NOME_TABELA SHRINK SPACE.
Fragmentao de tablespace
Este tipo de fragmentao ocorre quando o espao livre de um tablespace est fragmentado
em vrias partes, ao invs de uma nica parte. Desta maneira novas solicitaes de EXTENTS no
consegue ser feita para a realizao de uma determinada tarefa.
Existe uma maneira de evitar esta fragmentao por meio do parmetro STORAGE, definindo a
opo de PCTINCREASE com valor igual a zero, Para que a fragmentao da tablespace no ocorra,
devemos definir PCTINCREASE igual zero tambm para as tabelas e ndices contidas na tablespace.
O PCTINCREASE igual a zero poder ser definido para os objetos por meio dos seguintes
comandos:
Outra maneira de evitar a fragmentao das tablespaces pelos parmetros INITIAL e NEXT,
ou seja, a quantidade de espao a ser alocada na tablespace definida no parmetro NEXT dever ser
compatvel e mltiplo da quantidade de espao alocado inicialmente no parmetro INITIAL, alm de
ser de acordo com o tamanho dos objetos alocados na respectiva tablespace.
Fragmentao de segmentos de datafiles
Esta fragmentao ocorre quando os espaos alocados nos EXTENTS no so mais suficientes
para os objetos da tablespace e h a necessidade de alocao de mais deles. Neste cenrio podem
ocorrer novas alocaes em locais diferentes dos at ento, gerando fragmentao. Este tipo de
problema poder ser evitado com a alocao inicial de EXTENTS suficientes para os objetos a serem
alocados na tablespace.
Tipos de fragmentao de espao
No caso da fragmentao do espao ocupado, os espaos livres encontram- -se separados pelo
primeiro, e, desta maneira, se torna necessria a compresso dos EXTENTS para eliminar a
fragmentao. Isso poder ser feito pelos procedimentos:
Exportao de todos os objetos do BD.

Eliminao dos respectivos objetos.
mportao dos mesmos objetos.
No caso da fragmentao do espao livre, os espaos desocupados esto todos contguos e

poder ser visualizado por meio do comando:
A eliminao da fragmentao do espao livre poder ser feita pelo comando:
No caso do espao livre alocado e nunca utilizado desde a criao da tablespace, ele dever
ser liberado para uso da tablespace por meio do comando:
Referncias
2012.
McGraw-Hill, 2007.
1988.
2013.M
Cenrio para avaliao da

fragmentao de ndices
Realizar uma avaliao detalhada da fragmentao dos ndices atravs da
criao de um cenrio para simulao da fragmentao, sua identificao e
posterior eliminao.
Introduo
O cenrio mostrado a seguir dever mostrar a identificao desta fragmentao e os
procedimentos para a eliminar tanto dos ndices quanto das tabelas.
Este cenrio ser composto de passos a serem seguidos para simular a fragmentao.
Cenrio da fragmentao
Para fazermos as simulaes para a criao e eliminao da fragmentao, primeiramente

devemos criar um ambiente no banco de dados atravs dos passos a seguir:
Passo 01: Primeiramente devemos nos conectar ao banco de dados como Administrador,
Usurio: system
Senha: manager
Passo 02: Uma vez conectado neste usurio, dever ser criado um usurio para fazermos as
simulaes atravs do comando a seguir, sendo que dever ser substitudo o nome_usuario por um
usurio especfico e a senha_usuario por uma senha especfica.

CREATE USER nome_usuario IDENTIFIED BY senha_usuario
Passo 03: Dever ser dada uma autorizao para o usurio criado se conectar ao banco de
dados, atravs do comando a seguir:
GRANT connect TO nome_usuario;
GRANT resource TO nome_usuario;
Passo 05: Dever ser criada uma tabela para podermos fazer as simulaes. Neste caso,
criaremos a tabela Cliente atravs do comando a seguir:
CREATE TABLE cliente
(nome varchar2(15), endereco varchar2(30),
estado varchar2(02), cep varchar2(08),
vendas number(13,2), juros_vendas number(13,2),
codigo number(07), primary key (cdigo), data_nasc date,
parcelas number(05), status varchar2(01),
valor_nota number(13,2), emissao_nota date);
Passo 06: Uma vez criada a tabela Cliente, dever ser criado um ndice, atravs dos comandos
a seguir:
CREATE INDEX vendas_idx
ON cliente (vendas);
Passo 07: Uma vez criada a tabela Cliente, devero ser inseridas linhas na tabela, de acordo
com os comandos a seguir:
INSERT INTO cliente
VALUES ('MARIA', 'Rua dos trilhos','SP','03040010', 7500.00,750.00,00020,
'10-10-58' ,5,'A',2000.00,'29-09-05');
INSERT INTO cliente
VALUES ('ANTONIO',?Rua Matilde','SP','07050001', 5000.00, 500.00,00010,
'08-08-60',8,'A',3000.00,'01-10-05');
INSERT INTO cliente
VALUES ('ITAMAR', 'Av. Emilio Ribas','SP','07050001', 6000.00,600.00,00030,
'01-01-80',10,'I',1000.00,'01-04-05');
Passo 08: Agora, vamos fazer uma carga grande na tabela Cliente, sendo que, para isto,
iremos primeiro criar uma sequence para ser usada no cdigo do cliente, ou seja, na sua respectiva
chave primria atravs do comando a seguir: Nota: Comearemos a sequence com o nmero 40,
pois j existem, na tabela, os clientes com os cdigos de 10 a 30
CREATE SEQUENCE sequencia_cliente START WITH 40;
Passo 09: Agora sim iremos fazer uma carga de 100.000 linhas na tabela Cliente utilizando a
sequence criada anteriormente, atravs do bloco PLSQL descrito a seguir:
DECLARE
contador integer; v_vendas number(13,2):=10.00;
BEGIN
contador := 1;
WHILE contador <= 100000 LOOP
insert into cliente values ('cliente x', 'rua x','SP',
'01000000',v_vendas,100.00,
sequencia_cliente.nextval,
sysdate,10,'A',1000.00,sysdate);
contador := contador + 1;
v_vendas:= v_vendas + 10.00;
END LOOP;
END;
Passo 10: Uma vez feita a carga na tabela, avaliaremos a porcentagem de fragmentao,
sendo que primeiro devemos validar o ndice junto tabela INDEX_STATS de acordo com o comando
a seguir:
Passo 11: Agora, vamos consultar a porcentagem de fragmentao do ndice VENDAS_idx, de
SELECT name, del_lf_rows, lf_rows
ROUND((del_lf_rows / lf_rows + 0.00000000001) * 100)
"Percentual Fragmentado"
FROM index_stats;
Resultado:
Apesar de haver 100003 linhas na tabela Cliente e nenhuma manuteno em seus dados, no
temos nenhuma fragmentao no respectivo ndice, ou seja, porcentagem de fragmentao igual a
zero.
Passo 12: Agora vamos apagar da tabela Cliente todas as 100.000 linhas inseridas com do
bloco PLSQL, atravs do comando a seguir:
DELETE FROM cliente WHERE codigo > 30;
Passo 13: Uma vez apagadas da tabela Cliente as 100.000 linhas, novamente avaliaremos a
porcentagem de fragmentao, sendo que primeiro devemos validar o ndice junto tabela
INDEX_STATS, de acordo com o comando a seguir:
Desta vez, gerou-se uma fragmentao de 100% na tabela e no seu respectivo ndice, pois
foram apagadas quase todas as linhas da tabela.
Passo 15: Agora vamos eliminar a fragmentao do ndice VENDAS_IDX atravs de sua
reconstruo, de acordo com o comando a seguir:
ALTER INDEX vendas_idx REBUILD;
Passo 16: Uma vez reconstrudo o ndice novamente, avaliaremos a porcentagem de
fragmentao, sendo que primeiro devemos validar o ndice junto tabela INDEX_STATS, de acordo
com o comando a seguir:
O comando REBUILD eliminou a fragmentao somente do ndice com sua reconstruo,

entretanto a tabela correspondente ao ndice ainda se encontra fragmentada. Vamos agora eliminar
a fragmentao da tabela e do ndice atravs de exportao e importao dos dados dos objetos da
tabela.
Passo 18: Primeiramente, devemos identificar qual tabela est associada ao ndice
fragmentado, de acordo com o comando a seguir:
SELECT table_name FROM dba_indexes WHER

UPPER (index_name) = 'VENDAS_IDX';
Passo 19: Para eliminar a fragmentao da tabela Cliente e do ndice vendas_idx, deve-se
fazer a exportao da tabela, de acordo com o comando a seguir:
C> EXP usuario/senha file=?c:\backup\cliente_exp.dmp?
Este comando esta sendo executado na raiz do sistema operacional Windows "C>"?, atravs da
linha de comando. Entretanto, ele poder ser feito atravs de alguma opo grfica, caso o usurio
tenha esta opo disponvel. Antes, dever ser criada uma pasta backup no drive disponvel do
sistema operacional para que seja criado o arquivo de exportao "cliente_exp".
Passo 20: Caso a exportao tenha sido executada com sucesso, dever ser apagado o objeto
cliente, atravs do ambiente do banco de dados Oracle, de acordo com o comando a seguir:
DROP TABLE cliente;
Passo 21: Agora, deve-se voltar ao mesmo ambiente em que foi feita a exportao do objeto e
deve-se fazer sua importao, de acordo com o comando a seguir:
C> IMP usuario/senha file=?c:\backup\cliente_exp.dmp?
Passo 22: Uma vez feita a importao do objeto, deve-se avaliar novamente a fragmentao
do ndice e, desta vez, veremos que no s a fragmentao do ndice foi eliminada, mas tambm a
do objeto correspondente, sendo que primeiro devemos validar o ndice junto tabela INDEX_STATS,
SITES
Referncias
2012.
McGraw-Hill, 2007.
1988.
Fragmentao de tabelas
e tablespaces
Avaliar detalhadamente a fragmentao das tabelas e das tablespaces em
que elas se localizam, considerando seus impactos nas aplicaes e no banco
de dados e tambm o ambiente eu que esto inseridos.
Introduo
quando possvel.
Caractersticas gerais
Antes do comearmos com os conceitos envolvendo a fragmentao das tablespaces e das

tabelas muito importante conhecermos o conceito de HWM (High Water Mark), ou marcad?gua.
A HWM um indicador para o gerenciador de banco de dados do limite que uma tabela j
ocupou do seu espao fsico, ou seja: a quantidade mxima de blocos que a tabela estar
utilizando. Na verdade, indica os blocos que uma tabela sempre utilizou e os blocos que ela nunca
utilizou.
Este valor sempre redimensionado em funo das linhas que a tabela recebe, ou seja, toda
vez que a tabela aumentada esta marca redimensionada pela necessidade de novos blocos,
utilizando o parmetro DB_BLOCK_SIZE e descobrindo o novo tamanho fsico da tabela.
Existem outros fatores que iro influenciar no tamanho fsico das tabelas ou HWM, como se as
tablespaces em que elas esto localizadas esto sendo gerenciadas localmente ou pelo dicionrio de
dados, do tamanho dos EXTENTS iniciais, dos EXTENTS utilizados no aumento das tablespaces e da
quantidade de blocos que um EXTENT pode suportar.
Este indicador importante porque o gerenciador sempre ir ler todos os blocos at essa
marca em caso de uma leitura total da tabela e se existir muitos blocos vazios o desempenho do
gerenciador ir ser degradado. Os blocos vazios que existirem at esta marca o que chamamos de
fragmentao e dever ser gerenciado e eliminado.
Nas verses mais antigas do Oracle podamos eliminar esta fragmentao de trs maneiras:
pela exportao, eliminao do objeto e posterior importao. Tambm possvel utilizando o
comando alter table com o parmetro move movimentando a tabela de uma tablespace para
outra. Ou quando uma tabela ocupa uma tablespace com autogerenciamento de espao, ou seja,
com o parmetro de espao auto segment space management pode-se utilizar a opo shrink
para eliminar os espaos no utilizados, por meio do comando: alter table nome_tabela shrink
space compact.
Esta opo quando utilizada produz uma melhoria considervel no desempenho dos comandos
SQL e tambm reduz a fragmentao do BD. Para que ela possa ser utilizada, dever ser configurado
o parmetro compatible com valor maior que 10.0.0 por meio do arquivo de parmetros spfile, pelo
comando:
Aps a execuo, dever ser reiniciada a instncia do banco. A opo shrink poder ser
aplicada na reorganizao dos espaos das tabelas, ndices, views, lob, etc.
Antes de executarmos esta opo devemos habilitar a reorganizao dos espaos por este
parmetro por meio do comando:
Este parmetro possui algumas opes, ou seja:

Sem nenhuma opo podemos reduzir os segmentos da tabela e tambm sua marca-d?gua
(HWM), por meio do comando:
Opo COMPACT neste caso reduz os segmentos da tabela, mas no reduz sua marca-d?gua,
Opo CASCADE neste caso reduz os segmentos da tabela, sua marca-d?gua e todos os
ndices relacionados, por meio do comando:
Existe tambm a opo que reduz os segmentos dos ndices somente, por meio do comando:
A opo shrink efetua lock exclusivo no objeto que est reorganizando os espaos. Assim, seria
interessante executar esta opo em horrios pr-determinados para no afetar o ambiente e os
comandos SQL executados pelas aplicaes.
Toda vez que o espao de uma tabela reorganizado dentro de um tablespace,
posteriormente, deve-se calcular novamente sua marca-d?gua, ou seja, o seu HWM. Isto feito pelo
comando ALTER TABLE NOME_TABELA SHRINK SPACE.
Fragmentao de tablespace
Este tipo de fragmentao ocorre quando o espao livre de um tablespace est fragmentado
em vrias partes, ao invs de uma nica parte. Desta maneira novas solicitaes de EXTENTS no
consegue ser feita para a realizao de uma determinada tarefa.
Existe uma maneira de evitar esta fragmentao por meio do parmetro STORAGE, definindo a
opo de PCTINCREASE com valor igual a zero, Para que a fragmentao da tablespace no ocorra,
devemos definir PCTINCREASE igual zero tambm para as tabelas e ndices contidas na tablespace.
O PCTINCREASE igual a zero poder ser definido para os objetos por meio dos seguintes
comandos:
Outra maneira de evitar a fragmentao das tablespaces pelos parmetros INITIAL e NEXT,
ou seja, a quantidade de espao a ser alocada na tablespace definida no parmetro NEXT dever ser
compatvel e mltiplo da quantidade de espao alocado inicialmente no parmetro INITIAL, alm de
ser de acordo com o tamanho dos objetos alocados na respectiva tablespace.
Fragmentao de segmentos de datafiles
Esta fragmentao ocorre quando os espaos alocados nos EXTENTS no so mais suficientes
para os objetos da tablespace e h a necessidade de alocao de mais deles. Neste cenrio podem
ocorrer novas alocaes em locais diferentes dos at ento, gerando fragmentao. Este tipo de
problema poder ser evitado com a alocao inicial de EXTENTS suficientes para os objetos a serem
alocados na tablespace.
Tipos de fragmentao de espao
No caso da fragmentao do espao ocupado, os espaos livres encontram- -se separados pelo
primeiro, e, desta maneira, se torna necessria a compresso dos EXTENTS para eliminar a
fragmentao. Isso poder ser feito pelos procedimentos:
Exportao de todos os objetos do BD.

Eliminao dos respectivos objetos.
mportao dos mesmos objetos.
No caso da fragmentao do espao livre, os espaos desocupados esto todos contguos e

poder ser visualizado por meio do comando:
A eliminao da fragmentao do espao livre poder ser feita pelo comando:
No caso do espao livre alocado e nunca utilizado desde a criao da tablespace, ele dever
ser liberado para uso da tablespace por meio do comando:
Referncias
2012.
McGraw-Hill, 2007.
1988.
2013.M
Cenrio de fragmentao
de tabelas e tablespaces
Avaliar detalhadamente a fragmentao de tablespaces por meio da criao
de um cenrio para simulao da fragmentao, sua identificao e posterior
eliminao pela movimentao dos objetos contidos nela.
Introduo
quando possvel.
Identificando e eliminando a fragmentao de tablespace

cenrio da fragmentao
Para fazermos as simulaes para criar e eliminar a fragmentao da tablespace,

primeiramente, devemos criar um ambiente no BD com base em alguns passos a seguir:
Passo 01: primeiro devemos nos conectar no BD com o usurio SYS, por meios dos comandos
a seguir:
Passo 02: agora devemos criar uma tablespace chamada TBLSPC01 com 50MB de tamanho,
com gerenciamento de espaos dos extents local e com autogerenciamento de espaos no
segmento:
O caminho do arquivo datafile dever ser identificado por meio do comando:
Passo 03: uma vez criada a tablespace dever ser desenvolvido um usurio usando a
tablespace criada e com sua quota ilimitada para fazermos as simulaes, por meio do comando
adiante, sendo que dever ser substitudo o nome do usurio e a senha para os seus valores
especficos.
Passo 04: dever ser dada uma autorizao para o usurio criado se conectar ao BD, por meio
do comando a seguir:
Passo 05: dever ser dada uma autorizao para o usurio criado usar os recursos do banco,
Passo 06: dever ser conectado no usurio criado para fazermos as simulaes de
fragmentao:
Passo 07: dever ser criada uma tabela utilizando a tablespace para fazer as simulaes,
sendo que neste caso criaremos a tabela Cliente, por meio do comando:
Passo 08: fazer uma carga grande na tabela Cliente, primeiro criando uma sequencia para ser
usada no cdigo do cliente, ou seja, na sua respectiva chave primria por meio do seguinte
comando:
Passo 09: agora sim iremos fazer uma carga de 100.000 linhas na tabela Cliente utilizando a
sequencia criada anteriormente, por meio do bloco PLSQL descrito a seguir:
Passo 10: atualizar algumas das informaes da tablespace e do segmento que contm a
tabela nas estatsticas do dicionrio de dados, por meio do comando:
Passo 11: agora vamos consultar os blocos utilizados e blocos livres utilizados na tablespace
TBLSPC01 aps a criao e carga da tabela Cliente, pelo comando a seguir:
Passo 12:agora devemos apagar da tabela todas as 100.000 linhas inseridas com do bloco
PLSQL e, em seguida, efetivamos a seo, por meio dos comandos a seguir:
Passo 13: novamente, vamos atualizar algumas das informaes da tablespace e do
segmento o qual contm a tabela nas estatsticas do dicionrio de dados, por meio do seguinte
comando:
Passo 14: mais uma vez vamos consultar os blocos utilizados e blocos livres utilizados na
tablespace TBLSPC01 aps a eliminao das linhas da tabela cliente, por meio do comando a seguir:
Concluso
Como podemos ver, continuam alocados os 1024 blocos para o segmento Cliente mesmo aps
a eliminao das linhas da tabela contidas nele.
Passo 15: vamos afora consultar os EXTENTS utilizados pelo segmento cliente, por meio do
comando a diante, mas antes devemos nos conectar no usurio SYSTEM e substituir o nome do
usurio para o usurio criado.
Extents utilizados pelo segmento cliente.
Concluso
Como podemos ver anteriormente, 23 EXTENTS foram alocados para armazenar os 1024
blocos, sendo que alguns armazenam 8 blocos de dados, enquanto os demais armazenam 128.
Passo 16: agora devemos voltar ao usurio criado e criar e popular uma nova tabela chamada
titulo, por meio dos comandos a seguir.
Passo 17: novamente vamos consultar os blocos utilizados e blocos livres utilizados na
tablespace TBLSPC01, aps a criao e inseres de linhas na tabela ttulo, por meio do comando a
seguir:
Passo 18: vamos consultar os EXTENTS utilizados pelo segmento TTULO, por meio do
comando a diante, mas antes devemos nos conectar no usurio SYSTEM, e substituir seu nome para
o usurio criado.
Extents utilizados pelo segmento ttulo
Extents utilizados pelo segmento ttulo
Concluso:
Como podemos ver, o Oracle alocou novos espaos (EXTENTS) para a tabela Ttulo mesmo com
a tabela Cliente vazia, ou seja, os EXTENTS da tabela Cliente no foram aproveitados. Seus espaos
somente sero aproveitados se a marca-d?gua (HWM) da respectiva tabela for ajustada e isto
poder ser feito com os comandos TRUNCATE, MOVE ou SHRINK.
Passo 19: agora dever ser feita a movimentao da tabela dentro do tablespace em que se
ela se encontra, mas antes se deve conectar ao usurio em que ela foi criada, de acordo com os
comandos a diante.
Com isso, suas extenses sero realocadas para um novo segmento e iro proporcionar o
ajuste da marca-d?agua (HWM).
Passo 20: nesse momento dever ser habilitada a movimentao das linhas na tabela Cliente,
de acordo com os comandos a seguir:
Passo 21: aqui dever ser feita a compactao dos segmentos da tabela cliente e o ajuste da
marca-d?gua (HWM), de acordo com os comandos a seguir
Passo 22: agora vamos consultar os EXTENTS utilizados pelo segmento CLIENTE, por meio do
comando a diante, mas antes devemos nos conectar no usurio SYSTEM, e substituir seu nome para
o usurio criado.
Extents utilizados pelo segmento cliente
Extents utilizados pelo segmento cliente.
Passo 23: nesse momento vamos atualizar algumas das informaes da tablespace e do
segmento que contm a tabela nas estatsticas do dicionrio de dados, mas antes devemos nos
conectar no usurio que criou a tabela, por meio do comando a seguir:
Passo 24: novamente, vamos consultar os blocos utilizados e blocos livres utilizados na
tablespace TBLSPC01 aps a reorganizao do segmento cliente e o ajuste da marca-d?gua (HWM),
por meio do comando a seguir:
Blocos utilizados e blocos livres
Blocos utilizados e blocos livres
Concluso
Como podemos ver, o Oracle liberou os espaos (EXTENTS) que tinham sido alocados para o
segmento cliente, podendo ser utilizados para outras locaes, eliminando, assim, a fragmentao
da respectiva tablespace.
Referncias
2012.
McGraw-Hill, 2007.
1988.
Estadual de Londrina. Dissertao de Mestrado. Disponvel em: www2.dc.uel.br. Acesso em 21
jan. 2013.
Mtodos de juno do
Oracle
Estudar detalhado dos mtodos de juno das tabelas utilizados pelo
otimizador do Oracle, identificando as principais caractersticas, vantagens e
desvantagens de cada um.
Introduo
O gerenciador de banco de dados, particularmente o Oracle, tem como caracterstica a

montagem de um plano de execuo, ou seja, toda vez que um comando SQL submetido a ele o
otimizador faz uma anlise e monta um plano de execuo para definir o caminho mais eficiente
para realiz-lo quando uma aplicao ou um usurio solicitar.
No caso especfico dos joins de tabela o gerenciador escolhe o mtodo de juno com um
menor custo e melhor desempenho. Existem mtodos mais e menos eficientes, dependendo da
situao encontrada quando o otimizador avalia um comando SQL envolvendo mais de uma tabela.
Avaliaremos a seguir os principais mtodos de juno, bem como as caractersticas de cada
um.
Nested loop
Este um dos melhores mtodos escolhido pelo otimizador em termos de desempenho no

Oracle. A principal caracterstica deste mtodo que ele normalmente retorna poucas linhas, e suas
tabelas envolvidas no Join devero estar relacionadas por meio da chave primria e chave
estrangeira.
Outra caracterstica importante no Join para que o otimizador escolha este mtodo que as
colunas informadas na clusula Where devero ter ndices, fazendo com que a pesquisa acesse
diretamente a informao por ele, evitando, assim, a varredura da tabela.
Quando o otimizador escolhe este mtodo para tratar o Join de um comando Select, este elege
uma tabela principal, normalmente a menor, a qual servir de base para pesquisar as outras linhas
na tabela dependente, ou seja, para cada linha da tabela principal, o otimizador ir buscar linhas(s)
correspondente(s) na tabela dependente que atenda s condies do filtro na clusula Where, e
tambm as condies de relacionamento entre a chave primria e a chave estrangeira.
Quando o otimizador escolher este mtodo de Join para uma determinada consulta, o Oracle
realiza os seguintes passos quando for executar o comando SQL:
Primeiro, escolhe-se a menor tabela e a elege como principal.

Para cada linha da tabela principal o Oracle vai pesquisar as linhas da tabela dependente que
atendam as condies de igualdade do Join identificadas no relacionamento atravs da chave
primria e chave estrangeira.
Quando encontra a igualdade o Oracle seleciona as linhas que atenderam essa condio e as
devolve como resultadas.
Exemplo de um nested loop
Supondo que as tabelas cliente e titulo estejam relacionadas entre si por meio da chave
primaria (PK) e chave estrangeira (FK) e ainda exista um ndice para a coluna vendas, o otimizador
ir escolher o mtodo de acesso nested loop.
Nesse caso, o Oracle ir dividir esta consulta em duas, de acordo com o modelo a seguir:
Consulta principal:
Esta consulta acaba sendo eleita porque acessa a tabela CLIENTE que ser eleita como a tabela
principal, pois pelo fato de retornar menos linhas acabar sendo menor, uma vez que retorna
somente clientes com vendas iguais a R$ 100,00.
A outra consulta feita aps a separao da original chamada de consulta dependente, pois
para cada linha retornada pela principal ir procurar as linhas correspondentes relacionadas. A
consulta dependente, aps a separao feita pelo otimizador, dever ser a seguinte:
Merge Join
Este mtodo tambm chamado de SORT_MERGE_JOIN e tem como principal caracterstica a

classificao das duas tabelas pela chave de unio das duas tabelas ou chave Join.
A chave Join nada mais do que os campos envolvidos na clusula Where, igualados s chaves
comuns das duas tabelas. Uma vez classificada as tabelas por esta chave, o Oracle, posteriormente,
ir buscar as linhas das duas tabelas que tm correspondentes por esta chave e devolve as colunas
desta linha para quem solicitou.
Este mtodo utilizado quando as tabelas envolvidas em um comando Join no foram
relacionadas previamente por meio da chave primria (PK) e chave estrangeira (FK) e costuma ter
um desempenho muito ruim na aplicao e no ambiente onde ser executado, pois ter que
classificar as duas tabelas pela mesma chave, ir comparando os valores da chave Join das duas
tabelas para encontrar os valores idnticos, separar esta linha e devolver para o solicitante.
Podemos exemplificar este cenrio imaginando que queremos identificar todos os ttulos
devidos dos clientes de uma empresa. Primeiro, necessrio classificar todos os clientes pelo CNPJ
e, posteriormente, classificar os ttulos em aberto pelo mesmo CNPJ que seria a chave de juno das
duas tabelas ou chave Join.
Uma vez feita a juno das duas tabelas faramos a comparao dos CNPJ da tabela cliente com
os da tabela de ttulos. Toda a linha encontrada que tivesse o mesmo CNPJ nas duas tabelas iria
disponibilizar para a consulta, sendo que neste caso estaramos fazendo um MERGE JOIN.
Hash Join
Este mtodo normalmente escolhido pelo otimizador quando uma consulta envolvendo um
Join de duas ou mais tabelas retornam um grande nmero de linhas como resultado. Outra
caracterstica para a escolha deste mtodo pelo otimizador que a consulta dever ter o operador
de igualdade no seu filtro de pesquisa (clusula Where).
Neste mtodo, o otimizador ir escolher a menor tabela e constru-la na memria com os
campos definidos pela consulta e tambm com o campo de juno das duas tabelas.
Esta tabela gravada na memria chamada de ?TABELA HASH?. Aps a sua construo na
memria, o otimizador ir buscar na outra tabela todas as linhas relacionadas com esta pela chave
de juno.
Este mtodo composto pelos seguintes passos:
Passo 01: faz uma leitura total nas duas tabelas (Full Table Scan) e as divide em vrias
parties de acordo com a memria principal disponvel no servidor.
Passo 02: escolhe a menor tabela e a elege com Tabela Hash e a usa para identificar os pares
de linhas das duas tabelas com base na igualdade da chave de juno.
Passo 03: todo o par de linhas encontrado nas duas tabela o otimizador disponibiliza para o
solicitante.
Sort Merge
Este mtodo costuma ser a ltima opo do otimizador, pois utilizado quando no existe
nenhuma relao entre as duas tabelas em um comando de seleo com a opo de Join.
Este mtodo tambm o que tem o pior desempenho entre os demais tanto para a aplicao
utilizada como para o ambiente do banco de dados.
Tambm utilizado quando temos os operadores <, <=, > ou >= nos filtros de pesquisa da
clusula Where do Join, pois o otimizador simplesmente organiza as duas tabelas e as une.
Seletividade
Este um dos principais critrios a ser utilizado pelo otimizador para escolher o mtodo de
juno das tabelas. Significa a porcentagem de linhas de uma tabela em relao ao total da tabela
que o Join seleciona, ou seja, um comando Join que seleciona uma grande quantidade de linhas de
uma tabela tem uma baixa seletividade, ao passo que quando seleciona uma pequena quantidade
de linhas tem uma alta seletividade.
Quando um comando Join tem uma alta seletividade o otimizador tem a tendncia de utilizar
um ndice. Caso exista ndice para a coluna do filtro de pesquisa, h o significativo aumentado do
desempenho da aplicao e do ambiente no qual o comando de seleo esta inserido.
Quando o Join tem uma baixa seletividade a varredura total da tabela tem um desempenho
melhor do que a leitura utilizando um ndice.
Os critrios para a determinao da seletividade de um Join devem considerar trs fatores que
so:
Os operadores utilizados na clusula Where.

Os campos de relacionamento das duas tabelas, ou seja, a chave primria (PK) e a chave
estrangeira (FK).
Estatsticas acessadas por meio de tabelas do dicionrio de dados.
Exemplo para anlise da seletividade de uma pesquisa

cenrio 01:
Neste caso, o campo cdigo ser nico ou chave primria da tabela cliente e esta consulta
dever retornar um nico valor para a pergunta. Aqui, o comando ter uma boa seletividade e o
otimizador dever utilizar um ndice para a coluna cdigo, caso exista.
Exemplo para anlise da seletividade de uma pesquisa

cenrio 02:
Aqui, o campo vendas poder ter vrios valores e no comando anterior poder ter vrias linhas
selecionadas. Sendo assim, o otimizador dever utilizar os valores de estatsticas encontrados em
tabelas do dicionrio de dados para determinar a seletividade.
Os valores pesquisados no dicionrio de dados so:
Aps a diviso do nmero de linhas da tabela cliente pelos valores distintos na coluna Vendas,
o otimizador estima o grau de seletividade do comando anterior.
SITES
Referncias
2012.
McGraw-Hill, 2007.
1988.
Cenrio para avaliao

dos mtodos de juno do
Oracle
Avaliar detalhadamente os mtodos de juno do Oracle, atravs da criao
de um cenrio para identificao e anlise de cada um dos mtodos.
Introduo
O gerenciador de banco de dados, particularmente o Oracle, tem como caracterstica a

montagem de um plano de execuo, ou seja, toda vez que um comando SQL submetido a ele, o
otimizador faz uma anlise no comando e monta um plano de execuo para definir o caminho mais
eficiente para execut-lo quando uma aplicao ou um usurio solicitar.
No caso especfico dos JOINS de tabela, o gerenciador escolhe o mtodo de juno com menor
custo e melhor desempenho.
Existem mtodos mais e menos eficientes dependendo da situao encontrada quando o
otimizador avalia um comando SQL envolvendo mais de uma tabela.
A seguir, ser criado um cenrio em que sero identificados cada um desses mtodos e haver
posterior anlise das caractersticas de cada um deles.
Cenrio para criao de cada um dos mtodos
Para a criao deste cenrio, primeiramente, dever ser criado um ambiente no banco de
dados atravs dos passos a seguir:
Passo 01: Devemos nos conectar ao banco de dados como Administrador, atravs do comando
a seguir:
Passo 02: Uma vez conectado no usurio Administrador, dever ser criado um usurio para
identificao dos mtodos, atravs do comando a seguir, sendo que dever ser substitudo o
"nome_usuario" por um usurio especfico e a "senha_usuario" por uma senha especfica.
Passo 03: Dever ser dada uma autorizao para o usurio criado se conectar ao Banco de
Dados, atravs do comando a seguir:
Passo 05: Dever ser conectado ao usurio criado para fazer as simulaes dos mtodos de
acesso:
Passo 06: Dever ser criada uma tabela CLIENTE e uma tabela TITULO para podermos fazer as
simulaes, atravs do comando a seguir:
Passo 07: Agora, sim, iremos fazer uma carga de 10.000 linhas na tabela cliente e 40.000 na
tabela titulo, atravs dos blocos PLSQL descritos a seguir:
Carga na tabela Cliente
Carga na tabela Ttulo
Passo 08: Dever ser criado o plano de acesso na tabela PLAN TABLE para avaliao de um
JOIN, usando as tabelas Cliente e Ttulo de maneira independente e sem nenhum relacionamento
entre as duas, de acordo com o comando a seguir:
Posteriormente, dever ser consultado o plano criado, atravs do comando a seguir:
O plano de acesso criado para o comando anterior ir trazer o seguinte resultado:
Figura 1: Resultado do plano de acesso de tabelas independentes.
De acordo com este resultado, o otimizador fez o seguinte:
Um merge cartesiano das tabelas Cliente e Ttulo com varredura total das duas tabelas.
Antes de fazer a varredura da tabela Ttulo, ele a classificou atravs de um SORT.
Podemos concluir que tal consulta de altssimo custo, afetando tremendamente o desempenho da
aplicao e do ambiente.
JOIN usando as tabelas Cliente e Ttulo de maneira independente e criando um filtro, de acordo com
o comando a seguir:
Posteriormente, dever ser consultado o plano criado atravs do comando a seguir:
Figura 2: Resultado do plano de acesso de tabelas independentes e utilizando um filtro.
Um merge cartesiano das tabelas Cliente e Ttulo, com varredura da tabela Ttulo.
Antes de fazer a varredura da tabela ttulo, ele a classificou atravs de um SORT.
Podemos concluir que o merge foi minimizado em funo do filtro da tabela Cliente, reduzindo a
quantidade de linhas trazida para sua memria.
JOIN usando as tabelas Cliente e Ttulo, igualando as chaves e colocando um filtro na tabela Cliente,
Figura 3: Resultado do plano de acesso usando as tabelas Cliente e Ttulo, igualando as chaves
e colocando um filtro na tabela Cliente.
Um HASH JOIN, fazendo varredura nas duas tabelas.

Escolheu a menor tabela (cliente) e colocou na memria.
Em seguida, buscou as linhas correspondentes na tabela Ttulo que satisfazem a condio de
igualdade.
Podemos concluir que o HASH JOIN foi minimizado em funo do filtro da tabela Cliente, reduzindo a
quantidade de linhas trazidas para a memria dela.
JOIN usando as tabelas Cliente e Ttulo, igualando as chaves e colocando um filtro na tabela Cliente,
sendo que ser criado um ndice para este campo, de acordo com o comando a seguir:
Figura 4: Resultado do plano de acesso usando as tabelas Cliente e Ttulo igualando as chaves,
colocando um filtro na tabela Cliente e usando um ndice.
Um HASH JOIN, fazendo varredura nas duas tabelas.

Escolhe a menor tabela (Cliente) e coloca na memria.
Em seguida, busca as linhas correspondentes na tabela Ttulo que satisfazem a condio de
igualdade.
Pode-se concluir que o HASH JOIN foi minimizado em funo do filtro da tabela Cliente ter usado o
ndice e, desta maneira, trouxe menos linhas para a construo da tabela HASH.
JOIN usando as tabelas Cliente e Ttulo, igualando as chaves e colocando um filtro na tabela Cliente
em um campo que faz parte da chave primria (PK), de acordo com o comando a seguir:
Primeiramente, devero ser criadas as chaves primarias (PK) e estrangeira (FK) para as duas
tabelas, tambm de acordo com os comandos a seguir:
Figura 5: Resultado do plano de acesso usando as tabelas Cliente e Ttulo, igualando as chaves
e colocando um filtro na tabela Cliente em um campo que faz parte da chave primria (PK).
Fez um NESTED LOOP nas duas tabelas.

Elegeu uma tabela principal (Cliente), buscando os valores selecionados dela, utilizando o ndice da
chave primria "cdigo".
Com base nos valores de igualdade encontrados na tabela principal, fez uma busca nos valores
correspondentes na tabela Ttulo.
Pode-se concluir que o otimizador obedeceu ao ndice da chave primria (PK) para eleger uma
tabela principal, desta forma, tendo um bom desempenho em relao ao uso da memria, pois
trar para a memria somente duas linhas da tabela ttulo.
JOIN usando as tabelas Cliente e Ttulo, igualando as chaves e colocando um filtro na tabela Cliente
em um campo que tem um ndice, de acordo com o comando a seguir:
Figura 6: Resultado do plano de acesso usando as tabelas cliente e titulo igualando as chaves e colocando
um filtro na tabela cliente em um campo que tem um ndice.
Um HASH JOIN nas duas tabelas.

Escolheu a menor tabela (Cliente), filtrando os dados utilizando o ndice criado.
Em seguida, busca as linhas correspondentes na tabela Ttulo que satisfazem a condio de
igualdade.
Pode-se concluir que o otimizador trouxe poucas linhas da tabela Cliente, eleita, e buscou as linhas
correspondentes na tabela Ttulo que satisfizeram a condio de igualdade, obtendo, desta
maneira, um bom desempenho.
Referncias
ORACLE. Database Perfosrmance Tuning Guide, Copyright 2000, 2011, Oracle and/or its affiliates.

2013.

Tuning de Banco de Dados

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Tuning de Banco de Dados

Transféré par

Droits d'auteur :

Formats disponibles

Procedimentos do

A avaliao da infraestrutura de TI, incluindo servidores, redes, desktops etc, so de extrema

Particularmente, para os gerenciadores de banco de dados so necessrios servidores com

A avaliao do desempenho de um Sistema Gerenciador de Banco de Dados (SGBD) no

Manter bem definidos os objetos fsicos

Os SGBD tm como caracterstica a distribuio lgica de seus objetos dentro de tablespaces.

Manter uma boa sintonia

Definir e gerenciar os perfis

Com o uso de ferramentas de monitoramento dos gerenciadores de banco de dados, o

Treinamento e apoio para analistas

O administrador de banco de dados tem a responsabilidade pelo desempenho de todos os

Um dos processos mais importantes definido pelo administrador a poltica de backup e

Processos avaliando as regras de negcio

Processos avaliando o projeto dos dados do banco de dados

Todo projeto de desenvolvimento de um banco de dados comea com a fase de modelagem, e

Processos avaliando o projeto das aplicaes

Processos avaliando as operaes do Sistema Gerenciador

Processos avaliando a memria utilizada pelo SGBD

Processos avaliando as operaes de I/O (input/output) de

Processos avaliando a alocao dos recursos do banco de

Quantidade de informaes fornecidas na clusula Where

Consultas simples envolvendo uma pequena quantidade de

Desempenho dos tipos de operadores de comparao

O desempenho de um comando SQL depende, entre outros fatores, do filtro de pesquisa na

Tipo de operador no filtro Pontuao relativo ao desempenho

Ordem das colunas em uma expresso no filtro de pesquisa

Avaliao de letras maisculas e minsculas

No momento da pesquisa podemos alterar o formato para o padro que precisarmos,

Uso de funes nas pesquisas dos comandos SQL

Ordem dos operadores e operando nos filtros

Operadores AND e OR envolvidos nos comandos SQL

Os operadores AND e OR de um comando SQL obedecem a um critrio na avaliao quando

Agrupamento de colunas iguais no uso do OR em um

Considerando o exemplo a seguir, podemos ver:

Operador de desigualdade NOT

Locks dos gerenciadores de banco de dados

Estrutura do lock no SGBD Oracle

Locks para tratamento de linhas

Locks para tratamento de tabelas

linha desta tabela, somente ir consulta-las.

Row Share (RS)

Os comandos que solicitam este tipo de lock so:

Row Exclusive (RX)

O comando que solicita este tipo de lock :

Share Row Exclusive (SSX)

de dados ou o desenvolvedor do aplicativo deve garantir que os procedimentos de bloqueio devam

Bloqueios do gerenciador de banco de dados Oracle

A seguir faremos uma simulao do mecanismo de trava do Oracle; em seguida, utilizaremos

Passo 2: criar um primeiro usurio para ser utilizado na simulao.

Content on this page requires a newer version of Adobe Flash Player.

Passo 3: criar um segundo usurio para ser utilizado na simulao.

Content on this page requires a newer version of Adobe Flash Player.

Passo 4: dar autorizao para os usurios isi_simulacao_01 e usu_simulacao_02 criar tabelas e

Content on this page requires a newer version of Adobe Flash Player.

Content on this page requires a newer version of Adobe Flash Player.

Content on this page requires a newer version of Adobe Flash Player.

Content on this page requires a newer version of Adobe Flash Player.

Content on this page requires a newer version of Adobe Flash Player.

Content on this page requires a newer version of Adobe Flash Player.

Content on this page requires a newer version of Adobe Flash Player.

Content on this page requires a newer version of Adobe Flash Player.

O objeto causador do lock a tabela CLIENTE.

Content on this page requires a newer version of Adobe Flash Player.

Content on this page requires a newer version of Adobe Flash Player.