Notions de base des E/S de SQL Server

S’applique à :SQL ServerAzure SQL Managed InstanceSQL Server sur des machines virtuelles Azure

L'objectif principal d'une base de données SQL Server est de stocker et de récupérer des données, l'utilisation intensive d'entrée/sortie (E/S) sur disque est donc une caractéristique centrale du moteur de base de données. Étant donné que les opérations d'E/S sur disque peuvent consommer beaucoup de ressources et durer relativement longtemps, SQL Server s'attache à rendre ces opérations efficaces.

Les sous-systèmes de stockage pour SQL Server sont fournis dans plusieurs facteurs de forme, notamment les lecteurs mécaniques et le stockage à état solide. Cet article fournit des précisions sur la manière d'utiliser des principes de mise en cache des lecteurs pour améliorer le Moteur de base de données E/S.

SQL Server exige que les systèmes prennent en charge la livraison garantie à un support stable, comme indiqué dans les exigences du programme de fiabilité des E/S SQL Server. Pour plus d’informations sur les exigences d’entrée et de sortie pour le Moteur de base de données SQL Server, consultez les exigences relatives à l’entrée/sortie (E/S) de disque du Moteur de base de données SQL Server.

E/S disque

Le gestionnaire de tampons n'effectue que des lectures et des écritures dans la base de données. Les autres opérations de base de données et de fichier comme les opérations d'ouverture, de fermeture, d'élargissement et de compactage sont prises en charge par les composants du gestionnaire de base de données et du gestionnaire de fichiers.

Les opérations d'E/S disque effectuées par le gestionnaire de tampons présentent les caractéristiques suivantes :

• Une opération d'E/S s'effectue généralement de manière asynchrone, ce qui permet au thread appelant de continuer le traitement durant l'opération d'E/S en arrière-plan. Dans certaines circonstances (par exemple, des E/S du journal mal alignées), des E/S synchrones peuvent se produire.

• Toutes les opérations d'E/S ont lieu dans des threads appelants, sauf si l'option affinity I/O est utilisée. L’option affinity I/O mask lie les E/S disque de SQL Server à un sous-ensemble de processeurs spécifié. Dans les environnements de traitement transactionnel en ligne (OLTP) SQL Server haut de gamme, cette extension permet d'améliorer les performances des threads SQL Server émettant des E/S.

• Les E/S de pages multiples s'effectuent à l'aide d'E/S par fragmentation-rassemblement, ce qui permet le transfert des données dans des zones contiguës de la mémoire ou hors de celles-ci. Cela signifie que SQL Server peut remplir ou vider rapidement le cache des tampons tout en évitant les demandes d'E/S physiques multiples.

Longues demandes d'E/S

Le gestionnaire de tampons signale les demandes d'E/S en suspens pendant un délai minimum de 15 secondes. Ce processus permet à l’administrateur système de faire la distinction entre les problèmes de SQL Server et les problèmes de sous-système d’E/S. Le message d'erreur MSSQLSERVER_833 est rapporté et consigné dans le journal des erreurs SQL Server comme suit :

SQL Server has encountered ## occurrence(s) of I/O requests taking longer than 15 seconds to complete on file [##] in database [##] (#). The OS file handle is 0x00000. The offset of the latest long I/O is: 0x00000.

Une longue E/S peut être une lecture ou une écriture ; le message n’indique pas actuellement lequel. Les messages d'opérations d'E/S longues sont des avertissements pas des erreurs. Ils n’indiquent pas de problèmes avec SQL Server, mais avec le système d’E/S sous-jacent. Les messages aident l’administrateur système à trouver la cause de temps de réponse SQL Server médiocres plus rapidement et à distinguer les problèmes qui se trouvent en dehors du contrôle de SQL Server. De ce fait, ces problèmes ne demandent aucune intervention, mais il est nécessaire que l'administrateur système analyse les raisons de la lenteur de la demande d'E/S et si ce délai est justifié.

Facteurs de longues demandes d'E/S

