Administrador De Banco De Dados O Que Faz

O trabalho real de quem gerencia bancos de dados

A maior parte das pessoas acha que administrador de banco de dados é só quem clica em botões num software e torce para nada dar erro. Quando eu entrei na área, fazia exatamente isso. Dois anos depois, aprendi que o trabalho real acontece quando nada parece estar acontecendo, e você precisa decidir se sobe uma cópia de produção para homologação às três da manhã ou não sobe. Um DBA moderno lida com infraestrutura, performance, segurança e, principalmente, com a pressão de manter tudo ligado enquanto todo mundo acha que banco de dados se configura uma vez e esquece.

administração de banco de dados: o que faz na prática

O dia começa com check-ins. Confirmações de backup, tamanho dos tablespaces, estado dos jobs agendados, latência das queries mais pesadas. Se você chega e vê que um backup noturno falhou, seu resto do dia já nasce comprometido, não importa o que mais aconteça. O cerne da função envolve manutenção preventiva e corretiva. Manutenção preventiva é rebuild de índices, atualização de estatísticas, análise de growth de tabelas. Corretiva é o tipo de coisa que te acorda sabendo que algum application server está fazendo um SELECT * em uma tabela com 40 milhões de linhas sem WHERE. Eu passei seis meses em uma implementação onde o time de desenvolvimento não sabia que EXISTS era mais barato que COUNT(*) para verificar se um registro existia. Cada vez que a query rodava, o lock durava o suficiente para bloquear gravações em tabelas adjacentes. A solução foi um índice covering e uma regra de code review obrigatória para queries que acessassem tabelas acima de cinco milhões de registros. Também tem o trabalho menos visível: planejamento de capacidade. Saber que seu storage vai encher em 47 dias com a taxa de crescimento atual não é drama, é o tipo de coisa que te tira o sono no domingo à noite. O ideal é ter um buffer de pelo menos 90 dias de espaço disponível antes de solicitar uma expansão.

Ferramentas que um profissional costuma usar

Não existe um único pacote. O conjunto de ferramentas depende totalmente do SGBD e do ambiente. Para bancos relacionais, as bases são as próprias utilidades nativas do fabricante. No PostgreSQL, por exemplo, a combinação de pg_stat_statements, auto_explain e pgbouncer resolve 80% dos problemas de observabilidade. No SQL Server, SQL Server Profiler deu lugar ao Extended Events, que é mais complexo mas infinitamente mais leve em produção. Para monitoramento contínuo, soluções como Zabbix, Prometheus com exporter específico do banco, ou ferramentas comerciais como SolarWinds Database Performance Analyzer. Eu já trabalhei em ambientes onde o DPA pagava sozinho porque reduziu o tempo médio de resolução de incidentes de performance de seis horas para pouco mais de quarenta minutos. Automação também entra nessa conta. Scripts Python com SQLAlchemy, PowerShell para SQL Server, Ansible para provisioning de instâncias. Ambientes que não automatizam procedimentos rotineiros de administração de banco de dados o que faz vão acumular débito técnico operacional rapidamente.

Decisões que parecem simples mas não são

Migração de versão é o exemplo clássico. Atualizar de uma versão para outra parece tranquilo até você descobrir que a nova versão mudou o comportamento padrão do lock manager. Já vi uma migração do MySQL 5.7 para o 8.0 travar um banco de produção inteira porque o innodb_lock_wait_timeout padrão era diferente e um job noturno que nunca causava problema passou a matar transações ativas de usuários. Outra decisão complicada é escolher entre consistência forte e disponibilidade. Replicação síncrona garante que você não perca dados, mas custa latência. Replicação assíncrona é mais rápida, mas em caso de failover você pode perder minutos de transações. Ninguém gosta de tomar essa decisão, e todo mundo quer sua opinião quando vai acontecer.

O que a maioria dos profissionais erra

Erros comuns incluem tratar backup como sinônimo de recuperação. Fazer o backup e não testar a restauração é como comprar seguro de carro e nunca simular um acidente. Eu trabalhava em uma empresa onde o backup era validado semanalmente por verificação de checksum, mas nunca restaurávamos para um ambiente isolado para confirmar que os dados estavam intactos e legíveis. Quando precisamos restaurar após um corruption de disk, metade dos backups tinha arquivos corrompidos silenciosamente por causa de um parâmetro errado no script de agregação. Levou quatro dias para recuperar um dia inteiro de operação. Outro erro frequente é não documentar mudanças. Se você ajustou um parâmetro de shared_buffers às duas da manhã e não anotou o valor anterior, o próximo DBA que chegar vai achá-lo meio maluco quando o banco começar a swapping memória.

Skills técnicas versus habilidades humanas

A parte técnica é estudável. Índices, normalização, query plans, replication topologies. Você aprende lendo documentação, fazendo labs, quebrando ambientes de teste. A parte difícil é comunicar para um desenvolvedor que a arquitetura dele está errada sem transformar a conversa num conflito pessoal. Já perdi a credibilidade duas vezes por tentar explicar que uma junction table com_trigger de atualização em cascata era pior do que deixar o aplicativo resolver a integridade referencial. A solução final foi escrever um documento técnico com benchmarks comparativos, não argumentar em reunião. Também ajuda saber dizer não. Existe limite para quantas solicitações de cópia de produção podem ser feitas num mesmo mês. Definir um SLA claro e seguir ele reduz tanto a frustração sua quanto a dos outros.

Por onde começar se você quer seguir essa área

Comece entendendo SQL de verdade. Não o básico de SELECT e INSERT, mas join types, subqueries correlacionadas, CTEs, window functions. A maioria dos problemas de performance que eu vi na vida tinha raiz em SQL mal escrito. Depois, escolha um SGBD e instale ele localmente. Crie tabelas, insira dados, quebre coisas de propósito. Aprenda a ler um execution plan. Isso vale mais do que qualquer certificação inicial. Quando você consegue olhar para um plano de execução e identificar que um index scan virou um table scan porque uma estatística desatualizada enganou o otimizador, você já sabe mais do que meio caminho andado. Finalmente, exponha-se a incidentes reais. Traga um banco pequeno para o trabalho, deixe ele crescer até virar algo que preocupa. Administrador de banco de dados o que faz não se aprende assistindo tutorial, se aprende lidando com o pânico de uma replication lag que cresceu de 30 segundos para trinta minutos sem motivo aparente.

Limitações reais da profissão

Não adianta fingir que é uma carreira sem atritos. On-call é inevitável. Você vai receber ligações fora do horário, às vezes por coisas que poderiam ter sido evitadas com monitoramento melhor, às vezes por falhas em camadas que não são do banco de dados mas parecem ser porque o usuário associa tudo a lentidão de consulta. Há também o teto de reconhecimento. Empresas maduras entendem o valor de um bom DBA. Empresas que tratam banco de dados como algo que "os desenvolvedores resolvem" vão cobrar entregas impossíveis e culpar você quando a aplicação travar por timeout. Alternativas existem. Você pode migrar para posições de data engineering, arquitetura de dados, ou infraestrutura como código. Muitas dessas trajetórias começam exatamente com a base técnica que um DBA constrói, só que com foco diferente.

O mercado ainda demanda profissionais que entendam tanto o lado operacional quanto o estratégico. Não é fácil, mas quem domina a área raramente fica desempregado.