Oracle9i: Tuning de Aplicações. Oracle9i: Tuning de Aplicações

Transcrição

1 Oracle9i: Tuning de Aplicações Oracle9i: Tuning de Aplicações I

2 Oracle9i: Tuning de Aplicações Sumário 1. Seguindo uma Metodologia de Tuning Objetivos Visão Geral Gerenciando a Performance Fatores a Serem Gerenciados Problemas de Performance Recursos Críticos Demanda Excessiva Metodologia de Tuning Responsabilidades do Tuning Tuning de Comandos SQL Aplicando a Metodologia Processamento de Comandos SQL Objetivos Visão Geral Shared SQL Areas Fases do Processamento de Comandos SQL Compartilhando Cursores: Benefícios Compartilhando Cursores: Requisitos Monitorando Cursores Compartilhados V$LIBRARYCACHE V$SQLAREA Monitorando o Uso de Cursores Compartilhados Escrevendo SQL para Compartilhar Cursores EXPLAIN e AUTOTRACE Objetivos Criando a Tabela PLAN_TABLE Comando EXPLAIN PLAN Exemplo de EXPLAIN PLAN Exibindo o Plano de Execução Interpretando o Plano de Execução AUTOTRACE do SQL*Plus Exemplos de AUTOTRACE do SQL*Plus Estatísticas do AUTOTRACE do SQL*Plus Exercícios SQL Trace e TKPROF Objetivos SQL Trace Utilizando o SQL Trace Parâmetros de Inicialização Habilitando o SQL Trace Encontrando seus Arquivos de Trace Formatando os Arquivos de Trace Opções do Comando TKPROF Resultado do Comando TKPROF

3 Oracle9i: Tuning de Aplicações Exemplo do Resultado do TKPROF: Sem Índice Exemplo do Resultado do TKPROF: Índice Único Algumas Armadilhas de Interpretação do TKPROF Exercícios Otimização Baseada em Regra Versus Otimização Baseada em Custo Objetivos Visão Geral Funções do Otimizador do Oracle9i Otimização Baseada em Regra Otimização Baseada em Custo Escolhendo entre RBO e CBO Configurando o Modo do Otimizador Características do RBO Esquema de Ranking do RBO Exemplo de Otimização Baseada em Regra Influenciando a Otimização Baseada em Regra Índices e Métodos de Acesso Básicos Objetivos ROWIDs do Oracle9i Índices Estrutura de Índice B-Tree Índices e Constraints Sintaxe do CREATE INDEX Índices e Foreign Keys Métodos de Acesso Básicos Coletando Estatísticas Objetivos Comando ANALYZE Estatísticas de Tabela Estatísticas de Índice Estatísticas de Coluna Estatísticas de Cluster Seletividade de Predicados Variáveis Bind e Seletividade de Predicados Histogramas Exemplo Comparativo de Histogramas Exemplo de Coleta de Estatísticas para Histogramas Dicas para Histogramas Quando Utilizar Histogramas Escolhendo um Sample Size Escolhendo o Número de Entradas Visualizando Estatísticas de Histogramas Exercícios Influenciando o Otimizador Objetivos Configurando o Modo de Otimização...8-3

4 Oracle9i: Tuning de Aplicações Alguns Parâmetros Adicionais do Otimizador Sintaxe de Hints para o Otimizador Regras para Hints Recomendações de Hints Exemplo de Hints de Otimização Categorias de Hints Hints de Caminhos de Acesso Básicos Hints de Caminhos de Acesso Avançados Hints Adicionais Hints e Visões Hints de Processamento de Visões Índices Avançados Objetivos Índices Bitmap Estrutura de Índices Bitmap Criando Índices Bitmap Utilizando Índices Bitmap para Consultas Combinando Índices Bitmap Quando Utilizar Índices Bitmap Vantagens de Índices Bitmap Dicas sobre Índices Bitmap Índices e Métodos de Acesso as Linhas Hints de Índices Exemplo do Hint INDEX_COMBINE Informações do Dicionário de Dados Workshops... 1 Workshop 1: Uma Única Tabela, Um Único Predicado... 2 Workshop 2: Ordenação, Agregação e Operações de Conjunto... 7

5 Oracle9i: Tuning de Aplicações 1. Seguindo uma Metodologia de Tuning

6 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 são de responsabilidade do desenvolvedor da aplicação. 1-2

