Você está offline; aguardando reconexão

Como conceder acesso para logons SQL em um banco de dados em espera quando o usuário convidado está desabilitado no SQL Server

Extended support for SQL Server 2005 ended on April 12, 2016

If you are still running SQL Server 2005, you will no longer receive security updates and technical support. We recommend upgrading to SQL Server 2014 and Azure SQL Database to achieve breakthrough performance, maintain security and compliance, and optimize your data platform infrastructure. Learn more about the options for upgrading from SQL Server 2005 to a supported version here.

IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine Translation ou MT), não tendo sido portanto traduzido ou revisto por pessoas. A Microsoft possui artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais, com o objetivo de oferecer em português a totalidade dos artigos existentes na base de dados de suporte. No entanto, a tradução automática não é sempre perfeita, podendo conter erros de vocabulário, sintaxe ou gramática. A Microsoft não é responsável por incoerências, erros ou prejuízos ocorridos em decorrência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza atualizações freqüentes ao software de tradução automática (MT). Obrigado.

Clique aqui para ver a versão em Inglês deste artigo: 303722
Sumário
Este artigo descreve como conceder acesso a um banco de dados que tenha sido carregado no estado em espera de outro servidor quando o usuário de "convidado" está desabilitado por motivo de segurança. As informações contidas neste artigo se aplicam apenas para logins do SQL Server e, portanto, para servidores que são configurados para usar "SQL Server e autenticação do Windows." Este procedimento não pode ser usado para logons do Microsoft Windows NT ou Windows NT grupos.

Esse procedimento também se aplica a um banco de dados em espera em configurações de envio de log. O banco de dados em espera é somente leitura e não pode ser configurado com qualquer informação de segurança/logon. No entanto, esse procedimento permite que acessem o banco de dados em espera.

Etapas para reproduzir o comportamento

No exemplo a seguir, pubs é o banco de dados, servidor1 é o servidor que tem o banco de dados de origem e server2 é o servidor que tem o banco de dados em espera.

No servidor1, execute estas etapas:
  1. Modificar o modelo de recuperação para o banco de dados pubs para FULL usando o código a seguir:
    alter database pubs set recovery full
  2. Remover o usuário de "convidado" deste banco de dados usando o código a seguir:
    use pubs go sp_dropuser 'guest' go

    Observação Se você estiver usando o SQL Server 2005, o usuário convidado não pode ser descartado. No entanto, o usuário convidado pode ser desabilitado por revogar sua permissão de conexão e executando REVOKE conexão de convidado em qualquer banco de dados diferente do banco de dados de origem ou o banco de dados em espera.
  3. Adicionar dois logins do SQL Server usando o código a seguir:
    sp_addlogin 'testlogin1', @passwd='pwd1', @defdb='pubs' go sp_addlogin 'testlogin2', @passwd='pwd2', @defdb='pubs' go
  4. Executar um backup completo do banco de dados pubs usando o código a seguir:
    backup database pubs to disk = 'c:\pubs.bak' with init
No Servidor2, execute as seguintes etapas:
  1. Remove o banco de dados Pubs Servidor2.
  2. Restaure o backup completo que você criou na etapa 4 do procedimento anterior no Servidor2 no modo STANDBY. Para fazer isso, use as instruções a seguir:
    drop database pubs go restore database pubs from disk = 'c:\pubs.bak' with move 'pubs' to 'c:\Program Files\Microsoft SQL Server\MSSQL\data\pubs.mdf', move 'pubs_log' to 'c:\Program Files\Microsoft SQL Server\MSSQL\data\pubs_log.ldf', standby = 'c:\Program Files\Microsoft SQL Server\MSSQL\data\pubs.udf'
    se você tentar conectar-se ao server2 usando o logon testlogin1 ou testlogin2, o falha de logon porque testlogin1 e testlogin2 não existem neste servidor. No entanto, adicionar esses logons Servidor2 não permite acesso o banco de dados pubs .

Etapas para resolver o comportamento

No servidor1, siga esta etapa:
  • Executar a consulta a seguir no servidor1 para obter o SID informações para os logons que você criou na etapa 3 do procedimento anterior:
    select name, sid from master..syslogins where name in ('testlogin1', 'testlogin2')
    a consulta retorna a saída é semelhante a seguinte saída:
    name                 sid -------------------- --------------------------------------testlogin1           0xED10269A01E2654BA89E33D42AEDFAAF testlogin2           0x704C5B2CB4DB234EAE89BFBCE7B6A46F (2 row(s) affected)
No Servidor2, execute as seguintes etapas:
  1. Descartar o testlogin1 logons e testlogin2 da Servidor2 (se você criado-los em um procedimento anterior). Para fazer isso, use o seguinte código:
    use master go sp_droplogin 'testlogin1' go sp_droplogin 'testlogin2' go
  2. Execute as seguintes consultas para criar testlogin1 e testlogin2 no server2 usando o código a seguir:
    sp_addlogin 'testlogin1', @passwd='pwd1', @sid=SID value go sp_addlogin 'testlogin2', @passwd='pwd2', @sid=SID value go
  3. Após a criação de logons, conectar-se para server2 usando as credenciais de logon para testlogin1 ou testlogin2.
  4. Depois de se conectar ao servidor, execute uma consulta SELECT no banco de dados pubs .
Há duas tabelas de sistema que são usadas para armazenar as informações de logon para o banco de dados pubs :
  • syslogins no banco de dados mestre.
  • sysusers no banco de dados pubs .
A tabela syslogins contém todos os logons que foram criados no servidor. A tabela de sysusers contém os usuários que são mapeados para o banco de dados usando o campo de SID . Se você backup do banco de dados em um servidor e restaurar o banco de dados em um segundo servidor, o backup manterá o valor de SID para os usuários na tabela sysusers . No entanto, como os valores de SID na tabela syslogins são diferentes, os usuários não é possível consultar o banco de dados em espera. Você pode corrigir esse problema criando logons com o mesmo valor SID que o servidor de origem.
Referências
Para obter mais informações, clique no número abaixo para ler o artigo na Base de dados de Conhecimento da Microsoft:
240872Como resolver problemas de permissão quando você move um banco de dados entre servidores que estão executando o SQL Server

Propriedades

ID do Artigo: 303722 - Última Revisão: 12/08/2005 22:02:53 - Revisão: 6.4

Microsoft SQL Server 2000 Standard Edition, Microsoft SQL Server 2000 64-bit Edition, Microsoft SQL Server 2005 Standard Edition, Microsoft SQL Server 2005 Developer Edition, Microsoft SQL Server 2005 Enterprise Edition, Microsoft SQL Server 2005 Workgroup Edition

  • kbmt kbhowtomaster kbhowto kbinfo KB303722 KbMtpt
Comentários
d"; document.getElementsByTagName("head")[0].appendChild(m);