Compartilhar via

Gerenciamento de logins e tarefas para os bancos de dados de um grupo de disponibilidade (SQL Server)

Você deve manter rotineiramente o mesmo conjunto de logons de usuário e trabalhos do SQL Server Agent em cada banco de dados primário de um grupo de disponibilidade AlwaysOn e nos bancos de dados secundários correspondentes. Os logons e tarefas devem ser reproduzidos em cada instância do SQL Server que hospede uma réplica de disponibilidade do 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 um grupo de alta disponibilidade podem ter configurações diferentes, como letras de unidade de disco diferentes ou outras variáveis semelhantes. 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 preferida 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 usam essa função nativamente. 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ários Ativos: Backup em Réplicas Secundárias (Grupos de Disponibilidade AlwaysOn).

  • Logons

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

    Se qualquer um de seus aplicativos usar a Autenticação do SQL Server ou um logon local do Windows, consulte Logons de aplicativos que usam a Autenticação do SQL Server ou um Logon local do Windows, mais adiante neste tópico.

    Observação

    Um usuário de banco de dados para o qual o logon do SQL Server é indefinido ou está definido incorretamente em uma instância de 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, confira Solucionar problemas de usuários órfãos (SQL Server).

  • Metadados adicionais

    Logons e trabalhos não são as únicas informações que precisam ser recriadas em cada uma das instâncias do servidor que hospeda uma réplica secundária para um determinado grupo de disponibilidade. Por exemplo, talvez seja necessário recriar as configurações de servidor, credenciais, dados criptografados, permissões, configurações de replicação, aplicativos do service broker, gatilhos (no nível do servidor) e assim por diante. Para obter mais informações, confira 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 do KB 918992-Como transferir os logons e as senhas entre instâncias do SQL Server).

Observaçã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

Visão geral dos Grupos de Disponibilidade AlwaysOn (SQL Server)
Bancos de dados independentes
Criar Empregos

  • Last updated on