Fixando com segurança os dados do banco de dados de produção

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 ...

1. Precisamos registrar quem executou a consulta e o que eles executaram
2. Idealmente, precisamos dar à pessoa acesso apenas para executar consultas nas tabelas de interesse e apenas por um curto período de tempo
3. 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
4. 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?

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.

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:

1. 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,

2. Todos os desenvolvedores que poderiam corrigir o bug no aplicativo são inacessíveis,

3. Atualmente, a empresa está perdendo milhares de dólares por hora (digamos, US $ 6.000, o que significa US $ 100 por minuto),

4. O bug está afetando várias tabelas, uma das quais é enorme e diz respeito apenas aos dados em si, não ao esquema,

5. Para contornar o erro, você deve experimentar um pouco os dados, o que envolve a remoção e a alteração,

6. O banco de dados é grande e levaria três horas para levar ou restaurar o backup,

7. 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,

8. Os backups do banco de dados são considerados confiáveis; eles foram severamente testados, incluindo recentemente,

9. Perder 14 horas de dados não é aceitável, mas a perda de uma a duas horas de dados é,

10. 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,

11. O banco de dados é o Microsoft SQL Server 2008 Enterprise.

A maneira limpa de fazer as coisas é:

1. Restaure o backup no ambiente de temporariedade,

2. Experimente lá,

3. Verifique o script final duas vezes,

4. 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:

1. 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),

2. 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.

Fixando com segurança os dados do banco de dados de produção. Qual é a maneira mais segura de fazer isso do ponto de vista de uma grande empresa? Existem ferramentas que podem ajudar?

É 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:

• Quão rápido você pode obter um bug corrigido na produção?
• Pirâmide de custos de desenvolvimento de software
• Quanto tempo deve ser alocado para testes e correção de bugs

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.

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.

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!

re: resposta da MainMa ...

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,

• Como você sabe que é um "bug"? Os dados são inconsistentes de acordo com as regras estabelecidas pelo desenvolvedor do produto de software.

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),

• Aparentemente, uma perda de US $ 100 / minuto não é importante o suficiente para que a gerência da empresa localize e garanta que os desenvolvedores competentes retornem para corrigir o erro e ajudar a restaurar o banco de dados.

O bug está afetando várias tabelas, uma das quais é enorme e diz respeito apenas aos dados em si, não ao esquema,

• Todos os problemas do banco de dados "dizem respeito" ao esquema. Como o esquema é projetado é o que vai determinar como você resolve esse problema.

Para contornar o erro, você deve experimentar um pouco os dados, o que envolve a remoção e a alteração,

• É para isso que serve o banco de dados de teste. Pode ser necessário preenchê-lo novamente com dados "corrompidos" do banco de dados de produção logo após fazer um backup online completo da produção.

O banco de dados é grande e levaria três horas para levar ou restaurar o backup,

• Então é melhor começar imediatamente, para que ele possa ser executado enquanto você estiver analisando o problema, desenvolvendo seus scripts de correção, testando e refinando-os junto com os desenvolvedores e outros DBAs que o ajudam.

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,

• Você não tem pelo menos backups online completos diários? Você está ferrado. Mas você provavelmente está acostumado a isso. Ainda bem que o backup completo iniciado acima está em execução. Certifique-se de que o gerenciamento reduza cada minuto os custos que poderiam ter sido evitados com backups online diários.

Os backups do banco de dados são considerados confiáveis; eles foram severamente testados, incluindo recentemente,

• Excelente! Talvez você não precise restaurar o banco de dados mais de uma vez.

Perder 14 horas de dados não é aceitável, mas a perda de uma a duas horas de dados é,

• Sob o cenário que você descreveu, todas as apostas estão desativadas. Esta é uma situação de "gerenciamento de desastres da informação". Uma coisa boa para o gerenciamento fazer ao longo disso é documentar os custos que poderiam ser evitados no futuro com backups mais propensos e procedimentos e recursos de recuperação.

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,

• Se o seu sistema de backup suportar backups online (ou seja, banco de dados totalmente operacional durante o backup), você poderá fazer a extração para preencher novamente o banco de dados temporário ao mesmo tempo, se tiver recursos de hardware suficientes para evitar a lentidão do backup.

O banco de dados é o Microsoft SQL Server 2008 Enterprise.

• Mais difícil de fazer tudo isso, mas não impossível. Boa sorte!