Академический Документы
Профессиональный Документы
Культура Документы
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
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
10. Workshops.............................................................................................................. 1
Workshop 1: Uma nica Tabela, Um nico Predicado .............................................................. 2 Workshop 2: Ordenao, Agregao e Operaes de Conjunto .................................................. 7
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.
Defina os Objetivos
Defina seus objetivos de uma forma aceita e acordada com todas as partes interessadas.
Trabalhe em Equipe
Administradores de banco de dados, administradores de sistema e programadores devem trabalhar em equipe como um time, no como adversrios.
1-4
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.
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:
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
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
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
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
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
2-7
2-8
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
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
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.
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
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
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
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
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.
3-8
EXPLAIN e AUTOTRACE
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.
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
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
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
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
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
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
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.
4-6
4-7
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
table
4-9
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).
current
rows
4-10
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.
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
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
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
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
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
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
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
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 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
5-6
5-7
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).
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
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
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
5-12
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.
6-4
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
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
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
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.
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
Coletando Estatsticas
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.
7-3
Coletando Estatsticas
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
Coletando Estatsticas
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.
7-5
Coletando Estatsticas
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
Coletando Estatsticas
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.
7-7
Coletando Estatsticas
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
Coletando Estatsticas
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).
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
Coletando Estatsticas
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
7-10
Coletando Estatsticas
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.
Nota: esta frmula assume min <= low <= high <= max.
7-11
Coletando Estatsticas
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
Coletando Estatsticas
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
Coletando Estatsticas
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
Coletando Estatsticas
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).
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
Coletando Estatsticas
7-16
Coletando Estatsticas
7-17
Coletando Estatsticas
7-18
Coletando Estatsticas
7-19
Coletando Estatsticas
SQL> 2 3 4 5
ENDPOINT_NUMBER ENDPOINT_VALUE --------------- -------------0 50008 1 55198 2 56718 3 63037 ... ... 74 146296 75 155801
7-20
Coletando Estatsticas
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?
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
Influenciando o Otimizador
OPTIMIZER_MODE = {CHOOSE|RULE|FIRST_ROWS|ALL_ROWS}
Para uma sesso, utilize o seguinte comando SQL:
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).
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
Influenciando o Otimizador
8-4
Influenciando 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:
8-5
Influenciando o Otimizador
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
Influenciando o Otimizador
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
Influenciando o Otimizador
Este um exemplo com hints que avisam o otimizador baseado em custo para utilizar ndices.
8-8
Influenciando o Otimizador
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
Influenciando o Otimizador
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]...)
Influenciando o Otimizador
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
Influenciando o Otimizador
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
Influenciando o Otimizador
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.
Influenciando o Otimizador
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).
8-14
Influenciando o Otimizador
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.
9-3
ndices Avanados
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
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
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
Voc pode utilizar ndices bitmap eficientemente quando um consulta combinar vrios valores possveis para um coluna ou duas colunas separadas de ndices so utilizadas.
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
9-8
ndices Avanados
9-9
ndices Avanados
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
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]...)
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
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
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
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
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.
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
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.
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> 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.
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.
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.
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
On Targget Treinamento e Consultoria A-5
Workshops
otimizador tem que aplicar uma converso de tipo de dado implicita, e reescrever a clusula WHERE para:
A-6
Workshops
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
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> @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.
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.
8. Inicie a consulta q208. Esta consulta mostra que uma operao de sort implcita necessria para avaliar um SELECT DISTINCT.
Workshops
necessrios porque os operadores de conjunto SQL so supostamente filtram linhas duplicadas de resultados.
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.
SQL> get SQL> / SQL> @ci on which on which SQL> get SQL> /
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).
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