Conditions préalables, restrictions et recommandations pour la mise en miroir de bases de données

Cette rubrique décrit les prérequis et les recommandations pour la configuration de la mise en miroir de bases de données. Pour une présentation de la mise en miroir de bases de données, consultez La mise en miroir de bases de données (SQL Server)

Prise en charge de la mise en miroir de bases de données

Pour plus d’informations sur la prise en charge de la mise en miroir de bases de données dans SQL Server 2014, consultez Fonctionnalités prises en charge par les éditions de SQL Server 2014.

Notez que la mise en miroir de bases de données fonctionne avec n’importe quel niveau de compatibilité de base de données pris en charge. Pour plus d’informations sur les niveaux de compatibilité pris en charge, consultez ALTER DATABASE Compatibility Level (Transact-SQL).

Conditions préalables

• Pour qu’une session de mise en miroir soit établie, les partenaires et le témoin doivent s’exécuter sur la même version de SQL Server.

• Les deux partenaires, c’est-à-dire le serveur principal et le serveur miroir, doivent exécuter la même édition de SQL Server. Le témoin, le cas échéant, peut s’exécuter sur n’importe quelle édition de SQL Server qui prend en charge la mise en miroir de bases de données.

  Remarque

  Vous pouvez mettre à niveau des instances de serveur qui sont des partenaires dans une session de mise en miroir vers une version plus récente de SQL Server. Pour plus d’informations, consultez Réduire les temps d’arrêt pour les bases de données mises en miroir lors de la mise à niveau des instances de serveur.

• La base de données doit utiliser le modèle de récupération complète. Les modèles de récupération simples et journalisés en bloc ne prennent pas en charge la mise en miroir de bases de données. Par conséquent, les opérations en bloc sont toujours entièrement journalisées pour une base de données mise en miroir. Pour plus d’informations sur les modèles de récupération, consultez Modèles de récupération (SQL Server).

• Vérifiez que le serveur miroir dispose d’un espace disque suffisant pour la base de données miroir.

  Remarque

  Pour plus d’informations sur l’utilisation de la mise en miroir de bases de données sur une base de données répliquée, consultez La mise en miroir et la réplication de bases de données (SQL Server).

• Lorsque vous créez la base de données miroir sur le serveur miroir, veillez à restaurer la sauvegarde de la base de données principale spécifiant le même nom de base de données WITH NORECOVERY. En outre, toutes les sauvegardes de journal créées après cette sauvegarde doivent également être appliquées, à nouveau en utilisant NORECOVERY.

  Important

  Si la mise en miroir de bases de données a été arrêtée, avant de pouvoir le redémarrer, toutes les sauvegardes de journaux suivantes effectuées sur la base de données principale doivent être appliquées à la base de données miroir.

Restrictions

• Seules les bases de données utilisateur peuvent être mises en miroir. Vous ne pouvez pas mettre en miroir les bases de données master, msdb, tempdb ou model .

• Une base de données mise en miroir ne peut pas être renommée pendant une session de mise en miroir de bases de données.

• La mise en miroir de bases de données ne prend pas en charge FILESTREAM. Impossible de créer un groupe de fichiers FILESTREAM sur le serveur principal. Impossible de configurer la mise en miroir de bases de données pour une base de données qui contient des groupes de fichiers FILESTREAM.

• Sur un système 32 bits, la mise en miroir de bases de données peut prendre en charge un maximum de 10 bases de données par instance de serveur en raison du nombre de threads de travail consommés par chaque session de mise en miroir de bases de données.

• La mise en miroir de bases de données n’est pas prise en charge avec les transactions entre bases de données ou les transactions distribuées. Pour plus d’informations, consultez Transactions inter-bases de données non prises en charge pour la mise en miroir de bases de données ou les groupes de disponibilité AlwaysOn (SQL Server).

Recommandations pour la configuration des serveurs partenaires

• Les partenaires doivent s’exécuter sur des systèmes comparables qui peuvent gérer des charges de travail identiques.

  Remarque

  Si vous envisagez d’utiliser le mode haute sécurité avec basculement automatique, la charge normale sur chaque partenaire de basculement doit être inférieure à 50 % du processeur. Si votre charge de travail surcharge le processeur, un partenaire de basculement peut ne pas être capable d'envoyer un ping aux instances de serveur dans la session de mise en miroir. Cela entraîne un basculement inutile. Si vous ne pouvez pas conserver l’utilisation du processeur sous 50 pour cent, nous vous recommandons d’utiliser le mode haute sécurité sans basculement automatique ou le mode hautes performances.

