Gestione di account di accesso e di processi dopo un cambio di ruolo (SQL Server)

Si applica a: SQL Server

Quando si distribuisce una soluzione di disponibilità elevata e ripristino di emergenza per un database di SQL Server, è importante riprodurre le informazioni più significative archiviate per il database nei database master o msdb. In genere, tra queste informazioni sono inclusi i processi del database primario/principale e gli account di accesso di utenti o processi necessari per la connessione al database. È consigliabile duplicare queste informazioni in qualsiasi istanza di SQL Server in cui viene ospitato un database secondario/mirror. Se possibile, dopo il cambio di ruolo, è opportuno riprodurre le informazioni a livello di programmazione nel nuovo database primario/principale.

Account di accesso

In tutte le istanze del server in cui viene ospitata una copia del database, è consigliabile riprodurre gli account di accesso con l'autorizzazione ad accedere al database principale. Quando il ruolo primario/principale cambia, solo gli utenti con account di accesso presenti nella nuova istanza del server primario/principale possono accedere al nuovo database primario/principale. Gli utenti i cui account di accesso non sono definiti nella nuova istanza del server primario/principale sono orfani e non possono accedere al database.

Se un utente è orfano, creare l'account di accesso nella nuova istanza del server primario/principale ed eseguire sp_change_users_login. Per altre informazioni, vedere Risolvere i problemi relativi agli utenti isolati (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 allamodalità 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).

Processi

I processi, ad esempio quelli di backup, richiedono una particolare attenzione. Dopo un cambio di ruolo, in genere il proprietario del database o l'amministratore di sistema deve ricreare i processi per il nuovo database primario/principale.

Se l'istanza del server primario/principale precedente è disponibile, è consigliabile eliminare i processi originali nell'istanza di SQL Server in questione. Si noti che i processi nel database mirror attuale non vengono eseguiti poiché il database si trova nello stato RESTORING e, pertanto, non è disponibile.

Nota

È possibile che istanze differenti di SQL Server siano configurate in modo diverso, ad esempio con lettere di unità differenti. I processi di ogni partner devono supportare eventuali differenze di questo tipo.

Vedi anche

Gestire i metadati quando si rende disponibile un database in un'altra istanza del server (SQL Server)
Risolvere i problemi relativi agli utenti isolati (SQL Server)