Un message d’E/S long peut indiquer qu’une E/S est définitivement bloquée et ne se terminera jamais (appelée E/S perdues), ou simplement qu’elle n’est pas encore terminée. Vous ne pouvez pas indiquer à partir du message de quel scénario il s'agit, bien qu'une E/S perdue entraîne souvent un délai d'expiration du verrou.

Les E/S longues indiquent souvent une charge de travail SQL Server trop intense pour le sous-système de disque. Un sous-système de disque inapproprié peut être indiqué dans les cas suivants :

• plusieurs opérations d'E/S longues dans le journal d'erreurs au cours d'une charge de travail SQL Server importante ;
• les compteurs Analyseur de performances indiquent des latences de disque longues, des files d'attente de disque longues ou pas d'inactivité de disque.

Un composant dans le chemin d'E/S (par exemple, un pilote, un contrôleur ou un firmware) peut entraîner des E/S longues en reportant continuellement le traitement d’une ancienne demande d’E/S, en faveur du traitement de requêtes plus récentes. Ce problème peut se produire dans des environnements interconnectés, tels que les réseaux iSCSI et Fibre Channel (en raison d’une configuration incorrecte ou d’un échec de chemin). L’outil Analyseur de performances peut rendre ce problème difficile à confirmer, car la plupart des E/S sont rapidement mises en service. Les charges de travail qui effectuent de grandes quantités d’E/S séquentielles, telles que la sauvegarde et la restauration, les analyses de table, le tri, la création d’index, les chargements en bloc et la suppression de fichiers, peuvent aggraver les demandes d’E/S longues.

Les opérations d'E/S longues isolées qui ne présentent a priori aucun rapport avec les conditions décrites plus haut peuvent être causées par un problème de matériel ou de pilote. Le journal des événements système peut peut-être contenir un événement associé qui est utile pour diagnostiquer le problème.

Problèmes de performances d’E/S causés par des requêtes ou des pilotes de filtre inefficaces

Les E/S lentes peuvent être provoquées par des requêtes qui ne sont pas écrites efficacement ou correctement paramétrées avec des index et des statistiques. Un autre facteur courant de latence des E/S est la présence d’antivirus ou d’autres programmes de sécurité qui analysent les fichiers de base de données. Ce logiciel d’analyse peut s’étendre à la couche réseau, ce qui ajoute une latence réseau et affecte ainsi indirectement la latence de la base de données. Bien que le scénario décrit environ 15 secondes d’E/S soit plus courant avec les composants matériels, les retards d’E/S plus courts sont plus fréquemment observés avec des requêtes non optimisées ou des programmes antivirus mal configurés.

Pour plus d’informations sur la façon de résoudre ces problèmes, consultez Résoudre les problèmes de performances lentes de SQL Server causés par des problèmes d’E/S.

Pour plus d’informations sur la configuration de la protection antivirus sur SQL Server, consultez Configurer un logiciel antivirus pour qu’il fonctionne avec SQL Server.

Mise en cache d'écriture dans les contrôleurs de stockage

Les transferts d’E/S qui n’utilisent pas de cache peuvent prendre beaucoup plus de temps sur les disques mécaniques en raison des taux de rotation de disque dur, du temps mécanique nécessaire pour déplacer les têtes de lecteur et d’autres facteurs de limitation. Les installations sql Server ciblent les systèmes qui fournissent des contrôleurs de mise en cache. Ces contrôleurs désactivent les caches sur disque et fournissent des caches multimédias stables pour répondre aux exigences en matière d’E/S de SQL Server. Ils évitent les problèmes de performances liés aux délais de recherche de stockage et d’écriture en utilisant les différentes optimisations du contrôleur de mise en cache.

