Symptômes
Prenons l’exemple du scénario suivant :
-
Vous utilisez Microsoft SQL Server 2016, 2014 ou 2012.
-
Vous disposez d’une base de données qui fait partie du groupe disponibilité AlwaysOn.
-
Sur le réplica principal, vous réduisez les fichiers de base de données pour réduire leur taille.
-
Le réplica principal envoie toutes les modifications enregistrées dans le journal de transactions vers le réplica secondaire.
-
Sur le réplica secondaire, les threads de rétablissement appliquent les modifications du journal des transactions à la base de données qui fait partie du groupe de disponibilités.
Dans ce scénario, le fac-similé est suspendu. Par ailleurs, vous pouvez recevoir un message d’erreur qui ressemble à ce qui suit :
<d’horodatage> erreur spid41s : 3456, gravité : 21, État : 1. <horodatage> spid41s ne peut pas rétablir l’enregistrement du journal (#), pour l’ID de la transaction (#), dans la page (#), la base de données' <dbname> ' (ID de base de données). Page : LSN = (#), unité d’allocation = #, type = #. JRN : OpCode = #, context #, PrevPageLSN : (#). Restauration à partir d’une sauvegarde de la base de données ou réparation de la base de données. <horodatage> spid41s de disponibilité des groupes de données AlwaysOn pour la base de données' <dbname> 'a été suspendu pour la raison suivante : "système" (ID source 2 ; Chaîne source : 'SUSPEND_FROM_REDO'). Pour reprendre la migration des données sur la base de données, vous devez reprendre la base de données manuellement. Pour plus d’informations sur la reprise d’une base de données de disponibilité, voir documentation en ligne sur SQL Server. <horodatage> erreur spid41s : 3313, gravité : 21, État : 2. <horodatage> spid41s lors de la reprise d’une opération dans la base de données' <dbname> ', une erreur est survenue dans l’ID du journal. En règle générale, l’échec spécifique est enregistré en tant qu’erreur dans le service du journal des événements Windows. Restauration de la base de données à partir d’une sauvegarde complète ou réparation de la base de données.
Cause
Ce problème se produit lorsque des modifications sont appliquées lors du processus de rétablissement si le moteur de base de données rencontre des problèmes d’ordre LSNs sur les pages système (GAM, PFS).
Résolution
Le problème a été résolu dans la mise à jour cumulative suivante de SQL Server :
Chaque nouvelle mise à jour cumulative pour SQL Server contient tous les correctifs et les correctifs de sécurité inclus dans la mise à jour cumulative précédente. Nous vous recommandons de télécharger et d’installer les dernières mises à jour cumulatives pour SQL Server :
La mise à jour empêche ce problème de se produire. Si le problème s’est produit, procédez comme suit pour rejoindre le groupe de disponibilité AlwaysOn :
-
Supprimez le réplica secondaire AlwaysOn existant.
-
Exécutez la commande suivante sur les fichiers de données concernés pour supprimer l’espace non alloué de la base de données :
DBCC SHRINKFILE(<file_id>, TRUNCATEONLY)
-
Sauvegarder la base de données et les fichiers journaux.
-
Restaurez la base de données et les journaux sur le réplica secondaire AlwaysOn.
-
Rejoignez le groupe disponibilité AlwaysOn.
Statut
Microsoft a confirmé l'existence de ce problème dans les produits Microsoft figurant dans la liste des produits concernés par cet article.
Références
Apprenez-en davantage sur la terminologie utilisée par Microsoft pour décrire les mises à jour logicielles.