7 Seguindo uma Metodologia de Tuning Visão Geral Gerenciamento da performance. Problemas de performance. Metodologia de tuning. Tuning de comandos SQL. Metodologia de aplicação. Qualquer pessoa envolvida em tuning deve seguir uma metodologia de tuning para obter o máximo de performance. Tuning de comandos SQL é um passo importante que custa menos quando efetuado no momento correto dentro da metodologia. Em adição a efetuar o tuning no momento correto, você deve também possuir uma boa compreensão dos detalhes envolvidos no gerenciamento da performance e os tipos de problemas de performance que podem aparecer. 1-3

8 Seguindo uma Metodologia de Tuning Gerenciando a Performance Inicie no momento certo. Defina os objetivos. Efetue o tuning e monitore a conformidade. Trabalhe em equipe. Trate exceções e modificações. O processo de tuning exige vários passos: Inicie no Momento Certo O gerenciamento de performance deve acompanhar a aplicação ou projeto continuamente para ser totalmente efetivo. Você deve começar a considerá-lo no estágio 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 Após 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 nível de conformidade conforme a necessidade. Você deve publicar indicativos de medidas em intervalos regulares, destacando quaisquer divergências ou tendências. Trabalhe em Equipe Administradores de banco de dados, administradores de sistema e programadores devem trabalhar em equipe como um time, não como adversários. Trate Exceções e Modificações Uma vez que o monitoramento efetivo estiver sendo realizado e suportado no mesmo nível da aplicação, você deve reagir prontamente a exceções quando estas forem reportadas. Utilize os dados disponíveis para traçar um curso de ação e então analise a performance resultante para determinar se sua ação foi bem sucedida. Se mudanças globais no uso de padrões ou capacidade de equipamento ocorrerem, então você deve considerar a definição de novos objetivos. 1-4

9 Seguindo uma Metodologia de Tuning Fatores a Serem Gerenciados Schema. Design de dados. Índices. Aplicação Comandos SQL. Código procedural. Instância. Banco de dados. Expectativas do usuário. O gerenciamento de performance pode ser dividido nas quatro áreas seguintes. Embora as áreas estejam separadas, são também independentes e necessitam diferentes qualificações. Schema O tuning do schema trata da estrutura física dos dados. O tuning da aplicação trata das funções de negócio e dos módulos de programa que implementam as funções. Tuning do código procedural para o tipo de aplicação e tuning dos comandos SQL embutidos também estão incluídos neste estágio. O tuning da instância trata da instalação do Oracle9i Server e como a memória será utilizada. O tuning do banco de dados trata do gerenciamento da localização física dos dados no disco. Se uma aplicação possuir um design de dados inadequado ou inapropriado, então efetue o tuning da alocação física, provendo índices ou reescrevendo programas que não superaram o problema. Comandos SQL Se uma aplicação foi bem desenhada, ainda assim pode prover uma performance ruim. Uma razão comum para isto são comandos SQL escritos de forma incorreta. Expectativas do Usuário Usuários esperam uma performance consistente. Eles podem competir com funções de aplicação lentas se entenderem porque a aplicação está demorando mais que o habitual. A equipe do projeto deve colocar esforços em construir uma expectativa de usuário realista em relação a performance, possivelmente incluindo mensagens de aplicação para advertir operadores que eles estão requisitando operações que consumidoras de recursos. O melhor momento para fazer isto é antes das fases de design e construção, e como parte da fase de transição. 1-5

10 Seguindo uma Metodologia de Tuning Problemas de Performance Recursos consumidos inadequadamente. CPU I/O Memória (pode ser detectado como um problema de I/O) Recursos de comunicação de dados Recursos de design inadequados. Bloqueio (locking). Problemas de performance ocorrem quando uma função 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 físico, como buffers de memória disponíveis 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 circunstâncias. Por exemplo, se você deseja que uma função 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 consumível, como poder de CPU, todos os usuários deste recurso são afetados. Recursos de Design Inadequados Se o fator limitante for a contenção de processos para um recurso de design, como um lock, então somente os usuários destes processos específicos serão provavelmente afetados. Bloqueio (locking) Contenção devido a lock por outras transações ou aplicações pode ser um problema. 1-6

11 Seguindo uma Metodologia de Tuning Recursos Críticos A performance depende: Quantos clientes necessitam do recurso. Quanto tempo terão de esperar por ele. Quanto tempo irão segurá-lo. Considere a limitação da demanda para manter tempos de resposta aceitáveis. O tempo de resposta é definido como o tempo de serviço mais o tempo de espera para completar uma determinada tarefa. 1-7

