SQL Tuning 9i PDF

Oracle9i: Tuning de Aplicaes
Oracle9i: Tuning de Aplicaes Sumrio
1. Seguindo uma Metodologia de Tuning............................................................. 1-1

Objetivos.................................................................................................................................... 1-2 Viso Geral ................................................................................................................................ 1-3 Gerenciando a Performance....................................................................................................... 1-4 Fatores a Serem Gerenciados .................................................................................................... 1-5 Problemas de Performance ........................................................................................................ 1-6 Recursos Crticos....................................................................................................................... 1-7 Demanda Excessiva................................................................................................................... 1-8 Metodologia de Tuning ............................................................................................................. 1-9 Responsabilidades do Tuning.................................................................................................. 1-10 Tuning de Comandos SQL ...................................................................................................... 1-11 Aplicando a Metodologia ........................................................................................................ 1-12
2. Processamento de Comandos SQL ................................................................... 2-1

Objetivos.................................................................................................................................... 2-2 Viso Geral ................................................................................................................................ 2-3 Shared SQL Areas ..................................................................................................................... 2-4 Fases do Processamento de Comandos SQL............................................................................. 2-5 Compartilhando Cursores: Benefcios....................................................................................... 2-7 Compartilhando Cursores: Requisitos ....................................................................................... 2-8 Monitorando Cursores Compartilhados..................................................................................... 2-9 V$LIBRARYCACHE ............................................................................................................. 2-10 V$SQLAREA.......................................................................................................................... 2-11 Monitorando o Uso de Cursores Compartilhados ................................................................... 2-12 Escrevendo SQL para Compartilhar Cursores......................................................................... 2-13
3. EXPLAIN e AUTOTRACE............................................................................... 3-1

Objetivos.................................................................................................................................... 3-2 Criando a Tabela PLAN_TABLE ............................................................................................. 3-3 Comando EXPLAIN PLAN ...................................................................................................... 3-5 Exemplo de EXPLAIN PLAN .................................................................................................. 3-6 Exibindo o Plano de Execuo .................................................................................................. 3-7 Interpretando o Plano de Execuo ........................................................................................... 3-9 AUTOTRACE do SQL*Plus................................................................................................... 3-10 Exemplos de AUTOTRACE do SQL*Plus............................................................................. 3-11 Estatsticas do AUTOTRACE do SQL*Plus........................................................................... 3-12 Exerccios ................................................................................................................................ 3-13
4. SQL Trace e TKPROF....................................................................................... 4-1

Objetivos.................................................................................................................................... 4-2 SQL Trace.................................................................................................................................. 4-3 Utilizando o SQL Trace............................................................................................................. 4-4 Parmetros de Inicializao ....................................................................................................... 4-5 Habilitando o SQL Trace........................................................................................................... 4-6 Encontrando seus Arquivos de Trace ........................................................................................ 4-7 Formatando os Arquivos de Trace............................................................................................. 4-8 Opes do Comando TKPROF ................................................................................................. 4-9 Resultado do Comando TKPROF ........................................................................................... 4-10
Exemplo do Resultado do TKPROF: Sem ndice ................................................................... 4-13 Exemplo do Resultado do TKPROF: ndice nico................................................................. 4-14 Algumas Armadilhas de Interpretao do TKPROF............................................................... 4-15 Exerccios ................................................................................................................................ 4-16
5. Otimizao Baseada em Regra Versus Otimizao Baseada em Custo........ 5-1

Objetivos.................................................................................................................................... 5-2 Viso Geral ................................................................................................................................ 5-3 Funes do Otimizador do Oracle9i .......................................................................................... 5-4 Otimizao Baseada em Regra .................................................................................................. 5-5 Otimizao Baseada em Custo .................................................................................................. 5-6 Escolhendo entre RBO e CBO .................................................................................................. 5-7 Configurando o Modo do Otimizador ....................................................................................... 5-8 Caractersticas do RBO ............................................................................................................. 5-9 Esquema de Ranking do RBO ................................................................................................. 5-10 Exemplo de Otimizao Baseada em Regra............................................................................ 5-11 Influenciando a Otimizao Baseada em Regra ...................................................................... 5-12
6. ndices e Mtodos de Acesso Bsicos ................................................................ 6-1

Objetivos.................................................................................................................................... 6-2 ROWIDs do Oracle9i ................................................................................................................ 6-3 ndices........................................................................................................................................ 6-4 Estrutura de ndice B-Tree ........................................................................................................ 6-5 ndices e Constraints.................................................................................................................. 6-6 Sintaxe do CREATE INDEX .................................................................................................... 6-7 ndices e Foreign Keys .............................................................................................................. 6-8 Mtodos de Acesso Bsicos ...................................................................................................... 6-9
7. Coletando Estatsticas ........................................................................................ 7-1

Objetivos.................................................................................................................................... 7-2 Comando ANALYZE................................................................................................................ 7-3 Estatsticas de Tabela................................................................................................................. 7-5 Estatsticas de ndice ................................................................................................................. 7-7 Estatsticas de Coluna................................................................................................................ 7-9 Estatsticas de Cluster.............................................................................................................. 7-10 Seletividade de Predicados ...................................................................................................... 7-11 Variveis Bind e Seletividade de Predicados .......................................................................... 7-12 Histogramas ............................................................................................................................. 7-13 Exemplo Comparativo de Histogramas ................................................................................... 7-14 Exemplo de Coleta de Estatsticas para Histogramas.............................................................. 7-15 Dicas para Histogramas ........................................................................................................... 7-16 Quando Utilizar Histogramas .................................................................................................. 7-17 Escolhendo um Sample Size.................................................................................................... 7-18 Escolhendo o Nmero de Entradas.......................................................................................... 7-19 Visualizando Estatsticas de Histogramas ............................................................................... 7-20 Exerccios ................................................................................................................................ 7-21
8. Influenciando o Otimizador .............................................................................. 8-1

Objetivos.................................................................................................................................... 8-2 Configurando o Modo de Otimizao ....................................................................................... 8-3
Alguns Parmetros Adicionais do Otimizador .......................................................................... 8-4 Sintaxe de Hints para o Otimizador........................................................................................... 8-5 Regras para Hints....................................................................................................................... 8-6 Recomendaes de Hints........................................................................................................... 8-7 Exemplo de Hints de Otimizao .............................................................................................. 8-8 Categorias de Hints.................................................................................................................... 8-9 Hints de Caminhos de Acesso Bsicos.................................................................................... 8-10 Hints de Caminhos de Acesso Avanados .............................................................................. 8-11 Hints Adicionais ...................................................................................................................... 8-12 Hints e Vises.......................................................................................................................... 8-13 Hints de Processamento de Vises .......................................................................................... 8-15
9. ndices Avanados .............................................................................................. 9-1

Objetivos.................................................................................................................................... 9-2 ndices Bitmap ........................................................................................................................... 9-3 Estrutura de ndices Bitmap ...................................................................................................... 9-4 Criando ndices Bitmap ............................................................................................................. 9-5 Utilizando ndices Bitmap para Consultas ................................................................................ 9-6 Combinando ndices Bitmap ..................................................................................................... 9-7 Quando Utilizar ndices Bitmap ................................................................................................ 9-8 Vantagens de ndices Bitmap .................................................................................................... 9-9 Dicas sobre ndices Bitmap ..................................................................................................... 9-10 ndices e Mtodos de Acesso as Linhas .................................................................................. 9-11 Hints de ndices ....................................................................................................................... 9-12 Exemplo do Hint INDEX_COMBINE.................................................................................... 9-13 Informaes do Dicionrio de Dados ...................................................................................... 9-14
10. Workshops.............................................................................................................. 1
Workshop 1: Uma nica Tabela, Um nico Predicado .............................................................. 2 Workshop 2: Ordenao, Agregao e Operaes de Conjunto .................................................. 7
1. Seguindo uma Metodologia de Tuning
Seguindo uma Metodologia de Tuning
Objetivos
Descrever as causas de problemas de performance. Identificar as principais reas de sistema que voc pode afetar pelo processo de tuning. Descrever a metodologia de tuning. Apresentar as vantagens de seguir a metodologia de tuning em sua ordem correta. Listar os passos de tuning que so de responsabilidade do desenvolvedor da aplicao.
1-2
Viso Geral
Gerenciamento da performance. Problemas de performance. Metodologia de tuning. Tuning de comandos SQL. Metodologia de aplicao.
Qualquer pessoa envolvida em tuning deve seguir uma metodologia de tuning para obter o mximo de performance. Tuning de comandos SQL um passo importante que custa menos quando efetuado no momento correto dentro da metodologia. Em adio a efetuar o tuning no momento correto, voc deve tambm possuir uma boa compreenso dos detalhes envolvidos no gerenciamento da performance e os tipos de problemas de performance que podem aparecer.
1-3
Gerenciando a Performance
Inicie no momento certo. Defina os objetivos. Efetue o tuning e monitore a conformidade. Trabalhe em equipe. Trate excees e modificaes.
O processo de tuning exige vrios passos:
Inicie no Momento Certo

O gerenciamento de performance deve acompanhar a aplicao ou projeto continuamente para ser totalmente efetivo. Voc deve comear a consider-lo no estgio de design.
Defina os Objetivos
Defina seus objetivos de uma forma aceita e acordada com todas as partes interessadas.
Efetue o Tuning e Monitore a Conformidade

Aps voc definir e acordar os objetivos, voc estar pronto para efetuar o tuning e atingir estes objetivos, monitorando seu progresso a medida que efetua o tuning. Voc deve manter registros detalhados sobre o nvel de conformidade conforme a necessidade. Voc deve publicar indicativos de medidas em intervalos regulares, destacando quaisquer divergncias ou tendncias.
Trabalhe em Equipe
Administradores de banco de dados, administradores de sistema e programadores devem trabalhar em equipe como um time, no como adversrios.
Trate Excees e Modificaes

Uma vez que o monitoramento efetivo estiver sendo realizado e suportado no mesmo nvel da aplicao, voc deve reagir prontamente a excees quando estas forem reportadas. Utilize os dados disponveis para traar um curso de ao e ento analise a performance resultante para determinar se sua ao foi bem sucedida. Se mudanas globais no uso de padres ou capacidade de equipamento ocorrerem, ento voc deve considerar a definio de novos objetivos.
1-4
Fatores a Serem Gerenciados

Schema. Design de dados. ndices. Aplicao Comandos SQL. Cdigo procedural. Instncia. Banco de dados. Expectativas do usurio. O gerenciamento de performance pode ser dividido nas quatro reas seguintes. Embora as reas estejam separadas, so tambm independentes e necessitam diferentes qualificaes. O tuning do schema trata da estrutura fsica dos dados. O tuning da aplicao trata das funes de negcio e dos mdulos de programa que implementam as funes. Tuning do cdigo procedural para o tipo de aplicao e tuning dos comandos SQL embutidos tambm esto includos neste estgio. O tuning da instncia trata da instalao do Oracle9i Server e como a memria ser utilizada. O tuning do banco de dados trata do gerenciamento da localizao fsica dos dados no disco.
Schema
Se uma aplicao possuir um design de dados inadequado ou inapropriado, ento efetue o tuning da alocao fsica, provendo ndices ou reescrevendo programas que no superaram o problema.
Comandos SQL
Se uma aplicao foi bem desenhada, ainda assim pode prover uma performance ruim. Uma razo comum para isto so comandos SQL escritos de forma incorreta.
Expectativas do Usurio
Usurios esperam uma performance consistente. Eles podem competir com funes de aplicao lentas se entenderem porque a aplicao est demorando mais que o habitual. A equipe do projeto deve colocar esforos em construir uma expectativa de usurio realista em relao a performance, possivelmente incluindo mensagens de aplicao para advertir operadores que eles esto requisitando operaes que consumidoras de recursos. O melhor momento para fazer isto antes das fases de design e construo, e como parte da fase de transio.
1-5
Problemas de Performance
Recursos consumidos inadequadamente. CPU I/O Memria (pode ser detectado como um problema de I/O) Recursos de comunicao de dados Recursos de design inadequados. Bloqueio (locking). Problemas de performance ocorrem quando uma funo consome muito mais tempo para executar que o tempo permitido. Isto devido a um recurso de um tipo particular ser insuficiente ou inadequado. O recurso pode ser um recurso fsico, como buffers de memria disponveis para armazenar blocos de dados, ou um recurso artificial, como um lock.
Recursos Consumidos Inadequadamente

Um recurso pode simplesmente ser inadequado para satisfazer a necessidade sob quaisquer circunstncias. Por exemplo, se voc deseja que uma funo seja completada em at um segundo, uma rede com um tempo de resposta de dois segundos nunca ir atingir o objetivo. Se o fator limitante um recurso consumvel, como poder de CPU, todos os usurios deste recurso so afetados.
Recursos de Design Inadequados

Se o fator limitante for a conteno de processos para um recurso de design, como um lock, ento somente os usurios destes processos especficos sero provavelmente afetados.
Bloqueio (locking)
Conteno devido a lock por outras transaes ou aplicaes pode ser um problema.
1-6
Recursos Crticos
A performance depende: Quantos clientes necessitam do recurso. Quanto tempo tero de esperar por ele. Quanto tempo iro segur-lo. Considere a limitao da demanda para manter tempos de resposta aceitveis.
O tempo de resposta definido como o tempo de servio mais o tempo de espera para completar uma determinada tarefa.
1-7
Demanda Excessiva
Grandes aumentos no tempo de resposta. Reduz o troughput. Deve ser evitada sempre que possvel limitando a demanda a um nvel que mantenha sempre um troughput razovel.
O troughput definido como a quantidade total de trabalho realizado pelo sistema em uma determinada quantidade de tempo. Muitos processos utilizando um sistema simultaneamente podem resultar nos seguintes sintomas:
Tempo de Resposta Maior

A maioria dos usurios conhece e compreende os efeitos de filas no aumento do tempo de resposta. Eles podem ser preparados para aceitar repostas lentas em momentos de alta utilizao do sistema se o efeito for linear. Entretanto, tanto teorias estatsticas quanto experincias mostram que uma vez que o tempo de resposta comea a deteriorar, pequenos aumentos na carga podem causar um efeito grava, o qual completamente inaceitvel para os usurios.
Throughput Reduzido
Qualquer degradao notvel no tempo de resposta como romper a taxa de trabalho dos usurios afetados. Muitas pessoas no entendem que adicionando mais usurios ao sistema significativamente diminui o throughput geral do sistema. Se o throughput do sistema for importante, voc deve garantir que o nmero de usurios no exceda o limite no qual o throughput comea a diminuir. melhor limitar o nmero de usurios mecanicamente. Isto pode forar uma mudana nos padres de trabalho para enfrentar a restrio, mas dividindo os perodos de pico atravs do dia de trabalho pode melhorar em muito a forma como o sistema utilizado.
1-8
Metodologia de Tuning
1. 2. 3. 4. 5. 6. 7. 8. 9. Tuning das funes de negcio. Tuning do design de dados. Tuning do design de processos. Tuning de comandos SQL. Tuning de estruturas fsicas. Tuning da alocao de memria. Tuning de I/O. Tuning da conteno de memria. Tuning do sistema operacional.
A lista acima apresenta as vrias fases do ciclo de desenvolvimento nas quais o tuning pode ser aplicado. Seguir os passos nesta ordem altamente recomendado pelas seguintes razes: Quanto mais anterior a etapa em que o tuning for iniciado, maior o potencial para melhoria na performance. Quanto mais posterior a etapa em que o tuning for iniciado, maior ser custo para efetuar ou refazer isto depois. Por exemplo, modificaes para as estruturas de dados e cdigo de aplicao aps o design inicial tendem a ser caras e necessitarem de gastos adicionais para retestar os componentes afetados. Decises feitas em um passo podem influenciar os passos subseqentes. Por exemplo, o comando SQL que voc escreveu no passo 4 pode ter significante influncia nos detalhes de parse e cache que so tratados no passo 6. Quanto mais extensivamente voc utilizar as tcnicas de design orientado a objeto e a arquitetura multi-tier, maior sero as chances de voc seguramente conseguir efetuar quaisquer mudanas na aplicao a um custo razovel.
1-9
Responsabilidades do Tuning
Analista de Negcios Designer Desenvolvedor da Aplicao Administrador do Banco de Dados Administrador do Sistema Operacional 1. Tuning das funes de negcio 2. Tuning do design de dados 3. Tuning do design de processos 4. Tuning de comandos SQL 5. Tuning de estruturas fsicas 6. Tuning da alocao de memria 7. Tuning de I/O 8. Tuning de conteno de memria 9. Tuning do sistema operacional
O analista de negcios, designer, desenvolvedor da aplicao, administrador do banco de dados e administrador do sistema operacional so responsveis por diferentes passos no processo de tuning. Em alguns casos, uma pessoa pode preencher vrios destes papis. Os passos efetuados pelo administrador do banco de dados e administrador do sistema operacional possuem menos efeito na performance do que os passos anteriores, mas eles podem ser efetuados a um custo relativamente baixo com resultados imediatamente disponveis e observveis. O quarto passo da metodologia principalmente responsabilidade do desenvolvedor da aplicao. Entretanto, o entendimento de como o tuning de SQL efetuado pode permitir aos designers projetar schemas que sero mais facilmente otimizados. Administrador de banco de dados com esta compreenso sero capazes de ajudar a definir as necessidades e soluo do tuning de SQL, desta forma aliviando o fardo de seus bancos de dados. Isto especialmente til se a aplicao j estiver em produo e os desenvolvedores no estiverem mais disponveis.
1-10
Tuning de Comandos SQL

