Restaurando um banco de dados SQL em um ambiente de produção como um mecanismo de atualização

Question

Sou um administrador de sistema que foi recentemente escalado com alguma responsabilidade de SQL DBA. Não com relutância, devo acrescentar, este é um mundo em que estou muito interessado em mergulhar.

Estou curioso sobre um dos aspectos da nossa configuração existente (em que as tarefas de DBA eram largamente deixadas para os desenvolvedores), ou seja, o mecanismo de atualização de um dos nossos bancos de dados de produção.

Essencialmente, o que acontece é que sempre que os dados subjacentes mudam, um dos desenvolvedores cria um novo banco de dados no ambiente de desenvolvimento e o restaura no ambiente de produção. Para facilitar isso, a equipe de desenvolvimento recebeu permissões de dbcreator. Isso acontece uma ou duas vezes por semana.

Algum dos DBAs mais experientes pode identificar falhas com essa abordagem? Devo insistir em lidar com todas as restaurações eu mesmo (eu escrevi os comandos T-SQL para a equipe de desenvolvimento usar em vez do SSMS que exigia direitos sysadmin para procurar a mídia disponível)? Alguma coisa poderia dar errado durante uma restauração que poderia deixar o banco de dados offline?

Estamos usando a edição padrão do SQL Server 2008 R2.

Obrigado a todos.

    

Answer 1

Como regra geral, tenho um problema com a equipe de desenvolvimento aplicando alterações em um banco de dados de produção pelo qual sou responsável.

Se eu estivesse no seu lugar, eu mudaria o processo para aplicar todas as alterações do banco de dados na Produção. Isso elimina surpresas (para você) e adiciona um novo conjunto de olhos ao processo no exato momento em que é crítico fazê-lo.

Eu também acredito firmemente no uso de ferramentas de comparação. Minhas escolhas atuais são o RedGate SQL Compare (para comparação de estrutura) e o RedGate SQL Data Compare (para comparação de dados). Você também pode usar o Visual Studio para profissionais de banco de dados, se você tiver carregado.

Outro benefício de usar as ferramentas de comparação é que elas minimizam as alterações no banco de dados modificado, fornecendo um conjunto de scripts que você pode adicionar ao seu sistema de controle de origem para documentar cada versão.

Seguir este caminho elimina a necessidade de os desenvolvedores terem permissões elevadas no banco de dados de produção e reduzir sua exposição. Na minha opinião, reduzir a exposição é sempre bom.

    

Answer 2

Eu estou supondo que este é um banco de dados somente leitura? Se assim for, não vejo grandes problemas com isso. A maneira como fiz isso antes é salvando os scripts de atualização escritos no banco de dados dev (no controle de origem, naturalmente!) E, em seguida, apenas reaplicando os mesmos desde a última atualização para prod. Esse método é provavelmente um pouco mais rápido do que fazer uma restauração completa do banco de dados, embora isso provavelmente não seja muito importante se você não o fizer com frequência ou se as restaurações forem pequenas. Ainda é bom tirar fotos instantâneas antes de cada atualização, no caso de algo dar errado e forçar e desviar.