Partager via


Basculement manuel

Le basculement manuel déconnecte les clients de la base de données et inverse les rôles des partenaires. Seul le mode haute sécurité prend en charge le basculement manuel.

ms191449.note(fr-fr,SQL.90).gifRemarque :
Le contenu de cette rubrique suppose une connaissance suffisante du mode haute sécurité. Pour plus d'informations, consultez Mise en miroir synchrone de bases de données (mode Haute sécurité).

Maintien de la disponibilité lors des mises à niveau

L'administrateur de base de données peut recourir au basculement manuel pour mettre du matériel ou des logiciels à niveau sans sacrifier la disponibilité. Pour utiliser la mise en miroir de base de données dans le cadre de mises à niveau logicielles, le serveur miroir et/ou le système doivent déjà avoir été mis à niveau.

ms191449.note(fr-fr,SQL.90).gifRemarque :
La fonction de mise en miroir de bases de données doit être en mesure d'effectuer une mise à niveau propagée mais sans le garantir puisque les modifications à apporter ultérieurement ne sont pas connues.

L'illustration suivante montre une instance qui utilise le basculement manuel pour maintenir la disponibilité d'une base de données pendant la mise à niveau d'une instance serveur de base de données. Lorsque la mise à niveau est terminée, un administrateur peut éventuellement basculer à nouveau vers l'instance serveur d'origine. Ceci est utile lorsque l'administrateur veut arrêter la session de mise en miroir et utiliser le serveur de miroir ailleurs. De cette façon, une instance serveur donnée peut être utilisée à plusieurs reprises lors de la mise à jour d'une série d'instances serveur de base de données.

Basculement manuel planifié

Le basculement manuel exige que la sécurité des transactions soit définie à FULL et que la base de données soit à l'état SYNCHRONIZED.

Le basculement manuel initialise la série d'actions suivante :

  1. Le serveur principal déconnecte les clients de la base de données principale, envoie la fin du journal au serveur miroir, puis définit l'état de la mise en miroir à SYNCHRONIZING pour se préparer à prendre le rôle miroir.
  2. Le serveur miroir enregistre le NSE (Numéro de Séquence d'Enregistrement) du dernier enregistrement journal reçu du serveur principal en tant que NSE de basculement.
    ms191449.note(fr-fr,SQL.90).gifRemarque :
    Pour afficher ce NSE, sélectionnez la colonne mirroring_failover_lsn de sys.database_mirroring (Transact-SQL).
  3. Si un journal est en attente dans la file d'attente de restauration par progression, le serveur miroir achève la restauration par progression de la base de données miroir. Le temps requis pour cette opération dépend de la vitesse du système, de la charge de travail récente et de la quantité de journal au sein de la file d'attente de restauration par progression. Dans le cadre d'un mode de fonctionnement synchrone, le temps de basculement peut être régulé en limitant la taille de la file d'attente de restauration par progression. Cependant, cela peut entraîner le serveur principal à ralentir pour permettre au serveur miroir de suivre.
    ms191449.note(fr-fr,SQL.90).gifRemarque :
    Pour connaître la taille actuelle de la file d'attente de restauration par progression, utilisez le compteur de performance File d'attente de restauration par progression de l'objet de performance de mise en miroir de bases de données (pour plus d'informations, consultez Analyse de la mise en miroir de bases de données).
  4. Le serveur miroir devient le nouveau serveur principal, et l'ancien serveur principal devient le nouveau serveur miroir.
  5. Le nouveau serveur principal restaure toute transaction non validée et met la copie de sa base de données en ligne, en tant que base de données principale.
  6. L'ancien serveur principal prend le rôle de miroir et l'ancienne base de données principale devient la base de données miroir. Le nouveau serveur miroir resynchronise rapidement la nouvelle base de données miroir avec la nouvelle base de données principale.
    ms191449.note(fr-fr,SQL.90).gifRemarque :
    Dès que le nouveau serveur miroir a resynchronisé les bases de données, le basculement est à nouveau possible, mais en sens inverse.

Après le basculement, les clients doivent se reconnecter à la base de données principale en cours. Pour plus d'informations, consultez Connexions de clients à une base de données mise en miroir.

Pour initialiser un basculement manuel

Voir aussi

Concepts

Sessions de mise en miroir de bases de données
États de la mise en miroir
Estimation de l'interruption de service au cours d'un basculement de rôle
Défaillances possibles pendant la mise en miroir d'une base de données
Mise en miroir synchrone de bases de données (mode Haute sécurité)

Aide et Informations

Assistance sur SQL Server 2005