Blog do Rajat DBA

esta é uma cópia da nota de referência 22908.1 da Metalink, para aqueles que não têm acesso a ela.

1. o que é uma trava?Travas são mecanismos de serialização de baixo nível usados para proteger estruturas de dados compartilhados no SGA. A implementação de travas depende do sistema operacional, particularmente no que diz respeito a se um processo aguardará uma trava e por quanto tempo.

uma trava é um tipo de trava que pode ser adquirida e liberada muito rapidamente. As travas são normalmente usadas para impedir que mais de um processo execute o mesmo código em um determinado momento. Associado a cada trava é um procedimento de limpeza que será chamado se um processo morrer enquanto segura a trava. Travas têm um nível associado que é usado para evitar deadlocks. Uma vez que um processo adquire uma trava em um determinado nível, ele não pode posteriormente adquirir uma trava em um nível igual ou inferior a esse nível (a menos que a adquira nowait).

2.Travas vs. Enqueues

Enqueues são outro tipo de mecanismo de bloqueio usado no Oracle.Um enqueue é um mecanismo mais sofisticado que permite que vários processos simultâneos tenham diferentes graus de compartilhamento de recursos “conhecidos”. Qualquer objeto que possa ser usado simultaneamente, pode ser protegido com enqueues. Um bom exemplo é de bloqueios em mesas. Permitimos níveis variados de compartilhamento em tabelas, por exemplo, dois processos podem bloquear uma tabela no modo de compartilhamento ou no modo de atualização de compartilhamento, etc. Uma diferença é que o enqueue é obtido usando um mecanismo de bloqueio específico do sistema operacional. Um enqueue permite ao usuário armazenar um valor no bloqueio, ou seja, o modo em que estamos solicitando. O Gerenciador de bloqueio do sistema operacional mantém o controle dos recursos bloqueados. Se um processo não puder ser concedido o bloqueio porque é incompatível com o modo solicitado e o bloqueio é solicitado com espera, o sistema operacional coloca o processo de solicitação em uma fila de espera que é atendida no FIFO.

outra diferença entre travas e enqueues é que em travas não há fila ordenada de garçons como em enqueues. Os garçons Latch podem usar temporizadores para despertar e tentar novamente ou girar (apenas em multiprocessadores). Como todos os garçons estão simultaneamente tentando novamente (dependendo do agendador), qualquer um pode obter a trava e, possivelmente, o primeiro a tentar pode ser o último a obter.

1. Quando precisamos obter uma trava?

um processo adquire uma trava ao trabalhar com uma estrutura na SGA (área global do sistema). Ele continua a segurar a trava pelo período de tempo em que trabalha com a estrutura. A trava é descartada quando o processo é concluído com a estrutura. Cada trava protege um conjunto diferente de dados, identificado pelo nome da trava.

Oracle usa instruções atômicas como” test and set ” para operar em travas. Os processos que aguardam para executar uma parte do código para a qual uma trava já foi obtida por algum outro processo aguardarão até que a trava seja liberada. Exemplos são refazer travas de alocação,travas de cópia, trava de controle de arquivo etc. A ideia básica é bloquear o acesso simultâneo a estruturas de dados compartilhadas. Como as instruções para definir e as travas livres são atômicas, o sistema operacional garante que apenas um processo o obtenha. Como é apenas uma instrução, é bastante rápido. As travas são mantidas por curtos períodos de tempo e fornecem um mecanismo para limpeza, caso um suporte morra anormalmente enquanto o segura. Esta limpeza é feita usando os serviços da PMON.

1. modos de solicitação de travas?

a solicitação de travas pode ser feita em dois modos:” disposto a esperar “ou”sem espera”. Normalmente, as travas serão solicitadas no modo” disposto a esperar”. Uma solicitação no modo” willing-to-wait ”
fará um loop, esperará e solicitará novamente até que a trava seja obtida. No modo “sem espera”, o processo solicita a trava. Se um não estiver disponível, em vez de esperar, outro é solicitado. Somente quando tudo falhar, o processo do servidor terá que esperar.

exemplos de travas” dispostas a esperar “São: travas de cache de pool e biblioteca compartilhadas
um exemplo de travas” sem espera ” é a trava de cópia refazer.