L’utilisation d’un contrôleur de stockage de mise en cache d’écriture (également appelée mise en cache d'écriture différée) peut améliorer les performances de SQL Server. Les contrôleurs de mise en cache d’écriture et les sous-systèmes de stockage sont sécurisés pour SQL Server, s’ils sont conçus pour être utilisés dans un environnement de système de gestion de base de données transactionnel (SGBD) critique pour les données. Ces fonctionnalités de conception doivent conserver les données mises en cache si une défaillance système se produit. L’utilisation d’une alimentation externe ininterruptible (UPS) pour obtenir cette protection n’est généralement pas suffisante, car les modes d’échec qui ne sont pas liés à l’alimentation peuvent se produire.

Des contrôleurs de mise en cache et des sous-systèmes de stockage peuvent être utilisés en toute sécurité par SQL Server. La plupart des nouvelles plateformes de serveur conçues à usage unique qui incorporent ces contrôleurs sont sécurisées. Toutefois, vous devez vérifier auprès de votre fournisseur de matériel que le sous-système de stockage a été testé et approuvé pour une utilisation dans un environnement de système de gestion de base de données relationnelle transactionnel (SGBDR) critique pour les données.

Recommandations en matière de sécurité du sous-système de cache

Les contrôleurs de mise en cache en écriture différée peuvent améliorer les performances s’ils répondent à des exigences de sécurité spécifiques :

• Incluez le cache soutenu par batterie ou la mémoire non volatile, telle que NVDIMM ou le flash de super-condensateur.
• Être certifié par le fournisseur pour les environnements de base de données OLTP critiques.
• Fournissez une protection qui couvre toutes les conditions de défaillance, pas seulement la perte d’alimentation.

Journalisation WAL

Les instructions de modification de données de SQL Server génèrent des écritures de pages logiques. Vous pouvez imager ce flux d’écritures comme allant à deux emplacements : le journal et la base de données elle-même. Pour des raisons de performances, SQL Server reporte les écritures dans la base de données via son propre système de mémoire tampon de cache. Le système reporte temporairement les écritures dans le journal jusqu’au COMMIT moment. Il ne met pas en cache ces écritures de la même façon que les écritures de données. Étant donné que les écritures de journal pour une page donnée arrivent toujours avant les écritures de données de la page, le journal est parfois appelé journal en écriture anticipée (WAL).

Protocole de journalisation WAL

Le terme protocole est un excellent moyen de décrire le WAL. Le WAL utilisé par SQL Server est appelé ARIES (Algorithme pour la sémantique d’exploitation de récupération et d’isolation). Pour plus d’informations, consultez l’article Résoudre les problèmes de récupération de base de données accélérée.

Il s’agit d’un ensemble spécifique et défini d’étapes d’implémentation nécessaires pour garantir que les données sont stockées et échangées correctement et peuvent être récupérées à un état connu en cas de défaillance. Tout comme un réseau contient un protocole défini pour échanger des données de manière cohérente et protégée, le WAL décrit lui aussi le protocole pour protéger les données. Toutes les versions de SQL Server ouvrent les fichiers journaux et de données à l’aide de la fonction Win32 CreateFile. Le membre dwFlagsAndAttributes inclut l’option FILE_FLAG_WRITE_THROUGH lors de son ouverture par SQL Server.

FILE_FLAG_WRITE_THROUGH

SQL Server crée ses fichiers de base de données à l’aide de l’indicateur FILE_FLAG_WRITE_THROUGH. Cette option indique au système d’écrire dans n’importe quel cache intermédiaire et d’accéder directement au stockage. Le système peut toujours mettre en cache les opérations d’écriture, mais il ne peut pas les vider de manière différée. Pour plus d’informations, consultez CreateFileA.

L’option FILE_FLAG_WRITE_THROUGH garantit que lorsqu’une opération d’écriture indique une réussite, les données sont correctement stockées dans un stockage stable. Cette fonctionnalité s’aligne sur la spécification du protocole WAL (Write-Ahead Logging) pour garantir l’intégrité des données. De nombreux périphériques de stockage (NVMe, PCIe, SATA, ATA, SCSI et IDE) contiennent des caches intégrés de 512 Ko, 1 Mo et plus. Les caches de stockage reposent généralement sur un condensateur et non sur une solution à batterie. Ces mécanismes de mise en cache ne peuvent pas garantir les écritures dans un cycle d’alimentation ou un point de défaillance similaire. Ils garantissent uniquement l’achèvement des opérations d’écriture du secteur. À mesure que les périphériques de stockage continuent de croître en taille, les caches deviennent plus volumineux et peuvent exposer de plus grandes quantités de données lors d’une défaillance.

Pour plus d’informations sur la prise en charge de FUA par la distribution Linux et son effet sur SQL Server, consultez SQL Server sur Linux : éléments internes d’accès d’unité forcé (FUA).

Intégrité transactionnelle et récupération de SQL Server

L’intégrité transactionnelle est l’un des concepts fondamentaux d’un système de base de données relationnelle. Les transactions sont des unités atomiques de travail qui sont entièrement appliquées ou annulées. Le journal des transactions à écriture anticipée de SQL Server est un composant essentiel de l’implémentation de l’intégrité transactionnelle.

Tout système de base de données relationnelle doit également traiter un concept étroitement lié à l’intégrité transactionnelle, qui est la récupération d’une défaillance système non planifiée. Plusieurs effets non idéaux et réels peuvent être à l’origine de cette défaillance. Sur de nombreux systèmes de gestion de base de données, une défaillance du système peut entraîner un long processus de récupération manuelle par une intervention humaine.

En revanche, le mécanisme de récupération de SQL Server est automatique et fonctionne sans intervention humaine. Par exemple, lors de sa prise en charge d'une application de production critique, SQL Server pourrait rencontrer une défaillance du système due à une fluctuation de puissance momentanée. Lors de la restauration de l’alimentation, le matériel du serveur redémarre, les logiciels de mise en réseau se chargent et initialisent, et SQL Server redémarre. À mesure de son initialisation, SQL Server exécute automatiquement son processus de récupération en fonction des données dans le journal des transactions. Ce processus se produit dans son intégralité sans intervention humaine. Lorsque les stations de travail clientes redémarrent, les utilisateurs trouvent toutes leurs données présentes, jusqu’à la dernière transaction qu’ils ont entrée.

L’intégrité transactionnelle et la récupération automatique dans SQL Server constituent une puissante fonctionnalité d’économie de temps et de travail. Si un contrôleur de mise en cache d’écriture n’est pas correctement conçu pour être utilisé dans un environnement SGBD transactionnel critique pour les données, il peut compromettre la capacité de récupération de SQL Server, potentiellement endommager la base de données. Ce problème peut se produire si le contrôleur intercepte les écritures du journal des transactions SQL Server et les met en mémoire tampon dans un cache matériel sur la carte du contrôleur, mais ne conserve pas ces pages écrites lors d’une défaillance système.

Risques de mise en cache d’écriture sur disque

La plupart des contrôleurs de mise en cache des dispositifs de stockage effectuent une mise en cache d'écriture. Vous ne pouvez pas toujours désactiver la fonction de mise en cache d’écriture.

Même si le serveur utilise un UPS, l’appareil ne garantit pas la sécurité des écritures mises en cache. De nombreux types de défaillances système peuvent se produire qu’un onduleur ne peut résoudre. Par exemple, une erreur de parité de mémoire, un piège de système d’exploitation ou une perturbation matérielle qui provoque une réinitialisation du système peut produire une interruption non contrôlée du système. Une défaillance de mémoire dans le cache d’écriture matériel peut également entraîner la perte d’informations de journal vitales.

Un autre problème possible lié à un contrôleur de mise en cache d’écriture peut se produire lors de l’arrêt du système. Il n’est pas rare de cycler le système d’exploitation ou de redémarrer le système pendant les modifications de configuration. Même si un opérateur prudent suit la recommandation du système d’exploitation d’attendre que toute l’activité de stockage cesse avant de redémarrer le système, des écritures mises en cache peuvent toujours être présentes dans le contrôleur. Lorsque la combinaison de touches Ctrl+Alt+Del est enfoncée ou qu’un bouton de réinitialisation matérielle est enfoncé, les écritures mises en cache peuvent être ignorées, ce qui peut être potentiellement nuisible à la base de données.

Il est possible de concevoir un cache d’écriture matériel qui tient compte de toutes les causes possibles de l’abandon des données de cache incorrectes, ce qui permet de sécuriser l’utilisation par un serveur de base de données. Certaines de ces fonctionnalités de conception incluent l’interception du signal de bus RST (réinitialisation) pour éviter la réinitialisation incontrôlée du contrôleur de mise en cache, alimentation de secours par batterie intégrée, et mémoire avec vérification et correction d’erreurs (ECC). Vérifiez auprès de votre fournisseur de matériel pour vous assurer que le cache d’écriture inclut ces fonctionnalités et toutes les autres nécessaires pour éviter la perte de données.

Utiliser des caches de stockage avec SQL Server

Un système de base de données est d’abord et avant tout responsable du stockage et de la récupération précise des données, même en cas de défaillances inattendues du système.

Le système doit garantir l’atomicité et la durabilité des transactions, tout en tenant compte de l’exécution actuelle, de plusieurs transactions et de divers points de défaillance. Cette propriété est souvent appelée propriété ACID (Atomicité, Cohérence, Isolation et Durabilité).

Cette section aborde les implications des caches de stockage. Pour plus d’informations sur la mise en cache et les discussions sur les modes alternatifs de défaillance, consultez les articles suivants :

• 86903 SQL Server et contrôleurs de disque de mise en cache
• Description des algorithmes de journalisation et de stockage des données qui augmentent la fiabilité des données dans SQL Server

Passez également en revue le contenu archivé suivant :

• Informations de base sur les E/S SQL Server 2000
• Principes de base des E/S SQL Server 2

Les concepts de ces deux articles restent largement applicables aux versions actuelles de SQL Server.

Solutions de mise en cache avec batterie

Les systèmes de contrôleur de mise en cache améliorés désactivent le cache sur disque et fournissent une solution fonctionnelle de mise en cache à batterie. Ces caches sont capables de conserver les données dans le cache pendant plusieurs jours et même d'autoriser l’utilisation de la carte de mise en cache sur un deuxième ordinateur. Lorsque l’alimentation est correctement restaurée, les données non écrites sont complètement vidées avant toute autre autorisation d’accès aux données. La plupart de ces systèmes vous permettent d’établir un pourcentage de cache de lecture et d’écriture pour des performances optimales. Certains systèmes contiennent des zones de stockage de mémoire volumineuses. Certains fournisseurs de matériel fournissent des systèmes de mise en cache de disques à batterie haut de gamme, de plusieurs gigaoctets de cache. Ces systèmes peuvent améliorer considérablement les performances de la base de données. Les solutions de mise en cache sauvegardées par batterie fournissent la durabilité et la cohérence des données attendues par SQL Server.

Implémentations du sous-système de stockage

Les sous-systèmes de stockage existent dans de nombreux types. Deux exemples courants sont RAID (tableau redondant de disques indépendants) et SAN (réseau de zone de stockage). Ces systèmes utilisent généralement des lecteurs basés sur SCSI. La section suivante décrit les considérations relatives au stockage de haut niveau.

SCSI, SAS et NVMe

Périphériques de stockage SCSI, SAS et NVMe :

• Sont généralement conçus pour une utilisation intensive.
• Visent généralement des implémentations multiutilisateurs et basées sur le serveur.
• En règle générale, les durées moyennes avant échec sont meilleures que celles d'autres implémentations.
• Contiennent des valeurs heuristiques sophistiquées pour aider à prédire les défaillances imminentes.

Non-SCSI

Implémentations d'autres pilotes, comme IDE, ATA et SATA :

• Sont généralement conçus pour une utilisation légère et moyenne.
• Sont généralement ciblés sur les applications mono-utilisateur.

Les contrôleurs non SCSI pour ordinateurs de bureau nécessitent davantage de ressources processeur (CPU) et sont fréquemment limités par une seule commande active. Par exemple, lorsqu’un lecteur non-SCSI ajuste un bloc incorrect, le lecteur nécessite que les commandes hôtes attendent. Le bus ATA présente un autre exemple : il prend en charge deux périphérique, mais une seule commande peut être active. Cette limitation laisse un lecteur inactif pendant que l’autre exécute la commande en attente. Les systèmes RAID basés sur les technologies de bureau peuvent tous subir ces symptômes et être considérablement affectés par le répondeur le plus lent. Sauf si ces systèmes utilisent des conceptions avancées, leurs performances ne sont pas aussi efficaces que celles des systèmes SCSI.

Considérations relatives au stockage

Un lecteur ou un système de stockage de bureau peut être une solution à faible coût pour certaines situations. Par exemple, si vous configurez une base de données en lecture seule pour la création de rapports, vous ne rencontrez pas de nombreux facteurs de performances d’une base de données OLTP lorsque la mise en cache du lecteur est désactivée.

La taille des périphériques de stockage ne cesse d’augmenter. Les disques à haute capacité et à faible coût peuvent être attrayants. Toutefois, lorsque vous configurez le lecteur pour SQL Server et vos besoins de temps de réponse métier, tenez soigneusement compte des problèmes suivants :

• Conception du chemin d’accès
• La nécessité de désactiver le cache sur disque

Les lecteurs de disque dur mécaniques

Les lecteurs mécaniques utilisent des plateaux magnétiques rotatifs pour stocker les données. Ils sont disponibles dans plusieurs capacités et facteurs de forme, tels que IDE, SATA, SCSI et SAS (Serial Attached SCSI). Certains lecteurs SATA incluent des constructions de prédiction d’échec. Les lecteurs SCSI sont conçus pour des cycles de travail plus intensifs et des taux d’échec réduits.

** Les systèmes IDE et ATA peuvent reporter les commandes hôtes lorsqu’ils effectuent des activités telles que l’ajustement de blocs défectueux, ce qui entraîne des périodes d'activité d'entrée-sortie bloquée.

Les avantages du SAS incluent la mise en file d’attente avancée jusqu’à 256 niveaux, ainsi que la gestion de la tête de file et de la mise en file d'attente hors ordre. Le fond de panier SAS est conçu de manière à permettre l’utilisation de lecteur SAS et de lecteur SATA au sein du même système.

Votre installation de SQL Server dépend de la capacité du contrôleur à désactiver le cache sur disque et à fournir un cache d’E/S stable. L’écriture de données dans le désordre sur plusieurs lecteurs n’est pas un obstacle à SQL Server, dès lors que le contrôleur fournit des capacités stables de mise en cache des supports. La complexité de la conception du contrôleur augmente avec les techniques avancées de sécurité des données telles que la mise en miroir.

Stockage à état solide

Le stockage à état solide présente des avantages par rapport aux disques durs mécaniques (rotatifs), mais il est également sujet à de nombreux modèles de défaillance similaires aux médias tournants. Vous pouvez connecter un stockage ssd à votre serveur à l’aide de différentes interfaces, notamment NVM Express (NVMe), PCI Express (PCIe) et SATA. Traitez les supports à semi-conducteurs comme vous le feriez pour des supports rotatifs et veillez à prendre des mesures de protection appropriées en cas de panne de courant, comme en prévoyant un contrôleur de mise en cache protégé par batterie.

Les problèmes courants causés par une panne d’alimentation sont les suivants :

• Altération du bit : les enregistrements affichent des erreurs de bits aléatoires.
• écritures volantes : des enregistrements bien formés se retrouvent au mauvais endroit.
• écritures tronquées : des opérations sont exécutées de manière incomplète, à un niveau inférieur à la taille attendue du secteur.
• Altération des métadonnées : les métadonnées de la couche de traduction flash (FTL) sont endommagées.
• périphérique qui ne répond pas : le périphérique ne fonctionne pas du tout ou quasiment pas.
• sérialisation impossible : l’état final du stockage ne résulte pas d’un ordre d’opération sérialisable.

512e

La plupart des appareils de stockage ssd signalent des tailles de secteur de 512 octets, mais utilisent des pages de 4 Ko à l’intérieur des blocs d’effacement de 1 Mo. L’utilisation de secteurs alignés sur 512 octets pour le périphérique de journal de SQL Server peut générer un plus grand nombre d'activités de lecture/modification/écriture (RMW), ce qui peut contribuer à ralentir les performances et l’usure du lecteur.

Recommandation : Assurez-vous que le contrôleur de mise en cache connaît la taille de page correcte du périphérique de stockage et qu'il est capable d'aligner correctement les écritures physiques avec l'infrastructure de stockage à semi-conducteurs.

0xFFFFFFFF

Un lecteur nouvellement mis en forme contient généralement tous les zéros. Un bloc effacé d'un appareil à état solide contient uniquement des 1, ce qui signifie qu'une lecture brute d'un bloc effacé ne donne que des caractères 0xFF. Toutefois, il est inhabituel qu'un utilisateur lise un bloc effacé pendant des opérations d’E/S normales.

Horodatage des modèles

Une technique utilisée dans le passé consiste à écrire un modèle connu sur l'ensemble du disque. Ensuite, lorsque les activités de base de données s'exécutent sur le même support de stockage, un comportement incorrect (lecture obsolète, écriture perdue ou lecture à décalage incorrect) peut être détecté lorsque le motif apparaît de manière inattendue.

Cette technique ne fonctionne pas bien avec un système de stockage à semi-conducteurs. Les opérations d'effacement et les RMW pour les écritures altèrent le schéma. L’activité de collecte de déchets du stockage à état solide (GC), le nivellement de l'usure, les blocs de liste proportionnels/réservés et d’autres optimisations ont tendance à entraîner les écritures à occuper des emplacements physiques différents, contrairement à la réutilisation du secteur des médias tournants.

Microprogramme

Les microprogrammes utilisés dans les systèmes de stockage à semi-conducteurs ont tendance à être plus complexes que ceux utilisés dans les systèmes de stockage rotatifs. De nombreux lecteurs utilisent plusieurs cœurs de traitement pour gérer les demandes entrantes et les activités de récupération de l'espace mémoire. Veillez à ce que le micrologiciel de votre dispositif à semi-conducteurs soit à jour afin d'éviter les problèmes connus.

Endommagement des données de lecture et répartition de l'usure

Une approche courante de la récupération de l'espace mémoire (garbage collection (GC)) pour le stockage à semi-conducteurs permet d’éviter les dommages répétés des données de lecture. Lors de la lecture répétée de la même cellule, il est possible que des électrons s'échappent et endommagent les cellules voisines. Le stockage sur semi-conducteurs protège les données à l'aide de différents niveaux de code de correction d'erreur (ECC) et d'autres mécanismes.

L’un de ces mécanismes concerne la répartition de l’usure. Le stockage sur semi-conducteurs assure un suivi des activités de lecture et d’écriture sur le périphérique de stockage. La récupération de l'espace mémoire (garbage collection) peut déterminer les zones réactives ou les emplacements qui s'usent plus rapidement que d’autres. Par exemple, le GC détermine qu’un bloc est dans un état en lecture seule et doit être déplacé. Ce déplacement se fait généralement vers un bloc plus usé, de sorte que le bloc d'origine soit utilisable pour des écritures. Ce processus permet d’équilibrer l’usure sur le lecteur, mais il déplace les données en lecture seule vers un emplacement qui a plus d’usure et augmente mathématiquement les chances d’échec, même si légèrement.

Un autre effet secondaire du nivellement de l’usure peut se produire avec SQL Server. Supposons que vous exécutiez DBCC CHECKDB et qu’il signale une erreur. Si vous l’exécutez une deuxième fois, il existe une petite chance que DBCC CHECKDB signale un modèle d'erreur supplémentaire ou différente, car l'activité de récupération de mémoire du stockage sur semi-conducteurs peut apporter des modifications entre les deux exécutions DBCC CHECKDB.

Erreur du système d’exploitation 665 et défragmentation

Les supports rotatifs doivent maintenir les blocs à proximité les uns des autres afin de réduire le mouvement de la tête du lecteur et d'augmenter les performances. Le stockage à état solide n’a pas de tête physique, ce qui élimine le temps de recherche. De nombreux appareils ssd sont conçus pour permettre des opérations parallèles sur différents blocs. La défragmentation du support d’état solide n’est donc pas nécessaire. Les activités série sont les meilleurs modèles d’E/S pour optimiser le débit d’E/S sur des périphériques de stockage à semi-conducteurs.

Recommandations :

• Utilisez un contrôleur protégé par batterie approprié conçu pour optimiser les activités d’écriture. Ce choix peut améliorer les performances, réduire l’usure des disques et diminuer les niveaux de fragmentation physique.

• Envisagez d’utiliser le système de fichiers ReFS pour éviter les limitations d’attribut NTFS.

• Vérifiez que les paramètres de croissance des fichiers sont appropriés.

Pour plus d’informations sur la résolution des problèmes liés à l’erreur de système d’exploitation 665, consultez Les erreurs OS 665 et 1450 sont signalées pour des fichiers de SQL Server..

Compression

Tant que le lecteur conserve l’intention d’un support stable, la compression peut prolonger la durée de vie du lecteur et affecter positivement les performances. Toutefois, certains microprogrammes peuvent déjà compresser les données de manière invisible. N’oubliez pas de tester de nouveaux scénarios de stockage avant de les déployer dans votre environnement de production.

Résumé

• Conservez les procédures et processus de sauvegarde et de récupération d’urgence appropriés.
• Conservez à jour vos microprogrammes
• Écoutez attentivement les conseils de votre fabricant de matériel.

Configuration du cache de lecteur

Pour utiliser un lecteur avec SQL Server, désactivez la mise en cache du lecteur. Le cache de lecteurs est activé par défaut. Dans Windows Server, utilisez l'onglet Propriétés du disque>Matériel>Stratégie pour désactiver la mise en cache en écriture au niveau du système d'exploitation.

Ne vous fiez pas uniquement aux paramètres au niveau du système d’exploitation. Certains lecteurs ignorent les paramètres Windows et nécessitent des utilitaires ou des paramètres de microprogramme fournis par le fabricant pour désactiver la mise en cache d’écriture. Vérifiez que la mise en cache de l’écriture est réellement désactivée via les outils fournisseurs.

Considérations relatives au cache et SQLIOSim

Pour confirmer les garanties de durabilité transactionnelle, validez votre sous-système d’E/S à l’aide de SQLIOSim avant de passer en production. Cet utilitaire simule une activité de lecture et d’écriture asynchrone lourde sur un appareil de données simulé et un appareil de journal. Pour plus d’informations, consultez Utiliser l’utilitaire SQLIOSim pour simuler l’activité SQL Server sur un sous-système de disque.

De nombreux fabricants de PC commandent les lecteurs avec le cache d’écriture désactivé. Toutefois, les tests montrent que cette condition peut ne pas toujours être le cas. Vous devez donc toujours la tester complètement. Si vous avez des questions sur l’état de mise en cache de votre appareil de stockage, contactez le fabricant et obtenez l’utilitaire approprié pour désactiver les opérations de mise en cache d’écriture. Sur les supports de stockage plus anciens, vous pouvez également avoir besoin de paramètres de jumper.

SQL Server exige que les systèmes prennent en charge la livraison garantie sur un support stable, comme indiqué dans les exigences du programme de fiabilité des E/S de SQL Server. Pour plus d’informations sur les exigences d’entrée et de sortie pour le Moteur de base de données SQL Server, consultez les exigences relatives à l’entrée/sortie (E/S) de disque du Moteur de base de données SQL Server.

Risques de mise en cache d’écriture incorrects

Lorsque vous activez la mise en cache d’écriture sans protection appropriée, certains sous-systèmes de stockage reconnaissent que les opérations d’écriture sont terminées avant que les données soient écrites en toute sécurité sur un support durable. Si une perte d’alimentation ou une défaillance du système se produit, cette condition peut entraîner :

• Perte de données, où les transactions validées ne sont jamais conservées.
• Altération de la base de données en raison de garanties d’ordre d’écriture rompues.

Contenu associé

• Guide d’architecture des pages et des extensions
• Guide d’architecture de gestion de la mémoire
• Storage : Meilleures pratiques en matière de performances pour SQL Server sur des machines virtuelles Azure
• SQL Server sur Linux : éléments internes d’accès d’unité forcé (FUA)
• SQL Server I/O Basics, Chapter 2 (en anglais)