Utilize ferramentas de anlise de performance para verificar o resultado dos seguintes passos: 1. Tuning de schema. Adicione ndices. Crie tabelas do tipo index organized. Crie clusters. 2. Escolha a linguagem: SQL ou PL/SQL. 3. Projete a reutilizao da otimizao de SQL. 4. Projete e otimize comandos SQL. 5. Maximize a performance com o otimizador. Durante os passos dentro do tuning de comandos SQL, tcnicas de anlise devem ser freqentemente utilizadas para determinar metas e progresso. 1. Tuning de schema. O designer responsvel por determinar quais tabelas devem ser utilizadas, seus contedos e detalhes similares. O desenvolvedor da aplicao pode ento necessitar decidir quando utilizar indexao, quando utilizar tabelas index organized e quando utilizar clusterizao. Desnormalizao pode ser necessria para se obter uma boa performance, especialmente em ambientes de data warehouse. As decises destes passos podem ter grande efeito na performance de quaisquer comandos SQL que venham a utilizar estas estruturas. 2. Escolhendo a linguagem: SQL ou PL/SQL. Em alguns casos, voc pode obter melhor performance utilizando a linguagem PL/SQL para executar um tarefa. 3. Projetando a reutilizao do parse de SQL, otimizao e esforos de tuning. O Oracle pode freqentemente reutilizar alguns de seus esforos ao efetuar o parse e a otimizao quando identificar comandos idnticos repetidos. Portanto, criando comandos SQL que sejam idnticos pode melhorar a performance. Ele tambm permite ao desenvolvedor da aplicao focar o tuning de comandos SQL individuais que so repetidamente utilizados. 4. Projetando e otimizando comandos SQL. Existe uma grande variedade de mtodos para projetar comandos SQL de alta performance. O conhecimento das funes globais do otimizador ajuda a visualizar onde os esforos de tuning podem ser efetivos.Considere reescrever comandos SQL em comandos semanticamente equivalentes. Alm disso, utilize a linguagem correta (SQL ou PL/SQL) em cada situao. 5. Obtendo o mximo de performance com o otimizador. Para fazer o melhor uso do otimizador baseado em custo do Oracle, voc deve entender como ele escolhe os mtodos de acesso aos dados. Voc deve auxiliar o otimizador baseado em custo utilizando o comando ANALYZE, e algumas vezes fornecendo hints sobre o melhor caminho de acesso. O otimizador baseado em regra tambm est disponvel. Ambos os otimizadores sero discutidos no captulo 6.
1-11
Aplicando a Metodologia
Seja pr-ativo comece no topo da metodologia e siga os passos. Se voc tiver que ser reativo, siga os passos de baixo para cima, utilizando as seguintes dicas: Estabelea objetivos quantificveis. Trabalhe a um mnimo de testes repetitivos. Faa perguntas aos usurios afetados e evite preconcepes. Teste hipteses e mantenha anotaes. Pare quando voc alcanar o objetivo. Freqentemente, especialistas em performance so chamados muito tarde no ciclo de vida de um projeto, quando os sistemas esto em produo e a performance ficou inaceitvel. Nesta situao, inicie pelo final da lista de mtodos de tuning e siga para os passos anteriores. Os itens do final so mais baratos e rpidos para se obter resultados. Se eles no resolverem o problema, voc ter que trabalhar os itens mais acima da lista, e isto ir aumentar os custos e os tempos para execuo.
1-12
2. Processamento de Comandos SQL
Processamento de Comandos SQL
Objetivos
Descrever os passos bsicos envolvidos no processamento de um comando SQL. Monitorar o uso de shared SQL areas. Escrever comandos SQL para obter vantagens das shared SQL areas.
2-2
Viso Geral
Shared SQL areas. Fases do processamento de SQL. Shared cursors. Padres de codificao SQL.
Conhecendo como funcionam reas de SQL compartilhadas, as fases de processamento SQL e cursores compartilhados, voc pode entender como padres de codificao permitem a voc minimizar a freqncia com que comandos necessitam ser compilados e otimizados. Adicionalmente, a medida que comandos que voc escreveu tornem-se mais e mais padronizados, voc ser capaz de identificar que ocorrem freqentemente e dedicar tuning adicional a eles.
2-3
Shared SQL Areas
A shared pool parte da System Global Area (SGA), que contm o cache do dicionrio e a shared SQL area. A shared SQL area tambm conhecida como library cache, embora no seja exatamente o mesmo; a shared SQL area parte da library cache. A shared pool automaticamente mantida por um mecanismo de envelhecimento. Este mecanismo utiliza o algortmo least recently used (LRU) para determinar o que est mais tempo sem utilizao removendo-o quando espao for requisitado. O administrador do banco de dados (DBA) pode modificar o espao disponvel para o dicionrio e shared SQL areas alterando o parmetro de inicializao SHARED_POOL_SIZE. O DBA pode efetuar isto como parte de um esforo global de tuning do banco de dados.
Cursores
Dentro da shared SQL area, cada comando SQL compilado (parsed) em sua prpria rea, conhecida como context area ou cursor. Cada cursor armazena as seguintes informaes: O comando compilado (SQL esttico, dinmico e recursivo, mais unidades de programas como procedures e triggers de banco de dados). O plano de execuo. Uma lista de objetos referenciados. Se dois usurios enviarem o mesmo comando SQL, ento podem utilizar o mesmo cursor. O comando recompilado se a representao na shared pool estiver invlida. Isto acontece, por exemplo, se comando da linguagem de definio de dados (DDL) como um ALTER TABLE foi utilizado em um dos objetos que esto referenciados no comando, ou se uma tabela dependente foi analisada.
2-4
Fases do Processamento de Comandos SQL
As quatro fases mais importantes no processamento de um comando SQL so parse, bind, execute e fetch. As setas indicam os cenrios do processamento, por exemplo: FETCH (RE)BIND EXECUTE FETCH A fase FETCH aplica-se somente a consultas.
Parse
O servidor Oracle9i: Procura pelo comando na shared pool. Verifica a sintaxe do comando, determinando a gramtica e especificaes da linguagem SQL. Verifica a semntica, garantindo que os objetos referenciados no comando SQL so vlidos e satisfazem as regras de segurana. Transforma um consulta sobre uma viso em uma consulta sobre sua definio, e tenta simplificar um comando com uma subconsulta reescrevendo-o em um join. Determina e armazena o plano de execuo.
Bind
O servidor Oracle9i verifica o comando por referncias de variveis bind. O servidor Oracle9i atribui ou reatribui um valor para cada varivel. Nota: esta ordem das fases implica que o servidor Oracle9i no conhece os valores das variveis bind no momento da otimizao de um comando. Isto permite uma rpida operao de rebind-execute sem a necessidade de recompilao, desta forma economizando tempo e memria, sendo que a desvantagem a impossibilidade de o otimizador estimar a seletividade.
Execute
O servidor Oracle9i aplica a parse tree aos buffers de dados. Mltiplos usurios podem compartilhar a mesma parse tree. O servidor Oracle9i efetua leituras fsicas ou leituras/escritas lgicas para comandos DML, e tambm ordena os dados quando necessrio.
2-5
Fetch
O servidor Oracle9i recupera as linhas para um comando SELECT durante a fase de fetch. Cada fetch normalmente recupera mltiplas linhas, utilizando um array fetch. Cada ferramenta Oracle oferece suas prprias formas de influenciar o tamanho do array. No SQL*Plus voc efetuar isto utilizando o parmetro ARRAYSIZE: SQL> show arraysize SQL> set arraysize 1 Com esta configurao o SQL*Plus ir processar uma linha de cada vez. O valor default 20.
2-6
Compartilhando Cursores: Benefcios

Quando um comando SQL encontrado na shared SQL area, ento a fase de parse reduzida e o cursor existente utilizado. O compartilhamento de cursores reduz a atividade de parse e economiza tempo de processamento. A memria ajusta-se dinamicamente ao SQL executado. A utilizao de memria pode melhorar dramaticamente, mesmo para ferramentas que armazenam SQL dentro da aplicao.
2-7
Compartilhando Cursores: Requisitos

Cursores podem ser compartilhados somente por comandos SQL idnticos: O texto dos comandos SQL deve ser exatamente o mesmo, incluindo distino entre maisculas e minsculas, espaos em branco e comentrios. Os objetos referenciados nos comandos SQL devem apontar para os mesmos objetos no banco de dados. Os tipos das variveis bind utilizadas nos comandos SQL deve ser o mesmo. Nota: antes de enviar comandos SQL para o servidor Oracle9i, a maioria dos utilitrios (como PL/SQL, pr-compiladores e o Oracle Developer) pr-processam os comandos SQL para torn-los o mais idnticos possveis removendo comentrios, comprimindo espaos em branco e convertendo para maisculas ou minsculas. O SQL*Plus entretanto, envia comandos SQL para o servidor Oracle9i no mesmo formato que eles foram inseridos.
2-8
Monitorando Cursores Compartilhados

V$LIBRARYCACHE fornece informaes gerais. V$SQLAREA verifica comandos individuais. Quando no existe espao para compilar um comando na shared SQL area, o cursor mais antigo e seu espao reutilizado. Se o comando original for necessrio novamente, o servidor ter que recompil-lo novamente. A shared pool deve ser grande o suficiente para manter o nmero de comandos que so compilados pelo menos mais de uma vez. Voc pode monitorar seus sistema para visualizar com que freqncia o servidor no encontra um comando em memria. Voc pode utilizar o Oracle Enterprise Manger, ou o Oracle Server Manager ou consultar as vises apropriadas do dicionrio de dados, V$LIBRARYCACHE e V$SQLAREA.
2-9
V$LIBRARYCACHE
NAMESPACE GETS GETHITS GETHITRATIO PINS PINHITS PINHITRATIO O nome da rea da library cache O nmero de vezes que um lock foi requisitado O nmero de vezes que um handle de um objeto foi encontrado em memria A proporo de GETHITS em relao aos GETS O nmero de vezes que um PIN foi requisitado O nmero de vezes que todos os pedaos do objeto foram encontrados em memria A proporo de PINHITS em relao aos PINS
Esta viso armazena informaes sobre o gerenciamento da library cache. Os valores para PINHITRATIO e GETHITRATIO prximos de 1 indicam uma boa performance da library cache. A viso V$LIBRARYCACHE utilizada na consulta abaixo para verificar a quantidade de cache. SQL> select gethitratio, pinhitratio 2 from v$librarycache 3 where namespace = 'SQL AREA'; Get Hit Ratio ------------0.94 Pin Hit Ratio ------------0.95
2-10
V$SQLAREA
SQL_TEXT VERSION_COUNT LOADS INVALIDATIONS PARSE_CALLS SORTS COMMAND_TYPE PARSING_USER_ID Texto do comando SQL Nmero de verses deste cursor Nmero de vezes que o cursor foi carregado Nmero de vezes que o contedo foi invalidado Nmero de vezes que um usurio solicitou o cursor Nmero de sorts efetuados pelo comando Tipo do comando ID do usurio que efetuou o parse (SYS = 0)
A viso V$SQLAREA armazena informaes sobre todos os cursores compartilhados no cache. VERSIONT_COUNT > 1 LOADS > 1 COMMAND_TYPE Indica que o mesmo texto utilizado por diferentes usurios, em sua prpria verso de uma tabela. Indica recargas do cursor aps o envelhecimento ou invalidao. 2: INSERT 3: SELECT 6: UPDATE 7: DELETE
Nota: somente as colunas mais importantes da viso V$SQLAREA esto listadas acima.
2-11
Monitorando o Uso de Cursores Compartilhados

Um LOAD por comando o ideal. Um LOAD por verso/invalidao aceitvel. Mais de um LOAD por verso indica um benefcio potencial a partir do aumento do tamanho da shared pool. No melhor cenrio, deveria haver uma verso de cada comando que nunca invalidada ou envelhecida. Se o nmero de loads significativamente maior que a soma de verses e invalidaes, especialmente se o nmero de loads similar ao nmero de chamadas (calls), ento os cursores provavelmente esto sendo recarregados devido ao envelhecimento e o sistema pode beneficiar-se do aumento do tamanho da shared pool. SQL> 2 3 4 5 6 select sql_text, version_count, loads, invalidations, parse_calls, sorts from v$sqlarea where parsing_user_id > 0 and command_type = 3 order by sql_text;
version invali parse sql_text count loads dations calls sorts -------------------- ------- ----- ------- ----- ----select * 2 2 0 3 0 from employees where EMP_ID = 70727 select * from employees where emp_id = 70727 1 2 1 4 0
O comando acima exclui informaes sobre SQL recursivo (parsing user SYS) e exibe somente comandos SELECT (command type 3). Existe duas verses do primeiro comando, provavelmente porque eles referenciam dois objetos EMPLOYEES diferentes. Entretanto, cada verso foi carregada somente uma vez. O comando foi enviado trs vezes (PARSE_CALLS). Existe somente uma verso do segundo comando, mas este foi carregado duas vezes, sendo invalidado uma vez (provavelmente por algum DDL na tabela ou ndice relacionado). Nota: o Oracle SQL Analyze, um componente do Oracle Enterprise Manager Tuning Pack, oferece uma excelente interface grfica sobre a V$SQLAREA.
2-12
Escrevendo SQL para Compartilhar Cursores

Se houver diferena entre maisculas e minsculas ou a quantidade de espao em branco for diferente, ento os comandos no so idnticos. SQL> select * from employees where emp_id = 70727; SQL> select * from EMPLOYEES where EMP_ID = 70727; Se os objetos pertencerem a usurios diferentes, ento os comandos no so idnticos. SQL> select * from employees where EMP_ID = 70727; SQL> select * from employees where EMP_ID = 70727; Comandos SQL devem ser idnticos para poderem compartilhar os cursores. Observe que o compartilhamento de comandos no importante em um ambiente DSS, porque a maioria dos comandos ser diferente de qualquer maneira. Distino de Maisculas/Minsculas Os primeiros dois exemplos acima no so idnticos. Observe a diferena de maisculas e minsculas nos nomes da tabela e coluna. Devido a esta diferena, os comandos no so idnticos e portanto no compartilham uma nica SQL area. Objetos Idnticos Mesmo quando dois comandos parecem idnticos, se os objetos na verdade referirem-se a objetos diferentes do banco de dados, ento os dois comandos no so idnticos. Nos dois ltimos exemplos, os comandos so enviados por dois diferentes usurios e cada um possui sua prpria tabela EMPLOYEES. Desta forma os comandos no so idnticos e no compartilham uma nica SQL area.
Variveis Bind e Cursores Compartilhados

SQL> select * from employees where emp_id = :c; SQL> select * from employees where emp_id = :d; Ambos os comandos so traduzidos para: SQL> select * from employees where emp_id = :b1; Se duas variveis bind possuem diferentes tipos de dados, ento os comandos no so idnticos. Se os tipos de dados da varivel bind correspondem mas seus nomes no so idnticos, como no exemplo acima, no h problema, porque variveis bind so internamente renomeadas. A primeira varivel sempre chamada :b1, a segunda :b2 e assim por diante.
Escrevendo SQL para Compartilhar Cursores

Desenvolva convenes de codificao para comandos SQL em consultas, scripts SQL e chamadas OCI.
2-13
Utilizando Cdigo Compartilhado Genrico Escreva e armazene procedures que possam ser compartilhadas pelas aplicaes. Utilize triggers de banco de dados. Escreva triggers e procedures referenciadas quando utilizar o Oracle Developer. Escreva bibliotecas de rotinas e procedures em outros ambientes.
Escrevendo Padres de Formatao

Desenvolva padres de formatao para todos os comandos, incluindo aqueles em cdigo PL/SQL. Desenvolva regras para a utilizao de maisculas e minsculas. Desenvolva regras para a utilizao de espaos em branco. Desenvolva regras para a utilizao de comentrios, preferencialmente mantedo-os fora dos comandos SQL. Utilize os mesmos nomes para referenciar objetos idnticos do banco de dados. Utilize variveis bind.
2-14
3. EXPLAIN e AUTOTRACE
EXPLAIN e AUTOTRACE
Objetivos
Criar a tabela PLAN_TABLE utilizando o script utlxplan.sql. Utilizar o comando EXPLAIN PLAN para visualizar como um comando SQL ser processado. Utilizar o AUTOTRACE do SQL*Plus para visualizar planos de execuo de comandos SQL e estatsticas.
3-2
EXPLAIN e AUTOTRACE
Criando a Tabela PLAN_TABLE

Execute o script padro para criar a tabela PLAN_TABLE: SQL> START utlxplan.sql Crie a tabela PLAN_TABLE manualmente, com um nome diferente: SQL> 2 3 4 5 create table my_plan_table (statement_id varchar2(30) ,timestamp date ,remarks varchar2(80) ,operation varchar2(30) ... )
O comando EXPLAIN PLAN utiliza uma tabela para armazenar informaes sobre o plano de execuo escolhido pelo otimizador. Se voc examinar o plano, voc pode visualizar como o servidor ir executar o comando. Voc deve executar trs passos para utilizar o EXPLAIN PLAN: 1. Criar a tabela de sada do plano. 2. Utilizar o comando EXPLAIN PLAN. 3. Recuperar o passos do plano utilizando comandos SQL.
PLAN_TABLE
Voc possui vrias opes na criao de uma tabela para os planos: A tabela de sada default chama-se PLAN_TABLE. Voc pode utilizar o script PLAN_TABLE para criar uma PLAN_TABLE. No ambiente Windows, este script pode ser encontrado em %ORACLE_HOME%\rdbms80\admin; no UNIX em $ORACLE_HOME/rdbms/admin. Em um ambiente cliente-server, garanta que voc esteja utilizando a verso correta (server) deste script. Voc pode criar uma tabela similar com qualquer nome que voc desejar, copiando e editando o script utlxplan.sql. A estrutura da tabela deve ser a mesma.
3-3
EXPLAIN e AUTOTRACE
A sintaxe completa para a PLAN_TABLE apresentada abaixo: create table PLAN_TABLE (statement_id varchar2(30) ,timestamp date ,remarks varchar2(80) ,operation varchar2(30) ,options varchar2(30) ,object_node varchar2(128) ,object_owner varchar2(30) ,object_name varchar2(30) ,object_instance numeric ,object_type varchar2(30) ,optimizer varchar2(255) ,search_columns number ,id numeric ,parent_id numeric ,position numeric ,cost numeric ,cardinality numeric ,bytes numeric ,other_tag varchar2(255) ,partition_start varchar2(255) ,partition_stop varchar2(255) ,partition_id numeric ,other long);
3-4
EXPLAIN e AUTOTRACE
Comando EXPLAIN PLAN
Este comando insere um linha na tabela PLAN_TABLE para cada passo do plano de execuo. No diagrama de sintaxe apresentado acima, os campos em itlico possuem o seguinte significado: text identificador opcional para o comando. Voc deve entrar um valor para identificar cada comando, de forma que voc possa depois especificar o comando que voc deseja visualizar. Isto especialmente importante quando voc compartilhar a tabela PLAN_TABLE com outros usurios. nome opcional da tabela de sada. O default PLAN_TABLE. texto do comando SQL.
schema.table statement
3-5
EXPLAIN e AUTOTRACE
Exemplo de EXPLAIN PLAN

SQL> 2 3 4 5 6 EXPLAIN PLAN set statement_id = 'demo_01' for select * from classes where status = 'CONF' and loc_id = 22;
Explained. Este comando insere o plano de execuo do comando SQL na tabela PLAN_TABLE, e adiciona a tag demo_01 para futura referncia. Nota: o comando EXPLAIN PLAN no executa a consulta.
3-6
EXPLAIN e AUTOTRACE
Exibindo o Plano de Execuo

column "Query Plan" format a60 select id, lpad(' ', 2*level)||operation ||decode(id, 0,' Cost = '||position) ||' '||options ||' '||object_name as "Query Plan" from plan_table where statement_id = 'demo_01' connect by prior id = parent_id start with id = 0 / O comando select acima designado para exibir os passsos que seriam efetuados se o comando SQL fosse executado. As seguintes colunas da tabela PLAN_TABLE so utilizadas: STATEMENT_ID valor do parmetro opcional STATEMENT_ID especificado no comando EXPLAIN PLAN. OPERATION OPTIONS OBJECT_NAME ID PARENT_ID POSITION nome da operao efetuada neste passo; contm um valor na primeira linha gerada para cada comando. as opes para a operao (por exemplo, isto pode exibir remote se uma tabela remota for referenciada no comando SQL). o nome do objeto. nmero deste passo no plano de execuo. ID do passo que opera nos resultados deste passo. ordem na qual os passos com o mesmo PARENT_ID so processados.
Nota: normalmente, voc coloca este comando em um script SQL com uma varivel para o valor de STATEMENT_ID. Alternativamente, utilize o AUTOTRACE do SQL*Plus para eliminar a necessidade de executar consultas sobre a PLAN_TABLE.
ID Query Plan ----- --------------------------------------------0 SELECT STATEMENT Cost = 1 TABLE ACCESS BY INDEX ROWID CLASSES 2 AND-EQUAL 3 INDEX RANGE SCAN STAT_INDEX 4 INDEX RANGE SCAN LOC_INDEX
As colunas mais teis da tabela PLAN_TABLE so: TIMESTAMP COST data e hora de quando o comando EXPLAIN PLAN foi executado. o otimizador baseado em custo estima o custo para efetuar a operao, incluindo o custo de quaisquer operaes que so necessrias para completar esta operao (o valor desta coluna
3-7
EXPLAIN e AUTOTRACE
no possui uma unidade de medida especfica; meramente um peso utilizado para comparar custos de planos de execuo). CARDINALITY BYTES OTHER OTHER_TAG OPTIMIZER OBJECT_TYPE o otimizador baseado em custo estima o nmero de linhas. o otimizador baseado em custo estima o nmero de bytes. o texto SQL para cursores remotos e parallel query slaves, bem como informaes de parallel query dataflow-operation. descries de funo do texto SQL da coluna OTHER. modo atual do otimizador. um modificador que descreve o objeto; por exemplo, NONUNIQUE para um ndice.
OBJECT_OWNER nome do schema que contm a tabela ou ndice.
3-8
EXPLAIN e AUTOTRACE
Interpretando o Plano de Execuo
Cada passo do plano de execuo ou recupera linhas do banco de dados ou aceita linhas como entrada a partir de um ou mais outros passos, tambm conhecidos como row sources. No diagrama, os nmero correspondem aos valores de ID na tabela PLAN_TABLE. A operao AND_EQUAL (2) recebe os ROWIDs obtidos pelos scans de STAT_INDEX (3) e LOC_INDEX (4), e retorna os ROWIDs que so obtidos de ambas as origens. Isto resulta em um conjunto de ROWIDs que permite que o TABLE_ACCESS (1) da tabela CLASSES retorne as linhas que satisfazem a consulta. O custo de um plano de execuo um valor proporcional ao tempo estimado necessrio para executar o comando, utilizando o plano de execuo. Se o otimizador baseado em regra for utilizado, ento o custo no estar disponvel e apresentar o valor NULL.
Comparando Planos de Execuo

