Symptômes
Supposez que vous utilisez la fonctionnalité groupes de disponibilité AlwaysOn dans Microsoft SQL Server 2012. Lorsque vous modifiez l’accès de connexion du réplica secondaire de « lisible » en « illisible », une défaillance se produit sur les pages qui utilisent la compression de page dans le réplica donné.Les bases de données de disponibilité présentant ce problème dans le réplica secondaire ne peuvent pas être récupérées en raison d’une erreur lors de la phase de rétablissement de la synchronisation. Le réplica secondaire n’est pas synchronisé avec le réplica principal et signale l’état de synchronisation « SUSPEND_FROM_REDO ». Par ailleurs, vous recevez les messages d’erreur suivants dans le journal des erreurs de SQL Server qui héberge le réplica secondaire :
<date> <temps> ID de connexion<ID> erreur : 17066, gravité : 16, État : 1 . <> <Date>> <0 spid> ID <SQL Server assertion : fichier :>. cpp, ligne = 3898 Échec assertion = ' ! pageFull'. Cette erreur est éventuellement liée au minutage. Si l’erreur persiste après avoir reexécuté l’instruction, utilisez DBCC CHECKDB pour vérifier l’intégrité structurelle de la base de données, ou redémarrez le serveur pour vous assurer que les structures de données en mémoire ne sont pas endommagées . <date> <temps > 3624ID de <deconnexion du système a échoué.> Pour plus d’informations, consultez le journal des erreurs SQL Server. En règle générale, un échec d’assertion est lié à un bogue logiciel ou à des données endommagées. Pour vérifier la corruption de la base de données, envisagez d’exécuter DBCC CHECKDB. Si vous avez accepté d’envoyer des vidages à Microsoft lors de l’installation, un mini-vidage sera envoyé à Microsoft. Il est possible qu’une mise à jour soit disponible à partir de Microsoft dans le dernier Service Pack ou dans un QFE du support technique. <Date> <temps> ID de<de SPID> le déplacement des données du groupe de disponibilité AlwaysOn de la base de données' <nom de la base de données> '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 le mode de reprise d’une base de données de disponibilité, voir documentation en ligne sur SQL Server . <de> <temps> SPID<ID> erreur : 3313, gravité : 21, état : 2 . <Date> <> IDde connexion> <0 '> ' 1786:4978584:74 ' <'> ' 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. <Date> <durée> SPID<ID> option modifier le param de la base de données : reprenez<date> <>> <0 SPID> ID <IDde la base de données. Il s’agit d’un message d’information uniquement. Aucune action de l’utilisateur n’est requise. <Date> <temps> SPID<ID> les transactions non qualifiées sont restaurées dans la base de données <nom de la base de données> pour un changement d’état des groupes d’AlwaysOn. Fin de restauration estimée : 100%. Il s’agit d’un message d’information uniquement. Aucune action de l’utilisateur n’est requise. <Date> <temps> ID de<SPID> connexion AlwaysOn de groupes disponibles avec la base de données principale arrêtée pour la base de données secondaire' <nom de la base de données> 'sur le réplica de disponibilité avec l’ID de réplica : {bbdedecb-F26B-47e9-9e7d-7c22f99edb23}. Il s’agit d’un message d’information uniquement. Aucune action de l’utilisateur n’est requise. <date> <temps> SPID<ID> démarrage de la base de données' <nom de la base de données> '. <> <Date> temps> <2 SPID> ID <restauration de la base de données> nom de la base de données' (13) est 781 terminé Phase 1 sur 3 Il s’agit d’un message d’information uniquement. Aucune action de l’utilisateur n’est requise....
Résolution
Le problème a été résolu 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
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. Consultez les dernières mises à jour cumulatives pour SQL Server :
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 aux bases de données de disponibilité sur le réplica secondaire en utilisant les deux méthodes suivantes :
-
Définissez l’accès en lecture à l’aide de la commande modifier le groupe de disponibilité :
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 disponibilité AlwaysOn.
-
Ouvrez le dossier groupes de disponibilité.
-
Cliquez avec le bouton droit sur le groupe disponibilité, puis sélectionnez Propriétés.
-
Changez la propriété secondaire lisible du réplica secondaire en non, puis cliquez sur OK.
-
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.
