Gestion des connexions et des travaux après un basculement de rôle
Seul le contenu de la base de données principale est mis en miroir. Les informations associées de la base de données système master ou de la base de données système msdb ne peuvent être mises en miroir. Ces informations associées incluent les travaux configurés pour agir sur la base de données principale, ainsi que les connexions ajoutées au serveur principal.
Si ces informations sont nécessaires pour la prise en charge du basculement de rôle, elles doivent être dupliquées au niveau du site mis en miroir. Si possible, il est préférable de reproduire, par programmation, l'information au niveau de la nouvelle base de données principale, après le basculement des rôles. Les problèmes les plus fréquents se situent au niveau des connexions et des travaux.
Connexions
Pour que les utilisateurs soient capables d'accéder à la base de données après un basculement de rôle, une connexion au serveur principal ayant l'autorisation d'accéder à la base de données principale doit également être définie sur le serveur miroir. Cependant, la base de données master ne peut être mise en miroir. Par conséquent, si vous créez une nouvelle connexion sur le serveur principal actuel pour accéder à la base de données principale, vous devez faire de même sur le serveur miroir.
La connexion de chaque utilisateur de la base de données doit être définie manuellement sur le serveur miroir et sur le serveur principal. Dans le cas contraire, lorsque le rôle principal bascule et que l'ancien serveur miroir présente sa base de données en tant que base de données principale, les utilisateurs dont les connexions ne sont pas définies sur l'ancien miroir ne peuvent accéder à la nouvelle base de données principale. Les utilisateurs sont orphelins.
Si un utilisateur est orphelin sur la nouvelle base de données principale, créez-y la connexion et exécutez sp_change_users_login (Transact-SQL). Pour plus d'informations, consultez Dépannage des utilisateurs orphelins.
Connexions des applications qui utilisent l'authentification SQL Server
Si une application qui tente de se connecter à une base de données mise en miroir utilise l'authentification SQL, une incompatibilité des SID peut empêcher la connexion de l'application après un basculement, ce qui crée un utilisateur orphelin. Vous pouvez utiliser sp_change_users_login pour résoudre un utilisateur orphelin (voir Dépannage des utilisateurs orphelins).
Cependant, nous vous recommandons de prendre des mesures préventives lorsque vous configurez une telle application pour utiliser la base de données miroir. Pour plus d'informations sur la manière d'éviter ce problème, consultez l'article 918992 de la base de connaissances Microsoft : Comment transférer les connexions et les mots de passe entre des instances de SQL Server 2005 et SQL Server 2008.
Notes
Ce problème ne se pose pas lorsque vous utilisez l'authentification Windows, car les SID pour les connexions Windows ne sont pas spécifiques aux ordinateurs et sont fournis par Active Directory.
Travaux
Les travaux tels que les travaux de sauvegarde, requièrent une attention particulière. Généralement, après un basculement de rôle, le propriétaire de la base de données ou l'administrateur système doit recréer les travaux de la nouvelle base de données principale.
Lorsque l'ancien serveur principal est disponible, vous devez également supprimer les travaux originaux de la nouvelle base de données miroir. Les travaux de la base de données miroir échouent dans la mesure où elle se trouve en état de restauration (RESTORING) et qu'elle n'est ainsi pas disponible.
Notes
Les partenaires doivent être configurés différemment, avec des lettres de lecteurs de bande différentes, ou quelque chose d'équivalent. Les travaux de chaque partenaire doivent autoriser de telles différences.