12 Seguindo uma Metodologia de Tuning Demanda Excessiva Grandes aumentos no tempo de resposta. Reduz o troughput. Deve ser evitada sempre que possível limitando a demanda a um nível que mantenha sempre um troughput razoável. 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 usuários 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 utilização do sistema se o efeito for linear. Entretanto, tanto teorias estatísticas quanto experiências mostram que uma vez que o tempo de resposta começa a deteriorar, pequenos aumentos na carga podem causar um efeito grava, o qual é completamente inaceitável para os usuários. Throughput Reduzido Qualquer degradação notável no tempo de resposta é como romper a taxa de trabalho dos usuários afetados. Muitas pessoas não entendem que adicionando mais usuários ao sistema significativamente diminui o throughput geral do sistema. Se o throughput do sistema for importante, você deve garantir que o número de usuários não exceda o limite no qual o throughput começa a diminuir. É melhor limitar o número de usuários mecanicamente. Isto pode forçar uma mudança nos padrões de trabalho para enfrentar a restrição, mas dividindo os períodos de pico através do dia de trabalho pode melhorar em muito a forma como o sistema é utilizado. 1-8

13 Seguindo uma Metodologia de Tuning Metodologia de Tuning 1. Tuning das funções de negócio. 2. Tuning do design de dados. 3. Tuning do design de processos. 4. Tuning de comandos SQL. 5. Tuning de estruturas físicas. 6. Tuning da alocação de memória. 7. Tuning de I/O. 8. Tuning da contenção de memória. 9. Tuning do sistema operacional. A lista acima apresenta as várias fases do ciclo de desenvolvimento nas quais o tuning pode ser aplicado. Seguir os passos nesta ordem é altamente recomendado pelas seguintes razões: 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, modificações para as estruturas de dados e código de aplicação após o design inicial tendem a ser caras e necessitarem de gastos adicionais para retestar os componentes afetados. Decisões feitas em um passo podem influenciar os passos subseqüentes. Por exemplo, o comando SQL que você escreveu no passo 4 pode ter significante influência nos detalhes de parse e cache que são tratados no passo 6. Quanto mais extensivamente você utilizar as técnicas de design orientado a objeto e a arquitetura multi-tier, maior serão as chances de você seguramente conseguir efetuar quaisquer mudanças na aplicação a um custo razoável. 1-9

14 Seguindo uma Metodologia de Tuning Responsabilidades do Tuning Analista de Negócios Designer Desenvolvedor da Aplicação Administrador do Banco de Dados Administrador do Sistema Operacional 1. Tuning das funções de negócio 2. Tuning do design de dados 3. Tuning do design de processos 4. Tuning de comandos SQL 5. Tuning de estruturas físicas 6. Tuning da alocação de memória 7. Tuning de I/O 8. Tuning de contenção de memória 9. Tuning do sistema operacional O analista de negócios, designer, desenvolvedor da aplicação, administrador do banco de dados e administrador do sistema operacional são responsáveis por diferentes passos no processo de tuning. Em alguns casos, uma pessoa pode preencher vários destes papéis. 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 disponíveis e observáveis. O quarto passo da metodologia é principalmente responsabilidade do desenvolvedor da aplicação. Entretanto, o entendimento de como o tuning de SQL é efetuado pode permitir aos designers projetar schemas que serão mais facilmente otimizados. Administrador de banco de dados com esta compreensão serão capazes de ajudar a definir as necessidades e solução do tuning de SQL, desta forma aliviando o fardo de seus bancos de dados. Isto é especialmente útil se a aplicação já estiver em produção e os desenvolvedores não estiverem mais disponíveis. 1-10

