Après avoir appliqué ce correctif, vous devez activer l’indicateur de trace 1800 comme paramètre de démarrage sur tous les serveurs ou réplicas dont la taille de secteur physique est de 512 octets et les redémarrer pour que ce correctif fonctionne correctement.
Symptômes
Prenons l’exemple du scénario suivant :
-
Vous activez la fonctionnalité Groupes de disponibilité AlwaysOn ou Logshipping dans Microsoft SQL Server.
-
Les disques qui stockent les fichiers journaux des réplica primaires et secondaires dans un groupe de disponibilité AlwaysOn ont des tailles de secteur différentes. Ou dans les environnements Logshipping, les disques qui stockent les fichiers journaux pour les serveurs principaux logshipping et les serveurs secondaires logshipping ont des tailles de secteur différentes. Par exemple :
-
Le fichier journal réplica principal se trouve sur un disque dont la taille de secteur est de 512 octets. Toutefois, le fichier journal réplica secondaire se trouve sur un disque dont la taille de secteur est de 4 kilo-octets (Ko).
-
Le fichier journal réplica principal se trouve sur un système local dont la taille de secteur est de 512 octets. Toutefois, le réplica secondaire se trouve sur un disque de stockage Windows Azure dont la taille de secteur est de 4 kilo-octets (Ko).
-
Dans ce scénario, le message d’erreur suivant est enregistré dans le journal des erreurs SQL Server. Le message d’erreur peut se poursuivre pendant un certain temps après le redémarrage si des journaux d’activité n’ont pas été appliqués au serveur secondaire avant le redémarrage du serveur.
Il y a eu X E/S de journal mal alignées qui ont nécessité de revenir à des E/S synchrones. L’E/S actuelle se trouve dans le fichier ....
En outre, la synchronisation de groupe de disponibilité ou de journalisation s’exécute très lentement en raison des E/S synchrones. Si le réplica secondaire se trouve dans stockage Windows Azure, le processus de synchronisation prend beaucoup plus de temps que prévu.
Remarque Ce problème se produit lorsque vous utilisez à la fois les nouveaux lecteurs qui ont une taille de secteur de 4 Ko et les anciens lecteurs qui ont une taille de secteur de 512 octets. Pour plus d’informations sur les nouveaux lecteurs, consultez SQL Server - Nouveaux lecteurs Utiliser une taille de secteur 4K et SQL Server–Espaces de stockage/VHDx et taille de secteur 4K.
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 5 pour SQL Server 2014 /en-us/help/3011055
Mise à jour cumulative 3 pour SQL Server 2012 SP2 /en-us/help/3002049
Mise à jour cumulative 13 pour SQL Server 2012 SP1 /en-us/help/3002044
Après avoir appliqué le correctif logiciel et activé l’indicateur de trace 1800 comme paramètre de démarrage sur tous les réplicas de serveurs s’exécutant sur un disque dont la taille de secteur est de 512 octets, vous remarquez une légère augmentation de la taille des fichiers suivants :
-
Fichier journal des transactions
-
Sauvegardes de journaux
En outre, vous remarquez que les messages suivants sont enregistrés dans le SQL Server journal des erreurs du serveur principal :
La fin du journal de la base de données « <nom de base de données> » est réécrite pour correspondre à la nouvelle taille de secteur de 4 096 octets
Il s’agit d’un message d’information qui peut être ignoré en toute sécurité.
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 :
Solution de contournement
Pour contourner ce problème, déplacez le fichier journal des transactions à la destination vers un lecteur dont Bytes per Physical Sector est défini sur 512 octets.
État
Microsoft a confirmé l’existence de ce problème dans les produits Microsoft répertoriés dans la section « S’applique à ».
Informations supplémentaires
Il est recommandé de s’assurer que tous les disques de tous les réplicas (au moins tous les disques qui hébergent des fichiers journaux) ont la même taille de secteur. Dans les environnements mixtes, où le secteur secondaire a un secteur physique de 512 octets et le principal a une taille de secteur de 4 Ko, TF 1800 doit être utilisé comme indicateur de démarrage sur tous les serveurs ou réplicas qui ont une taille de secteur physique de 512 octets et redémarrés. Cela permet de s’assurer que le format de création de journal en cours utilise une taille de secteur de 4 Ko.
Pour plus d’informations sur la façon dont SQL Server fonctionne avec des tailles de secteur plus importantes, consultez le billet suivant sur le blog de support :
SQL Server–Espaces de stockage/VHDx et taille
de secteur 4K
Vous pouvez utiliser l’utilitaire d’invite de commandes Fsutil pour déterminer la valeur Octets par secteur physique. Si ce paramètre n’est pas visible dans la sortie, vous devez appliquer le correctif logiciel spécifié dans l’article de la base de connaissances 982018.
Pour vérifier le type de lecteur dont vous disposez, procédez comme suit :
-
Exécutez la commande suivante à une invite de commandes avec élévation de privilèges :
Fsutil fsinfo ntfsinfo x : Remarque L’espace réservé x représente le lecteur que vous vérifiez.
-
Utilisez les valeurs octets par secteur et Octets par secteur physique pour déterminer le type de lecteur dont vous disposez. Pour ce faire, utilisez le tableau suivant :
Valeur « Octets par secteur »
Valeur « Octets par secteur physique »
Type de lecteur
4096
4096
4K natif
512
4096
Format avancé (également appelé 512E)
512
512
Natif de 512 octets
