Partilhar via

Gerir logins para tarefas usando bases de dados em um grupo de disponibilidade Always On

Aplica-se a:SQL Server

Você deve rotineiramente manter 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 Always On (AG), assim como nos bancos de dados secundários correspondentes. Os logons e tarefas devem ser reproduzidos em qualquer instância do SQL Server que hospede uma réplica de disponibilidade para o AG.

  • Trabalhos do SQL Server Agent

    Você precisa copiar manualmente trabalhos relevantes da instância do servidor que hospeda a réplica primária original para as instâncias do 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 fazer com que o trabalho seja executado somente no banco de dados primário, ou seja, somente 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 ser configuradas de forma diferente, com letras de unidade diferentes, por exemplo. Os trabalhos para cada réplica de disponibilidade devem permitir essas diferenças.

    Os trabalhos de backup podem usar a função sys.fn_hadr_backup_is_preferred_replica para identificar se a réplica local é a preferida para backups, de acordo com as preferências de backup AG. Os trabalhos de backup criados usando o Assistente do Plano de Manutenção usam essa função de forma nativa. Para outros trabalhos de backup, recomendamos que você use essa função como uma condição em seus trabalhos de backup, para que eles sejam executados apenas na réplica preferida. Para obter mais informações, consulte Transferir backups suportados para réplicas secundárias de um grupo de disponibilidade.

  • Inícios de sessão

    Se você estiver usando bancos de dados contidos, poderá configurar usuários contidos nos bancos de dados e, para esses usuários, não será necessário criar logons nas instâncias do servidor que hospedam uma réplica secundária. Para um banco de dados de disponibilidade não contido, 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, consulte CREATE USER.

    Se algum dos seus aplicativos usar a Autenticação do SQL Server ou um logon local do Windows, consulte Logons de aplicativos que usam autenticação do SQL Server ou um logon local do Windows, mais adiante neste artigo.

    Observação

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

  • Metadados adicionais

    Logins e trabalhos não são as únicas informações que precisam ser recriadas em cada uma das instâncias do servidor que hospedam uma réplica secundária para um AG determinado. Por exemplo, talvez seja necessário recriar definições de configuração do servidor, credenciais, dados criptografados, permissões, configurações de replicação, aplicativos do agente de serviços, gatilhos (no nível do servidor) e assim por diante. Para obter mais informações, consulte Gerenciar metadados ao disponibilizar um banco de dados em outro servidor.

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

Se um aplicativo usa a Autenticação do SQL Server ou um logon local do Windows, identificadores de segurança (SIDs) incompatíveis podem impedir que o logon do aplicativo seja resolvido em uma instância remota do SQL Server. Os SIDs incompatíveis fazem com que o logon se torne um usuário órfão na instância do servidor remoto. Esse problema pode ocorrer quando um aplicativo se conecta a um banco de dados espelhado ou de envio de logs após um failover ou a um banco de dados de assinante de replicação que foi inicializado a partir de um backup.

Você deve tomar medidas preventivas ao configurar um aplicativo para usar um banco de dados hospedado por uma instância remota do SQL Server. A prevenção envolve a transferência dos logons e das 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 da Base de Dados de Conhecimento 918992-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 é o mesmo em cada um dos computadores.

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

  • Last updated on