15 Seguindo uma Metodologia de Tuning Tuning de Comandos SQL Utilize ferramentas de análise 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 reutilização da otimização de SQL. 4. Projete e otimize comandos SQL. 5. Maximize a performance com o otimizador. Durante os passos dentro do tuning de comandos SQL, técnicas de análise devem ser freqüentemente utilizadas para determinar metas e progresso. 1. Tuning de schema. O designer é responsável por determinar quais tabelas devem ser utilizadas, seus conteúdos e detalhes similares. O desenvolvedor da aplicação pode então necessitar decidir quando utilizar indexação, quando utilizar tabelas index organized e quando utilizar clusterização. Desnormalização pode ser necessária para se obter uma boa performance, especialmente em ambientes de data warehouse. As decisões 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 reutilização do parse de SQL, otimização e esforços de tuning. O Oracle pode freqüentemente reutilizar alguns de seus esforços ao efetuar o parse e a otimização quando identificar comandos idênticos repetidos. Portanto, criando comandos SQL que sejam idênticos pode melhorar a performance. Ele também permite ao desenvolvedor da aplicação focar o tuning de comandos SQL individuais que são repetidamente utilizados. 4. Projetando e otimizando comandos SQL. Existe uma grande variedade de métodos para projetar comandos SQL de alta performance. O conhecimento das funções globais do otimizador ajuda a visualizar onde os esforços de tuning podem ser efetivos.considere reescrever comandos SQL em comandos semanticamente equivalentes. Além disso, utilize a linguagem correta (SQL ou PL/SQL) em cada situação. 5. Obtendo o máximo de performance com o otimizador. Para fazer o melhor uso do otimizador baseado em custo do Oracle, você deve entender como ele escolhe os métodos 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 também está disponível. Ambos os otimizadores serão discutidos no capítulo

16 Seguindo uma Metodologia de Tuning 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: Estabeleça objetivos quantificáveis. Trabalhe a um mínimo de testes repetitivos. Faça perguntas aos usuários afetados e evite preconcepções. Teste hipóteses e mantenha anotações. Pare quando você alcançar o objetivo. Freqüentemente, especialistas em performance são chamados muito tarde no ciclo de vida de um projeto, quando os sistemas estão em produção e a performance ficou inaceitável. Nesta situação, inicie pelo final da lista de métodos de tuning e siga para os passos anteriores. Os itens do final são mais baratos e rápidos para se obter resultados. Se eles não resolverem o problema, você terá que trabalhar os itens mais acima da lista, e isto irá aumentar os custos e os tempos para execução. 1-12

17 Oracle9i: Tuning de Aplicações 2. Processamento de Comandos SQL

18 Processamento de Comandos SQL Objetivos Descrever os passos básicos 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

19 Processamento de Comandos SQL Visão Geral Shared SQL areas. Fases do processamento de SQL. Shared cursors. Padrões de codificação SQL. Conhecendo como funcionam áreas de SQL compartilhadas, as fases de processamento SQL e cursores compartilhados, você pode entender como padrões de codificação permitem a você minimizar a freqüência 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 freqüentemente e dedicar tuning adicional a eles. 2-3

20 Processamento de Comandos SQL Shared SQL Areas A shared pool é parte da System Global Area (SGA), que contém o cache do dicionário e a shared SQL area. A shared SQL area é também conhecida como library cache, embora não 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 algorítmo least recently used (LRU) para determinar o que está mais tempo sem utilização removendo-o quando espaço for requisitado. O administrador do banco de dados (DBA) pode modificar o espaço disponível para o dicionário e shared SQL areas alterando o parâmetro de inicialização SHARED_POOL_SIZE. O DBA pode efetuar isto como parte de um esforço global de tuning do banco de dados. Cursores Dentro da shared SQL area, cada comando SQL é compilado (parsed) em sua própria área, conhecida como context area ou cursor. Cada cursor armazena as seguintes informações: O comando compilado (SQL estático, dinâmico e recursivo, mais unidades de programas como procedures e triggers de banco de dados). O plano de execução. Uma lista de objetos referenciados. Se dois usuários enviarem o mesmo comando SQL, então podem utilizar o mesmo cursor. O comando é recompilado se a representação na shared pool estiver inválida. Isto acontece, por exemplo, se comando da linguagem de definição de dados (DDL) como um ALTER TABLE foi utilizado em um dos objetos que estão referenciados no comando, ou se uma tabela dependente foi analisada. 2-4

