Partager via

Notions de base des E/S de SQL Server

S'applique à :SQL ServerAzure SQL Managed InstanceSQL Server sur une machine virtuelle 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, y compris des lecteurs mécaniques et des systèmes de stockage à semi-conducteurs. 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. L'administrateur système peut ainsi distinguer entre les problèmes liés à SQL Server et les problèmes au niveau du 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 opération d'E/S peut correspondre à une opération de lecture ou d'écriture ; celle-ci ne figure pas dans le message actif. 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 permettent à l'administrateur de détecter la cause des temps de réponse SQL Server médiocres plus rapidement et de distinguer les problèmes qui ne dépendent pas 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 signalant une opération d'E/S longue peut indiquer qu'une E/S est bloquée de manière permanente et ne peut s'achever (E/S perdue) ou qu'elle ne s'est pas encore terminée. Il est impossible d’identifier le type de scénario à partir du message, même si une E/S perdue entraîne souvent un délai d’attente de verrou.

Une opération d'E/S longue indique 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.

Les opérations d'E/S longues peuvent également être causées par un composant du chemin d'E/S (par exemple, un pilote, un contrôleur ou un microprogramme) qui reporte continuellement le traitement d'une ancienne demande d'E/S au profit de demandes plus récentes. Cela peut se produire dans des environnements interconnectés, tels que les réseaux iSCSI et fibre channel (en raison d’une mauvaise configuration ou d’un échec de chemin). Cela peut être difficile à corroborer avec l'outil Analyseur de performances car la plupart des E/S sont traitées rapidement. Les opérations d'E/S longues peuvent se compliquer en raison de charges de travail impliquant de grandes quantités d'E/S séquentielle, parmi lesquelles figurent les opérations de sauvegarde et de restauration, les analyses de table, les tris, les créations d'index, les chargements en masse et les réinitialisations de fichiers.

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 qui ne sont pas 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 concernant les E/S de 15 secondes soit plus courant avec des composants matériels, une latence d'E/S plus faible est plus fréquemment observée 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 effectués sans l’utilisation d’un cache peuvent être beaucoup plus longs dans des lecteurs de disque dur mécaniques, en raison de la vitesse de rotation du disque dur, du temps mécanique nécessaire pour déplacer les têtes de lecteur et d’autres facteurs de limitation. Les installations de SQL Server visent 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.

Note

Certains fournisseurs de stockage utilisent comme stockage la mémoire persistante (PMEM) plutôt qu’un cache, ce qui peut améliorer les performances globales. Pour plus d’informations, consultez Configurer la mémoire persistante (PMEM) pour SQL Server sur Windows et Configurer la mémoire persistante (PMEM) pour SQL Server sur Linux.

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 peuvent être utilisés en toute sécurité pour SQL Server, s’ils sont conçus pour être utilisés dans un environnement de gestion de base de données (SGBD) transactionnel 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'un onduleur externe ne suffit généralement pas,, car des modes de défaillance non 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 spécialement conçues qui incorporent ces plateformes 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 (SGBDR) transactionnel critique pour les données.

Journalisation WAL

Les instructions de modification de données de SQL Server génèrent des écritures de pages logiques. Ce flux d’écritures peut être illustré comme étant à destination à deux endroits : le journal et la base de données proprement dite. 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. Les écritures dans le journal ne sont différées que momentanément jusqu’au moment COMMIT. Elles ne sont pas mises en cache de la même façon que les écritures de données. Étant donné que les écritures de journal pour une page donnée précèdent toujours les écritures de données de la page, le journal est parfois appelé journal WAL (write-ahead log).

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 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 retourne une opération réussie, les données sont correctement stockées dans un stockage stable. Cela s’aligne sur la spécification du protocole WAL (Write Ahead Logging) pour garantir les 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 considérées comme des unités atomiques de travail qui sont soit totalement appliquées, soit totalement restauré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, le logiciel réseau se charge et s'initialise, 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. Chaque fois que les stations de travail clientes sont redémarrées, 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, ce qui endommage la base de données. Cela 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.

Contrôleurs de mise en cache d'écriture et du dispositif de stockage

La plupart des contrôleurs de mise en cache des dispositifs de stockage effectuent une mise en cache d'écriture. La fonction de mise en cache d’écriture ne peut pas toujours être désactivée.

