Banco de dados lento não é sempre o banco: anatomia de um troubleshooting de performance Oracle

"O banco está lento" é, provavelmente, a frase mais comum — e mais imprecisa — que chega para qualquer DBA ou administrador de infraestrutura. Ela descreve um sintoma, não um diagnóstico. E a armadilha mais comum em troubleshooting de performance é começar a investigação dentro do banco de dados, quando, em boa parte dos casos reais, a causa raiz está em uma camada completamente diferente: storage, sistema operacional ou rede.

Este artigo percorre, de forma estruturada, como investigar um caso real e recorrente em ambientes Oracle: lentidão generalizada causada por saturação de I/O em disco, com sintomas que aparecem no banco, mas nascem na infraestrutura abaixo dele. O objetivo não é um tutorial de comandos — é mostrar a lógica de investigação que separa quem resolve a causa de quem só trata o sintoma.

Neste artigo

1. O sintoma: lentidão "no banco" sem mudança aparente

2. Por que o instinto de olhar só o Oracle costuma errar o diagnóstico

3. Camada 1: o que o sistema operacional já está te dizendo

4. Processos em uninterruptible sleep — o sinal mais revelador

5. Camada 2: descendo até o storage e o ASM

6. Camada 3: voltando ao Oracle com hipótese, não suposição

7. O padrão geral: de fora para dentro, não de dentro para fora

8. Por que isso importa também para quem não é DBA

9. Conclusão