Voc pode encontrar o plano de execuo utilizado pelo otimizador com o comando EXPLAIN PLAN. Se um comando SQL no executar satisfatoriamente, voc pode decidir introduzir um ndice. Voc deve verificar o plano de execuo novamente para garantir que o ndice seja utilizado. Voc pode tambm verificar o efeito da utilizao de diversos hints de otimizao, os quais sero discutidos posteriormente.
3-9
EXPLAIN e AUTOTRACE
AUTOTRACE do SQL*Plus
No SQL*Plus, voc pode obter o plano de execuo e algumas estatsticas adicionais sobre a execuo de um comando SQL automaticamente, utilizando a configurao de AUTOTRACE. Diferente do comando EXPLAIN PLAN, os comandos agora so executados, mesmo se voc escolher suprimir a sada do comando. Desta forma voc pode exibir estatsticas reais. AUTOTRACE, uma nova caracterstica do Oracle Server Release 7.3, uma excelente ferramenta de diagnstico para tuning de comandos SQL. Uma vez que ela puramente declarativa, mais fcil de ser utilizada do que o EXPLAIN PLAN.
Opes do Comando
OFF ON TRACEONLY EXPLAIN STATISTICS desabilita o autotrace de comandos SQL. habilita o autotrace de comandos SQL. habilita o autotrace de comandos SQL, e suprime a sada do comando. exibe os planos de execuo, mas no exibe as estatsticas. exibe as estatsticas, mas no exibe os planos de execuo.
3-10
EXPLAIN e AUTOTRACE
Exemplos de AUTOTRACE do SQL*Plus

SQL> SET AUTOTRACE ON SQL> SET AUTOTRACE TRACEONLY SQL> SET AUTOTRACE TRACEONLY EXPLAIN Para utilizar a opo EXPLAIN do AUTOTRACE, voc deve primeiro criar a tabela PLAN_TABLE no seu schema, da mesma maneira que voc necessita fazer antes de utilizar o comando EXPLAIN PLAN. Normalmente esta tabela criada executando-se o script utlxplan.sql. Para utilizar STATISTICS, voc deve possuir acesso a vrias tabelas de performance dinmica. O DBA pode conceder acesso utilizando a role plustrace criada no script plustrce.sql (o nome deste script pode variar conforme o sistema operacional). O DBA deve executar este script com o usurio SYS e conceder a role para os usurios que querem utilizar a opo STATISTICS do SET AUTOTRACE.
Controlando o Layout do Plano de Execuo do AUTOTRACE

O plano de execuo consiste de quatro colunas exibidas na seguinte ordem: ID_PLUS_EXP PARENT_ID_PLUS_EXP PLAN_PLUS_EXP nmero da linha de cada passo. nmero da linha do passo de nvel superior. relatrio do passo.
OBJECT_NODE_PLUS_EXP database links ou servidores parallel query utilizados. Voc pode modificar o formato destas colunas, ou suprimi-las, utilizando o comando COLUMN do SQL*Plus.
3-11
EXPLAIN e AUTOTRACE
Estatsticas do AUTOTRACE do SQL*Plus

SQL> set autotrace traceonly statistics SQL> select * from dual; Statistics --------------------------------------------------0 recursive calls 3 db block gets 1 consistent gets 0 physical reads 0 redo size 565 bytes sent via SQL*Net to client 646 bytes received via SQL*Net from client 4 SQL*Net roundtrips to/from client 1 sorts (memory) 0 sorts (disk) 1 rows processed O AUTOTRACE exibe diversas estatsticas, mas nem todas relevantes a discusso neste estgio. No prximo captulo, quando for visto o SQL Trace e TKPROF, sero tratados mais detalhes sobre estatsticas de execuo de comandos SQL. As mais importantes so: db block gets consistent gets physical reads redo size sorts (disk) nmero de I/Os lgicos para gets correntes. nmero de I/Os lgicos para gets de leitura consistente. nmero de blocos lidos a partir do disco. quantidade de redo gerado (para comandos DML). nmero de sorts efetuados utilizando armazenamento temporrio em disco.
sorts (memory) nmero de sorts efetuados em memria.
3-12
EXPLAIN e AUTOTRACE
Exerccios
1. Verifique a existncia de uma tabela PLAN_TABLE no seu schema. Crie a tabela se necessrio utilizando o script utlxplan.sql. 2. Verifique o plano de execuo do seguinte comando SQL. SQL> select first_name, last_name 2 from employees 3 where emp_id = 6191; 3. Consulte a tabela PLAN_TABLE: SQL> select * from plan_table; Utilize o script rp.sql para consultar a tabela PLAN_TABLE de uma maneira mais sofisticada. SQL> @rp 4. Habilite o AUTOTRACE do SQL*Plus para exibir os planos de execuo e execute o comando do exerccio 2 novamente. 5. Configure o AUTOTRACE para suprimir a sada do comando e exibir o plano de execuo e estatsticas, e execute o exerccio 2 novamente. 6. Se voc tiver algum tempo restando, execute seus prprios comandos SQL e verifique-os com EXPLAIN PLAIN e AUTOTRACE.
3-13
4. SQL Trace e TKPROF
SQL Trace e TKPROF
Objetivos
Invocar o SQL Trace para coletar estatsticas. Configurar parmetros de inicializao apropriados. Habilitar o SQL Trace Verificar como encontrar seus arquivos de trace. Formatar estatsticas de trace com TKPROF. Interpretar a sada do comando TKPROF.
4-2
SQL Trace e TKPROF
SQL Trace
Configurado a nvel de instncia ou sesso. Coleta estatsticas para comandos SQL. Produz um relatrio que pode ser formatado pelo TKPROF.
Uma boa maneira para comparar dois planos de execuo execut-los e comparar as estatsticas para visualizar qual deles possui melhor performance. Voc pode utilizar o SQL Trace para obter informaes sobre performance. O SQL Trace escreve seus resultados para um arquivo e voc utiliza o TKPROF para format-lo. O SQL Trace: Pode ser habilitado para uma instncia ou uma sesso. Fornece estatsticas de volume e tempo para as fases de parse, execute e fetch. Produz resultados que podem ser formatados com a ferramenta TKPROF. Quando o SQL Trace for habilitado para uma sesso, o Oracle ir gerar um arquivo de trace contendo estatsticas para os comandos SQL desta sesso. Quando o SQL Trace for habilitado para uma instncia, o Oracle ir criar um arquivo de trace separado para cada processo.
4-3
SQL Trace e TKPROF
Utilizando o SQL Trace

1. 2. 3. 4. 5. Configure os parmetros de inicializao apropriados. Habilite o SQL Trace. Execute a aplicao (desabilitando o SQL Trace no final). Formate o arquivo de trace gerado com o TKPROF. Interprete o resultado e efetue o tuning dos comandos SQL quando necessrio.
A execuo com SQL Trace habilitado aumenta o overhead do sistema. Utilize SQL Tracce somente quando necessrio, e utilize-o a nvel de sesso ao invs de utiliz-lo a nvel de instncia.
4-4
SQL Trace e TKPROF
Parmetros de Inicializao
TIMED_STATISTICS = {FALSE | TRUE} MAX_DUMP_FILE_SIZE = n USER_DUMP_DEST = directory_path Vrios parmetros de inicializao esto relacionados com SQL Trace.
TIMED_STATISTICS
O SQL Trace fornece uma variedade de informaes sobre processos, opcionalmente incluindo informaes de tempo. Se voc desejar obter tais informaes, voc deve habilitar este parmetro. Voc pode efetuar isto para o banco de dados inteiro configurando o seguinte parmetro de inicializao no arquivo de parmetro antes de efetuar o startup e abrir o banco de dados: TIMED_STATISTICS = TRUE O parmetro tambm pode ser configurado dinamicamente para uma sesso especfica com o seguinte comando: SQL> ALTER SESSION SET TIMED_STATISTICS = TRUE; As estatsticas de tempo possuem uma preciso de 1 centsimo de segundo. Isto significa que qualquer operao que encerrar muito rpido pode no ter o seu tempo calculado precisamente; por exemplo, consultas simples que executam muito rapidamente. Estando TIMED_STATISTICS habilitado a performance ser ligeiramente afetada porque o servidor Oracle dever efetuar trabalho adicional. Portanto, este parmetro normalmente fica desabilitado at ser especificamente habilitado para propsitos de tuning.
MAX_DUMP_FILE_SIZE e USER_DUMP_DEST
Estes dois parmetros controlam o tamanho e o destino dos arquivos de trace: MAX_DUMP_FILE_SIZE = n USER_DUMP_DEST = directory_path O valor default de MAX_DUMP_FILE_SIZE 500, e o valor deste parmetro expressado em blocos do sistema operacional. A localizao default de USER_DUMP_DEST varia de acordo com o sistema operacional.
Obtendo Informaes sobre a Configurao de Parmetros

Voc pode exibir os valores atuais de parmetros consultando a viso V$PARAMETER: SQL> select name, value 2 from v$parameter 3 where name like '%dump%';
NAME -------------------background_dump_dest user_dump_dest max_dump_file_size VALUE --------------%RDBMS80%\trace %RDBMS80%\trace 10240 4-5
SQL Trace e TKPROF
Habilitando o SQL Trace

Para toda uma instncia, configure o seguinte parmetro de inicializao: SQL_TRACE = TRUE Para a sua sesso corrente: SQL> alter session set sql_trace = true; SQL> execute dbms_session.set_sql_trace(true); Para qualquer sesso: SQL> execute dbms_system.set_sql_trace_in_session 2 (session_id, serial_id, true); Para habilitar o SQL Trace para toda uma instncia, configure o parmetro de inicializao SQL_TRACE para TRUE.
Habilitando SQL Trace para uma Sesso

Voc pode utilizar um comando SQL para habilitar o SQL Trace para a sua sesso. SQL> alter session set sql_trace = true; Voc pode tambm utilizar uma package fornecida com o Oracle para habilitar o SQL Trace para a sua sesso. SQL> execute dbms_session.set_sql_trace(true); Voc pode tambm habilitar o SQL Trace para uma sesso de outro usurio com uma package fornecida com o Oracle. SQL> execute dbms_system.set_sql_trace_in_session 2 (session_id, serial_id, true); Nesta chamada desta procedure, session_id e serial_id so os valores das colunas SID e SERIAL# da viso V$SESSION, normalmente utilizada pelos administradores de banco de dados.
Desabilitando o SQL Trace

Quando voc tiver encerrado o tuning, voc pode desabilitar o SQL Trace por qualquer um dos mtodos acima, substituindo a palavra TRUE por FALSE. Se voc tiver habilitado o SQL Trace para uma nica sesso, encerrando esta sesso tambm desabilita o SQL Trace.
4-6
SQL Trace e TKPROF
Encontrando seus Arquivos de Trace

Procure no diretrio especificado em USER_DUMP_DEST. Se poucas pessoas estiverem utilizando o SQL Trace, procure pelo arquivo mais recente. Caso contrrio, considere escrever um script. SQL> @readtrace.sql SQL> execute gettrace; PL/SQL procedure successfully completed. Identificar seu arquivo de trace no diretrio especificado por USER_DUMP_DEST normalmente uma simples questo de encontrar o arquivo de trace com o mais recente time stamp. Entretanto, esta tarefa torna-se mais difcil quando vrios usurios esto gerando arquivos de trace ao mesmo tempo.
Quando Vrios Usurios esto Criando Arquivos de Trace

Quando vrios usurios esto criando arquivos de trace ao mesmo tempo, o script read_trace.sql pode ser til. Ele cria uma procedure que abre seu arquivo de trace corrente utilizando a package UTL_FILE. O nome do arquivo de sada default username.trc, mas voc pode tambm especificar um nome. SQL> SQL> SQL> SQL> @readtrace.sql alter session set sql_trace = true; select * from dual; execute gettrace('output_file.trc');
4-7
SQL Trace e TKPROF
Formatando os Arquivos de Trace

Exemplos de comandos do TKPROF: OS> tkprof80 ora_804.trc run1.txt OS> tkprof80 Utilize o comando TKPROF para formatar seus arquivos de trace em um resultado legvel. A sintaxe do utilitrio TKPROF a seguinte: OS> tkprof80 tracefile outputfile [options] tracefile outputfile nome do arquivo de trace gerado (entrada para o TKPROF). nome do arquivo para armazenar os resultados formatados.
Quando o comando TKPROF executado sem quaisquer argumentos (veja o segundo exemplo acima), gera uma mensagem de utilizao junto com uma descrio de todas as opes do TKPROF. Veja a seguir uma listagem completa. Nota: o comando para iniciar o TKPROF em uma ambiente Windows contm um componente da verso; por exemplo, tkprof73 ou tkprof80. Nos sistemas UNIX o comando tkprof.
Usage: tkprof tracefile outputfile [explain= ] [table= ] [print= ] [insert= ] [sys= ] [sort= ] table=schema.tablename Use 'schema.tablename' with 'explain=' option. explain=user/password Connect to ORACLE and issue EXPLAIN PLAIN. print=integer List only the first 'integer' SQL statements. aggregate=yes|no insert=filename List SQL statements and data inside INSERT statements. sys=no TKPROF does not list SQL statements run as user SYS. record=filename Record non-recursive statements found in the trace file. sort=option Set of zero or more of the following sort options: prscnt number of times parse was called prscpu cpu time parsing prsela elapsed time parsing prsdsk number of disk reads during parse prsqry number of buffers for consistent read during parse prscu number of buffers for current read during parse prsmis number of misses in library cache during parse execnt number of execute was called execpu cpu time spent executing exeela elapsed time executing exedsk number of disk reads during execute exeqry number of buffers for consistent read during execute execu number of buffers for current read during execute exerow number of rows processed during execute exemis number of library cache misses during execute fchcnt number of times fetch was called fchcpu cpu time spent fetching fchela elapsed time fetching fchdsk number of disk reads during fetch fchqry number of buffers for consistent read during fetch fchcu number of buffers for current read during fetch fchrow number of rows fetched userid userid of user that parsed the cursor
4-8
SQL Trace e TKPROF
Opes do Comando TKPROF

SORT = option PRINT = n EXPLAIN = user/password INSERT = filename SYS = NO AGGREGATE = NO RECORD = filename TABLE = schema.tablename sort print explain insert sys aggregate record ordem na qual os comandos devem ser listados no relatrio. produz um relatrio ordenado com este nmero de comandos apenas. conecta ao banco de dados e executa EXPLAIN PLAN no schema especificado. cria um script SQL para carregar os resultados do TKPROF em uma tabela do banco de dados. desabilita a listagem de comandos SQL recursivos, enviados pelo usurio SYS. desabilita/habilita o comportamento do TKPROF de agregar comando idnticos em um registro. cria um script SQL com todos os comandos SQL no recursivos encontrados no arquivo de trace (este script pode ser utilizado para reaplicar a sesso de tuning posteriormente). especifica a tabela para temporariamente armazenar planos de execuo antes de escrev-los para o arquivo de sada.
table
4-9
SQL Trace e TKPROF
Resultado do Comando TKPROF

Texto do comando SQL. Estatsticas de trace (para comandos e chamadas recursivas) separadas em trs passos do processamento SQL: Traduz o comando SQL em um plano de execuo. Este passo PARSE inclui verificaes para autorizao de segurana e verificaes pela existncia de tabelas, colunas e outros objetos referenciados. Executa o comando. Para INSERT, UPDATE e DELETE, este EXECUTE passo modifica os dados. Para SELECT, este passo identifica as linhas selecionadas. Recupera as linhas retornadas por uma consulta e efetua a FETCH ordenao quando necessrio. Fetches so efetuados somente para comandos SELECT. O resultado do TKPROF apresenta as estatsticas para um comando SQL para cada passo do processamento SQL. O passo para o qual cada linha contm estatsticas identificado pelo valor da coluna CALL.
Estatsticas de Trace
Junto com a coluna CALL, o TKPROF exibe as seguintes estatsticas para cada comando: count nmero de vezes que um comando sofreu parse, execute ou fetch (verifique esta coluna por valores maiores que 1 antes de interpretar as estatsticas nas outras colunas; a menos que seja utilizada a opo AGGREGATE=NO, o TKPROF agrega execues de comandos idnticos em uma nica tabela). tempo total de CPU em segundos para todas as chamadas de parse, execute ou fetch. tempo total decorrido em segundos para todas as chamadas de parse, execute ou fetch. nmero total de blocos de dados fisicamente lidos a partir dos data files no disco para todas as chamadas de parse, execute ou fetch. nmero total de buffers recuperados em modo consistente para todas as chamadas de parse, execute ou fetch (buffers so normalmente recuperados em modo consistente para consultas). nmero total de buffers recuperados em modo corrente (buffers normalmente so recuperados em modo corrente para comandos DML. Entretanto, blocos de header de segmentos sempre so recuperados em modo corrente). nmero total de linhas processadas pelo comando SQL (este total no inclui linhas processadas por subconsultas do comando SQL. Para comandos SELECT, o nmero de linhas retornadas aparece para o passo de fetch. Para comandos UPDATE, DELETE e INSERT, o nmero de linhas processadas aparece para o passo de execute).
CPU elapsed disk query
current
rows
4-10
SQL Trace e TKPROF
O resultado do TKPROF tambm inclui o seguinte: Comandos SQL recursivos. Library cache misses. ID do usurio que efetuou o parse. Plano de execuo. Modo do otimizador ou hint.
Chamadas Recursivas (Recursive Calls)

Algumas vezes, para executar um comando SQL enviado por um usurio, o servidor Oracle deve executar comandos adicionais. Estes comandos so chamados comandos SQL recursivos. Por exemplo, se voc inserir uma linha em uma tabela que no possui espao suficiente para armazenar esta linha, o servidor Oracle efetua chamadas recursivas para alocar espao dinamicamente. Chamadas recursivas tambm so geradas quando informaes do dicionrio de dados no esto disponveis no data dictionary cache e devem ser recuperadas do disco. Se chamadas recursivas ocorrerem enquanto o SQL Trace estiver habilitado, o TKPROF marca estas chamadas claramente como comandos SQL recursivos no arquivo de sada. Voc pode suprimir a listagem de chamadas recursivas no arquivo de sada configurando o parmetro SYS=NO. Observe que as estatsticas para comandos SQL recursivos so includas na listagem para aquele comando, no na listagem para o comando SQL que causou a chamada recursiva. Assim, quando voc estiver calculando o total de recursos necessrios para processar um comando SQL, voc deve considerar as estatsticas para este comando bem como aquelas para as chamadas recursivas causadas por este comando.
Library Cache Misses

O TKPROF tambm lista o nmero de library cache misses resultando em passos de parse e execute para cada comando SQL. Estas estatsticas aparecem em linhas separadas seguindo a tabela de estatsticas.
Parsing User ID
Este o ID do ltimo usurio que efetuou o parse do comando.
Plano de Execuo
Se voc especificar o parmetro EXPLAIN na linha de comando do TKPROF, ser utilizado o comando EXPLAIN PLAN para gerar o plano de execuo de cada comando SQL do arquivo de trace. O TKPROF tambm exibe o nmero de linhas processadas por cada passo do plano de execuo. Nota: arquivos de trace gerados imediatamente aps o startup da instncia contm dados que refletem a atividade do processo de startup. Em especfico, refletem uma desproporcional quantidade de atividade de I/O a medida em que os caches da system global area (SGA) esto sendo preenchidos. Para propsitos de tuning ignore estes arquivos de trace. Alm disso, esteja atento ao fato de que o plano de execuo gerado no momento em que o comando TKPROF executado e no no momento que o arquivo de trace foi produzido. Isto pode fazer diferena se, por exemplo, um ndice foi criado ou removido desde o trace dos comandos.
4-11
SQL Trace e TKPROF
Optimizer Hint
Isto indica o hint do otimizador utilizado durante a execuo do comando. Se no existir nenhum hint, ento apresenta o modo do otimizador que foi utilizado. Hints e modos do otimizador sero discutidos posteriormente neste curso.
4-12
SQL Trace e TKPROF
Exemplo do Resultado do TKPROF: Sem ndice

