Mapeamento do usuário perdido após o failover manual

Question

Eu tenho duas instâncias do Microsoft SQL Server configuradas para espelhar cada uma com vários bancos de dados. Há vários logins e, para cada banco de dados, um ou mais mapeamentos de usuário / login.

Quando eu restauro um backup do banco de dados, sempre tenho que refazer os mapeamentos de login / usuário. Eu entendo isso porque os logins são por servidor de banco de dados. Então, depois de restaurar os bancos de dados no principal, eu refiz os mapeamentos de login / usuário. Isso não foi possível para o espelho porque os bancos de dados estavam "restaurando".

Após um failover manual, não pude usar os bancos de dados porque as credenciais do usuário estavam ausentes. Isso não foi inesperado, então fiz o mapeamento de login / usuário novamente.

Eu fiz um failover manual novamente para tornar o valor inicial, que agora era o espelho, principal novamente. Para minha surpresa, não pude usar os bancos de dados porque os mapeamentos de login / usuário foram eliminados.

Este é o comportamento esperado?

    

Answer 1

São esses logins SQL? Em caso afirmativo, é provável que o mapeamento entre os logins do SQL e os usuários do banco de dados esteja fora de sincronia entre o principal e o espelho.

Eu já tive problemas com isso no passado, embora eu tenha tido a sorte de apenas me importar com um usuário específico.

Você deve tentar a seguinte função no espelho:

EXEC sp_change_users_login 'update_one', @login, @login

Para redefinir o mapeamento entre login @login e usuário do banco de dados @login.

Se isso não funcionar, tente a abordagem "Auto_fix":

EXEC sp_change_users_login 'Auto_Fix', @login, NULL, @password

Isso deve criar o usuário do banco de dados e mapeá-lo de acordo se ele ainda não existir.

Isso acontece com logins SQL porque o servidor de banco de dados gerará SIDs para esses logins. Esses SIDs são o que liga um usuário do banco de dados a um login. Mesmo que o mesmo login possa existir em dois servidores diferentes, seus SIDs podem ser diferentes e, assim, você terá credenciais "perdidas", se desejar. Isso não acontece para contas do Windows, porque o SQL Server usará o SID do Windows da própria conta ao criar o logon associado.

    

Answer 2

A execução de sp_change_users_login funciona bem, mas eu gosto de corrigir esse problema (comum) com as seguintes etapas:

1. Identifique os logins do SQL Server com os quais você está tendo problemas. Você deve ser capaz de ignorar logins de domínio. Seria melhor ignorar os logins do SQL Server que você não usa, sendo o melhor exemplo "sa".

2. Escolha um servidor que será seu sistema "conhecido". O primário atual é provavelmente a melhor escolha.

3. Use sp_help_revlogin para fazer engenharia reversa (a partir do primário) um script TSQL para criar os logins problemáticos. O sp_help_revlogin é mantido pela Microsoft em esta página . Quando executado no secundário, o script TSQL preservará o "SID" usado pelo SQL Server para identificar logins e vinculá-los aos usuários em cada banco de dados.

4. No secundário, solte o login problemático e execute o script TSQL que você gerou. Quando o login é recriado, o SID corresponderá ao do servidor principal. Na próxima vez que você fizer failover ou restaurar um banco de dados do primário para o secundário, os SIDs deverão coincidir e você não deverá executar o procedimento sp_change_users_login para 'consertar coisas'.

Até que você esteja familiarizado com esse processo, é melhor fazer um login de cada vez.

Seja cauteloso: A execução desse script TSQL também sincronizará a senha no secundário com a do primário. Se você tiver senhas diferentes nos dois servidores (talvez um seja um servidor de desenvolvimento e um seja um servidor de produção), talvez seja necessário voltar a alterar a senha no secundário de volta para o que deveria ser. Se você não sabe o que são essas senhas, ou não consegue alguém para lhe contar, isso pode ser um problema.

6. Depois de executar o script no secundário, você deve verificar novamente os bancos de dados no secundário que não são parte do seu aplicativo e corrigir o mapeamento de usuário para login nesses. Por exemplo, talvez você tenha o AdventureWorks nesse sistema. Quando você soltar o login, o mapeamento de usuário para login será quebrado e terá que ser recriado.

Answer 3

Em meus bancos de dados, geralmente uso esses comandos:

EXEC sp_change_users_login 'Report'
EXEC sp_change_users_login 'Auto_Fix', 'username'
EXEC sp_change_users_login 'Report'

em que nome de usuário é o nome de usuário que você deseja corrigir.