Partage via

Mise à niveau de la copie des journaux de transaction vers SQL Server 2016 (Transact-SQL)

  • Article

S'applique à : SQL Server

Pour préserver votre solution de récupération d’urgence de copie des journaux de transaction, mettez à niveau ou appliquez les mises à jour de maintenance dans l’ordre approprié. Les mises à jour de maintenance incluent des service packs ou des mises à jour cumulatives.

Remarque

La compression de la sauvegarde a été introduite dans SQL Server 2008 (10.0.x) Enterprise. Une configuration mise à niveau de copie des journaux de transaction utilise l’option de configuration du niveau serveur par défaut pour la compression de sauvegarde pour contrôler si la compression de la sauvegarde est utilisée pour les fichiers de sauvegarde du journal des transactions. Le comportement de la compression de la sauvegarde des sauvegardes de fichiers journaux peut être spécifié pour chaque configuration de la copie des journaux de transaction. Pour plus d’informations, consultez Configurer la copie des journaux de transaction (Transact-SQL).

Dans cette rubrique :

Prérequis

Avant de commencer, passez en revue les informations importantes suivantes :

Protéger vos données avant la mise à niveau

Comme méthode conseillée, nous vous recommandons de protéger vos données avant une mise à niveau de la copie des journaux de transaction.

Pour protéger vos données

  1. Effectuez une sauvegarde complète de chaque base de données primaire.

    Pour plus d’informations, consultez Créer une sauvegarde complète de base de données (SQL Server).

  2. Exécutez la commande DBCC CHECKDB sur chaque base de données primaire.

Important

Veillez à disposer de suffisamment d’espace sur votre serveur principal pour conserver les copies de sauvegarde du fichier journal pour la durée prévue de la durée de mise à niveau des serveurs secondaires. Si vous basculez sur un serveur secondaire, ce même problème s'applique à ce serveur (le nouveau serveur principal).

Mise à niveau (facultative) d'une instance du serveur moniteur

L'instance du serveur moniteur, si elle existe, peut être mise à niveau à tout moment. Cependant, il n’est pas nécessaire de mettre à niveau le serveur moniteur facultatif lorsque vous mettez à niveau le serveur principal et les serveurs secondaires.

Pendant que le serveur moniteur est mis à niveau, la configuration de la copie des journaux de transaction continue à fonctionner, mais son état n'est pas enregistré dans les tables sur le moniteur. Les alertes qui ont été configurées ne sont pas déclenchées tant que le serveur moniteur est en cours de mise à niveau. Après la mise à niveau, vous pouvez mettre à jour les informations dans les tables du moniteur en exécutant la procédure stockée système sp_refresh_log_shipping_monitor. Pour plus d’informations sur les serveurs moniteurs, consultez À propos de la copie des journaux de transaction (SQL Server).

Mise à niveau des instances de serveur secondaires

Le processus de mise à niveau implique la mise à niveau des instances de serveur secondaire d’une configuration de SQL Server avant la mise à niveau de l’instance du serveur principal. Mettez toujours à niveau les instances secondaires de SQL Server en premier. La copie des journaux de transaction se poursuit durant le processus de mise à niveau car les instances de serveur secondaires mises à niveau continuent de restaurer les sauvegardes des journaux à partir de l’instance du serveur principal. Si l’instance du serveur principal a été mise à niveau avant une instance de serveur secondaire, la copie des journaux de transaction échoue parce qu'une sauvegarde créée sur une version plus récente de SQL Server ne peut pas être restaurée sur une version antérieure de SQL Server. Vous pouvez mettre à niveau les instances secondaires simultanément ou en série, mais toutes les instances secondaires doivent être mises à niveau avant l’instance principale, pour éviter un échec de copie des journaux de transaction.

Pendant qu’une instance de serveur secondaire est mise à niveau, les travaux de copie et de restauration de la copie des journaux de transaction ne s'exécutent pas. Cela signifie que les sauvegardes de journal des transactions s’accumulent sur le serveur principal et que vous devez disposer de suffisamment d’espace pour conserver ces sauvegardes non restaurées. Le niveau d’accumulation dépend de la fréquence des sauvegardes planifiées sur l’instance du serveur principal et de la séquence de mise à niveau des instances secondaires. De même, si un serveur moniteur séparé a été configuré, il se peut que des alertes soient déclenchées et indiquent que les restaurations n'ont pas été effectuées sur une durée supérieure à l'intervalle configuré.

Une fois que les instances serveur secondaires ont été mises à niveau, les travaux des agents de copie des journaux de transaction reprennent et poursuivent la copie et la restauration des sauvegardes de journal à partir de l'instance du serveur principal vers les instances de serveur secondaires. La durée nécessaire pour que les instances de serveur secondaires remettent la base de données secondaire à jour varie, selon la durée requise pour mettre à niveau l’instance de serveur secondaire et la fréquence des sauvegardes sur le serveur principal.

Notes

Pendant la mise à niveau du serveur, la base de données secondaire elle-même n’est pas mise à niveau vers la nouvelle version. Il ne sera mis à niveau que s’il est mis en ligne en lançant un basculement de la base de données de copie des journaux de transaction. En théorie, cette condition peut perdurer indéfiniment. La durée nécessaire pour mettre à niveau les métadonnées de la base de données lors du lancement d’un basculement est faible.

Important

L'option RESTORE WITH STANDBY n'est pas prise en charge pour une base de données qui requiert une mise à niveau. Si une base de données secondaire mise à niveau a été configurée à l'aide de RESTORE WITH STANDBY, les journaux des transactions ne peuvent plus être restaurés après la mise à niveau. Pour reprendre la copie des journaux de transaction sur cette base de données secondaire, vous devrez reconfigurer la copie des journaux de transaction sur ce serveur de secours. Pour plus d’informations sur l’option STANDBY, consultez Restaurer une sauvegarde de journal des transactions (SQL Server).

Mise à niveau de l'instance du serveur principal

Étant donné que la copie des journaux de transaction est essentiellement une solution de récupération d’urgence, le scénario le plus simple et le plus courant est de mettre à niveau l’instance principale à la place, et de simplement laisser la base de données indisponible pendant cette mise à niveau. Une fois que le serveur est mis à niveau, la base de données est automatiquement remise en ligne, ce qui entraîne sa mise à niveau. Après que la base de données a été mise à niveau, les travaux de la copie des journaux de transaction reprennent.

Notes

La copie des journaux de transaction de journaux permet aussi de Basculer vers une copie des journaux de transaction secondaire (SQL Server) et éventuellement de Changer des rôles entre les serveurs primaire et secondaire de copie des journaux de transaction (SQL Server). Cependant, étant donné que la copie des journaux de transaction est rarement configurée en tant que solution à haute disponibilité de nos jours (les nouvelles options sont bien plus robustes), le basculement ne réduira généralement pas le temps d’arrêt, car les objets de base de données système ne sont pas synchronisés. De plus, permettre aux clients de localiser et se connecter facilement à un serveur secondaire promu peut être un calvaire.

Voir aussi

Effectuer une mise à niveau vers SQL Server 2016 à l’aide de l’Assistant Installation (programme d’installation)
Installer SQL Server 2016 à partir de l’invite de commandes
Configurer la copie des journaux de transaction (SQL Server)
Surveiller la copie des journaux de transaction (Transact-SQL)
Tables et procédures stockées liées à la copie des journaux de transaction