Como resolver problemas de permissão ao mover um banco de dados entre servidores que estão executando o SQL Server

Traduções deste artigo Traduções deste artigo
ID do artigo: 240872 - Exibir os produtos aos quais esse artigo se aplica.
Expandir tudo | Recolher tudo

Neste artigo

Sumário

Este artigo descreve como mapear logons padrão e integrados para resolver problemas de permissão ao mover um banco de dados entre servidores que estão executando o SQL Server.

Mais Informações

Ao mover um banco de dados de um servidor que está executando o SQL Server para outro servidor que está executando o SQL Server, pode ocorrer uma incompatibilidade entre os números de identificação de segurança (SIDs) dos logons no banco de dados mestre e os usuários no banco de dados usuário. Por padrão, o SQL Server 7.0, SQL Server 2000 e SQL Server 2005 fornecem o procedimento armazenado do sistema sp_change_users_login para mapear estes usuários incompatíveis. No entanto, é possível usar o procedimento armazenado sp_change_users_login apenas para mapear logons padrão do SQL Server e é necessário realizar mapeamento para um usuário de cada vez. Para obter mais informações sobre o procedimento armazenado sp_change_users_login, consulte o tópico "sp_change_users_login" nos Manuais online do SQL Server 7.0, do SQL Server 2000 e do SQL Server 2005.

No SQL Server 7.0 ou em versões mais recentes, é possível manter o mapeamento entre logons no banco de dados mestre e usuários no banco de dados usuário usando os SIDs. Este mapeamento é necessário para manter as permissões corretas para logons nos bancos de dados do usuário. Quando este mapeamento é perdido, os logons têm problemas de permissão que incluem, mas não estão limitados, aos seguintes:
  • Se o logon do SQL Server não existir no novo servidor e o usuário tentar fazer logon, o usuário poderá receber a seguinte mensagem de erro:
    Servidor: Msg 18456, Nível 16, Estado 1
    Falha de logon do usuário '%ls'.
  • Se o logon do SQL Server existir no novo servidor, mas o SID no banco de dados mestre for diferente do SID no banco de dados usuário, o usuário poderá efetura o logon no SQL Server com êxito. No entanto, quando o usuário tenta acessar este banco de dados, a seguinte mensagem de erro pode ser exibida:
    Servidor: Msg 916, Nível 14, Estado 1, Linha1
    O usuário de servidor '%.*ls' não é um usuário válido no banco de dados '%.*ls'.
    Observação No SQL Server 2005, o usuário pode receber a seguinte mensagem de erro:

    O usuário de servidor '%s' não é um usuário válido no banco de dados '%s'. Primeiro, adicione a conta do usuário ao banco de dados.
Para obter mais informações sobre o modelo de segurança do SQL Server 7.0, consulte o documento "Microsoft SQL Server 7.0 Security". Para exibir o documento, visite o seguinte site da Microsoft (em inglês):
http://msdn2.microsoft.com/en-us/library/Aa226173(SQL.70).aspx
Para obter mais informações sobre o modelo de segurança do SQL Server 2000, clique no número abaixo para ler o artigo na Base de Dados de Conhecimento Microsoft (a página pode estar em inglês):
322712 Recursos de segurança e melhores práticas do Microsoft SQL Server 2000 S322712

Restrições

  • Se houverem usuários na tabela sysusers sem um prefixo no nome do computador ou no nome de domínio proprietário dos objetos e estes objetos foram citados em aplicativos usando o nome de duas partes nome_de_usuário.nome_do_objeto, o aplicativo poderá falhar pois o procedimento armazenado sp_sidmap renomeia estes usuários com o prefixo do nome do computador ou do nome de domínio da forma que aparece na tabela sysxlogins. Como alternativa para este problema, após a conclusão do procedimento armazenado sp_sidmap, renomeie os usuários que foram afetados na tabela sysusers com seus nomes antigos ou contate seu provedor de suporte primário.
  • Este artigo não considera aliases. É necessário gerenciar os aliases manualmente.
  • Se um logon padrão do SQL Server não existir no novo servidor com SQL Server, será possível adicionar logon com uma senha NULA. Pode ser necessário alterar a senha destes logons adequadamente.
  • Se um usuário tiver sido criado no banco de dados usuário com um nome diferente do que aparece na tabela sysxlogins, será impossível saber o logon correspondente deste usuário. Por isso, antes de executar o procedimento armazenado sp_sidmap:
    1. Transfira todos os objetos pertencentes a este usuário para um banco de dados de teste.
    2. Descarte o usuário e o usuário que tem o nome correto e transfira de volta todos os objetos deste usuário.
  • Se um usuário não tiver um logon correspondente nem um prefixo do nome do computador local ou do nome do domínio, a seguinte mensagem será exibida com relação a este usuário. Esta mensagem indica que é necessário primeiro adicionar o usuário no nível do Windows e adicioná-lo ao SQL Server como um logon. Após fazer isto, é necessário executar o procedimento armazenado sp_sidmap novamente.
  • Se um usuário tiver um prefixo do nome do domínio ou do nome do servidor local do Windows, mas o logon correspondente não existir na tabela sysxlogins, o procedimento armazenado tentará adicioná-lo como um novo logon no SQL Server. Se o usuário do Windows não existir, uma mensagem de saída será gerada na janela de resultados e o logon será criado manualmente após adicionar o usuário do Windows pela primeira vez.
  • Se houver mais de um logon para um usuário na tabela sysusers, uma mensagem de saída será exibida no arquivo de resultados e listará todos os logons com o mesmo nome de usuário. Neste momento, é necessário intervir manualmente para verificar se o usuário corresponde a apenas um logon.

    Exemplo Se a tabela sysusers tiver um usuário chamado "johndoe" e a tabela sysxlogins tiver logons com nomes como "Teste\johndoe" e "Teste2\johndoe", ao executar o procedimento armazenado, uma mensagem será exibida afirmando que um dos usuários tem mais de um logon e que o Administrador do sistema deve escolher um. Este é o único momento no qual é preciso executar um segundo procedimento armazenado, sp_prefix_sysusersname, fornecido neste artigo. Além disso, esta situação é descrita em detalhes no arquivo Readme.txt.

