Gestire gli account di accesso per i processi che usano i database di un gruppo di disponibilità Always On

Si applica a:SQL Server

È necessario gestire periodicamente lo stesso set di account di accesso utente e processi SQL Server Agent in ogni database primario di un gruppo di disponibilità AlwaysOn e nei database secondari corrispondenti. Gli account di accesso e i processi devono essere riprodotti in ogni istanza di SQL Server Agent in cui è ospitata una replica di disponibilità per il gruppo di disponibilità.

  • SQL Server Agent - processi

    È necessario copiare manualmente i processi rilevanti dall'istanza del server in cui è ospitata la replica primaria originale alle istanze del server in cui sono ospitate le repliche secondarie originali. Per tutti i database è necessario aggiungere logica all'inizio di ogni processo rilevante affinché il processo venga eseguito solo nel database primario, ovvero solo se la replica locale è la replica primaria del database.

    Le istanze del server che ospitano le repliche di disponibilità di un gruppo di disponibilità potrebbero essere configurate in modo diverso, con lettere di unità nastro diverse e così via. I processi per ogni replica di disponibilità devono supportare eventuali differenze di questo tipo.

    I processi di backup possono usare la funzione sys.fn_hadr_is_preferred_backup_replica per identificare se la replica locale è quella preferita per i backup, in base alle preferenze di backup del gruppo di disponibilità. I processi di backup creati tramite la Creazione guidata piano di manutenzione a livello nativo usano questa funzione. Per altri processi di backup, è consigliabile utilizzare questa funzione come condizione nei processi di backup, pertanto vengono eseguiti solo nella replica preferita. Per altre informazioni, vedere Repliche secondarie attive: Backup in repliche secondarie (Gruppi di disponibilità Always On).

  • Account di accesso

    Se si utilizzano database indipendenti, è possibile configurare utenti indipendenti nei database per i quali non è necessario creare account di accesso nelle istanze del server che ospitano una replica secondaria. Per un database di disponibilità non indipendente, sarà necessario creare utenti per gli account di accesso nelle istanze del server che ospitano le repliche di disponibilità. Per altre informazioni, vedere CREATE USER (Transact-SQL).

    Se una o più applicazioni usano l'autenticazione SQL Server o un account Windows locale, vedere Account di accesso di applicazioni in cui viene usata l'autenticazione di SQL Server o un account di accesso di Windows locale, più avanti in questo argomento.

    Nota

    Un utente del database il cui account di accesso di SQL Server non è definito o è definito in modo errato in un'istanza del server non potrà accedere a tale istanza. Questo utente viene definito utente orfano del database nell'istanza del server. Se un utente è isolato in una determinata istanza del server, è possibile impostare account di accesso utente in qualsiasi momento. Per altre informazioni, vedere Risolvere i problemi relativi agli utenti isolati (SQL Server).

  • Metadati aggiuntivi

    Gli account di accesso e i processi non sono le uniche informazioni che è necessario ricreare in ogni istanza del server in cui è ospitata una replica secondaria per uno specifico gruppo di disponibilità. Potrebbe ad esempio essere necessario ricreare le impostazioni di configurazione del server, credenziali, dati crittografati, autorizzazioni, impostazioni di replica, applicazioni di Service Broker, trigger (a livello di server) e così via. Per altre informazioni, vedere Gestire i metadati quando si rende disponibile un database in un'altra istanza del server (SQL Server).

Account di accesso di applicazioni in cui viene utilizzata l'autenticazione di SQL Server o un account di accesso di Windows locale

Se in un'applicazione viene usata l'autenticazione di SQL Server o un account di accesso di Windows locale, i SID non corrispondenti possono impedire la risoluzione in un'istanza remota di SQL Server da parte dell'account di accesso dell'applicazione. In caso di SID non corrispondenti, l'account di accesso diventa un utente orfano nell'istanza del server remoto. Questo problema si può verificare quando tramite un'applicazione si effettua la connessione a un database di log shipping o con mirroring dopo un failover o a un database Sottoscrittore di replica inizializzato da un backup.

Per evitare questo problema, è consigliabile intraprendere misure preventive quando si configura un'applicazione di questo tipo per usare un database ospitato da un'istanza remota di SQL Server. La prevenzione comporta il trasferimento degli account di accesso e delle password dall'istanza locale di SQL Server all'istanza remota di SQL Server. Per altre informazioni su come evitare questo problema, vedere l'articolo della Knowledge Base 918992 relativo alla modalità di trasferimento degli account di accesso e delle password tra le istanze di SQL Server.

Nota

Questo problema influisce sugli account di Windows locali in computer diversi. Tuttavia, non si verifica in caso di account di dominio, dal momento che il SID è identico in ogni computer.

Per altre informazioni, vedere la pagina relativa agli utenti orfani con log shipping e mirroring del database (blog del motore di database).

Attività correlate

Vedi anche

Panoramica di Gruppi di disponibilità AlwaysOn (SQL Server)
Database indipendenti
Creare commesse