CORRECTIF : La synchronisation lente lorsque les disques ont des tailles de secteur différente pour les fichiers journaux de réplica principal et secondaire dans les environnements SQL Server AG et Logshipping

IMPORTANT : Cet article est issu d'une traduction automatique réalisée par un logiciel Microsoft et non par un traducteur professionnel. Cette traduction automatique a pu aussi être révisée par la communauté Microsoft grâce à la technologie Community Translation Framework (CTF). Pour en savoir plus sur cette technologie, veuillez consulter la page http://support.microsoft.com/gp/machine-translation-corrections/fr. Microsoft vous propose en effet des articles traduits par des professionnels, des articles issus de traductions automatiques et des articles issus de traductions automatiques révisées par la communauté Microsoft, de manière à ce que vous ayez accès à tous les articles de notre Base de connaissances dans votre langue. Il est important de noter que les articles issus de la traduction automatique, y compris ceux révisés par la communauté Microsoft, peuvent contenir des erreurs de vocabulaire, de syntaxe ou de grammaire. Microsoft ne pourra être tenu responsable des imprécisions, erreurs, ainsi que de tout dommage résultant d’une traduction incorrecte du contenu ou de son utilisation par les clients.

La version anglaise de cet article est la suivante: 3009974
Avertissement
Remarque : Après avoir appliqué ce correctif, vous devez activer l'indicateur de trace 1800 sur tous les serveurs pour que ce correctif fonctionne correctement.
Symptômes
Considérez le scénario suivant :
  • Vous activez la fonctionnalité de groupes de disponibilité AlwaysOn ou Logshipping de Microsoft SQL Server 2012 ou SQL Server 2014.
  • Les disques qui stockent les fichiers journaux du réplica principal et secondaire dans un groupe de disponibilité AlwaysOn (AG) ont des tailles de secteur différente. Ou, dans les environnements Logshipping, les disques que le magasin les fichiers journaux pour les serveurs principaux de Logshipping et Logshipping des serveurs secondaires ont des tailles de secteur différente. Par exemple :
    • Le fichier journal de réplica principal se trouve sur un disque ayant une taille de secteur de 512 octets. Toutefois, le fichier journal de réplica secondaire se trouve sur un disque qui a la taille de secteur de 4 kilo-octets (Ko).
    • Le fichier journal de réplica principal se trouve sur un système local sur site qui a une taille de secteur de 512 octets. Toutefois, le réplica secondaire se trouve sur un disque de stockage de Windows Azure qui a la taille de secteur de 4 kilo-octets (Ko).
Dans ce scénario, le message d'erreur suivant est enregistré dans le journal des erreurs de SQL Server :

Il y a eu X aligné de manière incorrecte journal e/s qui requis retomber à e/s synchrones. L'e/s en cours figure dans le fichier...

En outre, la synchronisation AG ou Logshipping s'exécute très lentement en raison de l'e/s synchrones. Si le réplica secondaire est dans le stockage de Windows Azure, il est beaucoup plus longue que prévu pour terminer le processus de synchronisation.

Remarque Ce problème se produit lorsque vous utilisez à la fois les nouveaux disques qui ont une taille de secteur de 4 Ko et les anciens disques d'une taille de secteur de 512 octets. Pour plus d'informations sur les nouveaux disques, reportez-vous à la section. Taille de secteur de 4K d'utilisation des lecteurs de SQL Server - nouvelle et SQL Server – stockage espaces/VHDx et la taille de secteur de 4 Ko.
Résolution
Le problème a été tout d'abord résolu dans la mise à jour cumulative suivante de SQL Server.

Mise à jour cumulative 5 pour SQL Server 2014

Mise à jour cumulative 3 pour SQL Server 2012 SP2

Mise à jour cumulative 13 pour SQL Server 2012 SP1

Après avoir appliqué le correctif et que vous activez l'indicateur de trace 1800 sur les serveurs principaux, vous remarquerez une légère augmentation de la taille des fichiers suivants :
  • Fichier journal des transactions
  • Sauvegardes de journal
En outre, vous remarquez que les messages suivants sont enregistrés dans le journal des erreurs de SQL Server du serveur principal :

La fin du journal de base de données 'nom de la base de données> » est en cours de réécriture 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é.

À propos des mises à jour cumulatives pour SQL Server

Chaque nouvelle mise à jour cumulative pour SQL Server contient tous les correctifs logiciels et des correctifs de sécurité qui ont été inclus dans la précédente mise à jour cumulative. Consultez les dernières mises à jour cumulatives pour SQL Server :

Contournement
Pour contourner ce problème, déplacez le fichier journal des transactions au lieu de destination sur un lecteur qui a des octets par secteur physique défini en tant que 512 octets.
Statut
Microsoft a confirmé l'existence de ce problème dans les produits Microsoft répertoriés dans la section « S'applique à ».
Plus d'informations
Pour obtenir les meilleurs résultats, essayez de vous assurer que tous les disques sur (au moins tous les disques qui hébergent les fichiers de journal) de tous les réplicas ont la même taille de secteur. Dans des environnements mixtes, où le serveur secondaire a un secteur physique de 512 octets et principal a une taille de secteur de 4 Ko, TF 1800 doit être utilisé comme indicateur d'un démarrage sur tous les serveurs (notamment les serveurs qui ont un secteur physique de 512 octets) que peut une transition vers le rôle principal. Cela permet de s'assurer que le format de création du journal en cours utilise une taille de secteur de 4 Ko.

Pour plus d'informations sur le fonctionnement de SQL Server avec des tailles de secteur plus importantes, consultez le billet suivant sur le blog de prise en charge :

SQL Server – stockage espaces/VHDx et la taille de secteur de 4 Ko

Vous pouvez utiliser l'utilitaire d'invite de la commande Fsutil pour déterminer la valeur d'octets par secteur physique. Si ce paramètre n'est pas visible dans la sortie, vous devez appliquer le correctif qui est spécifié dans Article 982018 de la base de connaissances.

Pour vérifier le type de lecteur dont vous disposez, procédez comme suit :
  1. 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 sur lequel vous voulez vérifier.
  2. Les valeurs des Octets par secteur et octets par secteur physique permet de déterminer le type de lecteur que vous avez. Pour ce faire, utilisez le tableau suivant :
    Valeur de « Octets par secteur »Valeur de « Octets par secteur physique »Type de lecteur
    40964096Natif de 4 Ko
    5124096Format avancé (également appelé 512E)
    512512512 octets natif

Avertissement : Cet article a été traduit automatiquement.

Ιδιότητες

Αναγνωριστικό άρθρου: 3009974 - Τελευταία αναθεώρηση: 01/19/2016 19:46:00 - Αναθεώρηση: 6.0

Microsoft SQL Server 2014 Developer, Microsoft SQL Server 2014 Enterprise, Microsoft SQL Server 2014 Standard, Microsoft SQL Server 2012 Enterprise, Microsoft SQL Server 2012 Developer, Microsoft SQL Server 2012 Standard

  • kbqfe kbhotfixserver kbfix kbsurveynew kbexpertiseadvanced kbmt KB3009974 KbMtfr
Σχόλια