5. O que causa a contenção da trava?Se uma trava necessária estiver ocupada, o processo solicitando que ela gire, tente novamente e, se ainda não estiver disponível, gire novamente. O loop é repetido até um número máximo de vezes determinado pelo parâmetro de inicialização _SPIN_COUNT. Se depois de todo esse loop, a trava ainda não estiver disponível, o processo deve render a CPU e ir dormir. Inicialmente é dorme por um centissegundo. Este tempo é duplicado em cada sono subsequente.Isso faz com que ocorra uma desaceleração e resulta no uso adicional da CPU, até que uma trava esteja disponível. O uso da CPU é uma consequência da” fiação ” do processo. “Girar” significa que o processo continua a procurar a disponibilidade da trava após certos intervalos de tempo, durante os quais ela dorme.

1. como identificar a contenção para travas internas?

dados Relevantes dicionário vistas para consulta:

V$TRAVA
V$LATCHHOLDER
V$LATCHNAME

Cada linha na V$TRAVA tabela contém estatísticas para um diferente tipo de trava. As colunas da tabela refletem a atividade para diferentes tipos de solicitações de trava. A distinção entre estes tipos de pedidos é a de saber se o processo de solicitação continua a pedido de um trinco se estiver disponível:

disposto a esperar Se a trava solicitado com uma dispostos a esperar
pedido não está disponível, o processo de solicitação
aguarda um curto período de tempo e solicitações de trava novamente.
o processo continua aguardando e solicitando até
a trava está disponível.

não espere se a trava solicitada com uma solicitação imediata for
não disponível, o processo de solicitação não espera
, mas continua o processamento.

V$LATCHNAME informações da chave:

obtém o número de solicitações de disponibilidade para espera bem-sucedidas para
uma trava.

erra o número de vezes que uma Solicitação Inicial de disponibilidade para espera
não teve sucesso.

dorme número de vezes que um processo esperou um solicitou uma trava
após uma Solicitação Inicial de wiling-to-wait.

IMMEDIATE_GETS número de solicitações imediatas bem-sucedidas para cada trava.

IMMEDIATE_MISSES número de solicitações imediatas malsucedidas para cada trava.

Cálculo de trava de acertos

Para obter a taxa de acertos para travas de aplicar a seguinte fórmula:

“dispostos a esperar” de acertos=(OBTÉM-ERROS)/OBTÉM
“não esperar” Hit Ratio=(IMMEDIATE_GETS-IMMEDIATE_MISSES)/IMMEDIATE_GETS

Este número deve ser próximo de 1. Caso contrário, ajuste de acordo com o nome da trava

1. scripts SQL úteis para obter informações de trava

/*
** sistema de exibição-estatísticas de trava ampla.
*/
formato do nome da coluna A32 truncar o título de “TRAVA NOME”
coluna pid designação “TITULAR PID”
selecione c.nome de um.addr,um.fica,um.erra,um.dorme,
um.immediate_gets,um.immediate_misses,b.pid
v$trava a, v$latchholder b, v$latchname c
onde um.addr = b.laddr(+)
e um.trava# = c.trava#
ordem por um.trava#;

/*
** Dado um latch de endereços, descobrir a trava nome.
*/
formato do nome da coluna a64 título ‘Nome’
e selecione um.nome de v$latchname a, v$trava b
onde b.addr = ‘&addr’
e b.trava#=um.trava#;

/*
** Exibir trava estatísticas trava nome.
*/
formato do nome da coluna a32 rubrica “TRAVA NOME’
coluna pid designação “TITULAR PID’
selecione c.nome de um.addr,um.fica,um.erra,um.dorme,
um.immediate_gets,um.immediate_misses,b.pid
v$trava a, v$latchholder b, v$latchname c
onde um.addr = b.laddr(+) e um.trava# = c.trava#
e c.nome like ‘&latch_name%’ ordem por um.trava#;

1. lista de todas as travas

as versões Oracle podem diferir na trava# atribuída às travas existentes.
a seguinte consulta irá ajudá-lo a identificar todas as travas e o número atribuído.

formato do nome da coluna a40 rubrica “TRAVA NOME’
selecione trava#, nome from v$latchname;

1. Lista de travas, que são de maior preocupação para um DBA

• CACHE de BUFFER de TRAVAS: Existem dois principais travas que proteger blocos de dados no buffer cache. A contenção para essas duas travas geralmente é vista quando um banco de dados tem altas taxas de E / S. Podemos reduzir a discórdia para essas travas e ajustá-las ajustando certo init.parâmetros ora.

Cache buffers chains latch:

esta trava é adquirida sempre que um bloco no cache do buffer é acessado (fixado).

reduzir a contenção para a trava de cadeias de buffer de cache geralmente exigirá a redução das taxas lógicas de E/S ajustando e minimizando os requisitos de E/S do SQL envolvido. Altas taxas de E / S podem ser um sinal de um bloco quente (ou seja, um bloco altamente acessado).

