O dia a dia real de quem administra banco de dados
A maioria das pessoas acha que um administrador de banco de dados passa o dia inteiro digitando comandos SQL e assistindo linhas de código subirem em monitores verdes. A realidade é bem mais chatinha. Você passa metade do tempo resolvendo problemas que ninguém previu e a outra metade tentando convencer gestores de que o servidor não está lento porque eles abriram três abas a mais no navegador. Se você está pesquisando sobre administrador de banco de dados o que faz, provavelmente quer entender se essa área é pra você ou apenas tentar sobreviver num job que já conseguiu. Vou tentar ser direto sobre isso, baseado no que eu vi funcionando na prática e no que deu errado também.
administrador de banco de dados o que faz no fim das contas
No papel, o job description pede alguém que gerencia infraestrutura, otimiza consultas, faz backup, garante disponibilidade e documentação. Na prática, você é o cara que desliga às duas da manhã porque uma query que foi inserida no sábado à tarde começou a travar o sistema todo. Tem dias que você mal consegue comer algo quente durante o expediente. O trabalho dividido costuma ficar assim: cerca de trinta por cento em manutenção preventiva e Monitoring, vinte e cinco em resposta a incidentes, vinte em modelagem e aprovação de esquemas novos que os desenvolvedores tentaram empurrar sem consultar ninguém, quinze em automação pra tentar reduzir essas outras porcentagens, e dez que são pura política de escritório discutindo quem paga a conta da licença do Oracle quando o projeto cresce.
Eu já trabalhei em ambientes onde tinha banco de dados legado rodando Oracle em produção enquanto o time de frontend nem sabia que ele existia. O desenvolvedor principal tinham ido embora dois anos antes e deixado pras próximas gerações uma aplicação que fazia join em tabela com trezentas colunas. Cada request do usuário disparava uma query que levava quarenta segundos pra rodar. O pior é que ninguém reclamava porque o sistema só era usado internamente por oito pessoas que já tinham costume de esperar.
As partes que ninguém contam nas entrevistas
Backup não é só agendar e torcer. Eu já perdi a conta das vezes que vi alguém configurar um backup script bonitinho e depois esquecer que precisava validar se realmente funcionava até o dia em que o disco falhou. Aí você descobre que o backup estava sendo escrito num caminho que não existia mais desde a última migração de servidor, ou que o tamanho do arquivo ultrapassava o limite de armazenamento disponível, ou simplesmente que o log de erro estava sendo ignorado porque o script redirecionava stderr pra /dev/null sem revisão. A regra prática que eu uso é simples. Todo backup tem que ter uma validação de restore programada pelo menos uma vez por trimestre. Se você não consegue restaurar, você não tem backup, tem só esperança. Isso vale pra qualquer motor, MySQL, PostgreSQL, SQL Server. O princípio é o mesmo.
Otimização de performance é outra área cheia de armadilhas. O óbvio é adicionar índice. Mas índice não é de graça. Cada índice novo aumenta o tempo de insert, update e delete. Tabela com muitos índices pode ter performance de escrita cair pela metade em comparação com uma versão sem índices extras. Eu vi caso de aplicação onde a remoção de três índices órfãos em uma tabela de log reduziu o tempo médio de gravação de oitenta milissegundos para doze milissegundos, porque os inserts eram muito mais frequentes do que as queries de leitura naquela tabela específica. Também é comum desenvolvedores caírem na armadilha de usar SELECT * achando que o banco vai buscar só o necessário. Isso não acontece. O banco busca as colunas que você pediu. Se pediu tudo, recebe tudo. Em tabelas com campos text ou binary, isso pode significar transferir gigabytes de informação pra uma aplicação que só precisa de dois campos. A solução é sempre especificar as colunas que realmente precisa, mesmo que isso demande esforço adicional durante o desenvolvimento.
As ferramentas que realmente importam
Todo mundo cita as mesmas coisas nos artigos genéricos. MySQL, PostgreSQL, MongoDB, Redis. Mas o que faz diferença no dia a dia são as ferramentas de acompanhamento. Monitoramento de processamento, memória, conexões ativas, lock contention. No meu dia a dia, as principais métricas que eu acompanho sem falhar são:
👉 Clique no botão abaixo para saber mais sobre o assunto!
- Threads conectadas versus o máximo configurado
- Tempo de resposta médio das queries mais pesadas
- Uso de espaço em disco com projeção baseada na taxa de crescimento dos últimos trinta dias
- Tempo de I/O no disco, especialmente latency de leitura e escrita
- Deadlocks e locks em espera
Ferramentas como pg_stat_activity no PostgreSQL ou sys.dm_exec_requests no SQL Server dão uma visão direta do que está acontecendo naquele exato momento. O problema é que muitos administradores novatos olham pra esses dados e não sabem interpretar. Ver uma query rodando há cinco minutos não significa automaticamente que ela está travada. Pode estar processando um lote grande, fazendo um merge sort, ou esperando I/O em disco. A diferença entre identificar isso rapidinho e perder meia hora explorando o caminho errado é experiência prática, não teoria.
O que dá errado e como resolver na hora
Um dos problemas que eu encontrei e resolvi de forma não óbvia aconteceu com um servidor PostgreSQL que começou a apresentar lentidão intermitente. As queries pareciam rápidas na maior parte do tempo, mas de vez em quando travavam por quinze ou vinte segundos. O monitoramento de CPU e memória não mostrava nada anormal. O disco também estava tranquilo. Eu gastei três dias esse problema antes de descobrir que o trigger de autovacuum estava colidindo com processos de backup contínuo. O workaround foi ajustar o parkautovacuum para rodar em janelas diferentes do backup e configurar um limitador de I/O separando os processos. O resultado foi estabilidade imediata. O detalhe importante aqui é que o sintoma não tinha relação aparente com a causa raiz. Lentidão intermitente é sempre mais difícil de diagnosticar do que lentidão constante, porque ela esconde padrões que só aparecem em horários específicos ou sob carga específica.
Outro problema clássico é falta de planejamento de crescimento. Eu já vi banco de dados crescer tão rápido que o volume de dados ultrapassou a capacidade do storage antes que o time de infraestrutura percebesse. Quando perceberam, precisaram fazer migração de disaster recovery com downtime planejado de quatro horas, que caiu no meio do horário comercial porque ninguém havia coordenado a janela corretamente. A lição prática é simples. Estabeleça alertas de crescimento mensuráveis. Uma projeção de crescimento de duzentos gigabytes por mês em um storage de dois terabytes disponíveis significa que você tem menos de um ano para se preparar para expansão. Se a projeção for de duzentos gigabytes por ano, você tem cerca de dez anos. A diferença entre esses dois cenários é enorme e muda completamente a urgência das decisões.
Caminhos de carreira e o que aprendi na prática
Se você está entrando nessa área, comece entendendo o motor que vai usar no seu primeiro emprego. Não tente aprender tudo de uma vez. Domine pelo menos um sistema relacional e entenda profundamente como ele funciona por dentro. Índices, transações, isolamento, locking, planos de execução. Depois expanda. A parte que ninguém enfatiza o suficiente é comunicação. Um administrador de banco de dados que não consegue explicar tecnicamente pra uma pessoa não técnica por que determinada decisão é arriscada vai ter muita dificuldade de avançar na carreira. Você vai precisar traduzir risco técnico em risco de negócio com frequência. Exemplos comuns incluem explicar por que não se pode migrar de versão no meio do expediente, ou por que determinado schema design vai gerar problemas de performance no futuro.
Existem certificações como OCP para Oracle ou PGDP para PostgreSQL que podem ajudar no currículo inicial, mas a experiência real vem de lidar com problemas que não têm manual. As situações mais instructivas costumam ser aquelas em que nada do que você leu funciona e você precisa combinar conhecimento teórico com observação prática e tentativa e erro controlado. O mercado ainda tem demanda forte pra quem sabe fazer o básico bem feito. Muitas empresas contratam alguém pra bancada o banco e depois percebem que precisam de alguém pra construir infraestrutura sólida. A diferença entre os dois perfis é consistente. O primeiro resolve problemas pontuais. O segundo projeta sistemas que não geram problemas pontuais constantemente.
Se sua dúvida inicial era sobre administrador de banco de banco de dados o que faz, espero que esse texto tenha mostrado pelo menos um pouco do que acontece por trás daquela função. É trabalho técnico, sim, mas também é trabalho de gestão de risco, comunicação e planejamento. E, honestamente, tem dias que é só trocar café e rezar pra nada explodir.
