Gerenciamento de logons e trabalhos para os bancos de dados de um grupo de disponibilidade (SQL Server)

  • Artigo

Você deve manter o mesmo conjunto de logons de usuários e trabalhos do SQL Server Agent rotineiramente em todo banco de dados primário de um grupo de disponibilidade AlwaysOn e nos bancos de dados secundários correspondentes. Os logons e trabalhos devem ser reproduzidos em toda instância do SQL Server que hospede uma réplica de disponibilidade para o grupo de disponibilidade.

  • Trabalhos do SQL Server Agent

    Você precisa copiar manualmente trabalhos relevantes da instância de servidor que hospeda a réplica primária original nas instâncias de servidor que hospedam as réplicas secundárias originais. Para todos os bancos de dados, você precisa adicionar lógica no início de cada trabalho relevante para que o trabalho seja executado somente no banco de dados primário, ou seja, apenas quando a réplica local for a réplica primária do banco de dados.

    As instâncias de servidor que hospedam as réplicas de disponibilidade de um grupo de disponibilidade podem ser configuradas de maneira diferente, com diferentes letras de unidade de fita ou algo assim. Os trabalhos de cada réplica de disponibilidade devem permitir essas diferenças.

    Observe que os trabalhos de backup podem usar a função sys.fn_hadr_is_preferred_backup_replica para identificar se a réplica local é a preferencial para backups, de acordo com as preferências de backup do grupo de disponibilidade. Os trabalhos de backup criados usando o Assistente de Plano de Manutenção nativamente usam essa função. Para outros trabalhos de backup, recomendamos o uso dessa função como condição em seus trabalhos de backup, de forma que eles sejam executados apenas na réplica preferencial. Para obter mais informações, consulte Secundárias ativas: backup em réplicas secundárias (Grupos de Disponibilidade AlwaysOn).

  • Logons

    Se você estiver usando bancos de dados independentes, poderá configurar usuários independentes nos bancos de dados e, para esses usuários, não precisará criar logons nas instâncias do servidor que hospedam uma réplica secundária. Para um banco de dados de disponibilidade dependente, você precisará criar usuários para os logons nas instâncias do servidor que hospedam as réplicas de disponibilidade. Para obter mais informações, consulte CREATE USER (Transact-SQL).

    Se algum de seus aplicativos usa a Autenticação do SQL Server ou um logon local do Windows, consulte Logons de aplicativos que usam Autenticação do SQL Server ou logon local do Windows posteriormente neste tópico.

    ObservaçãoObservação

    Um usuário de banco de dados para o qual o logon do SQL Server não está definido ou está definido incorretamente em uma instância do servidor não pode fazer logon na instância. Esse usuário é um usuário órfão do banco de dados nessa instância do servidor. Se um usuário se tornar órfão em uma determinada instância de servidor, você poderá configurar os logons de usuários a qualquer momento. Para obter mais informações, consulte Solução de problemas de usuários órfãos (SQL Server).

  • Metadados adicionais

    Os logons e os trabalhos não são as únicas informações que precisam ser recriadas em cada instância de servidor que hospeda uma réplica secundária para determinado grupo de disponibilidade. Por exemplo, talvez você precise recriar parâmetros de configuração de servidor, credenciais, dados criptografados, permissões, configurações de replicação, aplicativos do service broker, gatilhos (em nível de servidor) e assim por diante. Para obter mais informações, consulte Gerenciar metadados ao disponibilizar um banco de dados em outra instância do servidor (SQL Server).

Os logons dos aplicativos que usam a autenticação do SQL Server ou Logon local do Windows

Se um aplicativo usar a autenticação do SQL Server ou um logon local do Windows, as SIDs incompatíveis poderão impedir que o logon do aplicativo seja resolvido em uma instância remota do SQL Server. As SIDs incompatíveis fazem o logon se tornar um usuário órfão na instância do servidor remoto. Esse problema pode ocorrer quando um aplicativo se conectar a um banco de dados espelhado ou de envio de logs depois de um failover ou a um banco de dados de assinante de replicação que foi inicializado de um backup.

Para evitar esse problema, recomendamos que você tome medidas preventivas quando configurar esse aplicativo para usar um banco de dados que seja hospedado por uma instância remota do SQL Server. A prevenção envolve transferir os logons e as senhas da instância local do SQL Server para a instância remota do SQL Server. Para obter mais informações sobre como evitar esse problema, consulte o artigo 918992 da base de dados: Como transferir os logons e senhas entre instâncias do SQL Server 2005 e SQL Server 2008.

ObservaçãoObservação

Esse problema afeta contas locais do windows em computadores diferentes. No entanto, esse problema não ocorre para contas de domínio porque o SID será o mesmo em cada computador.

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).

Tarefas relacionadas

Consulte também

Conceitos

Visão geral de grupos de disponibilidade AlwaysOn (SQL Server)

Bancos de dados contidos

Criar trabalhos