Gestion des connexions et des travaux pour les bases de données d'un groupe de disponibilité (SQL Server)
Vous devez maintenir régulièrement le même ensemble de connexions utilisateur et de travaux de l'Agent SQL Server sur chaque base de données primaire d'un groupe de disponibilité AlwaysOn et les bases de données secondaires correspondantes. Les connexions et les travaux doivent être reproduits sur chaque instance de SQL Server qui héberge un réplica de disponibilité pour le groupe de disponibilité.
Travaux de l'Agent SQL Server
Vous devez copier manuellement les travaux appropriés de l'instance de serveur qui héberge le réplica principal d'origine vers les instances de serveur qui hébergent les réplicas secondaires d'origine. Pour toutes les bases de données, vous devez ajouter la logique au début de chaque travail approprié de façon à ce que le travail s'exécute uniquement sur la base de données primaire, c.-à-d., uniquement lorsque le réplica local est le réplica principal pour la base de données.
Les instances de serveur qui hébergent les réplicas de disponibilité d'un groupe de disponibilité peuvent être configurées différemment, avec des lettres de lecteurs de bande ou de lecteur différentes. Les travaux de chaque réplica de disponibilité doivent autoriser de telles différences.
Notez que les travaux de sauvegarde peuvent utiliser la fonction sys.fn_hadr_is_preferred_backup_replica pour déterminer si le réplica local est celui qui est utilisé par défaut pour les sauvegardes, selon les préférences de sauvegarde du groupe de disponibilité. Les travaux de sauvegarde créés à l'aide de l'Assistant Plan de maintenance utilisent cette fonction en mode natif. Pour d'autres travaux de sauvegarde, nous vous recommandons d'utiliser cette fonction comme condition dans vos travaux de sauvegarde, de façon à ce qu'ils s'exécutent uniquement sur le réplica par défaut. Pour plus d'informations, consultez Secondaires actifs : sauvegarde sur les réplicas secondaires (groupes de disponibilité d'AlwaysOn).
Connexions
Si vous utilisez des bases de données à relation contenant-contenu, vous pouvez configurer les utilisateurs contenus dans les bases de données, et pour ces utilisateurs, vous n'avez pas besoin de créer des connexions sur des instances de serveur qui hébergent un réplica secondaire. Pour une base de données de disponibilité sans relation contenant-contenu, vous devrez créer les utilisateurs pour les connexions sur les instances de serveur qui hébergent les réplicas de disponibilité. Pour plus d'informations, consultez CREATE USER (Transact-SQL).
Si l'une de vos applications utilise l'authentification SQL Server ou une connexion locale Windows, consultez Connexions des applications qui utilisent l'authentification SQL Server ou une connexion locale Windows, plus loin dans cette rubrique.
[!REMARQUE]
Un utilisateur de base de données pour lequel la connexion SQL Server n'est pas définie sur une instance de serveur, ou l'est de façon incorrecte, ne peut pas se connecter à cette instance. L'utilisateur devient donc un utilisateur orphelin de la base de données sur cette instance du serveur. Si un utilisateur est orphelin sur une instance de serveur donnée, vous pouvez configurer les connexions utilisateur à tout moment. Pour plus d'informations, consultez Dépanner des utilisateurs orphelins (SQL Server).
Métadonnées supplémentaires
Les connexions et les travaux ne sont pas les seules informations qui doivent être recréées sur chaque instance de serveur qui héberge un réplica secondaire d'un groupe de disponibilité donné. Par exemple, vous devrez peut-être recréer les paramètres de configuration du serveur, les informations d'identification, les données chiffrées, les autorisations, les paramètres de réplication, les applications de Service Broker, les déclencheurs (au niveau du serveur), etc. Pour plus d'informations, consultez Gérer les métadonnées lors de la mise à disposition d'une base de données sur une autre instance de serveur (SQL Server).
Connexions des applications qui utilisent l'authentification SQL Server ou une connexion locale Windows
Si une application utilise l'authentification SQL Server ou une connexion locale Windows, des SID incompatibles peuvent empêcher la résolution de la connexion de l'application sur une instance distante de SQL Server. En cas de SID incompatibles, la connexion peut se solder par un utilisateur orphelin sur l'instance de serveur distante. Ce problème peut se produire lorsqu'une application se connecte à une base de données de copie des journaux de transaction ou une base de données mise en miroir suite à un basculement ou à une base de données d'abonné de réplication qui a été initialisée à partir d'une sauvegarde.
Pour éviter ce problème, nous vous recommandons de prendre des mesures préventives lorsque vous configurez une telle application de manière à utiliser une base de données hébergée par une instance distante de SQL Server. La prévention implique de transférer des connexions et des mots de passe de l'instance locale de SQL Server à l'instance distante de SQL Server. Pour plus d'informations sur la manière d'éviter ce problème, consultez l'article 918992 de la base de connaissances Microsoft : Comment faire pour transférer des noms d'accès et des mots de passe entre instances de SQL Server 2005 et SQL Server 2008.
[!REMARQUE]
Ce problème affecte les comptes Windows locaux sur différents ordinateurs. Toutefois, ce problème ne se pose pas pour les comptes de domaine car le SID est identique sur chacun des ordinateurs.
Pour plus d'informations, consultez Orphaned Users with Database Mirroring and Log Shipping (blog du moteur de base de données).
Tâches associées
Voir aussi
Concepts
Vue d'ensemble des groupes de disponibilité AlwaysOn (SQL Server)