O sintoma: lentidão "no banco" sem mudança aparente {#sintoma}

O cenário típico: um sistema que funcionava normalmente começa a apresentar lentidão perceptível — telas demorando para carregar, relatórios que levavam segundos passando a levar minutos, filas de processamento batch atrasando. Nenhuma mudança aparente foi feita: nenhum deploy novo, nenhuma alteração de configuração, nenhum aumento brusco de usuários.

É exatamente esse "nada mudou, mas piorou" que costuma indicar um problema de infraestrutura subjacente degradando gradualmente — não um problema de lógica de aplicação ou de query mal escrita, que tipicamente aparece de forma mais abrupta e correlacionada a um deploy específico.

Por que o instinto de olhar só o Oracle costuma errar o diagnóstico {#instinto}

Quando "o banco está lento", o caminho mais natural é abrir o Oracle Enterprise Manager ou rodar uma consulta de sessões ativas e procurar queries lentas. Isso não está errado — mas é insuficiente quando o problema não é a query, é o hardware que sustenta a query.

Um banco de dados Oracle, em última análise, é um processo de sistema operacional fazendo chamadas de leitura e escrita em disco. Se o disco está saturado, toda operação de I/O fica mais lenta — não uma query específica, mas o banco inteiro, de forma proporcional ao quanto cada operação depende de leitura/escrita. Isso produz um padrão de sintoma muito específico: lentidão generalizada, sem uma query "culpada" isolada, e sem correlação com alteração de código.

Camada 1: o que o sistema operacional já está te dizendo {#camada-so}

Antes de qualquer ferramenta específica do Oracle, o sistema operacional Linux já carrega evidência direta de saturação de I/O, através de ferramentas básicas:

• iostat -x: mostra utilização de disco, tempo médio de espera (await) e percentual de utilização (%util) por dispositivo. Quando %util se aproxima consistentemente de 100% e await sobe de forma anormal, o disco está sendo o gargalo — não a CPU, não a memória.

• vmstat: revela quantos processos estão esperando na fila de execução (r) e, mais importante neste cenário, quantos estão bloqueados esperando I/O (b). Um número alto e persistente na coluna b é evidência direta de processos travados esperando resposta do storage.

• top/htop: aqui o sinal mais revelador costuma aparecer no estado dos processos, detalhado a seguir.

Processos em uninterruptible sleep — o sinal mais revelador {#uninterruptible-sleep}

Em sistemas Linux, todo processo tem um estado. Os mais comuns são running (R, executando ou pronto para executar) e sleeping (S, aguardando algum evento, de forma interrompível). Existe, porém, um terceiro estado frequentemente ignorado: D — uninterruptible sleep.

Um processo em estado D está esperando uma operação de I/O de baixo nível terminar — e, por definição, não pode ser interrompido nem mesmo por um sinal do kernel enquanto está nesse estado. Isso significa que nem um kill -9 resolve um processo travado em D: o processo não vai responder até que a operação de disco que ele está esperando finalmente complete (ou falhe).

Quando se observa múltiplos processos do Oracle simultaneamente em estado D, de forma persistente (não um pico isolado de um segundo), isso é evidência praticamente direta de que o subsistema de armazenamento não está respondendo na velocidade que o banco de dados está exigindo dele. Em outras palavras: o Oracle não está lento porque está mal configurado — ele está lento porque está esperando o disco, e o disco não está entregando.

Esse é o ponto de virada típico de uma investigação: sair da pergunta "o que está errado na configuração do banco?" para "o que está acontecendo na camada de armazenamento abaixo dele?".

Camada 2: descendo até o storage e o ASM {#camada-storage}

Em ambientes Oracle, é comum o armazenamento ser gerenciado pelo ASM — Automatic Storage Management, uma camada própria da Oracle que abstrai discos físicos em disk groups. Quando a suspeita aponta para saturação de I/O, a investigação no ASM e na camada de storage costuma seguir esta sequência:

• Verificar se algum disco do disk group desapareceu ou está em estado degradado. Um disco que cai de um disk group redundante (normal/high redundancy) não derruba o banco imediatamente — mas reduz a capacidade de I/O disponível e força o ASM a redistribuir carga sobre os discos restantes, criando exatamente o padrão de saturação observado.

• Conferir a saúde da controladora RAID (em ambientes com RAID por hardware, como controladoras LSI/Broadcom MegaRAID) — um disco físico falhando ou em processo de rebuild consome banda de I/O significativa da própria controladora, competindo diretamente com as operações normais do banco.

• Avaliar se o volume de dados simplesmente cresceu além da capacidade de IOPS dimensionada originalmente — esse é o cenário mais "saudável" de se descobrir, porque significa que a infraestrutura estava correta para o volume anterior, e agora precisa de expansão — não de correção de um erro.

Esse processo de eliminação é o que transforma "o banco está lento" em um diagnóstico concreto e acionável: "o disk group X perdeu um disco e está operando em modo degradado, sobrecarregando os discos remanescentes", por exemplo — uma frase que já indica exatamente qual ação corrige o problema.

Camada 3: voltando ao Oracle com hipótese, não suposição {#camada-oracle}

Só depois de eliminar (ou confirmar) a hipótese de infraestrutura é que faz sentido voltar ao instrumental específico do Oracle — agora com uma pergunta muito mais precisa do que "por que está lento":

• AWR (Automatic Workload Repository) e ASH (Active Session History): permitem confirmar, com dado histórico do próprio banco, se os wait events dominantes no período da lentidão são eventos de I/O (como db file sequential read ou db file scattered read em volume anormal) — o que corrobora a hipótese de storage — ou eventos de outra natureza (lock, contenção de CPU, parsing excessivo), o que indicaria uma causa diferente.

• V$SESSION e V$SESSION_WAIT: mostram em tempo real o que cada sessão ativa está esperando — útil para confirmar, no momento exato do incidente, que múltiplas sessões estão paradas no mesmo tipo de espera de I/O.

Essa ordem de investigação — sistema operacional, depois storage/ASM, depois instrumentação específica do Oracle — é o que evita o erro mais custoso em troubleshooting: passar horas ajustando parâmetros de banco de dados (memória, cache, planos de execução) para um problema que, na origem, é um disco físico falhando ou uma controladora RAID sobrecarregada.

O padrão geral: de fora para dentro, não de dentro para fora {#padrao-geral}

Generalizando o caso específico de I/O, existe um princípio de troubleshooting que vale para praticamente qualquer "sistema lento" em produção:

1. Confirme o sintoma com dado, não com percepção — "está lento" precisa virar "a latência subiu de X para Y" ou "o tempo de resposta dobrou às 14h".

2. Olhe a infraestrutura abaixo da aplicação antes de olhar a aplicação — sistema operacional, storage, rede, virtualização. Em boa parte dos casos reais, é aí que a causa está.

3. Só depois disso, investigue a camada específica do software (banco de dados, aplicação, código) — agora com hipóteses já reduzidas pelo processo de eliminação anterior.

Esse padrão é o oposto do instinto mais comum, que é abrir direto a ferramenta da camada mais visível (o próprio banco de dados, o próprio sistema) e procurar o problema ali primeiro — o que costuma levar a ajustes que não resolvem nada, porque a causa nunca esteve naquela camada.

Por que isso importa também para quem não é DBA {#por-que-importa}

Para um gestor de TI ou dono de empresa que não vai pôr a mão em iostat ou AWR, o ponto prático deste artigo é outro: a qualidade do troubleshooting de banco de dados depende de profundidade em múltiplas camadas — sistema operacional, storage, virtualização e o próprio banco — não apenas em conhecimento de SQL ou administração do Oracle isoladamente.

Esse é, inclusive, um critério legítimo para avaliar um fornecedor de suporte ou um parceiro de infraestrutura: a pergunta certa não é só "vocês conhecem Oracle?", mas "quando o banco está lento, vocês sabem investigar abaixo dele, ou só dentro dele?" A diferença entre essas duas respostas é, frequentemente, a diferença entre resolver um incidente em uma hora ou ficar dias ajustando parâmetros que nunca eram a causa real.

Conclusão {#conclusao}

Lentidão de banco de dados raramente nasce dentro do banco de dados. Ela nasce na camada que sustenta o banco — e só se manifesta lá, porque é onde o usuário sente o efeito. Um troubleshooting eficiente segue o caminho inverso ao do sintoma: do sistema operacional para o storage, do storage para o ASM, e só então, com hipótese formada, para dentro do próprio Oracle.

É esse tipo de profundidade — entender não só SQL e tuning, mas o hardware, o sistema operacional e a virtualização por trás do banco — que separa um diagnóstico correto de uma sequência de tentativas e erros.

A Nyverra opera e dá suporte a ambientes de banco de dados críticos — Oracle, PostgreSQL, MariaDB e SQL Server — com troubleshooting que vai da camada de aplicação até o storage físico. Conheça a solução completa em nyverra.com.br/pt-br/services.