Ver Nota 163424.1 Como identificar um Hot Block dentro do banco de dados para identificar corretamente esse problema.

Cache buffers LRU chain latch:

o cache buffer LRU chain latch é adquirido para introduzir um novo bloco no cache do buffer e ao gravar um buffer de volta no disco, especificamente ao tentar digitalizar a cadeia LRU (menos usada recentemente) contendo todos os blocos Sujos no cache do buffer.

é possível reduzir a contenção para a trava da cadeia LRU do buffer de cache, aumentando o tamanho do cache do buffer e, assim, reduzindo a taxa na qual novos blocos são introduzidos no cache do buffer. Dois parâmetros ditam o tamanho do cache do buffer, DB_BLOCK_SIZE e DB_BLOCK_BUFFERS. Na verdade, apenas os DB_BLOCK_BUFFERS podem ser alterados sem recriar o banco de dados. Cuidado, ao ajustar o pool de buffer, evite o uso de buffers adicionais que contribuem pouco ou nada para a taxa de acerto do cache. Um erro comum é continuar aumentando o valor de DB_BLOCK_BUFFERS. Esses aumentos não têm efeito se você estiver fazendo verificações de tabela completas ou outras operações que não usam o cache do buffer. Vários pools de buffer podem ajudar a reduzir a contenção nessa trava.Você pode criar travas de cadeia LRU de buffer de cache adicionais ajustando o parâmetro de configuração DB_BLOCK_LRU_LATCHES. Você pode reduzir a carga nas travas da cadeia de buffer de cache aumentando o parâmetro de configuração _DB_BLOCK_HASH_BUCKETS

• travas de BUFFER REDOLOG: existem duas travas de buffer refazer, a trava de alocação refazer e a trava de cópia refazer. A trava de alocação de refazer deve ser adquirida para alocar espaço dentro do buffer. Se a entrada refazer log a ser feita for maior que o parâmetro de configuração LOG_SMALL_ENTRY_MAX_SIZE, a sessão que adquire a trava refazer alocação poderá copiar a entrada no buffer refazer imediatamente enquanto segura a trava de alocação. Se a entrada de log for maior que LOG_SMALL_ENTRY_MAX_SIZE, a sessão liberará a trava de alocação de refazer e adquirirá a trava de cópia de refazer para copiar a entrada. Há apenas uma trava de alocação refazer, mas pode haver até travas de alocação LOG_SIMULTANEUS_COPIES.

redo allocation latch:

esta trava controla a alocação de espaço para refazer entradas no buffer de refazer log. Há uma trava de alocação refazer por instância.

a contenção para esta trava no Oracle7 pode ser reduzida diminuindo o valor de LOG_SMALL_ENTRY_MAX_SIZE em sistemas multi-cpu para forçar o uso da trava de cópia redo
. No Oracle8i este parâmetro é obsoleto, então você precisa considerar para aumentar o tamanho do LOG_BUFFER ou reduzir a carga do buffer de log usando NOLOGGING recursos, quando possível.

refazer trava de cópia:

esta trava é usada para gravar registros refazer no buffer redolog. Esta trava é esperada em sistemas de cpu única e multi-cpu.

em sistemas multi-cpu, a contenção pode ser reduzida aumentando o valor de LOG_SIMULTANEOUS_COPIES (oculto em Oracle8i) e / ou aumentando LOG_ENTRY_PREBUILD_THRESHOLD (não documentado em Oracle7).

• cache da biblioteca

trava do cache da Biblioteca:

as travas do cache da biblioteca protegem as instruções SQL em cache e as definições de objetos mantidas no cache da biblioteca dentro do pool compartilhado. A trava do cache da biblioteca deve ser adquirida para adicionar uma nova instrução ao cache da biblioteca. Durante uma análise, o Oracle pesquisa o Cache da biblioteca por uma instrução correspondente. Se um não for encontrado, o Oracle analisará a instrução SQL, obterá a trava do cache da biblioteca e inserirá o novo SQL.

o primeiro recurso a reduzir a contenção nessa trava é garantir que o aplicativo esteja reutilizando o máximo possível de representação de instruções SQL. Use variáveis de ligação sempre que possível no aplicativo. Erros nessa trava também podem ser um sinal de que o aplicativo está analisando SQL em uma taxa alta e pode estar sofrendo de muita sobrecarga da CPU de análise.Se o aplicativo já estiver sintonizado, o SHARED_POOL_SIZE poderá ser aumentado. Esteja ciente de que, se o aplicativo não estiver usando o cache da biblioteca adequadamente, a contenção pode ser pior com uma estrutura maior a ser tratada.

