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 :
Excelente artigo Hudson, me esclareceu bem o que são latches.
Grande Abraço
Obrigado Flávio
Abraços !
ÓTIMO !!
🙂
Obrigado Daniel,
Ler um ótimo seu, é muito bom.
Abraços!