Restaure bancos de dados no SQL Server sem criar usuários órfãos
Eu já vi isso em praticamente todas as versões do SQL Server e postagens de blog sobre isso parecem tratá-lo como algo que ocorre esporadicamente, mas como eu sempre pareço encontrar esse problema, até e até o SQL Server 2017, agora é tempo para descobrir o que estou fazendo errado.
cenário:
- Um banco de dados com um usuário do SQL Server (não AD)
- Backup (ou seja, para um arquivo) e, em seguida, restauração em outro computador ou servidor de banco de dados
-
O usuário aparecerá agora para esse banco de dados, mas não poderá ser usado e não poderá ser adicionado aos Logins (porque ele irá reclamar que ele já existe):
- Excluindoesseusuáriolançará:Oprincipaldobancodedadospossuiumesquemanobancodedadosenãopodeserdescartado.
Então:
Nãoépossívelremoveressapropriedade:
- Aconcessãodeoutrapropriedadedeusuárionãoatenuaesseproblema
Existemváriassoluções(este um , ou este one ) para corrigir isso após o fato, mas eu gostaria de corrigir isso na raiz:
- Posso fazer backup do banco de dados sem seus usuários?
- Posso restaurar um banco de dados sem seus usuários?
- Posso fazer backup / restaurar um banco de dados com seus usuários (eles são usuários sql, então eles devem ser exportáveis)?
- Qualquer outra coisa, ou seja, posso de alguma forma criar os logins para os usuários alienados, ou o que mais estou fazendo de fundamentalmente errado?
Eu faço a maioria das minhas ações com o SQL Server Management Console, o que pode não ser sábio, mas aprendo com prazer uma técnica melhor do que as ferramentas que devem fazer isso para nós.
A documentação do MS é falsa
Isso deve ser óbvio, de acordo com a Microsoft :
When a database is restored on another computer, the SQL Server login or Microsoft Windows user who initiates the restore operation becomes the owner of the new database automatically. When the database is restored, the system administrator or the new database owner can change database ownership.
Tudo isso parece não ser fundamentalmente verdadeiro, como os rascunhos do cenário acima.
Aviso: procurei, mas não ficaria surpreso se isso fosse duplicado.
PS: basicamente, a frustração é, geralmente você restaura em casos de emergência. Passar horas "consertando" o que não deveria ser quebrado é muito chato. Não é impossível, não é fixo, apenas um incômodo.
PPS: executando SELECT name FROM sys.schemas WHERE principal_id = USER_ID('TeamcityUsr') para o exemplo acima retorna o conjunto vazio. Então o usuário que foi copiado está realmente alienado.