Symptômes
Supposons que vous utilisez la fonctionnalité Groupes de disponibilité AlwaysOn dans Microsoft SQL Server 2012. Lorsque vous remplacez l’accès à la connexion de la réplica secondaire de « lisible » par « illisible », une corruption se produit sur les pages qui utilisent la compression de page dans le réplica donné.
Les bases de données de disponibilité qui rencontrent ce problème au niveau du réplica secondaire ne peuvent pas récupérer en raison d’une erreur lors de la phase de restauration par progression de la synchronisation. Le réplica secondaire ne se synchronise pas avec le réplica principal et signale un état de synchronisation de « SUSPEND_FROM_REDO ». En outre, les messages d’erreur suivants s’affichent dans le journal des erreurs de SQL Server qui héberge le réplica secondaire :
Remarque
<
Date><Heure> erreurd’ID> spid< : 17066, gravité : 16, État : 1.
<
Date><Heure>ID> spid< SQL Server Assertion : File : <page.cpp>, line=3898 Failed Assertion = ' !pageFull'. Cette erreur peut être liée à la minutage. Si l’erreur persiste après la réexécution de l’instruction, utilisez DBCC CHECKDB pour vérifier l’intégrité structurelle de la base de case activée ou redémarrez le serveur pour vous assurer que les structures de données en mémoire ne sont pas endommagées.
<
Date><Heure> erreurd’ID> spid< : 3624, gravité : 20, état : 1.
<
Date><Heure>ID> spid< Un case activée d’assertion système a échoué. Pour plus d’informations, consultez le journal des erreurs de SQL Server. En règle générale, un échec d’assertion est causé par un bogue logiciel ou une altération des données. Pour vérifier la case activée pour la base de données endommagée, envisagez d’exécuter DBCC CHECKDB. Si vous avez accepté d’envoyer des vidages à Microsoft pendant l’installation, un mini-vidage sera envoyé à Microsoft. Une mise à jour peut être disponible auprès de Microsoft dans le dernier Service Pack ou dans un QFE du Support technique.
<
Date><Heure>ID> spid< Groupes de disponibilité AlwaysOn Le déplacement de données pour la base de données «<Nom> de la base de données » a été suspendu pour la raison suivante : « system » (ID source 2 ; Chaîne source : 'SUSPEND_FROM_REDO'). Pour reprendre le déplacement 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é, reportez-vous à la documentation en ligne de SQL Server.
<
Date><Heure> erreurd’ID> spid< : 3313, gravité : 21, état : 2.
<
Date><Heure>ID> spid< Au cours de la restauration d’une opération journalisée dans la base de données «< Nom >de la base de données », une erreur s’est produite au niveau de l’ID d’enregistrement du journal (1786:4978584:74). En règle générale, l’échec spécifique est précédemment consigné comme une erreur dans le service Journal des événements Windows. Restaurez la base de données à partir d’une sauvegarde complète ou réparez-la.
<
Date><Heure> spid<ID> ALTER DB param option : RESUME
<
Date><Heure>ID> spid< Groupes de disponibilité AlwaysOn Le déplacement des données pour la base de données «< Nom >de la base de données » a repris. Ceci n’est qu’un message d’information. Aucune action de l’utilisateur n’est requise.
<
Date><Heure> ID spid<Les> transactions non qualifiées sont en cours d’annulation dans la base de données <Nom> de la base de données pour un changement d’état des groupes de disponibilité AlwaysOn. Achèvement estimé de la restauration : 100 %. Ceci n’est qu’un message d’information. Aucune action de l’utilisateur n’est requise.
<
Date><Heure>ID> spid< AlwaysOn Connexion des groupes de disponibilité avec la base de données principale terminée pour la base de données secondaire 'DataBase Name>' sur le réplica de disponibilité avec l’ID< de réplica : {bbdedecb-f26b-47e9-9e7d-7c22f99edb23}. Ceci n’est qu’un message d’information. Aucune action de l’utilisateur n’est requise.
<
Date><Heure>ID> spid< Starting up database '<DataBase Name>'.
<
Date><Heure>ID> SPID< La récupération de la base de données «< Nom >de la base de données » (13) est achevée à 0 % (environ 781 secondes restantes). Phase 1 sur 3. Ceci n’est qu’un message d’information. Aucune action de l’utilisateur n’est requise.
……
Résolution
Le problème a été résolu pour la première fois dans la mise à jour cumulative suivante de SQL Server.
Mise à jour cumulative 6 pour SQL Server 2012 SP2
Mise à jour cumulative 16 pour SQL Server 2012 SP1
À propos des mises à jour cumulatives pour SQL Server
Chaque nouvelle mise à jour cumulative pour SQL Server contient tous les correctifs logiciels et tous les correctifs de sécurité inclus dans la mise à jour cumulative précédente. Consultez les dernières mises à jour cumulatives pour SQL Server :
- Dernière mise à jour cumulative pour SQL Server 2012 SP2
- Dernière mise à jour cumulative pour SQL Server 2012 SP1
Informations supplémentaires
Le problème précédent peut se produire lorsque l’accès en lecture est modifié pour le réplica secondaire.
Vous pouvez définir l’accès en lecture des bases de données de disponibilité sur le réplica secondaire à l’aide des deux méthodes suivantes :
Définissez l’accès en lecture à l’aide de la commande ALTER AVAILABILITY GROUP :
ALTER AVAILABILITY GROUP [AGName] MODIFY REPLICA ON N'<SRV>' WITH (SECONDARY_ROLE(ALLOW_CONNECTIONS = NO))Définissez l’accès en lecture en modifiant les paramètres dans l’Explorateur d’objets de SQL Server Management Studio (SSMS) :
- Connectez-vous au serveur, puis ouvrez le dossier de disponibilité AlwaysOn.
- Ouvrez le dossier Groupes de disponibilité.
- Cliquez avec le bouton droit sur le groupe de disponibilité, puis sélectionnez Propriétés.
- Modifiez la propriété secondaire en lecture pour le réplica secondaire sur Non, puis cliquez sur Ok.
État
Microsoft a confirmé qu’il s’agissait d’un problème dans les produits Microsoft répertoriés dans la section « S’applique à ».