Eu tenho um banco de dados de produção que está desconectado há vários meses. Tenho feito modificações em uma cópia duplicada em um servidor de teste/desenvolvimento. Adicionei alguns campos adicionais (nulos permitidos) a várias tabelas, bem como algumas novas tabelas e índices a tabelas novas e existentes.
Minha pergunta é a seguinte: estou pronto para pegar meu banco de dados de teste/desenvolvimento e colocá-lo em produção. O problema é que preciso migrar todos os dados do meu banco de dados de produção para o meu banco de dados de teste/desenvolvimento. Meu primeiro pensamento foi usar o SSMS para "IMPORTAR" dados da produção para testar/desenvolver, o problema que estou tendo é que mesmo com "ativar inserção de identidade" ainda recebo todos os tipos de erros de restrição de chave estrangeira. Este é um pouco de duas partes
- Existe uma maneira melhor de migrar alterações de esquema de teste/desenvolvimento para produção do que o processo que acabei de descrever?
- Caso contrário, existe uma maneira de desativar temporariamente todas as restrições de inserção durante a importação?
Eu ficaria muito feliz em migrar apenas meu esquema de teste/desenvolvimento para meu servidor de produção, mas não encontrei nenhuma maneira de fazer isso sem ir manualmente tabela por tabela, índice por índice, exibição por exibição, procedimento armazenado por procedimento armazenado. .etc. Já vi algumas ferramentas que afirmam ser capazes de fazer isso, mas estou procurando uma solução gratuita/de código aberto e não encontrei nada.
nota: o banco de dados é pequeno < 10 gb, o banco de dados de teste/desenvolvimento está totalmente truncado com zero registros em todas as tabelas.
Parece que você tem isso inteiramente de trás para frente e de cabeça para baixo. Normalmente, as alterações são rastreadas usando scripts, que você aplicaria ao banco de dados de produção. Nunca encontrei um caso em que fizesse sentido importar dados de produção para a próxima versão criada a partir do desenvolvimento.
Se seu banco de dados não estiver atualmente sob controle de versão, os artigos vinculados ao artigo de Jeff Atwood Obtenha seu banco de dados sob controle de versão são uma boa introdução. Além disso, o ebook gratuito Redgate SQL Server Team Based Development inclui um capítulo sobre controle de origem para bancos de dados.
Se você estiver fazendo alterações por meio de ferramentas GUI e não tiver nenhum registro do que mudou, sua melhor aposta é uma ferramenta de comparação de banco de dados, como Redgate SQLCompare ou Apex SQLDiff . Essas ferramentas gerarão os scripts para atualizar seu banco de dados de produção para corresponder ao esquema de desenvolvimento.
Se o chefe não der o dinheiro para uma ferramenta de comparação, você pode reconciliar as alterações manualmente usando uma ferramenta de comparação como WinMerge ou DiffMerge . Use as ferramentas SSMS Generate Script para criar scripts de objetos para arquivos individuais e, em seguida, use a ferramenta diff para identificar as diferenças. Por fim, crie manualmente as instruções ALTER necessárias para quaisquer alterações nas tabelas.
Para esses tipos de migrações, sugiro que você dê uma olhada no esquema e no software de sincronização de dados. Eles geralmente têm uma lógica especial que lida com as restrições da tabela durante a sincronização. O SQL Server oferece ferramentas de dados do SQL Server que, para tarefas básicas de sincronização, farão o trabalho. Não tentei nada muito complicado com essas ferramentas, então não posso dizer quais são seus limites.
Se você estiver aberto a software de terceiros, sugiro que dê uma olhada em xSQL Schema Compare para sincronização de esquema e xSQL Data Compare para sincronização de dados. Eles têm várias opções que você pode ativar ou desativar (incluindo restrições de chave estrangeira ou inserções de identidade) para personalizar o processo de sincronização ao seu gosto.
Espero que isto ajude!
Divulgação: sou afiliado ao xSQL