Mapear os logons padrão e integrado

Após mover um banco de dados de um servidor que está executando o SQL Server para outro servidor que está executando o SQL Server, execute as seguintes etapas para minimizar ao máximo a intervenção do usuário:
  1. Verifique se existe um logon na tabela sysxlogins no banco de dados mestre para cada usuário na tabela sysusers do banco de dados.

    Observação Para adicionar um logon padrão do SQL Server, consulte o tópico "sp_addlogin" nos Manuais online do SQL Server. Para adicionar um logon integrado do SQL Server, consulte o tópico "sp_grantlogin" nos Manuais online do SQL Server.
  2. Baixe o arquivo MapSids.exe e extraia os arquivos Sp_sidmap.sql e Readme.txt.
  3. Faça logon como administador do sistema no servidor que está executando o SQL Server e execute o arquivo Sp_sidmap.sql no banco de dados do usuário. A execução do arquivo Sp_sidmap.sql cria os dois procedimentos armazenados, sp_sidmap e sp_prefix_sysusersname.
  4. Verifique se o banco de dados não é acessado por nenhum outro usuário além daquele que está executando os procedimentos armazenados.
  5. Verifique se o Analisador de consultas exibe os resultados em formato de texto e não em formato de grade. Para fazer isto, pressione as teclas CTRL^T ou clique em Consultar e clique em Resultados em texto. Isto é muito importante para que seja possível exibir os resultados e as mensagens informativas em uma janela e salvar o resultado em um arquivo de texto. Este arquivo pode ser necessário posteriormente para resolver alguns dos mapeamentos.
  6. Como não é possível verificar se os parâmetros são passados corretamente, certifique-se de passá-los corretamente para o procedimento armazenado sp_sidmap:
    EXEC sp_SidMap @old_domain = old_domain_name,
    @new_domain = new_domain_name,
    @old_server = old_server_name,
    @new_server = new_server_name
    Substitua os valores dos nomes de domínio antigo e novo e os nomes de servidor apropriadamente.
  7. Salve os resultados em um arquivo e siga as direções fornecidas no arquivo Readme.txt.

    Observação Ao executar estes procedimentos armazenados, a tabela sysusers é a única que muda no banco de dados. Para retornar a um estado inicial, restaure o banco de dados do backup ou anexe novamente o banco de dados.

Referências

Para obter informações adicionais, clique nos números abaixo para ler os artigos na Base de Dados de Conhecimento Microsoft (alguns artigos podem estar em inglês):
274188 O tópico "Solução de problemas de usuários órfãos" está incompleto no manual online
246133 Como transferir logins e senhas entre instâncias do SQL Server
168001 Logon e/ou erros de permissão de usuário depois da restauração de despejos
298897 EXEMPLO: O Mapsids.exe ajuda a mapear os SIDs entre os bancos de dados mestre e usuário quando o banco de dados é movido

Propriedades

ID do artigo: 240872 - Última revisão: quarta-feira, 5 de setembro de 2007 - Revisão: 7.3
A informação contida neste artigo aplica-se a:
  • Microsoft SQL Server 2000 Standard Edition
  • Microsoft SQL Server 2000 64-bit Edition
  • Microsoft SQL Server 7.0 Standard Edition
  • Microsoft SQL Server 2005 Developer Edition
  • Microsoft SQL Server 2005 Enterprise Edition
  • Microsoft SQL Server 2005 Express Edition
  • Microsoft SQL Server 2005 Standard Edition
  • Microsoft SQL Server 2005 Workgroup Edition
Palavras-chave: 
kbhowtomaster KB240872

Submeter comentários

 

Contact us for more help

Contact us for more help
Connect with Answer Desk for expert help.
Get more support from smallbusiness.support.microsoft.com