Planejamento Parte 1 01 - Visão Geral do Ajuste de Desempenho do Banco de Dados 02 - Arquivos de Alert e Trace do Oracle 03 - Utilitários e Visões Dinâmicas de Performance 04 - Otimizando a Shared Pool 05 - Otimizando o Buffer Cache 06 - Otimizando o Redo Log Buffer 07- Configuração do Banco de Dados e Problemas de I/O 08- Utilizando Blocos do Oracle com Eficiência
Utilitários e Visões Dinâmicas de Performance
Tuning Refere-se ao conceito de propor e aplicar mudanças para otimizar o desempenho na recuperação ou atualização de dados; Desperta interesse dos profissionais de TI, devido ao: Do legado de sistemas corporativos (ERPs, GEDs etc.) e sistemas web; Da quantidade de usuários de BDs; Da quantidade de dados.
Objetivo Minimizar tempo de resposta na recuperação de dados; Otimizar a taxa de transferência de dados; Os problemas mais comuns: Gargalos de CPU; Estruturas de memória subdimensionadas; I/O ruim; Instruções SQL ineficientes ou pesadas; Regressão de performance após tunar SQL; Contenção de recursos e alta concorrência; Má configuração do BD. Tuning
Passo-a-passo 1 - Entender e identificar o problema; 2 - Elaborar o diagnóstico; 3 Aplicar as melhorias com base no diagnóstico; 4 - Validar o diagnóstico. Tuning
Tuning Pense primeiro no diagnóstico e depois no tuning; Após alterar, teste: Verifique se foi obtido o ganho de performance desejado; Se necessário, volte atrás. Não existe processos alternativos ou paralelos: Contra fatos não há argumentos
Tuning
Tuning Os 3 tipos de atividades de tuning que podem ser realizadas em um BD são: Planejamento de performance; Tuning de instância e BD; SQL Tuning.
Tuning Ajuste de parâmetros e configurações do BD para otimizar performance; Faz parte do trabalho de um DBA gerenciar a segurança do Banco de Dados sem prejudicar a sua performance, e vice-versa;
Como identificar o problema e elaborar o diagnóstico? Consulte as visões de performance dinâmicas; Analise os Wait Events; Gere e analise SQL Traces: Utilize as seguintes ferramentas: Statspack; AWR; ADDM. Tuning
Visões de performances Dinâmicas Definição: são um conjunto de tabelas virtuais construídas a partir de estruturas de memória e de disco, que são de propriedade do SYS, e que possuem informações de atividades do BD (desde o seu startup até o momento atual). Possuem este nome porque contém informações primariamente relacionadas à performance do BD e porque são constantemente atualizadas enquanto o BD está aberto Parecerem tabelas regulares, elas são armazenadas somente em memória e seus dados são dependentes do estado da instância e do BD, portanto, você conseguirá acessá-las somente se o BD estiver aberto (modo OPEN)
Visões de performances Dinâmicas Nos auxiliam Performance Diagnostics and Tuning São um dos bons métodos (e boas praticas) atuais possíveis para encontrar problemas de performance Também conhecidas como visões V$
Visões de performance Dinâmicas Para ver uma lista completa das V$ no seu BD, execute a consulta abaixo: SQL> select * from v$fixed_table where name like 'V% ; V$ não começa com V$, mas sim com V_$. Ao consultar, por exemplo, o objeto V$SYSSTAT, estamos acessando um sinônimo público que aponta para a visão V_$SYSSTAT Ex.: como no exemplo abaixo: SQL> GRANT SELECT ON V_$SYSSTAT TO <usuario>;
Visões de performance Dinâmicas V$ACTIVE_SESSION_HISTORY - Contém estatísticas atualizadas a cada segundo, de snapshots de sessões de BD ativas. V$OSSTAT - Contém estatísticas de utilização de recursos do sistema operacional. V$SESSION - Fornece informações de sessão de todas as sessões atuais do BD. V$SESSION_EVENT - Fornece um resumo sobre todos os eventos que a sessão esperou desde o momento em que o BD foi inicializado; V$SESSION_WAIT - Fornece informações sobre o atual ou último evento de espera de cada sessão aberta no BD. V$SQLTEXT - Exibe o texto SQL completo de instruções SQL pertencentes a cursores compartilhados na SGA.
Visões de performance Dinâmicas V$SQLSTATS: Contém estatísticas de performance básicas de instruções SQL. V$SYSMETRIC: Contém métricas de sistema capturadas em 2 intervalos de tempo: últimos 15 segundos ou últimos 60 segundos. V$SYS_TIME_MODEL - Contém estatísticas acumuladas de várias operações de todo o sistema. V$SYSSTAT - Contém estatísticas globais de várias partes do BD, incluindo rollback, I/O físico e lógico e outros. Pode ser usada p/ calcular hit ratio de áreas de memória, tais como a buffer cache.
Visões de performance Dinâmicas Exemplo: SELECT to_char(m.begin_time,'hh24:mi') "start time", to_char(m.end_time,'hh24:mi') "end time", m.value "current value", s.average "average value", m.metric_name, m.metric_unit FROM v$sysmetric m, v$sysmetric_summary s WHERE s.average > 0 AND ((m.value - s.average)/s.average)*100 >= 10 AND lower(m.metric_name) NOT LIKE '%ratio%';
Visões de performance Dinâmicas Select s.sid, s.username FROM v$sessmetric sm, v$session s WHERE s.sid = sm.session_id AND (sm.cpu/(select decode(value,0,-1) FROM v$sysmetric)
Duvidas?
Otimizando Shared Pool
Memória Sistema área global (SGA) O SGA é um grupo de estruturas de memória compartilhada, conhecidos como componentes do SGA, que contêm dados e informações de controle para uma instância de banco de dados Oracle. Todos os processos do servidor e do fundo compartilhar o SGA. Exemplos de dados armazenados na PIG incluem blocos de dados em cache e áreas comuns SQL. Programa de área global (PGA) É uma região da memória não compartilhada que contém dados e informações de controle para utilização exclusiva por um processo Oracle. Oracle Database cria o PGA quando um processo Oracle é iniciado. Existe um PGA para cada processo servidor e processo de fundo. A coleção de páginas individuais é o total instância PGA, ou instância PGA. Parâmetros de inicialização do banco de dados de definir o tamanho da instância PGA, PGAs não individuais. Usuário área global (UGA) A UGA é a memória associada a uma sessão do usuário. Áreas de código Software Áreas de código de software são partes da memória usado para armazenar o código que está sendo executado ou pode ser executado. Código de banco de dados Oracle são armazenados em uma área de software que é tipicamente em um local diferente de programas de um usuário local mais exclusivo ou protegido
Otimizando a Shared Pool O que é: é uma área de RAM dentro da pilha da RAM que é criado no momento da inicialização, um componente do System Global Area (SGA). O Shared Pool é a área mais importante do SGA, exceto para os caches de buffer de dados. Há uma série de sub-áreas dentro do SGA, cada um com sua própria finalidade importante. O Oracle utilize a SHARED POOL para armazenar declarações PL/SQL e SQL, dados do dicionário entre outros
Otimizando a Shared Pool é impossível determinar um tamanho inicial para uma base nova. Colocar um valor e avaliar o ambiente. Lembrando que a SHARED POOL inicia vazia, e à medida que os usuários vão submetendo as declarações SQL ela vai sendo preenchida
Otimizando a Shared Pool Utilize sempre que possível bind variables ao invés de caracteres literais nas declarações. Isso faz com que o Oracle armazene apenas uma declaração SQL. As declarações, apesar de semelhantes, ocupam duas áreas distintas na SHARED_POOL Exemplo: SELECT employee_id FROM employees WHERE department_id = 20; Por: SELECT employee_id FROM employees WHERE department_id = :dept_id;
Otimizando a Shared Pool As aplicações devem evitar os usuários possam criar suas próprias instruções. Crie padrões para as bind variables e para os espaços nas declarações SQL blocos de PL/SQL. O objetivo do tuning na SHARED_POOL é fazer com que uma declaração SQL que está no cache possa ser reutilizada o maior número de vezes possível.
Otimizando a Shared Pool Utilize a declaração abaixo para identificar a taxa de hit ratio da shared pool: SELECT sum(pinhits) / sum(pins) FROM V$LIBRARYCACHE; SUM(PINHITS)/SUM(PINS) ----------------------. 996986356 1 row selected. A consulta mostrou que 99,69 dos códigos de SQL e PLSQL estão sendo reaproveitados.
Otimizando a Shared Pool A declaração abaixo mostra a quantidade de bytes livres na SHARED_POOL. SELECT * FROM V$SGASTAT WHERE NAME = 'free memory' AND POOL = 'shared pool'; POOL NAME BYTES ----------- ------------------------- --------- shared pool free memory 385236520
Otimizando a Shared Pool A consulta abaixo também auxilia na descoberta da taxa de acerto da SHARED POOL. SELECT (SUM(GETS - GETMISSES - FIXED)) / SUM(GETS) "ROW CACHE" FROM V$ROWCACHE; ROW CACHE ----------.994562437
Otimizando a Shared Pool Também é possível utilizar a view VSHARED_POOL_ADVICE. Para isso é preciso que o parâmetro STATISTICS_LEVEL esteja configurado como ALL ou TYPICAL. show parameter statistics_level; statistics_level string TYPICAL SELECT shared_pool_size_for_estimate "Size of Shared Pool in MB", shared_pool_size_factor "Size Factor", estd_lc_time_saved "Time Saved in sec" FROM v$shared_pool_advice; A saída acima mostra que o tamanho da shared pool é de 1472M. Mostra também que, se o tamanho da shared pool fosse ajustado para 3072M, teria a mesma eficiência.
A saída acima mostra que o tamanho da shared pool é de 1472M. Mostra também que, se o tamanho da shared pool fosse ajustado para 3072M, teria a mesma eficiência. Otimizando a Shared Pool Size of Shared Pool in MB Size Factor Time Saved in sec ------------------------- ----------- ----------------- 352.2391 1461671 512.3478 1465054 672.4565 1470451 832.5652 1472452 992.6739 1472513 1152.7826 1472536 1312.8913 1472542 1472 1 1472542 1632 1.1087 1472542 1792 1.2174 1472542 1952 1.3261 1472542 2112 1.4348 1472542 2272 1.5435 1472542 2432 1.6522 1472542 2592 1.7609 1472542 2752 1.8696 1472542 2912 1.9783 1472542 3072 2.087 1472542 18 rows selected.
Duvidas?
Buffer cache
Buffer Cache é utilizado para armazenar os blocos lidos a partir dos discos Significa que um buffer cache pequeno irá fazer com que o Oracle precise remover do cache os blocos de dados seguindo a lista LRU (LAST RECENTLY USED), e dependendo da frequência com que isso acontece, poderá gerar uma queda na performance. o que normalmente se faz é estimar um tamanho inicial e monitorar o acerto, caso não esteja dentro do ideal, você precisará aumentar e repetir o ciclo de monitoramento
Buffer Cache quando a instância é inicializada, o buffer cache está vazio, portanto, qualquer consulta irá gerar misses no buffer. Significa dizer que validar as taxas de acerto no buffer logo após o startup é errado, você provavelmente terá uma taxa de acerto muito baixa Utilizado em operações particulares como ordenação e leitura paralela
Buffer Cache O buffer é calculado usando a seguinte fórmula: (physical_reads/(db_block_gets consistent_gets)) consistent gets é o número de vezes que uma leitura consistente foi requisitada para um bloco do buffer cache. db block gets from é o número de vezes que um bloco foi requisitado para o buffer cache. physical reads é o número total de blocos de dados lidos do disco para o buffer cache.
Buffer Cache SELECT NAME, PHYSICAL_READS, DB_BLOCK_GETS, CONSISTENT_GETS, 1 (PHYSICAL_READS / (DB_BLOCK_GETS CONSISTENT_GETS)) "Hit Ratio" FROM V$BUFFER_POOL_STATISTICS; NAME PHYSICAL_READS DB_BLOCK_GETS CONSISTENT_GETS Hit Ratio ------------------- -------------- --------------- -------- ---------- DEFAULT 2382927 85639921 46004325.981898738 1 row selected. No exemplo acima, a taxa de acerto foi de 98 no buffer cache.
Buffer Cache IMPORTANTE: Quando falamos de memória, estamos falando de memória física, um servidor Oracle, não deve fazer swap. Para utilizar o buffer cache de forma eficiente, as declarações SQL da aplicação devem estar ajustadas para evitar consumo desnecessário de recursos. Verificar as declarações SQL executadas com mais frequência e as que fazem uso de uma maior quantidade de buffers.
Buffer Cache A consulta abaixo retorna as 50 maiores consultas consumidoras de BUFFERS. SELECT * FROM (SELECT SQL_FULLTEXT, BUFFER_GETS FROM V$SQL ORDER BY BUFFER_GETS DESC) WHERE ROWNUM <= 50; Existem duas formas de melhorar o acerto no buffer: Otimizando as consultas de forma a retornarem menos blocos, e dessa forma utilizar menos buffer. Aumentando o buffer cache.
Buffer Cache Têm seus tamanhos determinados pelo parâmetro DB_BLOCK_SIZE. O número de blocos em memória é determinado pelo parâmetro DB_BLOCK_BUFFERS. Como Aumentar: Defina o valor do parâmetro de inicialização DB_CACHE_ADVICE a ON. Permitir que as estatísticas de cache de buffer para estabilizar. Examine os dados de assessoria no V vista $ DB_CACHE_ADVICE para determinar o próximo incremento necessária para diminuir significativamente a quantidade de E / S física realizada, conforme descrito em "Utilizando o V $ DB_CACHE_ADVICE View". Se é possível alocar a memória extra necessária para o cache de buffer sem causar o sistema a página, em seguida, atribui essa memória. Para aumentar a quantidade de memória alocada para o cache de buffer, aumente o valor do parâmetro de inicialização DB_CACHE_SIZE.
Duvidas?
Redo Log Buffer
Redo Log Buffer Definição: é um buffer circular no SGA que contém informações sobre as alterações feitas no banco de dados. Essas informações são armazenadas Contêm as informações necessárias para reconstruir, ou refazer, as alterações feitas no banco de dados, INSERT, UPDATE, DELETE, criar, alterar, ou DROP. São usadas para recuperação de banco de dados, se necessário.
Redo Log Buffer Um tamanho inicial para o log buffer é: MAX(0.5M, (128K * número de CPUs)) A maioria dos sistemas que possuem log buffer maior que 1M não possuem ganhos de performance. A análise da performance do log buffer é feita por intervalo. Deve ser coletado em intervalos, e verificar se existe um aumento do valor. O ideal é que não existam alterações
Redo Log Buffer SELECT NAME, VALUE FROM V$SYSSTAT WHERE NAME = 'redo buffer allocation retries'; NAME VALUE ------------------------------ ---------- redo buffer allocation retries 11 1 row selected. Se o valor aumentar de forma consistente, é necessário ajustar o tamanho do log buffer.
Redo Log Buffer
Excluindo um arquivo SQL> alter database drop logfile group 1; Database altered. Alternando o arquivo corrente Redo Log Buffer
Duvidas?
Bibliografia Oracle Tuning, The Definitive Reference Third Edition, Donald K. Burleson http://www.fabioprado.net/2014/04/visoes-deperformance-dinamicas.html Banco de Dados Oracle 11g: Visão geral do Real Application Testing e da capacidade de gerenciamento (Docs Oracle) Wagner Pinheiro (Colunista Imaters)
Obrigado Evandro Deliberal evandro@deljoe.com.br