Classificacao Das Bases

Como fazer classificacao das bases no seu dia a dia

Você chega no escritório, o chefe pede uma auditoria rápida do parque de bancos de dados, e você percebe que não tem ideia de quantas bases existem, onde estão rodando, qual o SGBD e para quê cada uma serve. Isso acontece com frequência. A classificacao das bases é basicamente o processo de inventariar, categorizar e documentar os bancos de dados de uma organização para que alguém consiga navegar por eles sem perder três dias. A parte chata é que raramente existe um inventário atualizado. O que existe são scripts que foram rodados uma vez em 2019 e ninguém mais olhou. Comece pelo básico: gere um catálogo brutos de todas as conexões ativas. Em SQL Server, uma query simples nas views do sistema retorna instâncias, versões, collation e tamanho. Em PostgreSQL, você consulta o pg_database. Em MySQL, show databases mais informações do performance_schema. O problema real começa quando você tenta padronizar esses dados vindos de tecnologias diferentes.

Metodologia prática que funciona

A classificação que eu uso segue quatro dimensões, nada revolucionário mas bastante eficaz quando aplicada com consistência. A primeira é o critério técnico: qual SGBD, versão, engine, storage. A segunda é o critério funcional: produção, desenvolvimento, homologação, relatórios, Data Warehouse, staging. A terceira é o critério de negócio: área responsável, dono do dado, sistema origem, nível de criticidade. A quarta é o critério de conformidade: dados sensíveis, LGPD, regulatório, retenção obrigatória. Eu monto uma planilha com essas colunas e preencho automaticamente o máximo que consigo via scripts de descoberta, deixando apenas a classificação funcional e de negócio para revisão humana. Uma ferramenta como o DBeaver conectado a todos os servidores ou um PowerShell rodando WMI consegue coletar a maior parte dos dados técnicos em horas, não dias. Tem um detalhe que muitos ignoram. A classificação técnica varia muito dependendo se a base é relacional ou não relacional. Para MongoDB, a abordagem é diferente porque não existe um conceito idêntico de schema rígido. Você acaba classificando por collection patterns e tamanho de documento, não por número de tabelas. Eu tive um caso em que uma base MongoDB de produção estava classificada erroneamente como desenvolvimento porque o nome do banco era "test_collection". O workaround foi cruzar métricas de throughput e latência com o histórico de backups. Se há backup diário agendado e latency média abaixo de 5ms, provavelmente não é dev.

Pegadinhas comuns e como evitar

A maioria das classificações falha porque alguém simplesmente copia a de outra pessoa sem verificar se o contexto é o mesmo. Você pega uma base que era homologação há dois anos, agora está em produção, e continua marcada como homologação na planilha. Isso gera erro em auditoria e em projetos de migração. Outro problema crônico é a classificação de bases que ninguém mais usa mas continuam rodando. Elas aparecem nos inventários, ocupam espaço, consomem recursos e ninguém sabe o que fazem. A solução mais prática é estabelecer um prazo de validade para a classificação. Se uma base não tiver alteração de schema ou inserção de dados nos últimos 180 dias, ela cai numa categoria de inativa e vai para revisão obrigatória antes de ser descartada. Quanto ao risco de classificação incorreta, o mais comum é confundir criticidade com volume de dados. Uma base pequena de logs pode ter milhares de inserções por segundo e ser crítica para compliance, enquanto uma base enorme de arquivos estáticos pode ser praticamente irrelevante para o negócio. Classifique por impacto operacional, não por tamanho.

Manutenção da classificacao das bases

Um inventário parado é pior que nenhum inventário. Configure um agendamento mensal de atualização automática dos campos técnicos e um trimestre para revisão completa das classificações funcionais e de negócio. Use um sistema de versionamento para registrar quando e por quem cada classificação foi alterada. Sem registro de alteração, você não consegue rastrear erros quando eles aparecem meses depois. Se a sua organização tem muitos bancos distribuídos entre nuvem e on-premise, considere integrar a classificação com ferramentas de catalogação de dados como Apache Atlas ou a própria interface do Azure Data Catalog. Elas reduzem o trabalho manual mas exigem configuração inicial e manutenção contínua. Para times pequenos, a planilha bem estruturada com scripts de coleta ainda é o caminho mais rápido e com menos pontos de falha. O resultado final não é perfeito, mas é suficiente para auditoria, migração e governança. E o suficiente nesse caso significa que você consegue responder em menos de dez minutos a perguntas como "quantas bases PostgreSQL estão rodando versão anterior a 14?" ou "quais bancos contêm dados de saúde e precisam de criptografia em repouso". Isso evita reuniões intermináveis e perda de tempo procurando informação que deveria estar organizada.