Latches - Conceito

 

Briefing

Pessoal, esse é um post simples e direto. Só irei explicar o que é um Latch.

Se você, estudante do banco de dados Oracle, começar a ler sobre a arquitetura desse SGBD, vai encontrar esse termo e, não sabendo o que é, pode interferir no entendimento. Nesse momento a minha expectativa é que você abra o Google e pesquise “o que é latch?” ou “o que são latches?” e, com sorte, caia exatamente aqui nessa página!

Esse texto é parte de um artigo que escrevi como TCC da Pós-graduação e minha intenção era publicá-lo na íntegra aqui no Blog, mas não será possível. Felizmente é por um bom motivo! Esse artigo foi publicado na SQL Magazine e, pelas normas editoriais, não pode ser publicado em outros meios. Confiram o artigo completo na revista! =)

O trecho abaixo eu já tinha publicado antes de trabalhar com a revista SQL Magazine, então vou mantê-lo aqui.

Espero que ajude tanto quanto o post sobre Blocos Anônimos (esse aqui) me parece que têm ajudado.

Não é um conceito direcionado aos iniciantes, está mais ligado a análises de tuning mas, enfim, não vai fazer mal saber o que é, ter uma noção sobre latches. Se eu li, aprendi um pouco e me foi útil, também pode ser pra você.

[Super Mario] Here we gooooo! [/Super Mario]

 

 

Latch – Extraído do meu artigo sobre Hard Parses

Latch é um mecanismo de alocação de estruturas na memória SGA serializado e desenhado para que sejam alocados por curtos períodos de tempo. Ele controla os vários processos que desejam acessar áreas compartilhadas da SGA, permitindo que somente um processo de cada vez acesse a estrutura requisitada, evitando corrupção da memória, ou seja, mantendo a integridade.

Latch não implementa fila de espera, como acontece com outros tipos de locks (travas). Se, ao tentar obter um latch, é identificado que outro processo já o obteve, sua sessão irá aguardar algum tempo e, depois, tentará novamente obter o latch.

Quando o latch for liberado pelo processo que o obtinha, se houver vários processos que precisam do mesmo latch, o primeiro processo que solicitá-lo após a liberação terá sucesso, os demais continuarão tentando aleatoriamente até conseguir ou até esgotar o tempo de tentativas.

Atente-se que não houve fila de espera e, portanto, pode ser que o primeiro processo que chegou para obter o latch bloqueado não seja o primeiro a consegui-lo após a liberação do latch.

Quando um processo fica em loop tentando obter o latch e há várias sessões tentando a mesma coisa, tal processo ficará um tempo ocupando CPU na esperança que o latch seja liberado logo (como o latch foi desenhado para durar curtos períodos, presume-se que a chance de ser liberado em breve é alta). Somente após algum tempo em CPU tentando obter o latch e falhando, o processo liberará a CPU e tentará de novo mais tarde. Isso indica, normalmente, um cenário em que há várias sessões tentando obter o mesmo latch, ao invés de uma sessão única alocando o latch por um longo tempo, como acontece com outros tipos de locks.

Tanto essa espera na CPU quanto a saída e a volta para a CPU para tentar novamente são gastos com recursos primários devem ser evitados, se possível.

Hard parse é uma operação que utiliza latches para ser completada. Portanto, temos a seguinte relação: quanto mais hard parses, mais latches. Aumentar o número de latches significa ter mais processos alocando as estruturas compartilhadas da memória (alta concorrência) e, consequentemente, aumenta a chance de que outro processo tenha que aguardar para obter seu latch ao invés de obtê-lo instantaneamente.

Quanto menos hard parses, menos latches, maior a chance de um processo obter seu latch instantaneamente (baixa concorrência), menor a chance de espera, mais rápido será o fluxo através dos mecanismos internos e mais rápido será o término da operação executada.

 

Caso o trecho tenha te deixado ainda mais confuso, peço que aguarde o post com o artigo completo. Se esse capítulo extraído não fez sentido no contexto onde você leu sobre latch, fará dentro do artigo.

 

About these ads