Exporter (0) Imprimer
Développer tout
Cet article a fait l'objet d'une traduction manuelle. Déplacez votre pointeur sur les phrases de l'article pour voir la version originale de ce texte. Informations supplémentaires.
Traduction
Source

Suspendre et reprendre la mise en miroir de bases de données (SQL Server)

État de la rubrique : certaines informations de cette rubrique constituent une documentation préliminaire et peuvent faire l'objet de modifications dans les versions à venir. Ces informations préliminaires décrivent les nouvelles fonctionnalités ou les modifications apportées à des fonctionnalités existantes de Microsoft SQL Server 2014.

Le propriétaire de la base de données peut suspendre et reprendre ultérieurement une session de mise en miroir de bases de données à tout moment. La suspension conserve l'état de la session tout en suspendant la mise en miroir. En cas de goulots, la suspension peut permettre d'améliorer les performances sur le serveur principal.

Lorsqu'une session est suspendue, la base de données principale reste disponible. La suspension d'une session de mise en miroir fait passer son état à SUSPENDED, et la base de données miroir ne reflète plus la base de données principale, ce qui rend cette dernière vulnérable lors de son exécution.

Nous vous recommandons de reprendre une session suspendue rapidement puisque le journal des transactions ne peut pas être tronqué tant que la session de mise en miroir de bases de données est suspendue. Par conséquent, si la session de mise en miroir de bases de données est suspendue trop longtemps, le journal peut être plein, ce qui rend la base de données indisponible. Pour une explication des causes de ce phénomène, consultez « Comment la suspension et la reprise affectent la troncature du journal » plus loin dans cette rubrique.

Important Important

Après un service forcé, lorsque le serveur principal d'origine se reconnecte, la mise en miroir est suspendue. La reprise de la mise en miroir dans cette situation peut entraîner des pertes de données sur le serveur principal d'origine. Pour plus d'informations sur la gestion des problèmes éventuels de perte de données, consultez Modes de fonctionnement de la mise en miroir de bases de données.

Dans cette rubrique :

En général, lorsqu'un point de contrôle automatique est effectué sur une base de données, son journal des transactions est tronqué jusqu'à ce point de contrôle après la sauvegarde du journal suivante. Durant la suspension de la session de la mise en miroir de bases de données, tous les enregistrements du journal en cours restent actifs puisque le serveur principal attend de les envoyer au serveur miroir. Les enregistrements de journal qui n'ont pas été envoyés s'accumulent dans le journal des transactions de la base de données principale en attendant que la session reprenne et que le serveur principal envoie les enregistrements du journal vers le serveur miroir.

Lors de la reprise de la session, le serveur principal commence immédiatement l'envoi des enregistrements accumulés du journal vers le serveur miroir. Après confirmation par le serveur miroir de la mise en file d'attente de l'enregistrement de journal correspondant jusqu'au point de contrôle automatique le plus ancien, le serveur principal tronque le journal de la base de données principale jusqu'à ce point de contrôle. Le serveur miroir tronque la file d'attente de restauration au même enregistrement de journal. Ce processus est répété pour chaque point de contrôle successif et le journal est tronqué par étape, point de contrôle par point de contrôle.

Remarque Remarque

Pour plus d'informations sur les points de contrôle et la troncature du journal, consultez Points de contrôle de base de données (SQL Server).

Icône de flèche utilisée avec le lien Retour en haut [Haut de la page]

Si le journal est plein (soit parce qu'il a atteint sa taille maximum, soit parce que l'instance du serveur manque de place), la base de données ne peut plus effectuer de mises à jour. Pour éviter ce problème, vous avez deux solutions :

  • Reprendre la session de mise en miroir de base de données avant que le journal ne soit plein, ou ajouter un espace journal supplémentaire. La reprise de la mise en miroir de bases de données permet au serveur principal d'envoyer son journal actif cumulé au serveur miroir et met la base de données miroir en état SYNCHRONIZING. Le serveur miroir peut alors renforcer le journal sur le disque et commencer à le refaire.

  • Arrêter la session de mise en miroir de bases de données en supprimant la mise en miroir.

    Contrairement à la suspension d'une session, la suppression d'une mise en miroir supprime toutes les informations sur la session de mise en miroir. Chaque instance de serveur partenaire conserve sa propre copie de la base de données. Si l'ancienne copie miroir est récupérée, elle divergera de l'ancienne copie principale et accusera un retard par rapport à la durée qui s'est écoulée depuis la suspension de la session. Pour plus d'informations, consultez Suppression d'une mise en miroir des bases de données (SQL Server).

Icône de flèche utilisée avec le lien Retour en haut [Haut de la page]

Cela vous a-t-il été utile ?
(1500 caractères restants)
Merci pour vos suggestions.

Ajouts de la communauté

AJOUTER
Microsoft réalise une enquête en ligne pour recueillir votre opinion sur le site Web de MSDN. Si vous choisissez d’y participer, cette enquête en ligne vous sera présentée lorsque vous quitterez le site Web de MSDN.

Si vous souhaitez y participer,
Afficher:
© 2014 Microsoft