SQL Server 2005 descartando objetos do banco de dados na recuperação?

Question

O SQL Server 2005 descartou um usuário de um dos nossos bancos de dados espelhados após a recuperação de uma simples reinicialização induzida pela atualização do Windows da máquina.

Eu verifiquei e o login não está no servidor espelho (está no primário). Se o sistema apresentasse um failover, isso explicaria por que o usuário foi removido do banco de dados do usuário após a recuperação para o primário? Não consigo encontrar nada no documento que indique que o SQL Server iria DROP usuários órfãos ( link ). Há algo que eu deveria procurar nos logs?

Editar: Configuração antes do fracasso: PRIMARY - Login OK. Usuário no banco de dados OK. MIRROR - Login não existe. O usuário não existe no banco de dados.

Após falha: PRIMARY - Login OK. O usuário não existe no banco de dados. MIRROR - Login não existe. O usuário não existe no banco de dados.

EDIT: Após a recuperação de um sistema de banco de dados após a reinicialização do WINDOWS UPDATES na semana passada, notamos que um acionador estava faltando em uma de nossas tabelas, assim como outro usuário. Estou 100% confiante de que isso não é o nosso fazer (só temos dois sa e eu sou um deles). QUE DIABOS ESTÁ ACONTECENDO? Isso tem que ser um bug com o espelhamento do SQL Server 2005.

    

Answer 1

Aqui está o que eu acho que aconteceu, isso é baseado no palpite na sua tag de pergunta de usuário órfão, então eu posso estar errado.

1. seu banco de dados falhou no principal para o espelho.
2. o servidor de banco de dados no espelho (agora o diretor) não tinha o login com script do primário, mas em vez disso foi criado como um novo entrar. Isso significaria que o sid não combinava, então havia problemas com o login do usuário após o failover.
3. Para corrigir o problema de login %código% foi executado para corrigir o problema de login. Isso teria mudou o sid do usuário no banco de dados para coincidir com o sid do login no servidor de banco de dados.
4. O banco de dados falhou novamente. Agora, o login sid no servidor de banco de dados não corresponde mais. O que fazer? usar sp_change_users_login 'Update_One' novamente para corrigir o problema.

O que deveria ter acontecido:
os logins do principal que são usados no banco de dados que participa do espelhamento são roteirizados (como sugerido por mr denny) para o espelho. A maneira mais fácil de fazer isso é usar sp_help_rev_login Você também pode usar o tarefa de logins de transferência do SSIS .

O sid para logins do servidor de banco de dados é visível em sys.server_principals. O sid para os usuários do banco de dados está em sys.database_principals. Verifique isso para garantir que não haja uma falta de correspondência.

    

Answer 2

O servidor espelho já criou o login? Caso contrário, você precisará fazer o script do login do sistema primário para que os SIDs correspondam.

    

Answer 3

O usuário provavelmente está no banco de dados espelhado, mas não está sincronizado com um login. Se o usuário estivesse lá quando você configurar o espelhamento, mesmo que o logon não existisse, o SQL Server não o descartaria. está aí.

Se você adicionou depois, ele se moveria pelo espelho. Não é o login, mas o CREATE USER seria transferido.

    

Answer 4

O aplicativo de nosso fornecedor de terceiros soltou o gatilho como parte de seu aplicativo. Insano.

    

Answer 5

O gatilho é errado porque alguém o abandona. Período. Sem intenção de ofender, mas se você for um dos administradores e não souber onde os principais do servidor residem e por que os principais do banco de dados podem ficar órfãos após um failover, não posso confiar que você sabe por que um disparador desaparece.

Use o rastreamento administrativo padrão para descobrir quem perdeu o gatilho e quando. Se você tiver sorte, o arquivo de rastreamento ainda não foi reciclado. Defina auditoria para acompanhar as alterações que ocorrem em seu servidor a partir de agora. Para os administradores, não deveria ser uma "surpresa" quando um gatilho desaparece. E não, você não pode culpar o produto.