select status from registrations where class_id = 155801 and stud_id = 7586 call count -----------Parse 1 Execute 1 Fetch 1 -----------total 3 cpu elapsed disk query current rows ---- ------- ---- ----- ------- ---0.54 0.56 1 0 0 0 0.01 0.01 0 0 0 0 0.52 1.47 1159 1160 0 1 ---- ------- ---- ---- ------- ---1.07 2.04 1160 1160 0 1
Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 75 O exemplo acima mostra uma linha sendo recuperada a partir da tabela REGISTRATIONS, sendo necessrias 1160 leituras e 0.52 segundos de tempo de CPU para o fetch. O comando foi executado atravs de um full table scan da tabela REGISTRATIONS, como voc pode verificar utilizando a opo EXPLAIN. O comando necessita ser otimizado.
4-13
SQL Trace e TKPROF
Exemplo do Resultado do TKPROF: ndice nico

select status from registrations where class_id = 155801 and stud_id = 7586 call count -----------Parse 1 Execute 1 Fetch 1 -----------total 3 cpu elapsed disk query current rows ---- ------- ---- ----- ------- ---0.10 0.10 0 0 0 0 0.00 0.00 0 0 0 0 0.00 0.00 0 4 0 1 ---- ------- ---- ---- ------- ---0.10 0.10 0 4 0 1
Misses in library cache during parse: 1 Optimizer goal: CHOOSE Parsing user id: 75 A mesma linha foi recuperada, mas neste caso o I/O foi substancialmente reduzido para somente quatro blocos lidos. Alm disso, o tempo de CPU foi reduzido para 0.00 segundos. Estes resultados foram obtidos porque o comando utilizou um ndice nico. Voc pode obter melhorias significativas na performance atravs de uma indexao sensata. Identifique reas para melhoria em potencial utilizando o SQL Trace. Nota: a criao de ndices por via de dvida no uma boa idia; eles no devem ser construdos a menos que seja necessrio. ndices retardam o processamento de comandos INSERT, UPDATE e DELETE, porque referncias para as linhas necessitam ser adicionadas, modificadas ou removidas. ndices no utilizados devem ser removidos. Se possvel, processe toda a aplicao SQL atravs do EXPLAIN PLAN e remova quaisquer ndices que no forem referenciados.
4-14
SQL Trace e TKPROF
Algumas Armadilhas de Interpretao do TKPROF

Armadilha de leitura consistente Armadilha de schema. Armadilha de tempo. Armadilha de triggers.
Armadilha de Leitura Consistente

Algumas vezes outras transaes armazenam modificaes no comitadas sobre a tabela. Isto aumenta o nmero de blocos visitados, porque blocos adicionais devem ser construdos e visitados para fornecer a leitura consistente.
Armadilha de Schema
As estatsticas do TKPROF mostram um grande nmero de blocos visitados enquanto o plano de execuo indica um acesso indexado. Especialmente se o resultado apresentar um valor diferente de zero para current, a tabela foi provavelmente acessado por um full table scan (compare as colunas current nas duas pginas anteriores). O ndice provavelmente foi construdo aps o arquivo de trace ser produzido, ou as estatsticas de tabela e coluna podem ser recalculadas.
Armadilha de Tempo
Se um comando DML especfico apresentar altas estatsticas de tempo, a explicao pode ser a interferncia de outra transao que est mantendo locks na tabela. Por causa disto o tempo de CPU um melhor indicador que o tempo decorrido.
Armadilha de Triggers
Os recursos reportados para um comando incluem aqueles para todos os SQLs enviados enquanto o comando estava sendo processado. Portanto, incluem quaisquer recursos utilizados dentro de uma trigger, junto com os recursos utilizados por qualquer outro SQL recursivo (como os SQL utilizados para alocao de espao). Com o SQL Trace habilitado, o TKPROF reporta estes recursos duas vezes. Evite tentar efetuar o tuning de comandos DML se o recurso estiver atualmente sendo consumido a um baixo nvel de recursividade.
4-15
SQL Trace e TKPROF
Exerccios
1. Verifique os seguintes parmetros de inicializao: TIMED_STATISTICS MAX_DUMP_FILE_SIZE USER_DUMP_DEST SQL_TRACE
Certifique-se que ambos TIMED_STATISTICS e SQL_TRACE estejam configurados para TRUE para a sua sesso. 2. Execute o seguinte comando SQL: SQL> select first_name, last_name 2 from employees 3 where emp_id = 6191; 3. Agora desabilite o trace para a sua sesso e tente encontrar o seu arquivo de trace. Abra o arquivo de trace com um editor do sistema operacional e investigue o contedo de seu arquivo de trace. 4. Inicie o TKPROF sem argumentos de linha de comando. O TKPROF exibe uma mensagem de utilizao, listando todas as opes de linha de comando. 5. Inicie o TKPROF novamente, desta vez com o nome de seu arquivo de trace como um argumento. Alm disso, especifique um nome para o arquivo de sada do TKPROF. Verifique o resultado com um editor do sistema operacional, e visualize como a legibilidade foi melhorada. 6. Finalmente, inicie o TKPROF de forma que os planos de execuo sejam adicionados ao relatrio e os comandos SQL recursivos sejam suprimidos.
4-16
5. Otimizao Baseada em Regra Versus Otimizao Baseada em Cus t o
Otimizao Baseada em Regra Versus Otimizao Baseada em Custo
Objetivos
Descrever a funo do otimizador do Oracle9i. Distingir entre RBO e CBO. Identificar como o otimizador escolhe entre RBO e CBO. Identificar os fatores que o CBO considera quando est decidindo sobre o plano de execuo. Identificar o comportanto do RBO e utilizar o esquema de ranking do RBO. Influenciar o comportamento do RBO. Configurar o tipo de otimizao a nvel de instncia e sesso.
5-2
Viso Geral
Otimizao baseada em regra (RBO). Otimizao baseada em custo (CBO). Configurando um modo de otimizao. Esquema de ranking do RBO. Influenciando o RBO.
Existem vrios mtodos e caminhos de acesso que podem ser utilizados para executar um comando SQL. trabalho do otimizador escolher qual deles ser utilizado. O RBO decide baseado em um conjunto de regras. O CBO baseia sua escolha em estatsticas armazenadas sobre as tabelas. Este captulo explica como o otimizador do Oracle decide entre estas duas alternativas. Para utilizar a otimizao baseada em custo, voc deve coletar estatsticas sobre as tabelas envolvidas. A otimizao baseada em custo pode ser influenciada de diversas maneiras sofisticadas, o que ser visto posteriormente. Embora permanea possvel utilizar a otimizao baseada em regra, o Oracle no recomenda esta escolha. Este captulo apresenta como a otimizao baseada em regra utiliza um esquema de ranking para produzir planos de execuo. Voc ver tambm tcnicas de codificao que foram bastante populares no passado para influenciar a otimizao baseada em regra. Finalmente, este captulo detalha as quatro alternativas bsicas do otimizador do Oracle9i, as quais podem ser configuradas a nvel de instncia e sesso.
5-3
Funes do Otimizador do Oracle9i

Avaliar expresses e condies. Transformar comandos em comandos equivalentes. Decidir como acessar os dados. Decidir como efetuar o join de tabelas. Decidir qual caminho mais eficiente.
O otimizador a parte do servidor Oracle9i que trabalha o plano de execuo para um comando SQL. Um plano de execuo uma srie de operaes que so efetuadas em seqncia para executar o comando. O otimizador pode utilizar vrios peas de informao para trabalhar o melhor caminho: Hints fornecidos pelo desenvolvedor. Estatsticas. Informaes do dicionrio. A clusula WHERE.
Normalmente, o otimizador trabalha em background. Entretanto, com utilitrios de diagnstico como o EXPLAIN, AUTOTRACE do SQL*Plus e o SQL Analyze do OEM, voc pode visualizar as decises que o otimizador efetuou.
5-4
Otimizao Baseada em Regra

Suportada por compatibilidade. Dirigida sintaxe. No utiliza estatsticas sobre os dados. No calcula custos.
Otimizao baseada em regra suportada no Oracle9i, mas somente por razes de compatibilidade com verses do Oracle6 e anteriores. Se voc ainda possui aplicaes OLTP desenvolvidas e cuidadosamente otimizadas utilizando o Oravle verso 6, voc pode querer continuar utilizando otimizao baseada em regra quando efetuar o upgrade destas aplicaes para o Oracle9i. Otimizao baseada em regra dirigida sintaxe, o que significa que modificando a sintaxe de comandos SQL pode modificar a performance. Estatsticas no so utilizadas, de forma que o otimizador no conhece nada sobre o nmero de linhas em uma tabela e os valores nas colunas da tabela. Custos dos planos de execuo no so calculados; a deciso sobre um plano de execuo totalmente baseada em um conjunto de regras.
5-5
Otimizao Baseada em Custo

Foi introduzida com o Oracle7. Dirigida estatsticas. Baseia as decises no clculo do custo: Nmero de leituras lgicas. Utilizao de CPU. Transmisses de rede. Continuamente melhorada. Normalmente melhor que RBO. O Oracle7 foi a primeira verso que possua a otimizao baseada em custo. Diferente da otimizao baseada em regra, o otimizador baseado em custo baseia suas decises na estimativa de custos, os quais por sua vez esto baseados em estatsticas armazenadas no dicionrio de dados. No clculo do custo de planos de execuo, a otimizao baseada em custo leva em conta: Nmero de leituras lgicas. Utilizao de CPU. Transmisses de rede. A otimizao baseada em custo continuamente melhorada com cada nova release do servidor Oracle, e vrias caractersticas do Oracle9i, como hash joins, star queries, histogramas e tabelas index-only, esto disponveis somente para otimizao baseada em custo.
5-6
Escolhendo entre RBO e CBO

Comportamento default do otimizador do Oracle9i: Utiliza RBO quando estatsticas no esto disponveis. Utiliza CBO quando estatsticas esto disponveis para pelos menos um dos objetos referenciados. Quaisquer estatsticas que estejam faltando so estimadas ou substitudas por valores internos hard-coded no software Oracle. Este comportamento default pode ser influenciado: A nvel de instncia. A nvel de sesso. A nvel de comando.
5-7
Configurando o Modo do Otimizador

A nvel de instncia, configure o seguinte parmetro: OPTIMIZER_MODE = {CHOOSE|RULE|FIRST_ROWS|ALL_ROWS} Para uma sesso, utilize o seguinte comando SQL: SQL> ALTER SESSION SET OPTIMIZER_MODE = {CHOOSE|RULE|FIRST_ROWS|ALL_ROWS} O Oracle9i possui quatro modos bsicos do otimizador: CHOOSE comporta-se como descrito anteriormente neste captulo: baseado em custo quando estatsticas esto disponveis, baseado em regra quando no esto (este o valor default). fora otimizao baseada em regra mesmo na presena de estatsticas.
RULE
FIRST_ROWS otimiza o tempo de resposta at que o primeiro resultado seja retornado para o usurio (por exemplo, para aplicaes OLTP interativas). ALL_ROWS otimiza o throughput global (por exemplo, para relatrios e jobs do tipo batch).
Nveis do Modo do Otimizador

A nvel de instncia, o modo do otimizador pode ser configurado utilizando o parmetro de inicializao OPTIMIZER_MODE. Quando este parmetro no estiver configurado, seu default CHOOSE. Quando estatsticas estiverem disponveis, CHOOSE equivalente a ALL_ROWS. A nvel de sesso, o modo do otimizador configurado a nvel de instncia pode ser sobreposto utilizando o comando ALTER SESSION. Nota: por razes de compatibilidade, OPTMIZER_GOAL suportado como um sinnimo para OPTIMIZER_MODE no comando ALTER_SESSION.
5-8
Caractersticas do RBO
Utiliza ndices incondicionalmente, porque no possui nenhum conhecimento de estatsticas. Utiliza um esquema de ranking interno com scores para os caminhos de acesso. Difcil de influenciar. Otimizao baseada em regra sempre utiliza ndices quando possvel, mesmo quando tabelas so pequenas ou quando consultas normalmente retornam um percentual significativo de linhas, quando um full table scan seria mais rpido. Otimizao baseada em regra no verifica estatsticas, como o nmero de linhas em uma tabela ou a seletividade de um predicado. Otimizao baseada em regra utiliza um esquema de ranking para decidir quais caminhos de acesso para os dados deve escolher. Voc no pode influenciar otimizao baseada em regra, exceto pela criao de ndices, remoo de ndices ou tornando ndices inutilizveis pela modificao da sintaxe do comando.
5-9
Esquema de Ranking do RBO

Rank 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Caminho de Acesso Uma nica linha por ROWID Uma nica linha por join do tipo cluster Uma nica linha pela chave de um hash cluster com chave nica ou primria Uma nica linha por chave nica ou primria Join do tipo cluster Chave de hash cluster Chave de cluster indexado ndice composto ndice de uma nica coluna Pesquisa com intervalo definido (bounded range) em colunas indexadas Pesquisa com intervalo indefinido (unbounnded range) em colunas indexadas Join do tipo sort-merge MAX ou MIN de coluna indexada ORDER BY em coluna indexada Full table scan
O otimizador baseado em regra aplica regras baseado na sintaxe do comando para estabelecer o caminho de acesso. O otimizador determina todos os caminhos de acesso disponveis para o comando e ento escolhe aquele de menor ranking a partir do esquema de ranking apresentado acima. Este mtodo sempre assume que um full table scan (rank 15) o pior mtodo de acesso. Isto pode no ser o caso, especialmente com tabelas pequenas ou com consultas que retornem um grande percentual das linhas de uma tabela. Estes (e outros) caminhos de acesso tambm esto disponveis para o otimizador baseado em custo. Entretanto, o otimizador ignora o ranking e trabalha o custo estimado para cada caminho de acesso possvel, ento escolhendo um com o menor custo estimado. Vrias caractersticas novas (como hash joins, start queries, histogramas e tabelas index-organized) esto disponveis somente atravs de otimizao baseada em custo.
5-10
Exemplo de Otimizao Baseada em Regra

SQL> 2 3 4 5 select from where and order last_name employees job = 'INSTRUCTOR' salary between 3000 and 6000 by last_name;
O RBO possui os seguintes caminhos de acesso disponveis: Full table scan Scan do ndice de job por igualdade Pesquisa no ndice de salrio por intervalo definido O RBO escolhe o menor rank (9). O modo baseado em regra escolhe um caminho baseado na sintaxe do comando (normalmente as condies da clusula WHERE). O otimizador escolhe o caminho de acesso com o ranking de menor nmero. Suponha que o RBO deva escolher um caminho de execuo para a consulta acima. Ambas as colunas JOB e SALARY esto indexadas. O otimizador possui as seguintes escolhas: full table scan scan do ndice job scan do ndice salary este caminho est disponvel para todos os comandos SQL (rank 15). utiliza o ndice da coluna JOB, um ndice de uma nica coluna (rank 9). utiliza o ndice da coluna SALARY, um pesquisa com intervalo determinado (rank 10). RANK = 15 RANK = 9 RANK = 10
O menor rank 9, de forma que o ndice sobre a coluna JOB ser utilizado para acessar as linhas da tabela EMPLOYEES. Observe que embora o ndice sobre a coluna JOB seja utilizado, uma operao de filtro necessita ser efetuada sobre a coluna SALARY para retornar o resultado correto.
5-11
Influenciando a Otimizao Baseada em Regra

Modifique a ordem da tabela na clusula FROM. Modifique a ordem do predicado na clusula WHERE. Crie ou remova ndices. Suprima o utilizao de ndices com truques de sintaxe: numeric_column + 0 date_column + 0 char_column || Otimizao baseada em regra altamente sensvel a sintaxe. Quando voc esta efetuando join de tabelas, a ordem na qual as tabelas so especificadas na clusula FROM pode ter um impacto significativo na performance. Por exemplo, voc deve sempre colocar a tabela mais restritiva no final, porque o otimizador avalia a clusula FROM da direita para a esquerda. Alm disso, a ordem dos predicados em uma combinao na clusula WHERE pode influenciar a performance. O otimizador sempre utiliza ndices quando estes estiverem disponveis. Desta forma muito importante criar ndices apropriados e remover ndices que deterioram a performance. Infelizmente, a maioria dos ndices nicos no podem ser removidos porque protegem as constraints de integridade. A forma padro para impedir a otimizao baseada em regra de utilizar ndices existentes a utilizao de um truque: ndices so utilizveis somente quando os nomes de colunas associadas aparecem isolados (clean) nos predicados. Aplicando um operador qualquer (adicionando zero ou concatenando uma string vazia), voc suprime a utilizao de ndice. Nota: a otimizao baseada em custo fornece um mtodo mais flexvel, legvel e aceitvel para influenciar o otimizador. Modificando predicados na forma descrita acima ainda funciona, mas no recomendado. Entretanto, voc deve entender o comportamento do RBO quando estiver efetuando a manuteno ou atualizao das aplicaes existentes.
5-12
6. ndices e Mtodos de Acesso Bsicos
ndices e Mtodos de Acesso Bsicos
Objetivos
Identificar ROWIDs do Oracle9i. Identificar tipos de ndices. Apresentar a relao entre ndices e constraints. Criar ndices manualmente. Identificar detalhes de ndices com foreign keys. Identificar mtodos de acesso bsicos.
6-2
ROWIDs do Oracle9i
Indicam o endereo (localizao) de uma linha no banco de dados. ROWIDs estendidos e restritos esto disponveis. Cada tabela possui uma pseudocoluna chamada ROWID. SQL> select rowid, rs.* 2 from reg_statuses rs; ROWID -----------------AAABDLAACAAAF0ZAAA AAABDLAACAAAF0ZAAB AAABDLAACAAAF0ZAAC AAABDLAACAAAF0ZAAD AAABDLAACAAAF0ZAAE ^^^^^^ ^^^^^^ REG_ ---CANC HOLD PEND REGI WAIT DESCRIPTION ----------Canceled Hold Pending Registered Waitlisted
O Oracle utiliza um tipo de dado de ROWID estendido para armazenar o endereo de cada linha no banco de dados. O ROWID estendido eficientemente identifica linhas em tabelas e ndices. Suporta endereos de blocos de dados relativos a tablespace. Um tipo de dado de ROWID restrito tambm est disponvel para compatibilidade com aplicaes existentes. Cada tabela no banco de dados Oracle internamente possui uma pseudocoluna chamada ROWID. ROWIDs no so armazenados no banco de dados. Entretanto, voc pode criar tabelas que contenham colunas com o tipo de dado ROWID, embora o Oracle no garanta que os valores destas colunas sejam ROWIDs vlidos. O ROWID estendido possui um formato com quatro partes, utilizando uma tcnica de codificao base 64. No exemplo acima, estes so os campos e seus significados: AAABDL AAC AAAF0Z AAA-AAE nmero do objeto de dados; identifica o segmento do banco de dados. nmero relativo do arquivo; nico dentro da tablespace. nmero do bloco de dados; relativo ao seu datafile. nmero das linhas no bloco.
Manipulao de ROWID
Voc pode utilizar a package DBMS_ROWID para extrair informaes a partir de um ROWID estendido ou converter um ROWID do formato estendido para o formato restrito (ou vice versa).
6-3
ndices
ndices nicos e no nicos. ndices compostos. Tcnicas de armazenamento de ndices: ndices b-tree. ndices bitmap. ndices de chave reversa. Um ndice um objeto do banco de dados que logicamente e fisicamente independente da tabela de dados. O servidor Oracle9i utiliza um ndice para acessar os dados necessrios para um comando SQL, ou utiliza ndices para garantir constraints de integridade. Voc pode criar e remover ndices a qualquer momento. O servidor Oracle9i automaticamente mantm estes quando dados relacionados forem modificados.
Tipos de ndices
ndices podem ser nicos ou no nicos. ndices nicos garantem que duas entradas de ndices no possuam o mesmo valor. Um ndice composto (tambm chamado de ndice concatenado) um ndice que voc cria sobre mltiplas colunas da tabela (at 32). Colunas em um ndice composto pode aparecer em qualquer ordem, e no necessitam ser adjacentes na tabela.
Tcnicas de Armazenamento de ndices

