Latches os “Locks” na memória no Oracle

Quem esta acostumado a verificar a performance através dos eventos de tempo, fatalmente vai se deparar com eventos de latches, e para esclarecer um pouco esse conceito não muito presente nos livros comuns, eu decide escrever esse post.

Latch é uma forma de lock. No RDBMS Oracle, latches são simples locks de dispositivos.
Eles são elementos de memória que consistem tipicamente em três partes:  PID (process ID), endereço de memória, e comprimento

Eles impõem o acesso exclusivo ás estruturas de dados na SGA e assim, protegem a integridade das estruturas de memória contra a corrupção. O Acesso as estruturas de dados da SGA devem ser serializados para prevenir a corrupção que pode resultar em várias sessões modificando as estruturas de memória ao mesmo tempo. A Integridade da estrutura de dados também deve ser preservada enquanto ela é inspecionada.

Uma diferença importante entre locks e latches é a requisição de filas (queuing).

Os pedidos de locks ficarão em filas se necessário e a manutenção da mesma é realizada em ordem, enquanto os Latches não suportam filas.

Se um pedido para obter um latch falhar porque o latch esta ocupado, o processo continuara a requisição até conseguir. Dessa forma solicitações por latch não são atendidas necessariamente em ordem.

Devido a um latch só poder ser concedido a um processo de cada vez, e por não haver conhecimentos de filas a estrutura de dados do latch em si é muito simples, essencialmente apenas um único local em memória representa o estado do lacth e porque a estrutura do latch é tão simples, as funções para receber e liberar o latch tem muito pouco trabalho a realizar. Em contraste, as estruturas de dados dos locks, são muito mais sofisticadas por causa do seu apoio a filas e a simultaneidade, assim funções para obter e liberar locks tem muito trabalho a fazer.

Família de Latchs

Existem três tipos de latches: parent (pai), child (filho) e solitary. Os tipos parent e solitary são fixos no kernel do Oracle.

Child Latches são criados na incialização da instância. As views V$LATCH_PARENT e V$LATCH_CHILDREN contém estatísticas de parent e child latches, respectivamente. A view V$LATCH contem a estatisticas para a solaitary latches com estatísticas agregadas dos parent e children latches.

Spin

A Idéia do spin é que um outro processo em execução em outra CPU possa liberar o LATCH, permitindo que o processo de spin possa continuar, claro que não faz sentido  um spin de uma máquina com apenas um CPU.

A Alternativa para o spin é renunciar a CPU e permitir que outro processo possa usá-la, isso pode parecer bom, porém para a CPU parar a execução e iniciar outra, deve ter uma troca de contexto, Ou se seja ele deve salvar o contexto do processo e determinar quais processos seguir, e então retornar o contexto do processo seguinte.A Mudança de contexto é uma operação cara, pois várias estruturas do kernel tem que ser pesquisada de atualizada.

A Seguir entenderemos melhor como funcionam os melhor os Spins.

Aquisição de Latches

Um processo pode solicitar um latch  e esperar ou não esperar para conseguir a sua aquisição. Quando o processo não tem que esperar pelo latch ele obtém alguns latches imediatemente. Latches que são adquiridos dessa forma tem estatísticas nas colunas IMMEDIATE_GETS e IMMEDIATE_MISSES.

Essas colunas são parte da família de  views sobre latches :V$LATCH, V$LATCH_PARENT e V$LATCH_CHILDREN.

Latches que são adquiridos com espera tem estatísticas nas colunas GETS e MISSES.

Se o Latch esta disponivel, sobre a primeira requisição, o processo o adquire e antes de modificar a estrutura de dados, o processo grava informações de recuperação na área de recuperação do Latch para que PMON saiba efetuar uma limpeza se necessário, caso o seu processo morra travando o latch.

Se o Latch não estiver disponível, o processo faz um spin na CPU por um curto tempo e tenta novamente adquirir o LATCH.

Esse SPIN pode ser repetir até o _SPIN_COUNT(parâmetro) vezes, o que normalmente o default fica em 2000. Resumidamente, se o Latch é obtido em uma das tentativas, o processo incrrementa as estatísticas de SPIN_GETS e MISSES por 1, caso contrário, temos o evento de tempo latch free imediatamente na visão V$SESSION_WAIT , e com isso ele entra em sleep. No final do ciclo de sleep, o processo acorda e tenta novamente conseguir um latch até repitir _SPIN_COUNT vezes. As estatísticas de SLEEPS, só são atualizadas quando ocorre um GET succeds, não a cada tentativa.

O Tempo máximo de um sleep é internamente definido pelo parâmetro _MAX_EXPONENTIAL_SLEEP, que geralmente tem o valor padrão de 2 segundos, mas será reduzido para o _MAX_SLEEP_HOLDING_LATCH, que tem como padrão a 4 centiseconds se o processo de sleep, tem um ou mais Latches em posse. Um processo que possui um latch não pode entrar em sleep durante muito tempo, se não ele impede que outros processos obtenham suas requisições com sucesso.

A Uníca maneira de sair da rotina de requisição de LATCH é conseguindo um get sobre um latch.

Então o que acontece se um processo que esta de posse de um latch morre?
Quando um processo não consegue obter um latch depois de algumas tentativas ele vai solicitar a PMON um ckeck up no LATCH o qual ele deseja, se o latch esta estiver vinculado a um processo morto, pmon ira efetuar a limpeza e irá liberar o latch.

Para quem quiser saber mais sobre Latches segue as fontes :

4 comentários em “Latches os “Locks” na memória no Oracle”

Deixe um comentário

Ads Blocker Image Powered by Code Help Pro

Ads Blocker Detectado !

Verificamos que está usando alguma extensão para bloquear os anúncios. O GPO (Grupo de Profissionais Oracle) obtém a sua renda através dos anúncios, para assim manter toda a estrutura dedicada a universalização do conhecimento.

Se você gosta de nosso trabalho, pedimos por gentileza que desabilite o ads blocker. Trabalhamos somente com o Google Adsense e tentamos ao máximo exibir apenas o necessário.

Agradecemos de antemão ! :)

Powered By
Best Wordpress Adblock Detecting Plugin | CHP Adblock