Criamos uma conta de Login do SQL apenas para uso de relatório (SSRS), vamos chamá-la de ' MyReportAcct '.
Usamos essa conta há algum tempo e ela é criada para cada instância recém-instalada. Tem funcionado como esperado, exceto em algumas instâncias espelhadas. Não vi esse problema em nenhuma instância autônoma em meu ambiente.
Aleatoriamente, os relatórios deixarão de funcionar e nada será alterado com base em nossos processos internos de gerenciamento de alterações, logs do Windows e logs de erros SQL. Aqui estão duas das mensagens de erro que recebemos:
Após a investigação da conta, ela aparece na pasta de objetos de segurança no SSMS. Além disso, descobrimos que a conta está associada a todos os bancos de dados em User Mapping para as propriedades da conta. Eu verifiquei que ' MyReportAcct ' tem publice db_datareader, portanto, na superfície, tudo parece conforme o esperado.
O problema surge quando tento alterar a conta ou remover os mapeamentos. Eu me encontro com:
- Não é possível alterar o usuário porque ele não existe ou você não tem permissão (Erro 15151).
- Não é possível descartar o dbo do usuário. (Erro 15150)
O que tive que fazer para corrigir o problema foi excluir todas as instâncias de ' MyReportAcct ' no servidor, recriá-las e adicioná-las a cada banco de dados. Isso não acontece o tempo todo, mas com frequência suficiente para ser irritante. Além disso, não deveríamos ter que fazer isso.
Acho que devemos alterar essa conta para uma conta do Windows em vez de um login SQL local em todas as instâncias. Tenho a sensação de que isso pode resolver o problema, mas preciso provar o motivo ou fornecer uma resposta razoável. Acho que parte do problema é o espelhamento de alguma forma, mas também não sei como provar isso.
A segurança é uma fraqueza minha e estou empregando medidas para mudar isso, portanto, qualquer insight que você possa fornecer será muito apreciado. Por favor, deixe-me saber se você precisar de mais informações.
Resposta curta:
Os SIDs para o login SQL ' MyReportAcct ' são diferentes em cada instância do servidor.
Resposta longa:
O
masterbanco de dados abriga o banco de dados de segurança para cada instância do SQL Server (pense no Active Directory para um servidor de banco de dados). Neste cenário temos doismasterbancos de dados diferentes, pois é um par espelhado. Cada vez que você cria um Login SQL, há um SID diferente criado junto com a conta, isso não é diferente de como o Active Directory sempre funcionou.Quando ocorre o failover de um banco de dados espelhado, o SID no banco de dados corresponde ao SID armazenado no
masterbanco de dados do servidor principal ( SERVER1 ), não do servidor espelhado ( SERVER2 ). Esse processo natural e padrão de failover faz com que o SQL Login ( MyReportAcct ) se torne uma conta órfã no servidor principal ( SERVER1 ). Esse processo de órfão acontece TODAS as vezes que há um failover. O início da autoridade para Logins SQL é a instância em que foram criados ( SERVER1 ). O failover para o servidor espelhado ( SERVER2 ) agora é um início de autoridade diferente, portanto, os SIDs serão diferentes, por isso os relatórios falham.Solução:
sysadmin.Soa como um usuário órfão para mim. SIDs incompatíveis. Você pode usar o seguinte procedimento armazenado para corrigir logins órfãos:
Talvez você possa criar um trabalho regular para sincronizar os logins entre instâncias de banco de dados de produção/DR e verificar e corrigir contas órfãs conforme descrito aqui: http://www.msbicoe.com/post/2012/04/05/Automatically-Transfer- and-Synchronize-SQL-Server-logins-SIDs-Passwords-and-Permissions.aspx