Aqui estão alguns dos eventos de espera comuns do Oracle que todos devem conhecer.
Aguardar eventos
Você pode encontrar qual sessão de evento está esperando por ela seguindo a consulta
select event from V$session_wait where sid=&1
Estou tentando explicar alguns eventos comuns de espera do Oracle, causas e resoluções
enfileirar
O processo está aguardando um enfileiramento oracle (um bloqueio que você pode ver em v$lock). Isso geralmente ocorre quando um usuário está tentando atualizar uma linha em uma tabela que está sendo atualizada por outro usuário. Os bloqueadores podem ser descobertos usando a seguinte consulta
select * from dba_waiters
pin do cache da biblioteca
O processo deseja fixar um objeto na memória no cache da biblioteca para exame, garantindo que nenhum outro processo possa atualizar o objeto ao mesmo tempo. Isso acontece quando você está compilando ou analisando um objeto PL/SQL ou uma visualização. Evite compilar o objeto PL/SQL ou a visualização oracle em alto tempo de uso para evitar esse evento de espera
bloqueio de carregamento do cache da biblioteca
O processo está aguardando a oportunidade de carregar um objeto ou parte de um objeto no cache da biblioteca. (Apenas um processo pode carregar um objeto ou parte de um objeto por vez.)
sem trava
O processo está aguardando uma trava mantida por outro processo. (Este evento de espera não se aplica a processos que estão girando enquanto aguardam uma trava; quando um processo está girando, ele não está esperando.). Travas são dispositivos de serialização leves usados para coordenar o acesso multiusuário a estruturas de dados compartilhadas, objetos, e arquivos.
Travas são travas projetadas para serem mantidas por períodos de tempo extremamente curtos, por exemplo, o tempo que leva para modificar uma estrutura de dados na memória. Eles são usados para proteger determinadas estruturas de memória, como o cache de buffer de bloco de banco de dados ou o cache de biblioteca no conjunto compartilhado.
Oracle Latches normalmente são solicitados internamente em um modo 'disposto a esperar'. Isso significa que, se a trava não estiver disponível, a sessão solicitante ficará inativa por um curto período de tempo e tentará novamente a operação mais tarde. Outras travas podem ser solicitadas em um modo 'imediato', que é semelhante em conceito a um SELECT FOR UPDATE NO-WAIT, o que significa que o processo fará outra coisa, como tentar pegar uma trava equivalente que pode estar livre, em vez de sentar e esperar que esta trava fique disponível. Como muitas solicitações podem estar aguardando uma trava ao mesmo tempo, você pode ver alguns processos esperando mais do que outros.
As travas são atribuídas aleatoriamente, com base na sorte do sorteio, se você quiser. Qualquer sessão que peça uma trava logo após a liberação, a obterá. Não há fila de garçons, apenas uma multidão de garçons constantemente tentando novamente.
esperas ocupadas do buffer
O processo deseja acessar um bloco de dados que não está atualmente na memória, mas outro processo já emitiu uma solicitação de E/S para ler o bloco na memória. (O processo está esperando que o outro processo termine de trazer o bloco para a memória.). Os blocos quentes podem ser encontrados usando a visão V$BH
arquivo db leitura dispersa
O processo emitiu uma solicitação de E/S para ler uma série de blocos contíguos de um arquivo de dados no cache de buffer e está aguardando a conclusão da operação. Isso normalmente acontece durante uma varredura completa de tabela ou varredura de índice completo.
Devemos verificar se a consulta deve usar a verificação completa da tabela. Certifique-se de que as estatísticas do otimizador Oracle estejam atualizadas. Use a remoção de partição para reduzir o número de blocos visitados
Se uma consulta que está funcionando bem por um tempo de repente passa muito tempo no evento de leitura dispersa do arquivo db e não houve uma alteração de código, você pode verificar se um ou mais índices foram descartados ou tornar-se inutilizável.
leitura sequencial do arquivo db
O processo emitiu uma solicitação de E/S para ler um bloco de um arquivo de dados no cache de buffer e está aguardando a conclusão da operação. Isso normalmente acontece durante uma pesquisa de índice ou uma busca de uma tabela oracle por ROWID quando o bloco de dados necessário ainda não está na memória. Não se deixe enganar pelo nome confuso deste evento de espera!
Devemos verificar se os índices corretos estão sendo usados. Um índice errado pode prejudicar o desempenho da consulta. Certifique-se de que as estatísticas do otimizador estejam atualizadas.
leitura paralela do arquivo db
O processo emitiu várias solicitações de E/S em paralelo para ler blocos de arquivos de dados na memória e está aguardando a conclusão de todas as solicitações. A documentação diz que esse evento de espera ocorre apenas durante a recuperação, mas na verdade também ocorre durante a atividade regular quando um processo agrupa várias solicitações de E/S de bloco único e as emite em paralelo. (Apesar do nome, você não verá esse evento de espera durante a consulta paralela ou DML paralela. Nesses casos, os eventos de espera com PX em seus nomes ocorrem.)
gravação paralela de arquivo db
O processo, normalmente DBWR, emitiu várias solicitações de E/S em paralelo para gravar blocos sujos do cache de buffer para o disco e está aguardando a conclusão de todas as solicitações.
leitura de caminho direto, gravação de caminho direto
O processo emitiu solicitações de E/S assíncronas que ignoram o cache do buffer e está aguardando a conclusão. Esses eventos de espera geralmente envolvem segmentos de classificação.
Instruções SQL com funções que exigem classificações, como ORDER BY, GROUP BY, UNION, DISTINCT e ROLLUP, a classificação de gravação é executada no tablespace temporário quando o tamanho da entrada é maior que a área de trabalho no PGA
Verifique se as estatísticas do otimizador estão de acordo com os dados e se a consulta está usando a tabela de condução correta. Verifique se as colunas do índice composto podem ser reorganizadas para corresponder à cláusula ORDER BY para evitar totalmente a classificação.
Verifique se o valor apropriado PGA_AGGREGATE_TARGET está definido. Se possível, use UNION ALL em vez de UNION.
Trava de pool compartilhado
A trava do conjunto compartilhado é usada para proteger operações críticas ao alocar e liberar memória no conjunto compartilhado. As contenções para as travas do pool compartilhado e do cache da biblioteca se devem principalmente à análise intensa. Uma análise difícil se aplica a novos cursores e cursores que estão desatualizados e devem ser executados novamente
O custo de analisar uma nova instrução SQL é caro tanto em termos de requisitos de CPU quanto do número de vezes que o cache da biblioteca e o pool compartilhado travas podem precisar ser adquiridas e liberadas.
A eliminação do SQL literal também é útil para evitar a trava do pool compartilhado
controle a leitura sequencial do arquivo
O processo está esperando que os blocos sejam lidos de um arquivo de controle. Isso acontece geralmente
- fazendo um backup dos arquivos de controle
- compartilhando informações (entre instâncias) do controlfile
- lendo outros blocos dos arquivos de controle
- lendo o bloco de cabeçalho
Se este for um grande evento de espera, significa que o local do arquivo de controle precisa ser alterado para um local de disco mais rápido
controlar a gravação paralela do arquivo
O processo emitiu várias solicitações de E/S em paralelo para gravar blocos em todos os arquivos de controle e está aguardando a conclusão de todas as gravações.
espaço de buffer de log
O processo está esperando que o espaço fique disponível no buffer de log (o espaço fica disponível somente depois que o LGWR gravou o conteúdo atual do buffer de log no disco.) Isso normalmente acontece quando os aplicativos geram redo mais rápido do que o LGWR pode gravá-lo para disco.
Isso também pode acontecer, se a E/S para o disco onde os logs de redo estão localizados estiver lenta
Não deve haver esperas de espaço de buffer de log como tal no banco de dados. Considere aumentar o buffer de log se for pequeno ou considere mover arquivos de log para discos mais rápidos, como discos distribuídos.
Select event, total_waits, total_timeouts, time_waited, average_wait from v$system_event where event = 'log buffer space'; Select sid, event, seconds_in_wait, state from v$session_wait where event = 'log buffer space'; Select name, value from v$sysstat where name in ('redo log space requests');
O pct_buff_alloc_retries deve ser zero ou menor que 0,01 (<1%). Se for maior, considere aumentar o buffer de log. Se for maior, considere mover os arquivos de log para discos mais rápidos, como discos distribuídos.
Select v1.value as redo_buff_alloc_retries, v2.value as redo_entries, trunc(v1.value/v2.value,4) as pct_buff_alloc_retries from v$sysstat v1, v$sysstat v2 where v1.name = 'redo buffer allocation retries' and v2.name = 'redo entries';
leitura sequencial do arquivo de log
O processo está esperando que os blocos sejam lidos do redo log online na memória. Isso ocorre principalmente na inicialização da instância e quando o processo ARCH arquiva os logs de redo online preenchidos.
gravação paralela do arquivo de log
O processo está aguardando que os blocos sejam gravados em todos os membros do redo log online em um grupo. Normalmente, o LGWR é o único processo a ver esse evento de espera. Ele aguardará até que todos os blocos tenham sido gravados para todos os membros.
sincronização do arquivo de registro
O processo está esperando que o LGWR termine de liberar o buffer de log para o disco. Isso ocorre quando um usuário confirma uma transação. (Uma transação não é considerada confirmada até que todo o redo para recuperar a transação tenha sido gravado com sucesso no disco.)
Um processo LGWR lento pode introduzir esperas de sincronização do arquivo de log, o que faz com que o usuário experimente tempos de espera durante a confirmação ou reversão. Os eventos de gravação paralela do arquivo de log e espera de sincronização do arquivo de log são inter-relacionados e devem ser tratados simultaneamente.
Devemos tentar alocar os logs de redo para o disco de alto desempenho (disco de estado sólido). Além disso, devemos tentar reduzir a carga no LGWR reduzindo commits nos aplicativos.
A peça de backup a quente manual também pode introduzir estresse no sistema, gerando muitas coisas de refazer. Portanto, evite isso durante o horário de pico
Às vezes, o LGWR está faminto por recursos de CPU. Se o servidor estiver muito ocupado, o LGWR também poderá ficar sem CPU. Isso levará a uma resposta mais lenta do LGWR, aumentando as esperas de 'sincronização do arquivo de log'. Afinal, essas chamadas de sistema e chamadas de E/S devem usar a CPU. Nesse caso, a 'sincronização do arquivo de log' é um sintoma secundário e resolver a causa raiz do alto uso da CPU reduzirá as esperas de 'sincronização do arquivo de log'.
Devido a problemas de falta de memória, o LGWR também pode ser paginado. Isso pode levar a uma resposta mais lenta do LGWR também.
desfazer extensão de segmento
A sessão está aguardando que um segmento de desfazer seja estendido ou reduzido.
escrever esperas completas
A sessão está aguardando que um buffer solicitado seja gravado no disco; o buffer não pode ser usado enquanto está sendo escrito.
Trava:cadeias de buffer de cache
As travas das cadeias de buffers de cache são usadas para proteger uma lista de buffers no cache de buffer. Essas travas são usadas ao pesquisar, adicionar ou remover um buffer do cache de buffer.
Os blocos no cache de buffer são colocados em listas vinculadas (cadeias de buffer de cache) que ficam suspensas em uma tabela de hash. A cadeia de hash na qual um bloco é colocado é baseada no DBA e na CLASSE do bloco. Cada cadeia de hash é protegida por uma única trava filho. Os processos precisam obter a trava relevante para permitir que eles verifiquem uma cadeia de hash em busca de um buffer para que a lista vinculada não seja alterada abaixo deles.
Contenção nesta trava geralmente significa que há um bloco que está em grande disputa (conhecido como bloco quente).
Para identificar a cadeia de buffers fortemente acessada e, portanto, o bloco disputado, observe as estatísticas de travas para as travas das cadeias de buffers de cache usando a visualização V$LATCH_CHILDREN. Se houver uma trava filho de cadeias de buffers de cache específica que tenha muito mais GETS, MISSES e SLEEPS quando comparada com as outras travas filhas, então essa é a disputa para trava filho.
Essa trava possui um endereço de memória, identificado pela coluna ADDR.
SELECT addr, sleeps FROM v$latch_children c, v$latchname n WHERE n.name='cache buffers chains' and c.latch#=n.latch# and sleeps > 100 ORDER BY sleeps /
Use o valor na coluna ADDR unida à visualização V$BH para identificar os blocos protegidos por essa trava. Por exemplo, dado o endereço (V$LATCH_CHILDREN.ADDR) de uma trava muito disputada, isso consulta os números do arquivo e do bloco:
SELECT file#, dbablk, class, state, TCH FROM X$BH WHERE HLADDR='address of latch';
X$BH.TCH é uma contagem de toque para o buffer. Um valor alto para X$BH.TCH indica um bloco ativo.
Muitos blocos são protegidos por cada trava. Um desses buffers provavelmente será o bloco quente. Qualquer bloco com um valor de TCH alto é um bloco quente em potencial. Execute esta consulta várias vezes e identifique o bloco que aparece consistentemente na saída.
Depois de identificar o bloco ativo, consulte DBA_EXTENTS usando o número do arquivo e o número do bloco para identificar o segmento.
Informações importantes sobre o evento de espera
A visualização v$session_wait exibe informações sobre eventos de espera para os quais as sessões ativas estão aguardando no momento. A seguir está a descrição dessa exibição e contém algumas colunas muito úteis, especialmente as referências P1 e P2 aos objetos associados aos eventos de espera.
desc v$session_wait Name Null? Type --------------------------- -------- ------------ SID NUMBER SEQ# NUMBER EVENT VARCHAR2(64) P1TEXT VARCHAR2(64) P1 NUMBER P1RAW RAW(4) P2TEXT VARCHAR2(64) P2 NUMBER P2RAW RAW(4) P3TEXT VARCHAR2(64) P3 NUMBER P3RAW RAW(4) WAIT_CLASS_ID NUMBER WAIT_CLASS# NUMBER WAIT_CLASS VARCHAR2(64) WAIT_TIME NUMBER SECONDS_IN_WAIT NUMBER STATE VARCHAR2(19)
Usando v$session_wait, é fácil interpretar cada parâmetro de evento de espera usando as colunas de texto descritivas correspondentes para esse parâmetro. Além disso, colunas de classe de espera foram adicionadas para que vários eventos de espera pudessem ser agrupados nas áreas relacionadas de processamento, como rede, aplicativo, inatividade, simultaneidade, etc.
Essa coluna também foi adicionada à tabela v$session a partir de 10g . Então você pode usar v$session para encontrar todos os detalhes
Cada evento de espera contém outros parâmetros que fornecem informações adicionais sobre o evento.
Como encontrar as informações sobre o evento de espera e seu parâmetro
The meaning of each wait event corresponds know by querying the V$EVENT_NAME p1, p2, p3 of col name format a25; col p1 format a10; col p2 format a10; col p3 format a10; SELECT NAME, PARAMETER1 P1, PARAMETER2 P2, PARAMETER3 P3 FROM V$EVENT_NAME WHERE NAME = '&event_name';
Digamos, por exemplo, que pegamos
Os valores de entrada event_name:db file dispersa leitura
Valor original de 3:WHERE NAME =‘&event_name A’
O novo valor 3:WHERE NAME =‘db file dispersa leitura’
O nome P1 P2 P3
db arquivo de leitura espalhado arquivo # bloco # blocos
arquivo #:número do arquivo de dados
Bloco #:número do bloco inicial
blocos:para ler o número do bloco de dados
Agora vamos ver como as informações acima podem nos ajudar a capturar várias coisas
Suponha que uma sessão específica aguarda um evento de espera de buffer ocupado, o objeto de banco de dados que causa esse evento de espera pode ser facilmente determinado:
select username, event, p1, p2 from v$session_wait where sid = 4563;
A saída desta consulta para uma sessão específica com SID 4563 pode ter esta aparência:
USERNAME EVENT SID P1 P2 ---------- ----------------- --- -- --- APPS buffer busy waits 4563 11 545
As colunas P1 e P2 permitem que o DBA determine os números de arquivo e bloco que causaram esse evento de espera. A consulta abaixo recupera o nome do objeto que possui o bloco de dados 155, o valor de P2 acima:
SQL> select segment_name,segment_type from dba_extents where file_id = 11 and 45 between block_id and block_id + blocks – 1;
A capacidade de analisar e corrigir eventos de espera do Oracle Database é fundamental em qualquer projeto de ajuste. A maioria das atividades em um banco de dados envolve a leitura de dados, portanto, esse tipo de ajuste pode ter um impacto enorme e positivo no desempenho.
Nota:Ao fazer a análise de espera, é fundamental lembrar que todos os bancos de dados Oracle passam por eventos de espera e que a presença de esperas nem sempre indica um problema. Na verdade, todos os bancos de dados bem ajustados têm algum gargalo.
podemos usar o evento 10046 para rastrear o evento de espera da sessão também
Também lê
Documentação do Oracle
v$active_session_history
Explicar o plano no Oracle