Même si le serveur utilise un onduleur, cela 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 prend en compte toutes les causes possibles d’ignorer des données de cache incorrectes, pour faire en sorte qu'un serveur de base de données puisse les utiliser en toute sécurité. Certaines de ces fonctionnalités de conception incluent l’interception du signal de bus RST afin d’éviter la réinitialisation incontrôlée du contrôleur de mise en cache, la sauvegarde de batterie embarquée et la mémoire miroir ou la mémoire de vérification et de correction des 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. On parle souvent dans ce cas de propriétés ACID (Atomicité, Cohérence, Isolation et Durabilité).

Cette section aborde les implications des caches de stockage. Nous vous recommandons de lire les articles suivants dans la Base de connaissances Microsoft pour obtenir des précisions sur les discussions relatives à la mise en cache et d'autres modes de défaillance :

Les documents suivants sont également recommandés :

Ces deux documents s’appliquent à toutes les versions actuellement prises en charge 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 d’entre eux permettent d’établir un pourcentage de cache de lecture et d’écriture afin d'assurer des performances optimales. Certains 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. Ceux-ci peuvent améliorer de manière significative les performances de la base de données. L’utilisation de solutions de mise en cache sauvegardées par batterie offre la durabilité et la cohérence des données attendues par SQL Server.

Implémentations du sous-système de stockage

Il existe de nombreux types d’implémentations de sous-système. RAID (tableau redondant de disques indépendants) et SAN (réseau de zone de stockage) sont deux exemples de ces types d’implémentations de sous-système. Ces systèmes sont généralement générés avec des lecteurs basés sur SCSI. et ce, pour plusieurs raisons. La section suivante présente une description générique des considérations relatives à un stockage de haut niveau.

SCSI, SAS et NVMe

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

  • Sont généralement fabriqués pour une utilisation intensive.
  • Visent généralement des implémentations multiutilisateurs et basées sur le serveur.
  • Présentent généralement de meilleurs taux de défaillance entre défaillances que d’autres implémentations.
  • Contiennent des valeurs heuristiques sophistiquées pour aider à prédire les défaillances imminentes.

Note

SQL Server est pris en charge sur les composants de technologie iSCSI (Internet Small Computer System Interface) qui répondent aux exigences du programme de compatibilité matérielle Windows. Bien que SQL Server n’interagit pas directement avec iSCSI, il fonctionne en toute transparence, car Windows présente le stockage iSCSI en tant que lecteurs standard. Cela permet à SQL Server de lire et d’écrire dans le stockage au niveau du bloc distant sur les réseaux IP. Étant donné que iSCSI dépend des réseaux, vous pouvez rencontrer des retards ou des goulots d’étranglement. Vous devez donc optimiser les performances de mise en cache du serveur et réduire la latence. Pour plus d’informations, consultez limites d’extensibilité du serveur cible iSCSI.

Non-SCSI

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

  • Sont généralement fabriqués pour une utilisation légère et moyenne.
  • Visent généralement des applications mono-utilisateur.

Les contrôleurs basés sur le bureau non SCSI nécessitent une bande passante de processeur plus importante 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. L'un des lecteurs reste donc inactif pendant que l'autre traite 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

Il existe des situations dans lesquelles un lecteur ou un tableau basé sur le bureau constitue une solution appropriée à faible coût. Par exemple, si vous configurez une base de données en lecture seule pour la création de rapports, vous ne devriez pas rencontrer les mêmes facteurs de performance qu'une base de données OLTP lorsque la mise en cache des lecteurs est désactivée.

La taille des périphériques de stockage ne cesse d’augmenter. Des lecteurs à faible coût et à haute capacité peuvent être attrayants. Toutefois, lorsque vous configurez le lecteur pour SQL Server et les besoins en temps de réponse de votre entreprise, vous devez examiner attentivement les facteurs 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. Ceux-ci 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.

La mise en cache des lecteurs doit être désactivée pour pouvoir utiliser le lecteur avec SQL Server. Le cache de lecteurs est activé par défaut. Dans Windows Server, utilisez l’onglet Propriétés du disque>Matériel pour accéder à l’onglet Propriétés>Stratégiespour contrôler la configuration du cache de lecteur.

Note

Certains lecteurs ne sont pas compatibles avec cette configuration. Ces lecteurs nécessitent un utilitaire de fabricant spécifique pour désactiver le cache.

