Criei um banco de dados local e, em seguida, configurei um trabalho único para copiar o banco de dados ativo para este novo banco de dados. Ou pelo menos foi o que pensei ter feito. Os logs sugerem que o trabalho pensou que tinha que criar o banco de dados ao vivo e replicou para isso, então devo ter configurado o trabalho incorretamente. O log mostra que a tabela foi criada ao vivo pelo trabalho.
Por um ou mais motivos, o trabalho de cópia falhou e o banco de dados criado foi carregado e aparentemente excluído (não consigo encontrar os arquivos .mdfou .log) e com isso eu poderia conviver.
No entanto, após a falha do trabalho, todas as permissões de objeto foram descartadas do banco de dados ao vivo, de modo que as contas que nosso aplicativo usa para acessar o banco de dados não puderam se conectar.
Após uma reinicialização, os bancos de dados estão funcionando bem, mas as permissões permanecem descartadas.
Eu gostaria de entender as razões por trás desse comportamento e reunir o que fazer e o que não fazer na próxima vez que tiver que fazer algo assim.
Alguém pode ajudar?
Os logins de banco de dados ao vivo substituirão seus logins de banco de dados locais. Portanto, os logins do banco de dados local, que contêm o usuário do aplicativo, podem ser apagados, a menos que exista no banco de dados ativo também. Às vezes, os mapeamentos entre o usuário do banco de dados e o esquema ficam confusos. Em seguida, você pode recriar o usuário ou usar sp_change_users_login para corrigir os mapeamentos de usuário do banco de dados.