o parâmetro _KGL_LATCH_COUNT controla o número de travas de cache da biblioteca. O valor padrão deve ser adequado, mas se a contenção da trava do cache da biblioteca não puder ser resolvida, pode ser aconselhável aumentar esse valor. O valor padrão para _KGL_LATCH_COUNT é o próximo número primo após CPU_COUNT. Este valor não pode exceder 66 (ver: ).

trava do pino do cache da Biblioteca:

a trava do pino do cache da biblioteca deve ser adquirida quando uma instrução no cache da Biblioteca for reexecutada. Erros nesta trava ocorrem quando há taxas muito altas de execução SQL.

há pouco que pode ser feito para reduzir a carga na trava do pino do cache da biblioteca, embora usando sinônimos privados em vez de públicos ou referências de objetos diretos, como proprietário.A tabela pode ajudar.

• travas relacionadas ao POOL compartilhado

trava do pool compartilhado:

enquanto a trava do cache da biblioteca protege as operações com o cache da biblioteca, a trava do pool compartilhado é usada para proteger operações críticas ao alocar e liberar memória no pool compartilhado.
se um aplicativo fizer uso de SQL literal (não compartilhado), isso pode limitar severamente a escalabilidade e a taxa de transferência. O custo de analisar uma nova instrução SQL é caro tanto em termos de requisitos de CPU quanto no número de vezes que o cache da biblioteca e as travas do pool compartilhado podem precisar ser adquiridos e liberados. Antes do Oracle9, costumava haver apenas uma trava em todo o banco de dados para proteger a alocação de memória no cache da biblioteca. No Oracle9, vários childs foram introduzidos para aliviar a discórdia neste recurso.

maneiras de reduzir a trava do pool compartilhado são, evite análises difíceis quando possível, analise uma vez, execute muitos. Eliminar o SQL literal também é útil para evitar a trava do pool compartilhado. O tamanho do shared_pool e o uso do MTS (opção de servidor compartilhado) também influenciam muito a trava do pool compartilhado. A nota 62143.1 explica como identificar e corrigir problemas com o pool compartilhado e a trava do pool compartilhado.

objetos de cache de linha trava:

essa trava entra em jogo quando os processos do usuário estão tentando acessar os valores do dicionário de dados em cache.

não é comum ter contenção nesta trava e a única maneira de reduzir a contenção para esta trava é aumentando o tamanho do pool compartilhado (SHARED_POOL_SIZE).

1. Tuning _spin_count (_latch_spin_count em Oracle7)

SPIN_COUNT controla quantas vezes o processo tentará novamente obter a trava antes de recuar e dormir. Isso basicamente significa que o processo está em um loop de CPU apertado continuamente tentando obter a trava para tentativas SPIN_COUNT. Em um único sistema de CPU, se um processo Oracle tentar adquirir uma trava, mas for mantido por outra pessoa, o processo liberará a CPU e adormecerá por um curto período antes de tentar novamente. No entanto, em um sistema multiprocessador (SMP), é possível que o processo que segura a trava esteja sendo executado em uma das outras CPUs e, portanto, libere a trava nas próximas instruções (as travas geralmente são mantidas por apenas períodos muito curtos de tempo).

o desempenho pode ser ajustado alterando o valor de SPIN_COUNT. Se um valor alto for usado, a trava será alcançada mais cedo do que se você usar um valor baixo. No entanto, você pode usar mais tempo de rotação da CPU para obter a trava se usar um valor alto para SPIN_COUNT. Você pode diminuir essa probabilidade de dormir em sessão aumentando o valor dos parâmetros de configuração _LATCH_SPIN_COUNT ou SPIN_COUNT. Este parâmetro controla o número de tentativas que a sessão fará para obter a trava antes de dormir. Girar na trava consome CPU, portanto, se você aumentar esse parâmetro, poderá ver um aumento na utilização geral da CPU de seus sistemas. Se o seu computador estiver perto de 100% de CPU e seu aplicativo for throughput em vez de tempo de resposta orientado, você pode considerar diminuir o SPIN_COUNT para conservar a CPU. Ajustar SPIN_COUNT é tentativa e erro. Em geral, apenas aumente o SPIN_COUNT se houver recursos de CPU gratuitos suficientes disponíveis no sistema e diminua-o somente se não houver capacidade de CPU sobressalente.