OWI – A Library Cache

Estudando o evento library cache lock…

Olá! Vamos continuar no estudo da movimentação da tartaruga?
He he he Vamos continuar lidando com as lentidões?? Sabe aquela de conhecer o inimigo para conseguir derrotá-lo né? Bem no estilo Arte da Guerra.
Neste intuito iremos trabalhar hoje, falando de um evento de espera que não é muito difícil de ocorrer, o library cache lock.

Trata-se de um evento de espera ligado à Library Cache, classe concorrência, ocorre quando uma transação adquire um lock de library cache. Ok! Nessa hora você chega e pergunta: “Ok, mas o que é isso efetivamente?”

Vamos lá então! Começando pelo começo….kkkkk

Quem é a Library Cache em poucas palavras:
A Library cache é um local dentro da Shared Pool que é um dos pools de memória que fica na SGA (que já comentamos a respeito dela) sendo responsável principalmente pela análise das instruções Oracle que são executadas no banco de dados.

Toda vez que uma instrução SQL chega ao banco de dados vinda de um client, de uma aplicação, de um comando de usuário,etc; ela é analisada por um “cara” chamado de Otimizador. Ele é  responsável por verificar a melhor forma de se trazer a resposta para a query. Ou seja, ele vai analisar como a(s) tabela(s) envolvida(s) serão melhor acessadas para que se tenha o resultado correto em menor espaço de tempo.

Então, toda vez que uma instrução chega esta análise feita se chama de parse. Por uma questão de performance são armazenados na Library Cache um SQL_ID para cada query que foi “parseada”, sendo assim, instruções que se repetem diversas vezes não necessitarão ser analisadas novamente.

Esta é a grande “jogada” de ficar armazenado em área de memória compartilhada por todas as sessões do banco de dados.
Este processo é muito importante, sendo inclusive um dos pilares de análise em tuning de banco de dados.
Geralmente o tamanho deste pool é gerenciado automaticamente pelo banco de dados, porém caso eu queira configurar para ela um tamanho mínimo poderá fazê-lo configurando pelo parâmetro de inicialização: SHARED_POOL_SIZE uma vez que a Library está dentro da Shared Pool.

Testando eficiência da Library Cache:
Uma dica interessante é testar a eficiência deste processo. Isso significa, testar a taxa de acertos das queries, ou seja, quanto mais itens forem encontrados no pool (pelo SQL_ID), menos necessidade de se fazer processos de parse, que de um modo geral costumam onerar a execução.

Para este teste existe uma query que costumo utilizar que é bem interessante. O seu resultado deverá ser o mais próximo possível de 100%.

SELECT ROUND(SUM(PINHITS)/SUM(PINS) * 100,2) “Eficiência – Library Cache”
FROM V$LIBRARYCACHE;

Continuando…
Ok! Explicado, voltamos agora ao nosso evento de espera e assim fica bem mais fácil de entendê-lo.
Este evento ocorre quando alguma sessão bloqueia um objeto, ou bloco, para que somente ele possa utilizar, evitando-se assim que alguma outra transação possa acessá-lo ao mesmo tempo, para manter uma dependência ou para localizar um objeto. Tudo isso a nível da Library Cache. É realmente aquele lance do egoísta sabe??? rsrsrs Os dados são meus e ninguém pega!

Então, quando a espera está ligada a este evento, poderemos descobrir qual o objeto que está sendo bloqueado analisando pela V$DB_OBJECT_CACHE.
Mais informações sobre esta view em:

https://docs.oracle.com/cd/E11882_01/server.112/e40402/dynviews_1107.htm#REFRN30058

Por fim vale lembrar que este é um evento do grupo de eventos tidos como “normais”, ou seja, na grande maioria das vezes não representam problemas para o ambiente. Necessitando ser analisado se a query de do OWI (já comentada anteriormente) apresentar este com grande frequência, ou algum evento com muito tempo de espera.

É meu amigo! Este era o assunto que tínhamos para hoje. Espero que tenha curtido, que continue acompanhando o blog, e não deixe de visitar a página no Facebook, lá sempre tem avisos de novos posts.
facebook.com/raulfdba

Grande abraço a todos! Excelente Sexta-feira e é claaaaro: FOCO NA META!!!!!!