A leitura de um bloco é o acesso típico por índice, e a média por leitura mede o armazenamento. Média alta aponta para o disco ou para o caminho até ele, mas a distribuição diz se o problema é de todas as leituras ou de poucas.
Sintomas
No Diagnóstico, aparece um destes achados (LEITURA_LENTA), com o nome do evento no fim do título:
- Leitura de bloco único lenta em db file sequential read, quando a média por leitura está muito acima do que um armazenamento saudável entrega. O texto lembra que disco rápido ou flash responde abaixo de 1 ms e pede para verificar o armazenamento e a fila de I/O.
- Leitura de bloco único acima do esperado em db file sequential read, quando a média passa do esperado sem chegar a tanto.
O texto traz a média em milissegundos, o número de leituras e o percentual do tempo total, por exemplo Média de 12,5 ms por leitura em 4 leituras (4,9% do tempo total). O link é Ver distribuição de latência, ou Ver no perfil quando o evento não tem tabela de latência.
A severidade é alta no primeiro título e média no segundo. Quando o evento pesa pouco no tempo total, o achado sai como baixa, só como registro: a média é ruim, mas acelerar o armazenamento quase não muda o tempo desta operação.
Vale para as esperas de leitura de um bloco por vez, como db file sequential read e cell single block physical read. Cada evento lento gera o próprio achado.
Causa
O plano decide quantas leituras a sessão faz; o armazenamento decide quanto cada uma demora. Média alta costuma vir de:
- armazenamento sobrecarregado no período, com fila de I/O: outras sessões, backup, lote noturno ou outro sistema no mesmo storage;
- leituras que vão ao disco em vez de cair no cache do storage ou no flash (no Exadata, o bloco não estava no flash cache);
- problema no caminho de I/O: multipath, controladora, rede do storage;
- poucas leituras muito lentas puxando a média para cima, com a maioria rápida.
Resolução
- Veja a distribuição antes da média. Na distribuição de latência do evento e em Leituras, com faixas para disco (cortes de 5 ms a 1 s) e para SSD (cortes de 15 µs a 10 ms), confira se todas as leituras são lentas ou se poucas lentas pesam mais.
- Confira o armazenamento no Período do trace: tempo de serviço e fila dos discos, por exemplo com o
iostat, e o que mais rodava no mesmo storage.iostat -x 5 - No banco, compare com a latência que a instância inteira vê no mesmo evento. Os números são acumulados desde o início da instância.
select wait_time_milli, wait_count from v$event_histogram where event = 'db file sequential read' order by wait_time_milli; - Reduza o número de leituras, que costuma render mais que acelerar o disco: veja muitas leituras de bloco único.
- Se o problema é do storage, leve a média, as faixas e o período do relatório para quem cuida dele.
Como confirmar
Depois da mudança no armazenamento ou no plano, gere um trace novo da mesma operação. Na linha do evento no perfil, Média (s) deve cair, para perto do que o armazenamento do banco entrega (leituras traz a referência de disco e de SSD), e o achado some. Compare também as faixas em Leituras: a parte lenta deve encolher.
No relatório
No relatório de exemplo, as 2 leituras de db file sequential read têm média de 0,000650 s (0,65 ms), sem achado. Os links abrem as seções do exemplo:
- Diagnóstico: o achado e o link Ver distribuição de latência.
- Perfil, linha db file sequential read: Ocorrências, Média (s) e Máx (s).
- Distribuição de latência do evento: quantas leituras caem em cada faixa.
- Leituras, faixas de disco e faixas de SSD: faixas mais finas para todas as esperas de leitura.
- Objetos com mais tempo de espera: em que tabela ou índice o tempo foi gasto.