Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Aplica-se a: 
SQL Server
Ao implementar uma solução de alta disponibilidade ou recuperação de desastres para uma base de dados SQL Server, é importante reproduzir a informação relevante que está armazenada para a base de dados nas bases de dados master ou msdb. Normalmente, a informação relevante inclui os trabalhos da base de dados primária/principal e os logins dos utilizadores ou processos que precisam de se ligar à base de dados. Deves duplicar esta informação em qualquer instância do SQL Server que aloje uma base de dados secundária/espelho. Se possível, após a troca de papéis, é melhor reproduzir programaticamente a informação na nova base de dados primária/principal.
Logins
Em cada instância de servidor que aloja uma cópia da base de dados, deve reproduzir os logins que têm permissão para aceder à base de dados principal. Quando o papel primário/principal muda, apenas os utilizadores cujos logins existem na nova instância primária/principal do servidor podem aceder à nova base de dados primária/principal. Os utilizadores cujos logins não estão definidos na nova instância principal/principal do servidor ficam órfãos e não conseguem aceder à base de dados.
Se um utilizador for órfão, crie o login na nova instância do servidor principal/principal e execute sp_change_users_login. Para mais informações, consulte Resolver problemas de utilizadores órfãos (SQL Server).
Logins de Aplicações que Utilizam Autenticação SQL Server ou Login Local no Windows
Se uma aplicação usar Autenticação SQL Server ou um login local no Windows, SIDs incompatíveis podem impedir que o login da aplicação seja resolvido numa instância remota do SQL Server. Os SIDs incompatíveis fazem com que o logon se torne um usuário órfão na instância do servidor remoto. Esse problema pode ocorrer quando um aplicativo se conecta a um banco de dados espelhado ou de envio de logs após um failover ou a um banco de dados de assinante de replicação que foi inicializado a partir de um backup.
Para evitar este problema, recomendamos que tome medidas preventivas ao configurar uma aplicação deste tipo para usar uma base de dados alojada por uma instância remota do SQL Server. A prevenção envolve a transferência dos logons e das senhas da instância local do SQL Server para a instância remota do SQL Server. Para mais informações sobre como evitar este problema, consulte o artigo da KB 918992 - Como transferir logins e palavras-passe entre instâncias de SQL Server).
Note
Esse problema afeta contas locais do Windows em computadores diferentes. No entanto, este problema não ocorre para contas de domínio porque o SID é o mesmo em cada um dos computadores.
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).
Jobs
Empregos, como os de reserva, exigem consideração especial. Normalmente, após uma mudança de papel, o proprietário da base de dados ou o administrador do sistema tem de recriar os trabalhos para a nova base de dados primária/principal.
Quando a anterior instância de servidor primária/principal estiver disponível, deve eliminar as tarefas originais nessa instância de SQL Server. Tenha em atenção que as tarefas na base de dados de espelho atual falham porque esta se encontra no estado RESTORING, tornando-se indisponível.
Note
Diferentes instâncias do SQL Server podem estar configuradas de forma distinta, com letras de drive diferentes ou afins. Os trabalhos de cada parceiro devem ter em conta quaisquer diferenças dessas situações.