• Dans la mesure du possible, le chemin d’accès (y compris la lettre de lecteur) de la base de données miroir doit être identique au chemin d’accès de la base de données principale. Vous devez inclure l’option MOVE dans l’instruction RESTORE si les dispositions de fichier doivent différer. Par exemple, si la base de données principale se trouve sur le lecteur « F : », mais que le système miroir ne dispose pas d’un lecteur F : .

  Important

  Si vous déplacez les fichiers de base de données lorsque vous créez la base de données miroir, il se peut que vous ne puissiez pas ajouter de fichiers à la base de données ultérieurement sans que la mise en miroir soit suspendue.

• Toutes les instances de serveur d’une session de mise en miroir doivent utiliser la même page de codes maîtres et le même classement. Les différences peuvent entraîner un problème lors de la configuration de la mise en miroir.

• Si vous le souhaitez, estimez le temps de basculement d’une base de données pour vous assurer que la configuration du système fournira les performances dont vous avez besoin. Pour plus d’informations, consultez Estimer l’interruption du service pendant le basculement de rôle (mise en miroir de bases de données).

• Pour des performances optimales, utilisez une carte réseau dédiée (carte d’interface réseau) pour la mise en miroir.

• Nous ne faisons aucune recommandation sur la fiabilité d’un réseau étendu (WAN) pour la mise en miroir de bases de données en mode haute sécurité. Si vous décidez d’utiliser le mode haute sécurité sur un WAN, soyez prudent sur la manière d'ajouter un témoin à la session, car des basculements automatiques non souhaités pourraient survenir. Pour plus d’informations, consultez Recommandations pour le déploiement de la mise en miroir de bases de données, plus loin dans cette rubrique.

Recommandations pour le déploiement de la mise en miroir de bases de données

Des performances optimales de mise en miroir de bases de données sont obtenues à l’aide d’une opération asynchrone. Une session de mise en miroir qui utilise une opération synchrone peut rencontrer des performances lentes quand sa charge de travail génère de grandes quantités de données du journal des transactions.

Dans les environnements de test, il est approprié d’explorer tous les modes d’exploitation pour évaluer l’exécution de la mise en miroir de bases de données. Toutefois, avant de déployer la mise en miroir dans un environnement de production, assurez-vous de comprendre comment fonctionne le réseau dans le monde réel.

Le mode haute sécurité avec basculement automatique est conçu pour un réseau à haut service doté d’une connexion dédiée ou d’une configuration réseau relativement simple qui réduit les sources de défaillances réseau possibles. Un tel environnement réseau de haute qualité est nécessaire pour le mode haute sécurité avec basculement automatique et est recommandé pour toutes les sessions de mise en miroir de bases de données. Toutefois, le mode hautes performances et le mode haute sécurité sans basculement automatique sont beaucoup moins affectés par la fiabilité du réseau.

Par conséquent, pour les environnements de production, nous vous recommandons de respecter les instructions de déploiement suivantes :

1. Commencez à fonctionner en mode asynchrone et haut performance. Ce mode est le moins sensible à l’environnement réseau et fournit la meilleure configuration pour explorer le fonctionnement de la mise en miroir. Nous vous recommandons d’exécuter votre système de manière asynchrone jusqu’à ce que vous soyez certain que votre bande passante prend en charge la mise en miroir et que vous avez développé une compréhension de la configuration de la mise en miroir et des performances du mode asynchrone dans votre environnement. Pour plus d’informations, consultez Modes d’exploitation de mise en miroir de bases de données.

   Important

   Tout au long du test, nous vous recommandons de surveiller vos sessions pour les erreurs réseau qui entraînent l’échec de la mise en miroir de bases de données. Pour plus d’informations sur les sources potentielles d’échec, consultez Échecs possibles pendant la mise en miroir de bases de données. Pour plus d’informations sur la surveillance de la mise en miroir de bases de données, consultez Surveillance de la mise en miroir de bases de données (SQL Server).

2. Lorsque vous êtes certain que l’opération asynchrone répond aux besoins de l’entreprise, vous pouvez essayer une opération synchrone pour améliorer votre protection des données. Lorsque vous testez le fonctionnement de la mise en miroir synchrone dans votre environnement, nous vous recommandons d’abord de tester le mode haute sécurité sans basculement automatique. L’objectif principal de ce test est de voir comment l’opération synchrone affecte les performances de la base de données. Pour plus d’informations, consultez Modes d’exploitation de mise en miroir de bases de données.

3. Attendez d’activer le basculement automatique jusqu’à ce que vous soyez certain que le mode haute sécurité sans basculement automatique répond aux besoins de l’entreprise et que les erreurs réseau ne provoquent pas de défaillances. Pour plus d’informations, consultez Changement de rôle pendant une session de mise en miroir de bases de données (SQL Server).

Voir aussi

Configuration de la mise en miroir de bases de données (SQL Server)
Sécurité du transport pour la mise en miroir de bases de données et les groupes de disponibilité AlwaysOn (SQL Server)
Mise en miroir de bases de données (SQL Server)
Résoudre les problèmes de configuration de mise en miroir de bases de données (SQL Server)