Administração de logons e trabalhos depois de troca de funções (SQL Server)

Aplica-se a: SQL Server

Ao implantar uma solução de alta disponibilidade ou de recuperação de desastre para um banco de dados do SQL Server, é importante reproduzir informações relevantes que são armazenadas para o banco de dados nos bancos de dados master ou msdb. Normalmente, as informações relevantes incluem os trabalhos do banco de dados principal/primário e os logons de usuários ou de processos que precisam se conectar ao banco de dados. É necessário duplicar essas informações em qualquer instância do SQL Server que hospeda um banco de dados secundário/espelho. Se for possível, após a troca de funções, o melhor é reproduzir de forma programática as informações do banco de dados primário/principal.

Logons

Em cada instância de servidor que hospeda uma cópia do banco de dados, você precisa reproduzir os logons que têm permissão para acessar o banco de dados principal. Quando a função principal/primária for alternada, somente os usuários cujos logons existirem na nova instância de servidor principal/primária poderão acessar o novo banco de dados principal/primário. Os usuários cujos logons não estão definidos na nova instância de servidor principal/primária ficam órfãos e não podem acessar o banco de dados.

Se um usuário ficar órfão, crie o logon na nova instância de servidor primária/principal e execute sp_change_users_login. Para obter mais informações, confira Solucionar problemas de usuários órfãos (SQL Server).

Os logons dos aplicativos que usam a autenticação do SQL Server ou Logon local do Windows

Se um aplicativo usar a autenticação do SQL Server ou um logon local do Windows, as SIDs incompatíveis poderão impedir que o logon do aplicativo seja resolvido em uma instância remota do SQL Server. As SIDs incompatíveis fazem o logon se tornar um usuário órfão na instância do servidor remoto. Esse problema pode ocorrer quando um aplicativo se conectar a um banco de dados espelhado ou de envio de logs depois de um failover ou a um banco de dados de assinante de replicação que foi inicializado de um backup.

Para evitar esse problema, recomendamos que você tome medidas preventivas quando configurar esse aplicativo para usar um banco de dados que seja hospedado por uma instância remota do SQL Server. A prevenção envolve transferir os logons e as senhas da instância local do SQL Server para a instância remota do SQL Server. Para obter mais informações sobre como evitar esse problema, confira o artigo da base de conhecimento 918992 –Como transferir logons e senhas entre instâncias do SQL Server).

Observação

Esse problema afeta contas locais do windows em computadores diferentes. No entanto, esse problema não ocorre para contas de domínio porque o SID será o mesmo em cada computador.

Para obter mais informações, consulte Usuários órfãos com espelhamento de banco de dados e envio de logs (um blog do mecanismo de banco de dados).

Trabalhos

Trabalhos, tais como trabalhos de backup, requerem consideração especial. Em geral, após uma troca de funções, o proprietário do banco de dados ou administrador do sistema deve recriar os trabalhos para o novo banco de dados primário/principal.

Quando a instância de servidor primária/principal anterior estiver disponível, será preciso excluir os trabalhos originais nessa instância do SQL Server. Os trabalhos no banco de dados espelho atual apresentam falhas porque o banco de dados está no estado RESTORING, tornando-o indisponível.

Observação

Diferentes instâncias do SQL Server poderiam ser configuradas de forma diferente, com diferentes letras de unidade de fita ou algo semelhante. Os trabalhos de cada parceiro devem permitir essas diferenças.

Consulte Também

Gerenciar metadados ao disponibilizar um banco de dados em outra instância do servidor (SQL Server)
Solucionar problemas de usuários órfãos (SQL Server)