Para ndices padro, o Oracle utiliza ndices b-tree que so balanceados para equalizar tempos de acesso para qualquer linha. Em um ndice bitmap, um bitmap para cada valor de chave criado. Cada bit no bitmap corresponde a uma linha, e se o bit estiver habilitado, significa que a linha correspondente contm este valor de chave. Se o nmero de valores de chaves distintas for pequeno, ndices bitmap so muito eficientes em termos de espao. ndices bitmap sero discutidos posteriormente. ndices de chave reversa invertem os bytes dos valores das colunas enquanto mantm a ordem das colunas. Podem auxiliar a evitar a degradao de performance em um ambiente Oracle Parallel Server, onde modificaes para o ndice esto concentradas na mesma pequena parte de um ndice.
6-4
Estrutura de ndice B-Tree
Cada ndice b-tree possui um bloco root (raiz) no ponto inicial. Dependendo do nmero de entradas, existem uma ou mais linhas de blocos branch (ramos). Finalmente, um ndice b-tree consiste de um conjunto de blocos leaf (folhas), contendo todos os valores mais um ROWID apontando para a linha no segmento de dados associado. Os blocos leaf (tambm chamados de sequence set) so conectados por ponteiros que indicam o bloco anterior e o prximo bloco. A estrutura interna de um ndice b-tree permite acesso rpido para os valores indexados. O servidor Oracle9i pode acessar as linhas diretamente aps ter recuperado seu endereo (ROWID) a partir dos blocos folha do ndice. Se o otimizador decide utilizar um ndice, o servidor Oracle9i pesquisa o ndice pelos valores da coluna acessada pelo comando e efetua os seguintes passos: Se o comando acessar somente colunas que esto presentes no ndice, recupera os valores das colunas diretamente a partir do ndice sem ir ao segmento de dados. Se o comando tambm acessar outras colunas, recupera o endereo a partir do ndice, e ento acessa os blocos de dados pelo ROWID. Nota: ndices b-tree padro armazenam somente valores no nulos; eles no contm entradas para valores nulos.
6-5
ndices e Constraints
O servidor Oracle9i implicitamente cria ndices b-tree quando voc define: Constraints de primary key. Constraints de unique. SQL> 2 3 4 5 create table REG_STATUSES (reg_status varchar2(4) constraint REG_STATUS_PK primary key ,description varchar2(40) );
Quando voc define uma constraint de chave primria ou nica em uma tabela, o Oracle9i automaticamente gera um ndice para suport-la. ndices utilizados para este propsito so fisicamente, mas no logicamente, independentes da estrutura da tabela. O servidor Oracle9i fornece ao ndice o mesmo nome da constraint. Voc no pode remover um ndice que esteja garantido uma constraint. Ao invs disto, voc deve desabilitar a constraint, o que na maioria dos casos faz com que o Oracle9i automaticamente remova o ndice. Esteja atento ao fato de Oracle9i suportar constraints do tipo deferrable (adiadas). Constraints deferrable do tipo unique so sempre garantidas utilizando ndices no nicos. Alm disso, ao desabilitar esta constraint, o servidor Oracle9i no remove o ndice associado, desta forma oferecendo uma verificao fcil quando a constraint for habilitada novamente. ndices servem a pelo menos dois propsitos: tornar consultas rpidas e para garantir chaves nicas e primrias. O otimizador do Oracle9i utiliza os ndices existentes quando novas constraints so definidas.
6-6
Sintaxe do CREATE INDEX
A maioria dos componentes do comando CREATE INDEX possuem uma sintaxe simples. A opo NOSORT pode ser utilizada somente com ndices b-tree padro, e somente se as linhas na tabela estiverem exatamente na ordem correta. Ser ignorada a fase de sort, aumentando a velocidade de criao do ndice. Se as linhas no estiverem na ordem correta, o seguinte erro ser retornado: ORA-01409: NOSORT option may not be used; rows are not in ascending order A opo NOLOGGING reduz a gerao de undo durante a criao do ndice.
ndices Compostos
Quando criar um ndice composto, siga duas diretrizes (possivelmente conflitantes): Coloque a coluna mais freqentemente consultada no nicio, porque o otimizador pode utiliz-lo como um ndice tambm quando as outras colunas no forem consultadas. Coloque a coluna mais restritiva primeiro se voc espera especificar sempre a chave completa. Nota: lembre que o servidor Oracle9i deve manter os ndices, desta forma tornanddo mais lentos comandos DML. Crie somente aqueles ndices que voc est certo que o otimizador ir utilizar para melhorar a velocidade de consultas.
6-7
ndices e Foreign Keys

ndices no so automaticamente criados. Existem implicaes de locking para deleo ou atualizao de dados em tabela pai-filho.
O Oracle9i no cria ndices automaticamente para uma constraint de chave estrangeira. Se as colunas da foreign key so freqentemente utilizadas em condies de join, ento voc deve criar um ndice nelas para melhorar o processo de join. Delees ou atualizaes de dados em tabelas pai-filho (com uma constraint de foreign key) causam um comportamento de lock diferente, dependendo da presena de um ndice sobre as colunas da foreign key. Se a sua aplicao atualiza a tabela pai freqentemente, contenes podem ocorrem. Indexe as colunas da foreign key, mesmo se elas no so normalmente utilizadas em condies de join.
6-8
Mtodos de Acesso Bsicos

Full table scans: Podem utilizar I/O multibloco. Podem ser paralelizados. Index scans: Acesso somente ao ndice. Acesso por ROWID. Fast full index scans: Podem utilizar I/O multibloco. Podem ser paralelizados.
Full Table Scans

Um full table scan pode envolver a leitura de vrios blocos de dado seqnciais a partir dos arquivos do banco de dados no disco para o buffer cache. Entretanto, o servidor Oracle9i pode ler vrios blocos seqnciais em um nico I/O. Isto referenciado como I/O multibloco. Voc pode influenciar I/O multibloco configurando o parmetro DB_FILE_MULTIBLOCK_READ_COUNT. A utilizao da caracterstica de parallel query pode auxiliar a melhorar a velocidade de full table scans alocando vrios processos para o trabalho.
Index Scans
ndices melhoram a performance de vrios comandos SQL. Entretanto, uma consulta indexada pode ler tanto blocos de ndice quanto de dados. Estes blocos normalmente no so seqnciais, de forma que a consulta no pode utilizar leituras multibloco. Utilize ndices somente quando estes melhorarem a performance. Como regra geral, utilize ndices b-tree para consultas que selecionem menos que 4% das linhas de uma tabela. Entretanto, este ponto pode variar com seus dados. Certifique-se de testar isto para todos os processos crticos, utilizando as ferramentas de diagnstico.
Fast Full Index Scans

O fast full index scan uma alternativa para um full table scan quando existir um ndice que contenha todas as colunas que so necessrias para uma consulta. Isto mais rpido que um scan de ndice normal porque pode utilizar I/O multibloco e pode ser paralelizado assim como um table scan. Diferente de scans normais, entretanto, as linhas no sero necessariamente retornadas em uma determinada ordem. Se existir um predicado que restringir a pesquisa do ndice para um intervalo de valores, ento o otimizador no considerar o fast full index scan.
6-9
7. Coletando Estatsticas
Coletando Estatsticas
Objetivos
Utilizar o comando ANALYZE para coletar estatsticas. Identificar estatsticas de tabela, ndice, coluna e cluster. Entender os clculos de seletividade de predicados. Criar histogramas para colunas com dados no uniformemente distribudos. Escolher valores apropriados para: Sample size para estimar estatsticas. O nmero de entradas de histogramas.
7-2
Comando ANALYZE
Voc coleta estatsticas sobre um objeto com o comando ANALYZE. Embora o otimizador no seja sensvel a pequenas mudanas no volume ou seletividade, voc pode querer coletar novas estatsticas periodicamente em tabelas freqentemente modificadas para garantir que o otimizador esteja utilizando informaes recentes e precisas. Ao utilizar o comando ANALYZE para coletar novas estatsticas, quaisquer estatsticas existentes no dicionrio de dados so sobrescritas e os planos de execuo relacionados so removidos da shared pool. A package DBMS_DDL contm uma procedure chamada ANALYZE_OBJECT que permite que uma tabela, ndice ou cluster seja analisado. A package DBMS_UTILITY contm um procedure chamada ANALYZE_SCHEMA que coleta estatsticas sobre todos os objetos de um determinado schema.
Opo COMPUTE STATISTICS

Voc calcula estatsticas exatas com esta opo. Isto efetua um full table scan e vrios clculos. Para grandes tabelas esta operao pode levar uma quantidade de tempo considervel.
Opco ESTIMATE STATISTICS

Voc estima estatsticas com esta opo. Entretanto, se voc utiliz-la com uma amostra satisfatria dos dados, esta opo quase to fidedigna quanto a opo COMPUTE STATISTICS.
Opo DELETE STATISTICS

Voc pode remover estatsticas com esta opo. Voc no necessita utilizar esta opo antes de reanalisar um objeto, porque as estatsticas existentes sero sobrescritas.
7-3
COMPUTE e ESTIMATE: for_clause
ESTIMATE: sample_clause
Se mais do que metade dos dados for especificado como um sample size, o servidor Oracle9i efetua a leitura de todos os dados e utiliza compute statistics ao invs de estimate. Se a tabela possui menos do que 1064 linhas e um sample size no for especificado, o servidor Oracle9i utiliza compute statistics independentemente se ESTIMATE STATISTICS ou COMPUTE STATISTICS for escolhido.
7-4
Estatsticas de Tabela
Estas so as estatsticas de tabela coletadas pelo comando ANALYZE: Nmero de linhas. Nmero de blocos (sempre exata). Nmero de blocos vazios (sempre exata). Mdia de espao livre disponvel. Nmero de linhas migradas (migrated) ou encadeadas (chained). Tamanho mdio das linhas. Data do ltimo ANALYZE e sample size utilizado.
Vises do dicionrio de dados: USER/ALL/DBA_TABLES Nota: cada tabela mantm uma high water mark no bloco de header do segmento. A high water mark indica o ltimo bloco que j foi utilizado alguma vez para a tabela. Quando o servidor Oracle executa full table scans, efetua a leitura de todos os blocos at a high water mark. Observe que a high water mark no retrocede quando linhas so removidas da tabela. A procedure DBMS_SPACE.UNUSED_SPACE pode tambm ser utilizada para encontrar a high water mark e o nmero de blcos acima dela, se a anlise da tabela for impossvel ou indesejada.
Vises ALL_TABLE e DBA_TABLES do Dicionrio de Dados

As estatsticas de tabela so armazenadas no dicionrio de dados, podendo ser exibidas consultando-se a viso ALL_TABLES ou DBA_TABLES.
Name ------------------------------OWNER TABLE_NAME TABLESPACE_NAME ... NUM_ROWS BLOCKS EMPTY_BLOCKS AVG_SPACE CHAIN_CNT AVG_ROW_LEN ... SAMPLE_SIZE LAST_ANALYZED ... Null? -------NOT NULL NOT NULL Type -----------VARCHAR2(30) VARCHAR2(30) VARCHAR2(30) ... NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER ... NUMBER DATE ...
7-5
Exemplo: SQL> analyze table employees 2 estimate statistics for table; SQL> 2 3 4 5 6 select , , from where and num_rows,blocks,empty_blocks avg_space,avg_row_len sample_size dba_tables table_name = 'EMPLOYEES' owner = user;
NUM_ROWS BLOCKS EMPTY_BLOCKS AVG_SPACE AVG_ROW_LEN SAMPLE_SIZE -------- ------ ------------ --------- ----------- ----------15132 434 5 225 48 1064
7-6
Estatsticas de ndice
Estas so as estatsticas de ndice coletadas pelo comando ANALYZE: Nvel da b-tree do ndice index level (sempre exata). Nmero de blocos folha (leaf blocks). Nmero de chaves distintas (isto pode incluir linhas que tenham sido deletadas). Nmero mdio de blocos folha por chave. Nmero mdio de blocos de dados por chave. Nmero de entradas de ndice. Clustering factor. Data do ltimo ANALYZE e sample size utilizado.
Vises do dicionrio de dados: USER/ALL/DBA_INDEXES
Clustering Factor de ndice

O clustering factor de ndice uma estatstica de ndice importante para o CBO estimar os custos de index scans. uma indicao do nmero de visitas (lgicas) blocos de dados necessrias para recuperar todas as linhas da tabela atravs do ndice. Se as entradas de ndice seguirem a ordem das linhas na tabela, este valor aproxima-se do nmero de blocos de dados (cada bloco ser visitado somente uma vez); por outro lado, se as entradas de ndice apontarem randomicamente para diferentes blocos de dados, o clustering factor pode aproximar-se do nmero de linhas. Suponha que uma tabela tpica contenha 50 linhas por bloco de dados e 5000 linhas no total. Quando um consulta estiver procurando por 50 linhas (seletividade de 1%), o clustering factor ir indicar se voc vai necessitar visitar um bloco (melhor caso: 1% dos blocos de dados) ou 50 blocos (pior caso: 50% dos blocos de dados).
7-7
Vises ALL_INDEXES e DBA_INDEXES do Dicionrio de Dados

As estatsticas de ndice so armazenadas no dicionrio de dados, podendo ser exibidas consultando-se a viso ALL_INDEXES ou DBA_INDEXES.
Name ------------------------------OWNER INDEX_NAME INDEX_TYPE ... UNIQUENESS ... BLEVEL LEAF_BLOCKS DISTINCT_KEYS AVG_LEAF_BLOCKS_PER_KEY AVG_DATA_BLOCKS_PER_KEY CLUSTERING_FACTOR ... NUM_ROWS SAMPLE_SIZE LAST_ANALYZED ... Null? -------NOT NULL NOT NULL Type -----------VARCHAR2(30) VARCHAR2(30) VARCHAR2(12) VARCHAR2(9) NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER NUMBER DATE
Exemplo: SQL> analyze index reg_pk compute statistics; SQL> 2 3 4 5 6 select , , from where and uniqueness, blevel leaf_blocks, distinct_keys clustering_factor dba_indexes index_name = 'REG_PK' owner = user;
UNIQUENESS BLEVEL LEAF_BLOCKS DISTINCT_KEYS CLUSTERING_FACTOR ---------- ------ ----------- ------------- ----------------UNIQUE 2 682 56252 21349
7-8
Estatsticas de Coluna
Estas so as estatsticas de coluna coletadas pelo comando ANALYZE: Nmero de valores distintos. Menor valor. Maior valor. Data do ltimo ANALYZE e sample size utilizado.
Vises do dicionrio de dados: USER/ALL/DBA_TAB_COL_STATISTICS Tanto o menor quanto o maior valor so armazenados em um formato RAW (binrio).
Vises ALL/ DBA_TAB_COL_STATISTICS do Dicionrio de Dados

As estatstiacs de coluna so armazenadas no dicionrio de dados, podendo ser exibidas consultando-se a viso ALL_TAB_COL_STATISTICS e DBA_TAB_COL_STATISTICS.
Name ------------------------------TABLE_NAME COLUMN_NAME NUM_DISTINCT LOW_VALUE HIGH_VALUE DENSITY NUM_NULLS NUM_BUCKETS LAST_ANALYZED SAMPLE_SIZE Null? -------NOT NULL NOT NULL Type -----------VARCHAR2(30) VARCHAR2(30) NUMBER RAW(32) RAW(32) NUMBER NUMBER NUMBER DATE NUMBER
Nota: para compatibilidade com o Oracle7, as vises ALL/DBA_TAB_COLUMNS do dicionrio de dados tambm mostram valores de estatsticas de coluna. Exemplo: SQL> 2 3 4 5 select , , from where column_name, num_distinct low_value, high_value num_nulls, num_buckets dba_tab_col_statistics table_name = 'EMPLOYEES';
NUM NUM NUM COLUMN_NAME DISTINCT LOW_VALUE HIGH_VALUE NULLS BUCKETS ----------- -------- -------------- -------------- ----- ------EMP_ID 15132 C2191A C403013E05 0 1 MGR_ID 1167 C21361 C403013D07 0 1 LAST_NAME 4383 4162626F7474 5A696D6D6572 0 1 FIRST_NAME 445 416B73686169 5A6875736869 107 1 HIREDATE 535 77980217010101 77C6050B010101 0 1 JOB 24 4141 54454348 36 1 SALARY 496 C208 C30A62 0 1
7-9
Estatsticas de Cluster
Tamanho mdio de encadeamento de chave do cluster (average cluster key chain length). Vises do dicionrio de dados: USER/ALL/DBA_CLUSTERS
Tamanho Mdio de Encadeamento de Chave do Cluster

Para acessar uma linha em uma tabela clusterizada, o servidor Oracle9i efetua a leitura de todos os blocos contendo linhas com este valor de chave. Se estas linhas ocuparem mltiplos blocos, acessar uma nica linha pode requerer mais leituras do que se o acesso da mesma linha fosse feito com uma tabela no clusterizada.
Vises ALL_CLUSTER e DBA_CLUSTERS do Dicionrio de Dados

Name ------------------------------OWNER CLUSTER_NAME ... AVG_BLOCKS_PER_KEY ... Null? -------NOT NULL NOT NULL Type -----------VARCHAR2(30) VARCHAR2(30) NUMBER
7-10
Seletividade de Predicados
Chave nica ou primria = constante predicado de uma linha (single-row predicate) ndice no nico = constante seletividade = 1/chaves distintas (distinct_keys) Intervalo limitado/ilimitado (bounded/unbounded) seletividade = (high low + 1) / (max min + 1) high: upperbound (ou max) low: lowerbound (ou min) max, min: estatsticas de colunas O percentual esperado de linhas (a seletividade) depende do tipo de operao efetuada na clusula WHERE. O mtodo baseado em custo mais propenso a escolher um caminho de acesso indexado para um consulta com melhor seletividade. O otimizador do Oracle9i utiliza as seguintes regras quando est calculando a seletividade.
Condies de Igualdade
Chave nica ou primria = constante Este um predicado do tipo single-row, retornando no mximo uma linha; possui mxima seletividade. ndice no nico = constante A consulta pode retornar mais do que uma linha, de forma que o otimizador utiliza o nmero de valores de chaves distintas na coluna. A seletividade 1 dividido pelo nmero de valores distintos.
Intervalos Limitados e Ilimitados

Intervalos limitados e ilimitados necessitam de estatsticas para calcular a seletividade, de forma que CBO e RBO causam diferentes resultados. O RBO deve confiar na sintaxe e no seu schema de ranking; o CBO utiliza a seguinte frmula:
seletividade = high low + 1 max min + 1
Nota: esta frmula assume min <= low <= high <= max.
7-11
Variveis Bind e Seletividade de Predicados