21 Processamento de Comandos SQL Fases do Processamento de Comandos SQL As quatro fases mais importantes no processamento de um comando SQL são parse, bind, execute e fetch. As setas indicam os cenários do processamento, por exemplo: Parse Bind FETCH (RE)BIND EXECUTE FETCH A fase FETCH aplica-se somente a consultas. O servidor Oracle9i: Procura pelo comando na shared pool. Verifica a sintaxe do comando, determinando a gramática e especificações da linguagem SQL. Verifica a semântica, garantindo que os objetos referenciados no comando SQL são válidos e satisfazem as regras de segurança. Transforma um consulta sobre uma visão em uma consulta sobre sua definição, e tenta simplificar um comando com uma subconsulta reescrevendo-o em um join. Determina e armazena o plano de execução. O servidor Oracle9i verifica o comando por referências de variáveis bind. O servidor Oracle9i atribui ou reatribui um valor para cada variável. Nota: esta ordem das fases implica que o servidor Oracle9i não conhece os valores das variáveis bind no momento da otimização de um comando. Isto permite uma rápida operação de rebind-execute sem a necessidade de recompilação, desta forma economizando tempo e memória, sendo que a desvantagem é a impossibilidade de o otimizador estimar a seletividade. Execute O servidor Oracle9i aplica a parse tree aos buffers de dados. Múltiplos usuários podem compartilhar a mesma parse tree. O servidor Oracle9i efetua leituras físicas ou leituras/escritas lógicas para comandos DML, e também ordena os dados quando necessário. 2-5

22 Fetch Processamento de Comandos SQL O servidor Oracle9i recupera as linhas para um comando SELECT durante a fase de fetch. Cada fetch normalmente recupera múltiplas linhas, utilizando um array fetch. Cada ferramenta Oracle oferece suas próprias formas de influenciar o tamanho do array. No SQL*Plus você efetuar isto utilizando o parâmetro ARRAYSIZE: SQL> show arraysize SQL> set arraysize 1 Com esta configuração o SQL*Plus irá processar uma linha de cada vez. O valor default é

23 Processamento de Comandos SQL Compartilhando Cursores: Benefícios Quando um comando SQL é encontrado na shared SQL area, então 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 memória ajusta-se dinamicamente ao SQL executado. A utilização de memória pode melhorar dramaticamente, mesmo para ferramentas que armazenam SQL dentro da aplicação. 2-7

24 Processamento de Comandos SQL Compartilhando Cursores: Requisitos Cursores podem ser compartilhados somente por comandos SQL idênticos: O texto dos comandos SQL deve ser exatamente o mesmo, incluindo distinção entre maiúsculas e minúsculas, espaços em branco e comentários. Os objetos referenciados nos comandos SQL devem apontar para os mesmos objetos no banco de dados. Os tipos das variáveis bind utilizadas nos comandos SQL deve ser o mesmo. Nota: antes de enviar comandos SQL para o servidor Oracle9i, a maioria dos utilitários (como PL/SQL, pré-compiladores e o Oracle Developer) pré-processam os comandos SQL para torná-los o mais idênticos possíveis removendo comentários, comprimindo espaços em branco e convertendo para maiúsculas ou minúsculas. O SQL*Plus entretanto, envia comandos SQL para o servidor Oracle9i no mesmo formato que eles foram inseridos. 2-8

25 Processamento de Comandos SQL Monitorando Cursores Compartilhados V$LIBRARYCACHE fornece informações gerais. V$SQLAREA verifica comandos individuais. Quando não existe espaço para compilar um comando na shared SQL area, o cursor mais antigo e seu espaço é reutilizado. Se o comando original for necessário novamente, o servidor terá que recompilá-lo novamente. A shared pool deve ser grande o suficiente para manter o número de comandos que são compilados pelo menos mais de uma vez. Você pode monitorar seus sistema para visualizar com que freqüência o servidor não encontra um comando em memória. Você pode utilizar o Oracle Enterprise Manger, ou o Oracle Server Manager ou consultar as visões apropriadas do dicionário de dados, V$LIBRARYCACHE e V$SQLAREA. 2-9

26 Processamento de Comandos SQL V$LIBRARYCACHE NAMESPACE GETS GETHITS GETHITRATIO PINS PINHITS PINHITRATIO O nome da área da library cache O número de vezes que um lock foi requisitado O número de vezes que um handle de um objeto foi encontrado em memória A proporção de GETHITS em relação aos GETS O número de vezes que um PIN foi requisitado O número de vezes que todos os pedaços do objeto foram encontrados em memória A proporção de PINHITS em relação aos PINS Esta visão armazena informações sobre o gerenciamento da library cache. Os valores para PINHITRATIO e GETHITRATIO próximos de 1 indicam uma boa performance da library cache. A visão 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 Pin Hit Ratio

