Compartilhar via

Gerenciar logons para trabalhos usando bancos de dados em um grupo de disponibilidade Always On

  • Artigo

Aplica-se: SQL Server

Como rotina, você deve manter o mesmo conjunto de logons de usuários e trabalhos do SQL Server Agent em cada banco de dados primário de um AG (grupo de disponibilidade) Always On 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 AG.

  • SQL Server Trabalhos do agente

    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 AG podem estar configuradas de maneira diferente, por exemplo, com diferentes letras de unidade. Os trabalhos de cada réplica de disponibilidade devem permitir essas diferenças.

    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 AG. 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 mais informações, confira Descarregar backups com suporte em réplicas secundárias de um grupo de disponibilidade.

  • Logons

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

    Se qualquer uma de suas aplicações usarem Autenticação do SQL Server ou um logon local do Windows, consulte Logons das aplicações que usam Autenticação do SQL Server ou Logon local do Windows posteriormente neste tópico.

    Observação

    Um usuário de banco de dados para o qual o logon do SQL Server não esteja definido ou esteja 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, confira Solucionar 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 AG. 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, confira Gerenciar metadados ao disponibilizar um banco de dados em outro servidor.

Autenticação do SQL Server ou um logon local do Windows

Se uma aplicação usar a autenticação do SQL Server ou um logon local do Windows, SIDs (IDs de segurança) divergentes podem impedir que o logon da aplicação 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.

Você deve adotar 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 prevenir esse problema, confira o artigo da base de dados 918992, Como transferir logons e 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).

Conteúdo relacionado