Les systèmes basés sur IDE et ATA peuvent reporter les commandes d’hôte lorsqu’ils effectuent des activités telles que l’ajustement de bloc incorrect. Cela peut entraîner des périodes d’activité d’E/S bloquées.

Un système SAS présentent plusieurs avantages, notamment la mise en file d’attente avancée de 256 niveaux maximum, ainsi que la mise en file d’attente par le haut de la file d’attente et dans le désordre. 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 à semi-conducteurs

Le stockage à semi-conducteurs présente des avantages par rapport aux disques durs mécaniques (rotatifs), mais est susceptible d’être sensible à la plupart des mêmes modèles d’échec que les supports rotatifs. Le stockage à semi-conducteurs est connecté à 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.

Voici une liste de problèmes courants causés par une panne de courant :

  • bit corrompu : les enregistrements présentent 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.
  • corruption des métadonnées : les métadonnées dans 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 systèmes de stockage à semi-conducteurs indiquent 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 que nous avons utilisée dans le passé consiste à écrire un modèle connu sur l’ensemble du lecteur. Ainsi, lorsque nous exécutons l’activité de base de données sur ce même lecteur, nous pouvons détecter un comportement incorrect (lecture obsolète / perte d’écriture / lecture de décalage incorrect / etc.) lorsque le modèle s’affiche de façon inattendue.

Cette technique ne fonctionne pas bien avec un système de stockage à semi-conducteurs. Les activités d’effacement et de RMW pour les écritures détruisent le modèle. Les activités de récupération de l'espace mémoire du système de stockage à semi-conducteurs, de répartition l'usure, les blocs de liste proportionnels/réservés et d'autres optimisations tendent à faire en sorte que les écritures acquièrent des emplacements physiques différents, contrairement à la réutilisation des systèmes de stockage rotatifs.

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, la récupération de l'espace mémoire détermine qu’un bloc est en lecture seule depuis un certain temps et qu'il 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. Cela permet d'équilibrer l'usure du disque, mais a pour effet de déplacer les données en lecture seule vers un emplacement plus usé, ce qui augmente mathématiquement les risques de défaillance, même s'ils sont minimes.

Un autre effet secondaire de la répartition 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 sur semi-conducteurs n’a pas de tête physique, ce qui élimine le temps de recherche. De nombreux périphériques de stockage à semi-conducteurs sont conçus pour permettre des opérations parallèles sur différents blocs en parallèle. Cela signifie que la défragmentation du stockage à semi-conducteurs n’est 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.

Note

Le stockage à semi-conducteurs bénéficie de la fonctionnalité trim , une commande au niveau du système d’exploitation qui efface les blocs considérés comme n’étant plus utilisés. Dans Windows, utilisez l’outil Optimiser les lecteurs pour définir une planification hebdomadaire d'optimisation des lecteurs.

Recommandations :

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

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

  • Veillez au bon dimensionnement des tailles de croissance des fichiers.

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 allonger la durée de vie du lecteur et avoir des effets positifs sur les performances. Toutefois, certains microprogrammes peuvent déjà compresser les données de manière invisible. N’oubliez pas de tester tous 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 vos fabricants de matériel.

Considérations relatives au cache et SQLIOSim

Pour sécuriser entièrement vos données, vous devez veiller à bien gérer toutes vos activités de mise en cache des données. Dans de nombreux cas, vous devez pour cela désactiver la mise en cache d’écritures du lecteur.

Note

Vérifiez que tout autre mécanisme de mise en cache est capable de gérer correctement plusieurs types de défaillances.

Microsoft a effectué des tests sur plusieurs lecteurs SCSI et IDE à l’aide de l’utilitaire SQLIOSim. Cet utilitaire simule une activité de lecture/écriture asynchrone intense sur un appareil de données simulé et un appareil de journal. Pour plus d’informations et de détails sur SQLIOSim, 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, des tests montrent que ce n'est pas toujours le cas, d'où la nécessité de le vérifier toujours complètement. Si vous avez des questions sur l’état de mise en cache de votre appareil de stockage, contactez le fabricant et obtenez les paramètres appropriés pour l’utilitaire ou le cavalier afin de désactiver les opérations de mise en cache d’écriture.

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.

Contenu associé