Condies de igualdade: sem diferena. Intervalo ilimitado: assume 25% de seletividade. Intervalo limitado: assume 50% de seletividade. No caso de condies de igualdade (ou seja, se o operador for um sinal de igual), uma varivel bind tratada como uma constante. Devido ao fato de a fase de bind seguir a fase de parse, o otimizador do Oracle9i no conhece o valor atual das variveis bind durante a otimizao. Isto significa que o otimizador deve utilizar uma seletividade padro (built-in) no caso de um comando SQL conter variveis bind.
Performance
Se performance for um foco importante, considere a utilizao de SQL dinmico para construir comandos com valores literais. Isto significa que cada comando ser otimizado separadamente (fornecendo a melhor performance disponvel). Entretanto, existe uma desvantagem: devido a maioria dos comandos SQL dinmicos serem diferentes um do outro, voc no pode beneficiar-se de SQLs compartilhados. Isto significa que os comandos SQL sero mais rapidamente removidos da shared pool.
7-12
Histogramas
Um otimizador de consultas deve determinar precisamente a quantidade de informao, ou seja, o nmero de linhas, processadas por uma determinada consulta. Isto parcialmente obtido estimando-se as seletividades de predicados de consultas. A preciso destas estimativas de seletividade depende da preciso das descries de otimizao das distribuies de dados dos atributos. Histogramas so um forma efetiva para obter uma boa descrio.
Tipos de Histogramas
Histogramas width-balanced: estes histogramas particionam o domnio do atributo em intervalos de largura igual, chamados de entradas de histrograma, e contam o nmero de linhas, sendo que o valor da linha determina em qual entrada esta ser sumarizada. Se vrias linhas contiverem o mesmo valor, sero colocadas na mesma entrada, aumentando a altura desta entrada. Histogramas height-balanced: cada intervalo, chamado de entrada de histograma, possui (na maioria das vezes) o mesmo nmero de linhas. Se vrias linhas possurem o mesmo valor, podem ser colocadas na mesma entrada ou distribudas atravs de vrias entradas, a medida que o histograma efetua o balanceamento da altura das entradas. As entradas podem cobrir um intervalo pequeno ou grande de valores. Algumas entradas podem cobrir somente um ou poucos valores, porque existem muitas linhas com estes valores. Algumas entradas podem cobrir vrios valores, porque existem poucas linhas com estes valores.
Histogramas height-balanced so mais sofisticados para o clculo de estimativas de seletividade e so utilizados pelo servidor Oracle9i.
7-13
Exemplo Comparativo de Histogramas
A imagem acima exibe um exemplo do aumento da preciso com histogramas. A tabela contm 13 linhas, das quais 7 linhas contm o valor 1, e os outros valores so os seguintes: 2, 3, 5, 8, 10 e 100.
Sem Histogramas
Sem histogramas, o otimizador baseado em custo (CBO) conhece apenas o valor mnimo (1), o valor mximo (100) e o nmero de valores distintos (7). Para um predicado de igualdade, o CBO pode somente supor que cada valor igualmente provvel: 1/7 ou 14%. Para pesquisas de intervalos, pode somente assumir uma distribuio uniforme entre 1 e 100; desta forma, col <= 3 e col > 3 apresentam 3% e 97%, respectivamente.
Com Histogramas
Com um histograma, o otimizador baseado em custo sabe quanto de cada valor estava na tabela quando esta foi analisada. Neste exemplo, ele sabe que as primeiras duas entradas do histograma esto completamente preenchidas com o valor 1. Devido ao valor mximo da terceira entrada ser 5 (e uma distribuio uniforme dentro de cada entrada assumida), o otimizador calcula que col = 1 possui uma seletividade de 2.2 entradas, ou 55%. Baseado na mesma distribuio uniforme dentro da terceira entrada, col <= 3 mapeado para 60% desta entrada, resultando em 2.6 entradas, ou 65%. Finalmente, col > 3 mapeada para 40% da terceira entrada mais a quarta, resultando em uma seletividade estimada de 35%.
7-14
Exemplo de Coleta de Estatsticas para Histogramas

Crie estatsticas de tabela sobre a tabela CLASSES e estatsticas de coluna sobre a coluna CLASS_ID; o nmero mximo de entradas 100.
SQL> analyze table classes compute statistics 2 for table for columns class_id size 100;
Recalcule as estatsticas sobre a coluna CLASS_ID com o nmero default de entradas (75).
SQL> analyze table classes compute statistics 2 for columns class_id;

As estatsticas de coluna contm as entradas para o histograma, o nmero de valores distintos e valores nulos, e a densidade destes valores. O fator densidade representa a frao mdia de valores com o mesmo valor, excluindo valores altamente populares. Valores altamente populares so aqueles que aparecem em mais de uma entrada do histograma. A frmula para calcular a densidade envolve a excluso de todos os valores altamente populares e o clculo de uma seletividade mdia para o restante.
Coleta de Estatsticas
Utilize o comando ANALYZE para coletar informaes para histogramas utilizando a clusula FOR. A opo SIZE especifica o nmero de entradas.
ANALYZE TABLE table {COMPUTE|ESTIMATE} STATISTICS FOR {TABLE | ALL INDEXES |ALL [INDEXED] COLUMNS [SIZE n] |FOR COLUMNS [SIZE n] column [SIZE n] [,column [SIZE n]]...}
7-15
Dicas para Histogramas

Utilize a opo FOR ALL INDEXED COLUMNS. Atualize os histogramas freqentemente se a distribuio dos dados no for esttica. Clusulas WHERE com variveis bind no utilizam histogramas. Variveis sofrem o bind aps a otimizao. No utilize histogramas a no ser que estes aumentem a performance substancialmente. Histogramas requerem espao de armazenamento adicional. Para vrias tabelas, apropriado simplesmente utilizar a clusula FOR ALL INDEXED COLUMNS para coletar estatsticas sobre todas as colunas indexadas. Fique atento, entretanto, que histrogramas tambm so criados sobre colunas com constraints de unique e primary key que so garantidas atravs de ndices, o que pode causar desperdcio de espao. Se a distribuio dos dados no for esttica, o histograma deve ser freqentemente atualizado. Devido ao otimizador no levar em considerao o valor corrente de variveis bind, histogramas no so teis (e portanto no compensam o custo) quando variveis bind forem utilizadas. Histogramas requerem espao de armazenamento adicional, e devem ser utilizados somente quando puderem aumentar substancialmente os planos de consultas.
7-16
Quando Utilizar Histogramas

Utilize histogramas para uma coluna quando os dados forem altamente distribudos atravs dos valores da coluna. Evite utilizar histogramas para uma coluna quando: A coluna no for utilizada na clusula WHERE. A coluna for nica e utilizada somente com predicados de igualdade. Todos os predicados sobre a coluna utilizam variveis bind. Os dados da coluna forem uniformemente distribudos. Histogramas possuem um alto custo de armazenamento; portanto, utilize-os somente quando estes aumentarem a performance substancialmente. Histogramas devem ser utilizados quando os dados possuem um alto grau de distribuio, com alguns valores ocorrendo muito mais freqentemente do que outros.
7-17
Escolhendo um Sample Size

Quando estiver estimando estatsticas com o comando ANALYZE, siga estas diretrizes: Se os dados esto uniformemente distribudos, 5% das linhas so suficientes. Escolha um sample size maior se o nmero de valores distintos forem mais do que 10% do nmero de linhas. Quando estiver utilizando histogramas, o nmero de linhas de amostra deve ser pelo menos 100 vezes o nmero de entradas. Se os dados a serem analisados esto quase sempre uniformemente distribudos, uma amostra de 5% das linhas deve ser adequado. No utilize histogramas neste caso, porque o benefcio ser mnimo. Se o nmero de valores distintos for grande, por exemplo, mais do que 10% do nmero de linhas, ento um percentual de amostra maior pode ser necessrio. Se voc decidir criar histogramas, o nmero de linhas de amostra deve ser pelo menos 100 vezes o nmero de entradas no histograma. Em outras palavras, o nmero mdio de linhas de amostra por entrada deve ser pelo menos 100. No faz muito sentido combinar um histograma muito detalhado com um sample size mnimo.
7-18
Escolhendo o Nmero de Entradas

Inicie com o tamanho default de 75 entradas. Experimente com tamanhos diferentes, para obter melhores resultados. Configure um nmero de entradas maior do que o nmero de valores distintos que ocorrem freqentemente, se estes forem relativamente poucos. O nmero default de entradas 75. Esta valor fornece um nvel apropriado de detalhes para a maioria das distribuies de dados. Entretanto, devido ao nmero de entradas no histograma, a taxa de amostra, e a distribuio dos dados afetarem a utilizao de um histograma, voc pode ter de experimentar diferentes nmeros de entradas para obter os melhores resultados. Se o nmero de valores distintos que ocorrem freqentemente em uma coluna forem relativamente poucos, ento voc deve configurar o nmero de entradas para um valor maior do que este nmero de valores distintos.
7-19
Visualizando Estatsticas de Histogramas

Informaes de histogramas: Vises USER/ALL/DBA_HISTOGRAMS Nmero de entradas em cada histograma: Vises USER/ALL/DBA_TAB_COL_STATISTICS
SQL> 2 3 4 5
select from where and and
* dba_histograms table_name = 'CLASSES' column_name = 'CLASS_ID' owner = user;
ENDPOINT_NUMBER ENDPOINT_VALUE --------------- -------------0 50008 1 55198 2 56718 3 63037 ... ... 74 146296 75 155801
7-20
Exerccios
1. Calcule as estatsticas para a tabela REGISTRATIONS e visualize as estatsticas de tabela e coluna com comandos select apropriados. 2. Porque a coluna STATUS da tabela REGISTRATIONS uma boa candidata para a criao de um histograma?
Dica: recupere os valores distintos da coluna STATUS e sua cardinalidade.

3. Crie um histograma para a coluna STATUS com 20 entradas e visualize as estatsticas do histograma. 4. Calcule a seletividade do seguinte comando select, antes e aps criar o histograma:
SQL> select * from registrations 2 where status = 'CANC';

5. Identifique a data do ltimo analyze e o sample size utilizado para todas as tabelas em seu schema. 6. Remova as estatsticas para a tabela REGISTRATIONS e verifique o dicionrio de dados novamente.
7-21
8. Influenciando o Otimizador
Influenciando o Otimizador
Objetivos
Influenciar o comportamento do otimizador: A nvel de instncia e sesso. A nvel de comando SQL, utilizando hints. Especificar hints de caminhos de acesso. Especificar hints sobre e em vises.
8-2
Configurando o Modo de Otimizao

A nvel de instncia, configure o seguinte parmetro:
OPTIMIZER_MODE = {CHOOSE|RULE|FIRST_ROWS|ALL_ROWS}
Para uma sesso, utilize o seguinte comando SQL:
SQL> ALTER SESSION SET OPTIMIZER_MODE = {CHOOSE|RULE|FIRST_ROWS|ALL_ROWS}

Como discutido anteriormente, o Oracle9i possui quatro modos de otimizao bsicos: CHOOSE RULE baseado em custo quando estatsticas estiverem disponveis; baseado em regra quando no estiverem presente. fora otimizao baseada em regra mesmo na presena de estatsticas.
FIRST_ROWS otimiza o tempo de resposta at o primeiro resultado ser retornado (por exemplo, para aplicaes OLTP interativas). ALL_ROWS otimiza o tempo global de execuo (por exemplo, para relatrio e trabalhos batch).
Nveis do Modo do Otimizador

A nvel de instncia, o modo do otimizador pode ser configurado utilizando-se o parmetro de inicializao OPTIMIZER_MODE. Quando este parmetro no estiver configurado, o default ser CHOOSE. A nvel de sesso, o modo de otimizao configurado a nvel de instncia pode ser sobreposto utilizando-se o comando ALTER SESSION. Este captulo explica como sobrepor o modo de otimizao a nvel de comando utilizando-se hints.
Nota: quando estatsticas no estiverem presentes e a otimizao baseada em custo for forada, o otimizador utiliza valores built-in defaults ao invs das estatsticas. Isto pode produzir planos de execuo sub-otimizados.
8-3
Alguns Parmetros Adicionais do Otimizador

FAST_FULL_SCAN_ENABLED COMPLEX_VIEW_MERGING OTMIZER_FEATURES_ENABLE Default 8.0.0. Configure para a release corrente para habilitar novas caractersticas do otimizador. FAST_FULL_SCAN_ENABLED habilitam operaes de fast full index scans, uma alternativa til para full table scans. Fast full scans requerem um ndice contendo todas as colunas que so necessrias para a consulta. Alm disso, pelo menos uma das colunas deve ser NOT NULL. Este um parmetro boleano que no pode ser modificado sem reiniciar a instncia. COMPLEX_VIEW_MERGING faz com que vises complexas ou subconsultas sejam combinadas. Quando configurado para FALSE, este parmetro faz com que vises complexas ou subconsultas sejam avaliadas antes da consulta que as est referenciando. Este um parmetro boleano dinmico que pode ser configurado com o comando ALTER SESSION. OPTIMIZER_FEATURES_ENABLE permite a voc modificar um conjunto de parmetros de inicializao que controlam o comportamento do otimizador. O valor 8.0.4 configura-o para TRUE. Este um parmetro esttico. Entretanto, indiferentemente da sua configurao, voc pode alterar cada um dos parmetros afetados individualmente.
8-4
Sintaxe de Hints para o Otimizador
Coloque hints dentro de comentrios de um comando SQL. Voc pode utilizar qualquer um dos estilos de comentrios. O delimitador de hint (+) deve vir imediatamente aps o delimitador de comentrio. Se voc separ-los por um espao, o Oracle no reconhecer o comentrio como hint. Por exemplo, o seguinte hint fora as tabelas da clusula FROM a sofrerem o join da esquerda para a direita:
select /*+ORDERED */ ... select /*+ ORDERED */ ...

A seguinte tentativa tratada como um comentrio normal devido ao espao entre o * e +:
select /* +ORDERED */ ...

O servidor Oracle9i ignora hints especificados incorretamente. Entretanto, esteja atento que: Um erro no retornado. Considera hints corretamente especificados dentro do mesmo comentrio. Ignora combinaes de hints conflitantes, mas considera outros hints dentro do mesmo comentrio.
8-5
Regras para Hints

Um hint colocado imediatamente aps a keyword de SQL (SELECT, INSERT, UPDATE, DELETE). Cada bloco de comando SQL pode ter somente um comentrio de hints, mas pode conter mltiplos hints. Hints aplicam-se somente ao bloco de comando no qual aparecem. Se um comando SQL utilizar um alias, hints devem referenciar o alias ao invs do nome da tabela. Voc deve colocar o comentrio de hint imediatamente aps a primeira keyword (SELECT, INSERT, UPDATE ou DELETE) de um bloco de comando SQL. Um bloco de comando pode ter somente um comentrio contendo hints, mas pode conter vrios hints dentro deste comentrio. Hints aplicam-se somente ao bloco de comando no qual aparecem e sobrescrevem parmetros a nvel de instncia ou sesso. Um bloco de comando : Um simples comando SELECT, INSERT, UPDATE ou DELETE. Um comando de nvel superior ou uma subconsulta de um comando complexo. Uma parte de uma consulta composta utilizando operadores de conjunto (UNION, MINUS, INTERSECT). Se um comando SQL utilizar um alias, ento os hints devem refernciar o alias ao invs do nome da tabela.
Nota: metas de otimizao configuradas a nvel de sesso com o comando ALTER SESSION aplicam-se somente a comandos enviados diretamente, no afetando SQLs que executem dentro do PL/SQL. Utilize hints para influenciar o otimizador baseado em custo para quaisquer comandos SQL enviados de dentro do PL/SQL.
8-6
Recomendaes de Hints
Utilize hints como ltima soluo, porque implicam em alta carga de manuteno. Esteja atento com o impacto de performance de hints codificados quando estes se tornarem menos vlidos. Hints podem tornar-se menos vlidos (ou mesmo invlidos) quando a estrutura do banco de dados ou seu contedo modificarem-se.
8-7
Exemplo de Hints de Otimizao

SQL> 2 3 4 5 6 7 8 9 10 update --+ index(e job_idx) employees e set e.salary = (select --+ index(m mgr_idx) (e.salary + m.salary)/2 from employees m where m.emp_id = e.mgr_id ) where e.job = 'INSTRUCTOR' and e.hiredate > to_date('01/01/1998' ,'dd/mm/yyyy');
Este um exemplo com hints que avisam o otimizador baseado em custo para utilizar ndices.
8-8
Categorias de Hints
Hints para o modo de otimizao: RULE, CHOOSE. ALL_ROWS, FIRST_ROWS. Hints para mtodos de caminhos de acesso. Hints para execuo em paralelo. Hints para operaes e ordem de joins. Parmetros para modificar o modo de otimizao a nvel de instncia ou sesso (RULE, CHOOSE, ALL_ROWS, FIRST_ROWS) foram discutidos anteriormente, e voc pode utilizar estes quatro valores como um hint a nvel de comando. Os demais tipos de hints sero discutidos neste captulo ou posteriormente.
8-9
Hints de Caminhos de Acesso Bsicos

FULL ROWID INDEX INDEX_ASC INDEX_DESC AND_EQUAL INDEX_FFS Efetua um full table scan Acessa uma tabela pelo ROWID Efetua um scan em um ndice em ordem ascendente Efetua um scan em um ndice em ordem ascendente Efetua um scan em um ndice em ordem descendente Efetua um merge de ndices de uma nica coluna Efetua um fast full index scan seleciona um full table scan. seleciona um table scan pelo ROWID. seleciona um index scan (ascendente). seleciona um index scan ascendente.
Descrio dos Hints

FULL(tabela) ROWID(table) INDEX(tabela [ndice]...) INDEX_ASC(tabela [ndice]...)
INDEX_DESC(tabela [ndice]...) seleciona um index scan descendente (este hint no possui efeito quando se estiver acessando mltiplas tabelas; estes comandos sempre efetuam range scans ascendentes). AND_EQUAL (table ndice ndice [ndice]...) seleciona um plano de execuo que utiliza um caminho de acesso que efetua um merge de scans sobre vrios ndices do tipo single-column (no mnimo 2 e no mximo 5). faz com que ocorra um fast full index scan.
INDEX_FFS(table [ndice]...)
Especificando Nomes de ndices

Um hint de ndice pode opcionalmente especificar um ou mais nomes de ndices. Se este hint especificar um nico ndice disponvel, o otimizador efetua um scan neste ndice. O otimizador no considera um full table scan ou um scan em outro ndice da tabela. Se este hint especificar uma lista de ndices disponveis, o otimizador considera o custo de um scan em cada ndice da lista e ento efetua um index scan no de menor custo. O otimizador pode tambm decidir efetuar mltiplos index scan a partir da lista efetuando o merge dos resultados, se tal caminho de acesso possuir o menor custo. O otimizador no considera um full table scan ou um scan em um ndice que no est listado no hint. Se este hint no especificar ndices, o otimizador considera o custo de um scan em cada ndice disponvel da tabela e ento efetua um index scan no de menor custo. O otimizador pode tambm decidir efetuar mltiplos index scan efetuando o merge dos resultados, se tal caminho de acesso possuir o menor custo. O otimizador no considera um full table scan.
Fast Full Index Scans

Fast full index scans so uma alternativa para full table scans quando o ndice contm todas as colunas que so necessrias para a consulta. No pode ser utilizado para eliminar uma operao de sort. Efetua a leitura de todo o ndice utilizando leituras multibloco (como em um full table scan).
8-10
Hints de Caminhos de Acesso Avanados

CLUSTER HASH HASH_AJ MERGE_AJ MERGE_SJ USE_CONCAT Efetua um cluster scan Efetua um hash scan Transforma uma subconsulta NOT IN em um hash anti-join Transforma uma subconsulta NOT IN em um merge anti-join Transforma uma subconsulta correlacionada EXISTS em um merge semi-join Reescreve OR em UNION ALL seleciona um cluster scan (aplica-se somente a index clusters). seleciona um hash scan (aplica-se somente a hash clusters). transforma uma subconsulta NOT IN em um hash anti-join.
Descrio dos Hints

