consistent gets é o número de vezes que uma leitura consistente foi requisitada para um bloco do buffer cache.

Transcrição

1 Ajustando o BUFFER CACHE, SHARED POOL e o LOG BUFFER BUFFER CACHE O 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. Não existe uma mágica para dimensionar o buffer cache, 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. Um detalhe importante é que 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. O buffer é calculado usando a seguinte fórmula: 1 - (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. SELECT NAME, PHYSICAL_READS, DB_BLOCK_GETS, CONSISTENT_GETS, 1 - (PHYSICAL_READS / (DB_BLOCK_GETS CONSISTENT_GETS)) "Hit Ratio" FROM VBUFFER_POOL_STATISTICS; NAME PHYSICAL_READS DB_BLOCK_GETS CONSISTENT_GETS Hit Ratio DEFAULT No exemplo acima, a taxa de acerto foi de 98 no buffer cache. Uma consulta semelhante pode ser feita na VSYSSTAT: SELECT NAME, VALUE FROM VSYSSTAT WHERE NAME IN ('db block gets from cache',

2 'consistent gets from cache', 'physical reads cache'); NAME VALUE db block gets from cache consistent gets from cache physical reads cache rows selected. 1 - ( /( )) = 0, O buffer cache também pode ser ajustado com base na view VDB_CACHE_ADVICE. Para que essa view seja populada é necessário que o parâmetro DB_CACHE_ADVICE esteja ON. show parameter db_cache_advice db_cache_advice string ON A declaração abaixo consulta a respectiva view, retornando estimativas de buffer e de acerto. COLUMN size_for_estimate FORMAT 999,999,999,999 heading 'Cache Size (MB)' COLUMN buffers_for_estimate FORMAT 999,999,999 heading 'Buffers' COLUMN estd_physical_read_factor FORMAT heading 'Estd PhysRead Factor' COLUMN estd_physical_reads FORMAT 999,999,999 heading 'Estd Phys Reads' SELECT size_for_estimate, buffers_for_estimate, estd_physical_read_factor, estd_physical_reads FROM VDB_CACHE_ADVICE WHERE name = 'DEFAULT' AND block_size = (SELECT value FROM VPARAMETER WHERE name = 'db_block_size') AND advice_status = 'ON'; Estd Phys Estd Phys Cache Size (MB) Buffers Read Factor Reads , ,251, , ,140, , ,329, , ,594, , ,309, , ,948, , ,763, , ,655, , ,581,271

3 800 99, ,510, , ,435, , ,380,060 1, , ,350,269 1, , ,309,334 1, , ,275,624 1, , ,249,930 1, , ,231,580 1, , ,211,413 1, , ,193,922 1, , ,167, rows selected. A análise dela é feita de forma diferente a de taxas. A consulta mostra uma redução de 2(0.98) no número de leitura físicas caso o buffer cache seja configurado para 960MB. Lembrando que, 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. Isso é feito verificando as declarações SQL executadas com mais freqência e as que fazem uso de uma maior quantidade de buffers. A consulta abaixo retorna as 50 maiores consultas consumidoras de BUFFERS. SELECT * FROM (SELECT SQL_FULLTEXT, BUFFER_GETS FROM VSQL 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. SHARED POOL O Oracle utilize a SHARED POOL para armazenar declarações PL/SQL e SQL, dados do dicionário entre outros. Da mesma forma que o BUFFER CACHE, é impossível determinar um tamanho inicial para uma base nova. Você deve seguir o mesmo principio do BUFFER CACHE, 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.

4 Para isso, observe o seguinte: 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: Substitua: SELECT employee_id FROM employees WHERE department_id = 10; SELECT employee_id FROM employees WHERE department_id = 20; Por: SELECT employee_id FROM employees WHERE department_id = :dept_id; 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. Por exemplo: SELECT employee_id FROM employees WHERE department_id = :dept_id É diferente de: SELECT employee_id FROM employees where department_id = :dept_id 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. Utilize a declaração abaixo para identificar a taxa de hit ratio da shared pool: SELECT sum(pinhits) / sum(pins) FROM VLIBRARYCACHE; SUM(PINHITS)/SUM(PINS) A consulta mostrou que 99,69 dos códigos de SQL e PLSQL estão sendo reaproveitados. A declaração abaixo mostra a quantidade de bytes livres na SHARED_POOL.

5 SELECT * FROM VSGASTAT WHERE NAME = 'free memory' AND POOL = 'shared pool'; POOL NAME BYTES shared pool free memory 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 VROWCACHE; ROW CACHE 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 vshared_pool_advice; Size of Shared Pool in MB Size Factor Time Saved in sec

6 18 rows selected 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. LOG BUFFER Aplicações que inserem, modificam ou excluem um grande volume de registros normalmente não utilizam o tamanho default de log buffer. Apesar do tamanho do log buffer ser bem menor frente ao tamanho total da SGA, ele tem grande impacto na performace de sistemas que realizam atualização no volume dos dados. 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. SELECT NAME, VALUE FROM VSYSSTAT WHERE NAME = 'redo buffer allocation retries'; NAME VALUE redo buffer allocation retries 11 Se o valor aumentar de forma consistente, é necessário ajustar o tamanho do log buffer