Erros acontecem e, algumas vezes, os dados precisam ser corrigidos na produção. Qual é a maneira mais segura de fazer isso do ponto de vista de uma grande empresa? Existem ferramentas que podem ajudar? Aqui estão algumas considerações que direcionam esse requisito ...
- Precisamos registrar quem executou a consulta e o que eles executaram
- Idealmente, precisamos dar à pessoa acesso apenas para executar consultas nas tabelas de interesse e apenas por um curto período de tempo
- O que quer que esteja executando as consultas precisa ter alguma inteligência para não permitir a execução longa e o bloqueio do SQL sem permissão explícita
- Esse processo precisa ser independente do DB ou, pelo menos, entender o DB2, Oracle e SQL Server.
Estamos tentando reduzir o risco de consultas ad-hoc de correção de produtos fazerem a "coisa errada" e, ao mesmo tempo, adicionar alguma segurança / auditoria ao processo. Pensamentos ou idéias?
Respostas:
Nunca atualize os bancos de dados de produção manualmente.
Escreva scripts.
Confira três vezes e faça com que várias pessoas façam isso, não apenas uma única pessoa fazendo isso três vezes.
Inclua consultas de validação pós-alteração nesses scripts.
Sempre que a situação permitir, teste toda a alteração em uma transação que é revertida no final, após a validação pós-alteração. Quando estiver confiante com os resultados, altere a reversão para uma confirmação.
Teste esses scripts ad nauseam em um banco de dados de teste.
Faça um backup antes de executar o script no banco de dados de produção.
Execute os scripts.
Verifique, valide e verifique três vezes os dados alterados usando os scripts de validação pós-alteração.
Faça uma verificação visual de qualquer maneira.
Se algo parecer errado, recue e restaure o backup.
Não continue com os dados alterados como com os dados de produção até ter certeza absoluta de que está tudo bem e você sair dos gerentes (comerciais) envolvidos.
fonte
WHEREe seu banco de dados ficará inativo pelo resto do dia. Ou semana.A resposta de Marjan Venema é tecnicamente válida e deve ser seguida sempre que possível. Infelizmente, Marjan responde do ponto de vista de um teórico ou de um administrador de banco de dados purista que gosta de fazer as coisas de maneira limpa. Na prática, às vezes as restrições de negócios tornam impossível fazer as coisas de maneira limpa.
Imagine o seguinte caso:
Há um erro no produto de software que faz com que ele pare de funcionar quando detecta o que considera uma inconsistência de dados no banco de dados,
Todos os desenvolvedores que poderiam corrigir o bug no aplicativo são inacessíveis,
Atualmente, a empresa está perdendo milhares de dólares por hora (digamos, US $ 6.000, o que significa US $ 100 por minuto),
O bug está afetando várias tabelas, uma das quais é enorme e diz respeito apenas aos dados em si, não ao esquema,
Para contornar o erro, você deve experimentar um pouco os dados, o que envolve a remoção e a alteração,
O banco de dados é grande e levaria três horas para levar ou restaurar o backup,
O último backup completo foi realizado três semanas atrás; também há backups incrementais diários e o último backup incremental diário foi feito há 14 horas,
Os backups do banco de dados são considerados confiáveis; eles foram severamente testados, incluindo recentemente,
Perder 14 horas de dados não é aceitável, mas a perda de uma a duas horas de dados é,
O ambiente de preparação foi usado por último seis meses atrás; parece que não está atualizado e pode levar horas para configurá-lo,
O banco de dados é o Microsoft SQL Server 2008 Enterprise.
A maneira limpa de fazer as coisas é:
Restaure o backup no ambiente de temporariedade,
Experimente lá,
Verifique o script final duas vezes,
Execute o script no servidor de produção.
Apenas o primeiro passo custará US $ 18.000 à sua empresa. O risco é bastante baixo se você der o terceiro passo na perfeição, mas como você trabalha sob pressão extrema, o risco seria muito maior. Você pode acabar com um script que funcionou perfeitamente bem na preparação e depois estragar o banco de dados de produção.
Em vez disso, você poderia ter feito assim:
Crie um instantâneo (o Microsoft SQL Server suporta isso e leva alguns segundos para reverter (e nada para criar) um instantâneo de um banco de dados que leva uma hora para fazer backup; imagino que outros produtos de banco de dados também suportem instantâneos),
Experimente diretamente no banco de dados de produção, revertendo para o instantâneo se algo der errado.
Enquanto um purista conserta o banco de dados de maneira limpa e ainda corre o risco de estragar tudo, devido à pressão do tempo, enquanto desperdiça mais de US $ 20.000 de sua empresa, um administrador de banco de dados que leva em conta as restrições de negócios corrige o banco de dados de uma maneira o que minimiza os riscos (graças aos instantâneos) enquanto faz isso rapidamente.
Conclusão
Sou purista e odeio fazer as coisas de uma maneira não limpa. Como desenvolvedor, refatoro o código que modifico, comento as partes difíceis que não puderam ser refatoradas, testo a base de código da unidade e faço revisões de código. Mas também levo em consideração as circunstâncias em que você faz as coisas de maneira limpa e no dia seguinte é demitido ou minimiza os riscos e o impacto financeiro fazendo um hack rápido que funciona.
Se um cara de TI quer fazer as coisas de maneira limpa apenas por uma questão de limpeza, enquanto isso causa milhares de dólares de perda para a empresa, esse cara de TI tem um profundo mal-entendido de seu trabalho.
fonte
É uma prática ruim e um portal de convite para mais problemas e problemas de dados. Existe até uma frase que descreve essa abordagem como " Rápida e suja ".
As correções / atualizações contínuas diretamente em um servidor de produção são muito perigosas , pois custarão uma fortuna para você / sua empresa ( ações judiciais, dados ruins / sujos, negócios perdidos etc. )
No entanto, os bugs estarão lá e precisam ser corrigidos. O padrão industrial de fato é aplicar patches / (scripts de implantação) em um armazenamento temporário (ambiente de pré-produção com a cópia mais recente do banco de dados prod) e deixar o analista de dados / controle de qualidade verificar a correção. O mesmo script deve ser controlado por versão e aplicado ao ambiente Prod para evitar problemas.
Existem várias boas práticas mencionadas nesta publicação pós- preparatória relacionada.
Um bom conjunto de referências para procurar são:
fonte
Na maioria das organizações, trabalhei que a atualização de dados no ambiente ao vivo era sempre realizada por um pequeno grupo de pessoas com direitos de acesso, normalmente com um cargo como DBA. Como as atualizações só podem ser feitas pelo pequeno número de pessoas, há pelo menos uma chance de que elas se familiarizem com os dados e, portanto, reduz (mas não elimine) o risco de problemas.
A pessoa que escrever o script de atualização faria isso em teste (como em outras respostas) e obteria aprovação séria de não técnicos (aqueles que conhecem o sistema, além de alguém com autoridade sênior) de que os recursos parecem estar "corretos novamente" em além de seus próprios testes paranóicos. Os scripts e os dados seriam verificados independentemente por outro técnico (geralmente a função de DBA que mencionei) em teste antes de serem colocados em produção. Os resultados seriam comparados com os valores previstos (exclusivos para todos os cenários, mas geralmente itens como contagem de linhas etc.)
Em uma empresa em que trabalhei, fazer backups não era uma opção realista, mas todas as linhas a serem atualizadas foram gravadas em um arquivo de texto para referência ANTES da atualização, e novamente APÓS a atualização, caso alguém precise se referir a ela. Os scripts e esses dados são mantidos em um registro de alterações de dados organizado corretamente.
Toda empresa é única e os riscos de atualizar alguns dados são claramente maiores do que em outras.
Por ter um processo que leva as pessoas a passar por obstáculos para fazer essas atualizações, esperamos que você promova uma cultura que faça as pessoas quererem tratar isso como último recurso e crie uma atitude saudável de "dupla verificação, tripla verificação" em relação a essas coisas.
fonte
Há momentos em que você deve corrigir dados no Prod que não existem em outros servidores. Não se trata apenas de bugs, mas de uma importação de dados de um arquivo enviado por um cliente incorreto ou de um problema causado por alguém invadindo seu sistema. Ou de um problema causado por entrada incorreta de dados. Se o seu banco de dados for grande ou crítico, talvez você não tenha tempo para restaurar o backup mais recente e corrigir o dev.
Sua primeira defesa (e algo que nenhum banco de dados corporativo pode ficar sem!) São as tabelas de auditoria. Você pode usá-los para recuperar alterações de dados incorretas. Além disso, você pode escrever scripts para retornar dados ao estado anterior e testá-los em outros servidores muito antes de precisar reverter os dados auditados. O único risco é que você identificou os registros corretos para reverter.
Em seguida, todos os scripts para alterar dados em produção devem incluir o seguinte:
Eles devem estar em transações explícitas e ter um bloco TRY Catch.
Eles devem ter um modo de teste que você pode usar para reverter as alterações depois de ver o que elas teriam sido. Você deve ter uma declaração selecionada antes da alteração e uma execução após a alteração para garantir que a alteração esteja correta. O script deve garantir que o número de linhas processadas seja mostrado. Temos algumas dessas opções pré-configuradas em um modelo que garante que as peças sejam concluídas. Modelos para alterações, também ajudam a economizar tempo ao escrever a correção.
Se houver uma grande quantidade de dados para alterar ou atualizar, considere escrever o script para ser executado em lotes com confirmações para cada lote. Você não deseja bloquear todo o sistema enquanto conserta um milhão de registros. Se você tiver grandes montantes de dados para corrigir, verifique se um dba ou alguém acostumado a ajustar o desempenho revisa o script antes de executar e executar fora do horário comercial, se possível.
Em seguida, todos os scripts para alterar qualquer coisa na produção são revisados e colocados no controle de origem. Todos eles - sem exceção.
Finalmente, os desenvolvedores não devem executar esses scripts. Eles devem ser executados pelo dbas ou por um grupo de gerenciamento de configuração. Se você não tiver um desses, apenas as pessoas que são líderes em tecnologia ou superior devem ter o direito de executar as coisas no prod. Quanto menos pessoas executando coisas em prod, mais fácil é localizar um problema. Os scripts devem ser escritos para que sejam simplesmente executados, sem partes de destaque e executando uma etapa de cada vez. É o material de destaque que muitas vezes coloca as pessoas em problemas quando se esquecem de destacar a cláusula where.
fonte
Atualizei dados muitas vezes na execução de bancos de dados de produção. Concordo com a resposta acima, que este nunca seria um procedimento operacional padrão.
Também seria caro (olharíamos por cima dos ombros dos outros e discutiríamos 2 ou 3, talvez)
E a regra de ouro: sempre faça uma instrução select para mostrar o que seria feito antes de fazer uma instrução de atualização / exclusão / inserção
A regra de ouro aplicada pelas outras duas pessoas da equipe!
fonte
re: resposta da MainMa ...
fonte