CLUSTER(table) HASH(table) HASH_AJ(table)
MERGE_AJ(table) transforma uma subconsulta NOT IN em um merge anti-join. MERGE_SJ(table) transforma um subconsulta correlacionada EXISTS em um merge semi-join. USE_CONCAT reescreve OR em um UNION ALL; desliga o processamento da lista IN e OR, expandindo todas as disjunes.
Anti-Joins e Semi-Joins
Estas duas tcnicas para modificar comandos de sunconsultas em joins sero tratadas posteriormente neste curso.
8-11
Hints Adicionais
CACHE NOCACHE Coloca os blocos no final da MRU da lista LRU (full table scan) Coloca os blocos no final da LRU da lista LRU (full table scans)
O hint CACHE especifica que os blocos recuperados a partir desta tabela sero colocados no final da most recently used (MRU) da lista least recently used (LRU) no buffer cache quando um full table scan for executado. Esta opo til para pequenas tabelas lookup. O parmetro CACHE_SIZE_THRESHOLD determina o que considerado uma tabela pequena neste contexto. O hint NOCACHE especifica que os blocos recuperados para esta tabela sero colocados no final da lista least recently used (LRU) no buffer cache quando um full table scan for executado. Este o comportamento normal dos blocos no buffer cache quando full table scans so efetuados.
8-12
Hints e Vises
A Oracle no recomenda a utilizao de hints em vises. Tcnicas de otimizao de vises: Transformao do comando. Acessar os resultados da viso como uma tabela. Hints e vises combinveis (mergeable). Hints e vises no combinveis (nonmergeable). A Oracle no recomenda o uso de hints dentro ou em vises. Isto porque vises podem ser definidas em um contexto e utilizadas em outro; tais hints podem resultar em planos inesperados. Em especfico, hints dentro de vises ou em vises so tratados diferentemente dependendo se a viso for ou no mergeable com a consulta de nvel superior.
Otimizao de Vises
Para otimizar um comando que acessa uma viso, o otimizador possui duas alternativas. Normalmente o comando transformado em um comando equivalente que acesssa as tabelas base da viso. O otimizador pode utilizar uma das seguintes tcnicas para transformar o comando. Combinar a consulta da viso com o bloco da consulta que a est referenciando no comando de acesso. Colocar o predicado do bloco da consulta que est referenciando a viso dentro dela. Quando estas transformaes so impossveis, a consulta da viso executada e o resultado acessado como se fosse uma tabela.
Vises Combinveis (Mergeable)

O otimizador pode combinar uma viso com o bloco da consulta que a est referencianddo, contanto que a viso no contenha: Operadores de conjunto (UNION, UNION ALL, INTERSECT, MINUS). Uma clusula CONNECT BY. A pseudocoluna ROWNUM. Funes de grupo (AVG, COUNT, MAX, MIN, SUM) na lista select.
Hints e Vises Combinveis (Mergeable)

O mtodo de otimizao e hints podem aparecer na consulta principal ou dentro de vises. Se existir tal hint na consulta principal, este hint ser utilizado indiferentemente de quaisquer outros hints dentro de vises. Se no existir hint de modo de otimizao na consulta principal, ento hints de modo de otimizao em vises referenciadas so utilizados contanto que todos os hints de modo nas vises esteja consistente. Se dois ou mais hints de modo nas vises referenciadas conflitarem, ento todos os hints de modo nas vises so descartados e o modo de sesso utilizado. Hints de mtodo de acesso e join nas vises referenciadas so ignorados a menos que a viso contenha apenas uma tabela (ou referencie outra viso com uma nica tabela). Para tais vises do tipo single-table, um hint de mtodo de acesso ou um hint de join na viso aplica-se a tabela dentro da viso.
8-13
Hints de mtodo de acesso e join podem tambm aparecer em uma definio de viso. Se a viso for uma subconsulta (ou seja, se aparecer na clusula FROM de um comando SELECT), ento todos os hints de mtodo de acesso e join dentro da viso so preservados quando a viso combinada com a consulta principal. Para vises que no so subconsultas, hints de mtodo de acesso e join na viso so preservados somente se a consulta principal no referenciar outras tabelas ou vises (ou seja, se a clusula FROM do comando SELECT contiver somente a viso).
Hints e Vises no Combinveis (Nonmergeable)

Com vises no combinveis, hints de otimizao de modo dentro da viso so ignorados. A consulta principal decide o modo de otimizao. Uma vez que vises no combinveis so otimizadas separadamente da consulta principal, hints de mtodo de acesso e join dentro da viso so sempre preservados. Pela mesma razo, hints de mtodo de acesso na viso na consulta principal so ignorados. Entratanto, hints de join na viso na consulta principal so preservados porque neste caso, a viso no combinvel similar a uma tabela.
8-14
Hints de Processamento de Vises

MERGE Avalia vises complexas ou subconsultas antes da consulta mais prxima NO_MERGE No efetua o merge de vises Quando o parmetro COMPLEX_VIEW_MERGING estiver configurado para FALSE, faz com que vises complexas ou subconsultas sejam avaliadas antes da consulta mais prxima. Neste caso, voc pode fazer com que uma viso sofra um merge em uma base por consulta utilizando o hint MERGE. O hint NO_MERGE faz com que o servidor Oracle9i no efetue o mege de vises combinveis. Quando COMPLEX_VIEW_MERGING estiver configurado para TRUE, voc pode utilizar o hint NO_MERGE dentro da viso para evitar que uma consulta especfica sofra um merge. Quando estiver utilizando o hint NO_MERGE sem um argumeto, voc deve colocar o hint no bloco da consulta da viso. Quando NO_MERGE for utilizado com o nome da viso como um argumento, coloque o hint na consulta mais prxima.
Exemplo: SQL> 2 3 4 5 6 7 8 9 select /*+ MERGE(v) */ c.class_id, c.crs_id, v.no_att from classes c , (select r.class_id , count(r.stud_id) as no_att from registrations r group by r.class_id ) v where c.class_id = v.class_id and c.days = 4;
8-15
9. ndices Avanados
ndices Avanados
Objetivos
Criar ndices bitmap. Identificar operaes com ndices bitmap. Especificar hins de ndices bitmap. Visualizar informaes do dicionrio de dados.
9-2
ndices Avanados
ndices Bitmap
ndices bitmap so rpidos e utilizam menos espao para colunas com baixa cardinalidade. Cada ndice bitmap composto de partes de armazenamento chamadas de bitmaps. Cada bitmap contm informaes sobre um valor especfico para cada uma das colunas indexadas. A indexao bitmap fornece tanto melhorias substanciais de performance quanto economia de espao sobre ndices normais (b-tree) onde existirem poucos valores distintos nas colunas indexadas. Se o nmero de chaves distintas em uma coluna for menor ou igual a 1% do nmero total de linhas para uma tabela, ento a coluna possui baixa cardinalidade. Por exemplo, em uma tabela com 10.000 linhas, se existir menos de 100 valores diferentes em uma determinada coluna, ento esta coluna possui baixa cardinalidade e um ndice bitmap pode fornecer a melhor performance para consultas baseadas nesta coluna. O nmero mximo de colunas em um nico ndice bitmap 30.
Nota: otimizao baseada em regra no considera a utilizao de ndices bitmap.
9-3
ndices Avanados
Estrutura de ndices Bitmap

Cada posio em um bitmap armazena informao sobre uma linha em particular.
Qualquer tipo de ndice designado a auxiliar a pesquisa de linhas que contenham certos valores de chave. Um ndice normal (b-tree) efetua isto juntando o ROWID de uma linha com seu valor de chave, e ento ordenando estes pares em uma estrutura b-tree. O ROWID serve como um ponteiro para um linha com aquele valor. Um ndice bitmap possui uma estrutura bastante diferente; ROWIDs no so armazenados. Devido a cada valor de chave possuir seu prprio bitmap, devem ser utilizados somente quando existirem poucos valores distintos na coluna ou colunas indexadas pelo bitmap. Cada header de bitmap armazena os ROWIDs iniciais e finais. Baseado nestes valores, o servidor Oracle9i utiliza um algortmo interno para mapear bitmaps em ROWIDs. Cada posio em um bitmap aponta para uma linha em potencial na tabela. O contedo desta posio no bitmap para um valor especfico indica se esta linha possui este valor nas colunas do bitmap. O valore armazenado 1 se os valores da linha correspondem a condio do bitmap e 0 caso contrrio. O servidor Oracle9i comprime o armazenamento do bitmap, tornando ndices bitmap muito eficientes em termos de armazenamento. Os bitmaps so armazenados em uma estrutura b-tree internamente para maximizar a performance de acesso.
9-4
ndices Avanados
Criando ndices Bitmap

SQL> create BITMAP index reg_status_bidx 2 on registrations(status);
Para criar um ndice bitmap, simplesmente utilize o comando CREATE INDEX e adicione a keyword BITMAP. O servidor Oracle9i ento cria uma srie de bitmaps, cada um correspondendo a um valor especfico das colunas envolvidas. No exemplo, se a colunas STATUS posssui cinco valores distintos, ento cinco bitmaps sero construdos. Se outro valor de status for adicionado posteriormente, um novo bitmap para este valor dever ser criado. No bitmap para status=CANC, a primeira posio contm o valor 1, mostrando que a primeira linha possui este valor de status. No bitmap para status=REGI, a primeira posio contm 0 porque a primeira linha no possui este valor. Cada linha aponta para uma posio nos bitmaps, e a linha correspondendo sua condio ir conter o valor 1 naquela posio. Se um ndice bitmap envolver mais de uma coluna, ento haver um bitmap para cada combinao possvel. Por exemplo, haveria um bitmap para status=REGI e attended=N e um diferente para status=REGI e attended=Y.
Nota: ndices bitmap no podem ser declarados como unique (ndices b-tree so sempre mais apropriados em tais casos), e nem podem utilizar-se da opo NOSORT durante sua criao.
9-5
ndices Avanados
Utilizando ndices Bitmap para Consultas

SQL> select * from registrations 2 where status = 'PEND';
Uma consulta que inclua uma condio WHERE envolvendo uma coluna mapeada pelo bitmap pode utilizar o ndice bitmap. Esta consulta simplesmente efetua o scan do bitmap para status=PEND por posies com um valor 1 nelas. Posies com 1 tero suas linhas correspondentes retornadas para a consulta. Em alguns casos, como uma consulta contando o nmero de linhas com status=PEND, a consulta pode simplesmente utilizar o bitmap e contar o nmero de 1, no necessitando das linhas atuais.
9-6
ndices Avanados
Combinando ndices Bitmap

ndices bitmap so muito eficientes: Quando utilizando IN (value_list). Quando predicados so combinados com AND/OR Isto baseado em operaes rpidas de bit-and e bit-or.
Voc pode utilizar ndices bitmap eficientemente quando um consulta combinar vrios valores possveis para um coluna ou duas colunas separadas de ndices so utilizadas.
Consultas Combinando Mltiplos Valores para um Coluna

Em alguns casos, uma clusula WHERE pode permitir vrios valores diferentes para uma coluna.
SQL> select * from registrations 2 where status in ('PEND','WAIT');

Neste caso, os bitmaps tanto para status=PEND quanto status=WAIT foram utilizados. Para cada posio, se qualquer um dos bitmaps possuir o valor 1 naquela posio, ento a linha retornada. Uma operao de bit-or executada primeiro, seguida por uma traduo em ROWIDs.
Consultas Combinando Dois ndices Bitmap Diferentes

Em alguns casos, uma clusula WHERE pode referenciar vrias colunas de ndices separados.
SQL> select * from registrations 2 where status = 'REGI' 3 and attended = 'N';
Se ambas as colunas STATUS e ATTENDED possurem ndices bitmap, uma operao bit-and sobre os dois ndices ir localizar rapidamente as linhas que esto sendo procuradas. Quanto mais complexa for a composio que a clusula WHERE adquirir, mais voc ser beneficiado com a indexao bitmap.
9-7
ndices Avanados
Quando Utilizar ndices Bitmap

Colunas com baixa cardinalidade. Colunas que so freqentemente referenciadas em: Condies da clusula WHERE complexas. Funes de agregao (COUNT, SUM, ...). Tabelas muito grandes. Ambientes DSS, com muitas consultas e poucas modificaes concorrentes para os dados. Utilize ndices bitmap nas seguintes circunstncias: A coluna possui uma baixa cardinalidade, significando que existem poucos valores possveis para a coluna. Uma cardinalidade ligeiramente maior tambm seria apropriada se a coluna freqentemente utilizada em condies complexas nas clusulas WHERE de consultas. As clusulas WHERE de consultas contm mltiplos predicados destas colunas de baixa ou mdia cardinalidade. ndices bitmap so especialmente teis para consultas complexas com clusulas WHERE longas ou consultas agregadas (contendo SUM, COUNT ou outras funes de agregao). A tabela possui muitas linhas. Uma tabela com 1 milho de linhas, mesmo com 10,000 valores distintos possveis seria aceitvel. O ambiente orientado para data warehousing (sistemas de suporte a deciso). ndices bitmap no so ideais para sistemas de processamento online de transaes (OLTP) devido ao seu comportamento de lock. No possvel bloquear uma nica posio do bitmap. A menor quantidade de um bitmap que pode ser bloqueada um segment de bitmap, o qual pode ter um tamanho de at metade de um bloco de dados. Modificar o valor de uma linha resulta no bloqueio (lock) de um segmento bitmap, de fato bloqueando modificaes em vrias linhas. Isto uma grande desvantagem quando existem muitos comandos UPDATE, INSERT ou DELETE sendo disparados pelos usurios. Isto no um problema quando os dados so inseridos ou atualizados em operaes de carga, como em ambientes de data warehousing.
9-8
ndices Avanados
Vantagens de ndices Bitmap

Quando utilizados apropriadamente, ndices bitmap fornecem: Tempo de resposta reduzido para diversas consultas. O otimizador baseado em custo capaz de considerar a utilizao de ndices bitmap e decidir quando sua utilizao ser o caminho mais eficiente para executar uma determinada consulta, incorporando paralelismo, se apropriado. Reduo substancial de utilizao de espao comparado com outras tcnicas de indexao. Se somente ndices normais (b-tree) forem utilizados, ento o designer de ndice deve predizer quais colunas devem ser utilizadas juntas e criar um ndice multicoluna (concatenado) para estas colunas. Este ndice normal necessitar de uma grande quantidade de espao e ser ordenado, tornando-o intil para muitas consultas que envolvam somente um subconjunto de colunas. O designer de ndice pode tambm criar ndices sobre as outras permutaes destas colunas; isto utilizaria muito espao de armazenamento. ndices bitmap entretanto, podem ser criados individualmente e ento combinados eficientemente em tempo de execuo. Se a coluna a ser indexada coluna de chave nica, ento o espao necessrio para ndices bitmap ir exceder ao do ndice b-tree. Utilize ndices bitmap somente em colunas com baixa ou mdia cardinalidade. Ganhos drsticos de performance, mesmo em hardwares de baixo nvel. Voc no necessita paralelizar o processamento para obter ganhos de performance com ndices bitmap.
9-9
ndices Avanados
Dicas sobre ndices Bitmap

Reduza as necessidades de armazenamento de ndices bitmap: Declarando colunas NOT NULL quando possvel. Utilizando tipos de dados de tamanho fixo quando possvel. Melhore a performance de bitmaps aumentando os seguintes parmetros: CREATE_BITMAP_AREA_SIZE BITMAP_MERGE_AREA_SIZE Simule operaes bitmap em ndices b-tree com o parmetro B_TREE_BITMAP_PLANS. Voc pode efetuar vrias coisas para melhorar a performance e o armazenamento de ndices bitmaps: Declarando constraints de NOT NULL em todas as colunas possveis reduz as necessidades de armazenamento por no requerer um bitmap para o valor NULO. Tipos de dados de tamanho fixo so mais amenos para uma representao compacta de um bitmap. O parmetro CREATE_BITMAP_AREA_SIZE determina a quantidade de memria alocada para a criao de bitmaps. O valor default 8Mb, o qual mais do que suficiente na maioria dos casos. Um valor maior pode resultar em grandes bitmaps contnuos e desta forma acelerar o processamento de consultas. O parmetro SORT_AREA_SIZE tambm influencia performance de criao de bitmaps. Aumentando o parmetro de inicializao BITMAP_MERGE_AREA_SIZE aumenta a velocidade de range scans do ndice. Este parmetro determina a quantidade de memria utilizada para efetuar o merge de bitmaps recuperados a partir de um range scan do ndice. O valore default 1Mb.
Nota: o parmetro B_TREE_BITMAP_PLAN permite ao otimizador baseado em custo considerar um caminho de acesso bitmap mesmo quando uma tabela possui somente ndices normais b-tree. Este parmetro pode melhorar a performance de certas consultas, sendo um parmetro boleano dinmico que pode ser configurado com o comando ALTER SESSION.
9-10
ndices Avanados
ndices e Mtodos de Acesso as Linhas

Em um captulo anterior, voc identificou os seguintes mtodos bsicos de acesso as linhas: Acesso de ndice b-tree. Acesso de tabela pelo ROWID. Merge de ndice b-tree. Fast full index scan.
Neste captulo voc ver como influenciar o otimizador baseado em custo especificando hints para ndices bitmaps.
9-11
ndices Avanados
Hints de ndices
INDEX INDEX_ASC INDEX_DESC AND_EQUAL INDEX_COMBINE INDEX_FFS Efetua o scan de um ndice em ordem ascendente Efetua o scan de um ndice em ordem ascendente Efetua o scan de um ndice em ordem descendente Efetua o merge de ndices do tipo single-column Utiliza ndices bitmap Efetua um fast full index scan seleciona um scan de ndice (ascendente) para a tabela especificada. seleciona um scan de ndice ascendente para a tabela especificada. seleciona um scan de ndice descendente para a tabela especificada (este hint no possui efeito quando se estiver acessando mltiplas tabelas; tais comandos sempre efetuam range scans ascendentes). seleciona um plano de execuo que utiliza um caminho de acesso efetuando o merge de scan sobre vrios ndices do tipo single-column (no mnimo 2 e no mximo 5).
A maioria dos seguintes hints foram discutidos em um captulo anterior: INDEX(tabela [ndice]...) INDEX_ASC(tabela [ndice]...) INDEX_DESC(tabela [ndice]...)
AND_EQUAL (tabela ndice ndice [ndice]...)
INDEX_COMBINE(tabela [ndice]...) utiliza uma combinao boleano de ndices bitmap. INDEX_FFS(tabela [ndice]...) causa um full index scan a ser efetuado.
Hint INDEX_COMBINE
Este hint significativo para operaes de ndices bitmap. Lembre-se: Se certos ndices forem fornecidos como argumentos para o hint, o otimizador tenta utilizar algumas combinaes destes ndices bitmap especficos. Se nenhum ndice for nomeado no hint, todos os ndices sero considerados. O otimizador sempre tenta utilizar os ndices especificados no hint, independente de consider-los ou no com custo efetivo.
9-12
ndices Avanados
Exemplo do Hint INDEX_COMBINE

SQL> 2 3 4 5 6 select --+index_combine(classes) * from classes where type = 'IDL' and status <> 'FULL' or loc_id between 30003 and 30005;
Suponha que todas as trs colunas referenciadas no predicado da clusula WHERE do comando acima (type, status e loc_id) possuem um ndice bitmap. Quando voc habilitar o AUTOTRACE, o plano de execuo do comando acima pode aparecer como o apresentado a seguir:
Execution Plan --------------------------------------------------------SELECT STATEMENT Optimizer=CHOOSE TABLE ACCESS (BY INDEX ROWID) OF 'CLASSES' BITMAP CONVERSION (TO ROWIDS) BITMAP OR BITMAP MINUS BITMAP MINUS BITMAP INDEX (SINGLE VALUE) OF 'BI_CL_TYPE' BITMAP INDEX (SINGLE VALUE) OF 'BI_CL_STATUS' BITMAP INDEX (SINGLE VALUE) OF 'BI_CL_STATUS' BITMAP MERGE BITMAP INDEX (RANGE SCAN) OF 'BI_CL_LOC'
No exemplo, as seguintes origens de linha bitmap so utilizadas: BITMAP CONVERSION TO ROWIDS: converte bitmaps em ROWIDs que podem ser utilizados para acessar a tabela. COUNT: retorna o nmero de ROWIDs se os valores atuais no so necessrios. BITMAP OR BITMAP MINUS BITMAP INDEX calcula o bit-wise OR de dois bitmaps. subtrai os bits de um bitmap de outro (este row source utilizado para predicados de negao). UNIQUE SCAN: investiga o bitmap por um nico valor de chave. RANGE SCAN: recupera bitmaps para um intervalo de valores. efetua o merge de vrios bitmaps resultantes de um range scan em um nico (utilizando o operador bit-wise AND).
BITMAP MERGE
9-13
ndices Avanados
Informaes do Dicionrio de Dados