27 Processamento de Comandos SQL V$SQLAREA SQL_TEXT Texto do comando SQL VERSION_COUNT Número de versões deste cursor LOADS Número de vezes que o cursor foi carregado INVALIDATIONS Número de vezes que o conteúdo foi invalidado PARSE_CALLS Número de vezes que um usuário solicitou o cursor SORTS Número de sorts efetuados pelo comando COMMAND_TYPE Tipo do comando PARSING_USER_ID ID do usuário que efetuou o parse (SYS = 0) A visão V$SQLAREA armazena informações sobre todos os cursores compartilhados no cache. VERSIONT_COUNT > 1 LOADS > 1 COMMAND_TYPE Indica que o mesmo texto é utilizado por diferentes usuários, em sua própria versão de uma tabela. Indica recargas do cursor após o envelhecimento ou invalidação. 2: INSERT 3: SELECT 6: UPDATE 7: DELETE Nota: somente as colunas mais importantes da visão V$SQLAREA estão listadas acima. 2-11

28 Processamento de Comandos SQL Monitorando o Uso de Cursores Compartilhados Um LOAD por comando é o ideal. Um LOAD por versão/invalidação é aceitável. Mais de um LOAD por versão indica um benefício potencial a partir do aumento do tamanho da shared pool. No melhor cenário, deveria haver uma versão de cada comando que nunca é invalidada ou envelhecida. Se o número de loads é significativamente maior que a soma de versões e invalidações, especialmente se o número de loads é similar ao número de chamadas (calls), então os cursores provavelmente estão sendo recarregados devido ao envelhecimento e o sistema pode beneficiar-se do aumento do tamanho da shared pool. SQL> select sql_text, version_count, loads, 2 invalidations, parse_calls, sorts 3 from v$sqlarea 4 where parsing_user_id > 0 5 and command_type = 3 6 order by sql_text; version invali parse sql_text count loads dations calls sorts select * from employees where EMP_ID = select * from employees where emp_id = O comando acima exclui informações sobre SQL recursivo (parsing user SYS) e exibe somente comandos SELECT (command type 3). Existe duas versões do primeiro comando, provavelmente porque eles referenciam dois objetos EMPLOYEES diferentes. Entretanto, cada versão foi carregada somente uma vez. O comando foi enviado três vezes (PARSE_CALLS). Existe somente uma versão 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 gráfica sobre a V$SQLAREA. 2-12

29 Processamento de Comandos SQL Escrevendo SQL para Compartilhar Cursores Se houver diferença entre maiúsculas e minúsculas ou a quantidade de espaço em branco for diferente, então os comandos não são idênticos. SQL> select * from employees where emp_id = 70727; SQL> select * from EMPLOYEES where EMP_ID = 70727; Se os objetos pertencerem a usuários diferentes, então os comandos não são idênticos. SQL> select * from employees where EMP_ID = 70727; SQL> select * from employees where EMP_ID = 70727; Comandos SQL devem ser idênticos para poderem compartilhar os cursores. Observe que o compartilhamento de comandos não é importante em um ambiente DSS, porque a maioria dos comandos será diferente de qualquer maneira. Distinção de Maiúsculas/Minúsculas Os primeiros dois exemplos acima não são idênticos. Observe a diferença de maiúsculas e minúsculas nos nomes da tabela e coluna. Devido a esta diferença, os comandos não são idênticos e portanto não compartilham uma única SQL area. Objetos Idênticos Mesmo quando dois comandos parecem idênticos, se os objetos na verdade referirem-se a objetos diferentes do banco de dados, então os dois comandos não são idênticos. Nos dois últimos exemplos, os comandos são enviados por dois diferentes usuários e cada um possui sua própria tabela EMPLOYEES. Desta forma os comandos não são idênticos e não compartilham uma única SQL area. Variáveis Bind e Cursores Compartilhados SQL> select * from employees where emp_id = :c; SQL> select * from employees where emp_id = :d; Ambos os comandos são traduzidos para: SQL> select * from employees where emp_id = :b1; Se duas variáveis bind possuem diferentes tipos de dados, então os comandos não são idênticos. Se os tipos de dados da variável bind correspondem mas seus nomes não são idênticos, como no exemplo acima, não há problema, porque variáveis bind são internamente renomeadas. A primeira variável é sempre chamada :b1, a segunda :b2 e assim por diante. Escrevendo SQL para Compartilhar Cursores Desenvolva convenções de codificação para comandos SQL em consultas, scripts SQL e chamadas OCI. 2-13