Como posso manter esquema DB consistente accross 18 bancos de dados (servidor SQL)?

Question

Temos 18 bases de dados que devem ter esquemas idênticos, mas não o fazem. Em determinados cenários, uma mesa foi adicionado a um, mas não o resto. Ou, determinados procedimentos armazenados foram requeridos em um punhado de bancos de dados, mas não os outros. Ou, o nosso DBA esqueceu de executar um script para adicionar pontos de vista sobre todos os bancos de dados.

Qual é a melhor maneira de manter os esquemas de banco de dados em sincronia?

Answer 1

Para correções de legado / limpeza, existem ferramentas, como SQLCompare , que pode gerar scripts para bancos de dados de sincronização.

Para lojas .NET com o SQL Server, há também a Visual estúdio Database Edition , que pode criar scripts de alteração para alterações de esquema que podem ser verificados no controle de origem, e automaticamente construídos usando o processo de CI / build.

Answer 2

SQL Compare pela Red Gate é uma ótima ferramenta para isso .

Answer 3

SQLCompare é a melhor ferramenta que eu têm usado para encontrar diferenças entre as bases de dados e fazê-los sincronizados.

Para manter os bancos de dados sincronizados, você precisa ter várias coisas no lugar:

1) Você precisa de políticas sobre quem pode fazer alterações para a produção. Geralmente isso só deve ser a (equipe DBA para orgs maiores) DBA e 1 ou 2 backaps. Os backups só deve fazer alterações quando a DBA está fora, ou em caso de emergência. Os backups não devem ser implantando em uma base regular. Definir direitos de banco de dados de acordo com esta política.

2) Processo A e ferramentas para gerenciar solicitações de implantação. Idealmente, você vai ter um ambiente de desenvolvimento, um ambiente de teste, e um ambiente de produção. Os desenvolvedores devem fazer o desenvolvimento inicial no ambiente dev, e ter mudanças empurrados para teste e produção, conforme apropriado. Você vai precisar de alguma maneira de deixar o know DBA quando empurrar mudanças. Eu não recomendo um processo onde você gritar para o próximo cubo. Grandes orgs podem ter um comitê de controle de mudanças e as mudanças só são feitas uma vez por mês. As empresas menores pode apenas ter o teste pedido desenvolvedor, e depois do teste é passado um pedido de destacamento para a produção. Uma pequena empresa que eu trabalhei para usado Problema Rastreador para essas solicitações.

Use o que funciona em sua situação e orçamento, basta ter um processo, e ter ferramentas que trabalham para esse processo.

3) Você disse que às vezes objetos só precisa ir a um punhado de bancos de dados. Com apenas 18 bases de dados, provavelmente em um servidor, eu recomendaria fazer cada partida Databse objetos exatamente. Apenas 5 bancos de dados precisam usp_DoSomething? E daí? Coloque-o em todos os databse. Isso será muito mais fácil de gerir. Nós fizemos isso dessa maneira em um sistema 6 servidor com cerca de 250-300 bancos de dados. Havia exceções, mas elas foram agrupadas. Bancos de dados no servidor C tem esse conjunto extra de objetos. Bases de dados em servidor L tenho esse outro conjunto.

4) Você disse que às vezes o esquece DBA para implantar scripts de alteração para todos os bancos de dados. Isso me diz que ele / ela precisa de ferramentas para implementar mudanças. S / Ele é, provavelmente, tomar um script SQL, abrindo-nos no Query Analyzer ou manejo Studio (ou o que quer que você usa) e ir manualmente para cada banco de dados e executar o SQL. Esta não é uma boa solução a longo prazo (ou curto prazo). Red Gate (fabricantes de SQLCompare acima) têm muitas ferramentas. MultiScript parece que pode funcionar para fins de implantação. Eu trabalhei com um DBA que escreveu é própria ferramenta no SQL Server 2000 usando O-SQL. Levaria um arquivo SQL e executá-lo em cada banco de dados no servidor. Ele tinha que executá-lo em cada servidor, mas bateu execução em cada DB. Eu também ajudou a escrever uma ferramenta de VB.net que faria a mesma coisa, exceto que ele também iria passar por uma lista de servidor, por isso só tinha de ser executado uma vez.

5) de controle de origem. Minha equipe atual não usa controle de origem, e eu não tenho tempo suficiente para lhe dizer quantos problemas Isto provoca. Se você não tem algum tipo de sistema de controle de origem, obter um.

Answer 4

Eu não tenho reputação suficiente para comentar sobre a resposta acima, mas a versão pro do SQL Compare tem uma API programável. Dado que você tem que coisas replicar para todos os desses bancos de dados que você pode usar isso para fazer um trabalho automatizado, quer gerar os scripts de alteração ou para validar que os bancos de dados estão todos em sincronia. Também não é muito mais caro do que a versão padrão.

Answer 5

Além do uso de ferramentas de comparação de banco de dados, com 18 bases de dados você deve ter um DBA, então aplicar uma política que só o DBA pode alterar as tabelas no nível de banco de dados, restringindo o acesso para criar e alterar apenas o DBA. Tanto no teste e bancos de dados ao vivo. O banco de dados dev não deve ter isso, é claro! Fazer os desenvolvedores que têm vindo a criar ou alterar os esquemas querendo ou não ir através do DBA.

Answer 6

Criar um único script DDL / SQL controlado-fonte para cada versão e única usá-lo para atualizar os bancos de dados. As ferramentas diff pode ser útil, mas principalmente para verificar se você não tiver feito um erro e ficar fora de problemas quando as políticas falhar. Combine o DDL, SQL e scripts de procedimento armazenados em um único script para que ele não é fácil "esquecer" para executar um dos scripts.

Answer 7

Temos uma ferramenta chamada DB Schema Difftective que pode comparar e esquemas de banco de dados sincronizados. Com a nossa outra ferramenta, DB MultiRun você pode facilmente implantar gerado scripts (sincronização) para vários servidores db (baseado em projeto).

Answer 8

Sei que este post é antigo, mas TurnKey está correto. Se você é um trabalho desenvolvedor em um ambiente de equipe, a melhor maneira de manter um esquema de banco de dados para um aplicativo grande, é fazer atualizações em um mestre de esquema em que sempre segura fonte que você usa. Basta escrever sua própria classe Scripting e seu banco de dados será perfeito o tempo todo.