Utilize a seguinte consulta para visualizar informaes do dicionrio de dados sobre ndices:
SQL> select i.index_name, i.index_type 2 , ic.column_name, i.status 3 from user_indexes i 4 , user_ind_columns ic 5 where i.index_name = ic.index_name 6 and i.table_name='CLASSES'; INDEX_NAME -------------CL_LOC_BIDX CLS_PK CL_INSTR_BIDX CL_CRS_BIDX INDEX_TYPE -----------BITMAP NORMAL BITMAP BITMAP COLUMN_NAME -----------LOC_ID CLASS_ID INSTR_ID CRS_ID STATUS -------VALID VALID VALID VALID
9-14
10.
Workshops
Workshops
Workshop 1: Uma nica Tabela, Um nico Predicado

Objetivos do Workshop
Aprender a efetuar a leitura de planos de execuo SQL. Entender os mtodos de acesso de dados mais comuns. Identificar quando ndices so utilizveis ou no. Aprender a utilizar o SQL*Plus AUTOTRACE.
Introduo
Neste primeiro workshop, voc ainda no vai investigar se o uso de ndices esta sendo apropriado ou no; portanto voc no deve considerar estatsticas ou tempos neste workshop. Voc deve somente investigar quando um ndice utilizvel, e aprender a ler planos de execuo SQL. Este workshop pode ser feito totalmente no ambiente do SQL*Plus.
Referncia de Scripts
Nome do Script utlxplan.sql rule.sql choose.sql w1stats.sql li.sql ci.sql Descrio Cria a tabela plan_table, utilizada pelo EXPLAIN e AUTOTRACE alter session set optimizer_goal = rule alter session set optimizer_goal = choose Script a ser executado antes de voc iniciar este workshop Lista todos os ndices; recebe o nome da tabela como um argumento; wildcards (%, _) em nomes de tabelas so permitidos Cria um ndice; solicita o nome da tabela e os nomes das colunas que devem deve ser separados por vrgulas; o nome do ndice gerado pelo script Cria um ndice nico; mesmo comportamento do ci.sql set autotrace on set autotrace on explain set autotrace traceonly set autotrace traceonly explain set autotrace off
cui.sql aton.sql atonx.sql atto.sql attox.sql atoff.sql
1. Execute o script w1stats para garantir que voc no possui quaisquer estatsticas sobre as tabelas utilizadas neste workshop. Ento verifique a existncia e a estrutura das colunas da tabela EMPLOYEES, e execute o script utlxplan.sql para criar a tabela plan_table no seu schema. Alm disso, liste os ndices existentes sobre a tabela EMPLOYEES utilizando o script li.sql.
SQL> SQL> SQL> SQL>
@w1stats describe employees @utlxplan @li employees
2. Utilize o script attox.sql para habilitar AUTOTRACE TRACEONLY EXPLAIN para suprimir o resultado do comando e produzir planos de execuo; verifique a configurao com SHOW AUTOTRACE.
On Targget Treinamento e Consultoria A-2
Workshops
3. Recupere e execute as consultas q101, q102 e q103.
SQL> SQL> SQL> SQL> SQL> SQL>
get q101 / get q102 / get 103 /
Os resultados destas trs consultas mostram que o otimizador do Oracle9i capaz de utilizar ndices para trs tipos de condies: Pesquisa de igualdade (q101). Intervalo ilimitado (q102). Intervalo limitado (q103). 4. Agora crie um ndice sobre a coluna SALARY da tabela EMPLOYEES utilizando o script ci.sql, e inicie as consultas q104 e q105.
SQL> @ci on wich table : employees on wich column(s): salary SQL> @li SQL> get q104 SQL> / SQL> get q105 SQL> /
Os resultados mostram que embora a coluna SALARY esteja indexada, o ndice no pode ser utilizado se a coluna indexada parte de uma expresso na clusula WHERE. Um ndice somente utilizvel se a coluna indexada aparecer limpa na clusula WHERE. Isto uma propriedade muito importante de ndices; antes do Oracle7 esta era a nica forma de influenciar o otimizador do Oracle. 5. Crie outro ndice sobre a coluna LAST_NAME da tabela EMPLOYEES, e inicie as consultas q106 e q107.
SQL> @ci on wich table : employees on wich column(s): last_name SQL> @li SQL> get q106 SQL> / SQL> get q107 SQL> /
Estas duas consultas so logicamente equivalentes, mas novamente voc observa que a coluna indexada deve estar limpa; assim que voc aplicar qualquer funo, a utilizao de ndices torna-se impossvel.
On Targget Treinamento e Consultoria
A-3
Workshops
6. Agora inicie a consulta q108, e compare o plano de execuo com a consulta q107. Como voc pode explicar a diferena?
SQL> get q108 SQL> /

7. Inicie a consulta q109, e observe o padro de pesquisa do LIKE.

Agora voc observa que o ndice inutilizvel, devido ao padro de pesquisa comear com um wildcard. Isto faz sentido: o ndice intil se voc no especificar uma parte inicial para a pesquisa. 8. Inicie a consulta q110, e tente explicar porque o ndice no utilizado: a coluna indexada est limpa, e o padro de pesquisa no inicia com um wildcard.

9. Neste exerccio voc investigar o tratamento de valores NULL, e utilizar a tabela CLASSES para este propsito. Primeiro, crie um ndice sobre a coluna INSTR_ID da tabela CLASSES; esta coluna contm vrios valores NULL. Ento inicie a consulta q111.
SQL> describe classes SQL> @ci on wich table : classes on wich column(s): instr_id SQL> @li classes SQL> get q111 SQL> /
Para explicar porque o ndice no foi utilizado neste caso, voc deve perceber que o Oracle no armazena quaisquer referncias para valores NULL em um ndice. Isto porque a nica maneira de encontrar linhas contendo valores NULL efetuando um full table scan. 10. Agora suponha que voc est interessado em todas as linhas que no contenham um valor NULL; inicie a consulta q112 e compare com a consulta q111.
A-4
Workshops
O ndice no utilizado novamente, mas desta vez por uma razo diferente; a deciso do otimizador est baseada em consideraes de seletividade. Voc pode tentar reescrever o comando SQL, forando otimizao baseada em regra, e iniciar a consulta q113.
SQL> @rule SQL> get q113 SQL> /
O otimizador baseado em regra ir utilizar o ndice agora; para o otimizador baseado em custo dependeria de estatsticas. Sobre quais circunstncias as consultas q112 e q113 so logicamente equivalentes? O melhor mtodo para influenciar o otimizador baseado em custo deve-se especificar um hint; inicie a consulta q114 e compare os resultados com q112.
SQL> @choose SQL> get q114 SQL> /
11. Voc j investigou IS NOT NULL; agora observe as negaes em geral (utilizando <>, != ou NOT). Observe que a distino entre condies normais e negaes somente importante para o otimizador baseado em regra, porque este tem que assumir a seletividade. Devido ao otimizador baseado em custo ser dirigido a estatsticas, este no se preocupa com negaes, embora a maioria das condies com uma negao possuam uma m seletividade.
@li employees @rule get q115 / get q116 /
A consulta q115 mosta que o ndice sobre a coluna SALARY no utilizado (por causa da negao); a consulta q116 mostra que uma negao de uma diferena internamente traduzida em uma formulao positiva da condio. Observe que voc enviou um comando alter session primeiro, para forar a otimizao baseada em regra.
Solues do Workshop
6. A diferena que a consulta q108 seleciona somente a coluna LAST_NAME, de forma que o acesso a tabela no necessrio; esta consulta somente acessa o ndice. Na consulta q107, o acesso a tabela necessrio para recuperar o nmero do empregado. 7. O padro de pesquisa em q110 no inicia com um wildcard, mas o ndice permanece inutilizvel. Isto porque a coluna EMP_ID uma coluna numrica, de forma que o
Workshops
otimizador tem que aplicar uma converso de tipo de dado implicita, e reescrever a clusula WHERE para:
where to_char(emp_id) like '7%'

10. As consultas q112 e q113 so somente logicamente equivalentes (o que significa que sempre retornaram o mesmo resultado indiferentemente do contedo atual do banco de dados) se a coluna INSTR_ID na tabela CLASSES possui uma constraint que somente aceita valores positivos.
A-6
Workshops
Workshop 2: Ordenao, Agregao e Operaes de Conjunto

Objetivos do Workshop
Aprender a efetuar o tuning de sorts para clusulas ORDER BY. Identificar e efetuar o tuning de operaes de sort implcitas causadas por SELECT DISTINCT. Aprender a efetuar o tuning de operaes GROUP BY e funes de grupo. Aprender a efetuar o tuning de operadores de conjunto (UNION, MINUS, INTERSECT).
Introduo
Neste segundo workshop, voc ir se concentrar no tuning de operaes de sort explcitas e implcitas. Ordenao uma operao muito comum. Se o servidor Oracle9i for capaz de realizar toda a atividade de sort em memria, a performance ser provavelmente aceitvel. Entretanto, algumas vezes o servidor Oracle9i tem que escrever resultados intermedirios para disco. Para tanto, o SQL*Plus AUTOTRACE mostra duas estatsticas: sorts (memory) e sorts (disk). Algumas vezes voc pode evitar operaes de sort criando ndices, ou suprimir ordenaes implcitas que no so necessrias para o resultado que voc quer. Voc no pode efetuar o tuning de memria; esta uma tarefa do DBA.
Referncia de Scripts
Nome do Script w2stats.sql li.sql ci.sql Descrio Script a ser executado antes de voc iniciar este workshop Lista todos os ndices; recebe o nome da tabela como um argumento; wildcards (%, _) em nomes de tabelas so permitidos Cria um ndice; solicita o nome da tabela e os nomes das colunas que devem deve ser separados por vrgulas; o nome do ndice gerado pelo script Cria um ndice bitmap; mesmo comportanto de ci.sql Remove todos os ndices; pergunta o nome da tabela set autotrace on set autotrace on explain set autotrace traceonly set autotrace traceonly explain set autotrace off
cbi.sql da.sql aton.sql atonx.sql atto.sql attox.sql atoff.sql
1. Primeiro execute o script w2stats, para garantir um nicio correto do workshop. Ento remova todos os ndices sobre a tabela EMPLOYEES utilizando o script dai.sql. Observe que o ndice relacionado a constraint de chave primria no pode (e no necessita) ser removido.
SQL> @w2stats SQL> @li employees SQL> @da on which table: employees SQL> @li employees
A-7
Workshops
2. Verifique a existncia da tabela plan_table, e utilize o script attox.sql para habilitar AUTOTRACE TRACEONLY EXPLAIN para suprimir o resultado do comando SQL e produzir os planos de execuo; verifique a configurao com SHOW AUTOTRACE.
SQL> describe plan_table SQL> @attox SQL> show autotrace

3. Execute a consulta q201.

Voc observa que o Oracle teve que efetuar uma operao de ordenao. A ordenao pode ser evitada criando-se ndices apropriados. Portanto investigue o que acontece quando criase um ndice sobre a coluna SALARY:
SQL> @ci on which table : employees on which column(s): salary SQL> get q201 SQL> /
4. Execute a consulta q202, e compare os resultados com a consulta q201. Aparentemente o ndice sobre a coluna EMP_ID utilizado: as linhas so recuperadas em ordem acessando as linhas atravs do ndice.
Nota: a presena de estatsticas pode modificar o comportamento do otimizador. Se voc tiver analisado a tabela EMPLOYEES, garanta que as estatsticas sejam removidas ou force a otimizao baseada em regra. SQL> get q202 SQL> /
Porque voc acha que o ndice sobre a coluna SALARY no foi utilizado; qual a diferena entre q201 e q202? 5. Execute a consulta q203. Aparentemente a clusula WHERE no importa; o ndice ainda utilizado para recuperar todas as linhas em ordem, e a clusula WHERE avaliada como um passo posterior.
A-8
Workshops
Investigue o que acontece se voc criar um ndice adicional sobre a coluna JOB.
SQL> @ci on which table : employees on which column(s): job SQL> @li SQL> get q203 SQL> /
Desta vez o otimizador aparentemente prefere utilizar o ndice sobre a coluna JOB, para reduzir o nmero de linhas que devem ser ordenadas. 6. Agora execute as consultas q204, q205 e q206.
get q204 / get q205 / get q206 /
Isto mostra que um ndice pode ser muito til para recuperar um valor mximo (e um valor mnimo tambm). Se nenhum ndice estiver disponvel, o otimizador ter que efetuar um full table scan e efetuar um sort. Observe que na consulta q205 o ndice utilizado, embora a coluna indexada seja parte de uma expresso (salary+1000). Pergunta: Porque a consulta q206 no apresenta o mesmo comportamento? 7. Execute a consulta q207. Uma clusula WHERE foi adicionada, e voc visualizou o resultado. Observe que removendo o ndice sobre a coluna JOB e executando a q207 novamente apresentar um full table scan e um sort. O ndice sobre a coluna SALARY no utilizado.
SQL> SQL> SQL> SQL> SQL>
get q207 / drop index i_employees_job; get q207 /
8. Inicie a consulta q208. Esta consulta mostra que uma operao de sort implcita necessria para avaliar um SELECT DISTINCT.

Tente evitar a utilizao de SELECT DISTINCT quando estiver escrevendo comandos SQL; isto incondicionalmente resulta em uma operao de sort. Portanto porque criar um ndice que no ajudar; ele no ser utilizado. 9. As seguintes consultas investigam os operados de conjunto SQL. Voc ver que estes operadores incondicionalmente resultam em operaes de sort, independente da presena de ndices. Crie quaisquer ndices que voc desejar para investigar isto. Os sorts sero
Workshops
necessrios porque os operadores de conjunto SQL so supostamente filtram linhas duplicadas de resultados.
get q209 / get q210 / get q211 /
Existe uma exceo: o operador UNION ALL no efetua um sort, e no filtra linhas duplicadas. Utilize o operador UNON ALL se voc estiver certo que no existam linhas duplicadas, ou linhas duplicadas no causem problemas de semntica.

10. Agora voc deve examinar o operador GROUP BY. Assim como SELECT DISTINCT e os operadores de conjunto, uma operao de sort sempre ser parte do plano de execuo.
SQL> get SQL> / SQL> @ci on which on which SQL> get SQL> /
q213
table : employees column(s): job q213
Como voc pode visualizar, criando um ndice sobre a coluna JOB no ajuda. Agora examine os seguintes comandos SQL, que so logicamente equivalentes (garanta a supresso do resultado do comando, porque os comandos resultam em um grande nmero de linhas).
SQL> SQL> SQL> SQL> SQL>
@atto get q214 / get q215 /
O ndice sobre a coluna JOB utilizado na consulta q214 para reduzir o conjunto de linhas que necessitam de ordenao. Isto no possvel na consulta q215, porque a clusula HAVING sempre avaliada aps a clusula GROUP BY. Observe que q215 um comando mal formulado; uma clusula HAVING normalmente contm uma funo de grupo, por exemplo: COUNT, SUM, AVG, MIN e MAX.
A-10
Workshops
11. Agora voc deve examinar a funo count. A funo count pode beneficiar-se de ndices bitmap contando o nmero de um dos bitmap, o que uma operao muito eficiente.
SQL> @aton SQL> get q216 SQL> / SQL> @cbi on which table : registrations on which column: attended SQL> get q216 SQL> /
Como voc pode ver, os I/Os reduziram consideravelmente. Se voc tiver algum tempo restante, substitua o ndice bitmap por um ndice normal. Ento voc ver que um ndice normal tambm melhora a performance; entretanto, o ndice bitmap aproximadamente dez vezes mais eficiente. Observe que ndices bitmap so somente considerados pelo CBO, de forma que voc necessita analisar suas tabelas ou forar otimizao baseada em custo.
Solues do Workshop
4. A diferena entre q201 e q202 que a coluna EMP_ID obrigatria (NOT NULL) e a coluna SALARY no; o ndice sobre SALARY no pode garantir que contenha uma entrada para cada empregado, porque valores NULL no so armazenados em ndices normais. 6. Em q206 voc no visualiza o mesmo comportamento que em q205 por razes de semntica. O otimizador sempre deve levar em conta a possibilidade de variveis bind; um plano de execuo deve ser independente do valor que uma varivel bind pode obter aps a otimizao e antes da execuo (lembre-se: PARSE BIND EXECUTE).
max(sal + :x) sempre equivalente a: max(sal) + :x max(sal * :x) no sempre equivalente a: max(sal) * :x
Desta forma o primeiro caso no problema; o ndice pode ser utilizado para recuperar o valor mximo primeiro. Entretanto, se a varivel bind :x obter um valor negativo, a segunda reescrita no ser vlida.
A-11

SQL Tuning 9i PDF

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

SQL Tuning 9i PDF

Caricato da

Copyright:

Formati disponibili

Oracle9i: Tuning de Aplicaes

Oracle9i: Tuning de Aplicaes

Oracle9i: Tuning de Aplicaes Sumrio

1. Seguindo uma Metodologia de Tuning............................................................. 1-1

2. Processamento de Comandos SQL ................................................................... 2-1

3. EXPLAIN e AUTOTRACE............................................................................... 3-1

4. SQL Trace e TKPROF....................................................................................... 4-1

Oracle9i: Tuning de Aplicaes

5. Otimizao Baseada em Regra Versus Otimizao Baseada em Custo........ 5-1

6. ndices e Mtodos de Acesso Bsicos ................................................................ 6-1

7. Coletando Estatsticas ........................................................................................ 7-1

8. Influenciando o Otimizador .............................................................................. 8-1

Oracle9i: Tuning de Aplicaes

9. ndices Avanados .............................................................................................. 9-1

Oracle9i: Tuning de Aplicaes

1. Seguindo uma Metodologia de Tuning

Seguindo uma Metodologia de Tuning

Seguindo uma Metodologia de Tuning

Seguindo uma Metodologia de Tuning

O processo de tuning exige vrios passos:

Inicie no Momento Certo

Efetue o Tuning e Monitore a Conformidade

Trate Excees e Modificaes

Seguindo uma Metodologia de Tuning

Fatores a Serem Gerenciados

Seguindo uma Metodologia de Tuning

Recursos Consumidos Inadequadamente

Recursos de Design Inadequados

Seguindo uma Metodologia de Tuning

Seguindo uma Metodologia de Tuning

Tempo de Resposta Maior

Seguindo uma Metodologia de Tuning

Seguindo uma Metodologia de Tuning

Seguindo uma Metodologia de Tuning

Tuning de Comandos SQL

Seguindo uma Metodologia de Tuning

Oracle9i: Tuning de Aplicaes

2. Processamento de Comandos SQL

Processamento de Comandos SQL

Processamento de Comandos SQL

Processamento de Comandos SQL

Shared SQL Areas

Processamento de Comandos SQL

Fases do Processamento de Comandos SQL

Processamento de Comandos SQL

Processamento de Comandos SQL

Compartilhando Cursores: Benefcios

Processamento de Comandos SQL

Compartilhando Cursores: Requisitos

Processamento de Comandos SQL

Monitorando Cursores Compartilhados

Processamento de Comandos SQL

Processamento de Comandos SQL

Processamento de Comandos SQL

Monitorando o Uso de Cursores Compartilhados

Processamento de Comandos SQL

Escrevendo SQL para Compartilhar Cursores

Variveis Bind e Cursores Compartilhados

Escrevendo SQL para Compartilhar Cursores

Processamento de Comandos SQL

Escrevendo Padres de Formatao

Oracle9i: Tuning de Aplicaes

Criando a Tabela PLAN_TABLE