Correção no banco de produção: registro e quem autoriza

Correção em produção não é tarefa de quem está mais perto do erro nem de quem tem acesso ao banco. A decisão de alterar dado real precisa de uma pessoa nomeada, fora de quem pediu o ajuste, que responda pelo que acontece se a correção estiver errada. Em operação pequena, essa pessoa pode ser a mesma que cuida da fila de sistemas, desde que o papel esteja escrito.

O pedido chega com o registro afetado, o valor atual, o valor correto e a origem do erro. Quem executa confere em ambiente de cópia antes de rodar em produção, registra o horário e avisa quem depende do dado: faturamento, atendimento, relatório. A aprovação vale para aquele conjunto de registros, não para o próximo ajuste parecido.

Todo ajuste deixa quatro itens: o script que foi executado, os valores antes e depois, o motivo e a origem. O script vive no mesmo repositório dos demais, com identificação e data, porque a próxima pessoa que investigar o dado vai precisar reproduzir o que aconteceu.

O motivo aponta para a causa: cadastro inconsistente, integração que não tratou o caso, rotina que rodou fora de ordem. Sem esse vínculo, o ajuste vira exceção que ninguém consegue auditar depois. O registro também guarda o script reverso, quando existir, e o que fazer quando ele não existir.

Corrigir o banco não conserta a regra que produziu o erro. Se a origem continua igual, a próxima carga ou o próximo cálculo recria o dado. O processo organiza o ajuste pontual; ele não substitui a mudança no sistema de origem, que segue outra fila e outro prazo.

Existe caso em que a correção direta é a única saída no momento, como dado bloqueando fechamento ou atendimento parado. O processo não elimina a pressa nem o risco. Ele garante que a pressa fique registrada, com responsável e motivo, para que ninguém precise reconstruir a história meses depois. Ele também não serve para migração nem para ajuste em massa, que pedem outro tipo de controle.