Gostaria de adicionar as informações do meu banco de dados de produção ao meu estágio DB. Eu tenho um BAK do banco de dados de produção e poderia apenas restaurar a partir dele no palco, mas estou preocupado com o impacto que a replicação de mesclagem terá sobre isso.
Deixe-me explicar melhor; Eu tenho 15 usuários testando um aplicativo às vezes conectado internamente. A estrutura é que existe um SQL Express Local em cada sistema que se inscreve no servidor Stage SQL 2005 com Subscrições de Captura. O servidor Stage funciona como editor e distribuidor. Uma solicitação foi feita pelos testadores para usar dados "reais". Se eu apenas restaurar os BAKs da produção para minha instância do Stage, o que acontecerá com meus Conjuntos de replicação? Quando os DBs Locais tentarem sincronizar, eles "ARRANCAREM" porque todos os GUIDS foram alterados?
Meu pensamento foi restaurar o banco de dados de produção para o Stage Server com um nome diferente e, em seguida, DELETE o conteúdo de, digamos, tblPerson e executar um INSERT INTO do tblPerson de produção para o tblPerson Stage, agora vazio.
Gostaria de ter ideias e sugestões sobre ambos.
Restaurar da causa do BAK o fim do mundo
e / ou
minha segunda solução é uma alternativa viável?
Eu preciso mesmo fazer tanto assim? Posso apagar o conteúdo de tblPerson (Stage) e então fazer um Cross DB SELECT INTO de tblPerson (Production) para a contraparte do Stage?
Principalmente, estou curioso / preocupado com o impacto que isso terá nas minhas assinaturas existentes.
Você não deseja usar o Replication da sua produção para o ambiente de estágio, especialmente para Mesclar replicação.
Sua melhor aposta é quando você precisar de dados no banco de dados de preparo para fazer backup do banco de dados de produção e restaurar a coisa toda. Se você tentar comer alguma coisa, terá que lidar com todos os problemas de integridade referencial que acompanham isso.
Restaurar o banco de dados irá destruir sua replicação (pelo menos, nos meus cenários. Se alguém souber diferente , por favor, me diga!
Fizemos praticamente o que você está sugerindo - DELETE * FROM myTable e INSERT INTO. Demorou um pouco, mas derrubar tabelas ou eliminar / restaurar o banco de dados destruiu a replicação em nosso cenário.
Não sei se isso será importante, mas também pausamos a replicação em todos os inscritos ao fazer isso.
O INSERT INTO ou o BCP provavelmente funcionariam. Como você mencionou, a restauração do banco de dados de produção exigiria que você recria sua replicação em sua instância de preparação. SELECT INTO não é uma boa ideia porque você não pode usar uma tabela existente como o alvo da cláusula INTO - tem que ser uma nova tabela - então você teria que deletar a tabela de destino, o que exigiria reparos para sua replicação.
Dos outros dois, INSERT é definitivamente o mais simples, e eu usei esse método com frequência. Se a velocidade for necessária, tente o BCP. Inserções em massa normalmente são muito mais rápidas que uma operação INSERT padrão. De acordo com o BOL ( link ), você precisa usar um switch para forçar os disparadores a disparar, mas parece que deveria funcionar bem, de outra forma.