Partager via

Notions de base des E/S de SQL Server

  • Article

S’applique à : Base de données Azure SQL Azure SQL Managed Instance SQL Server on Azure VM

L'objectif principal d'une base de données SQL Server est de stocker et de récupérer les données, l'utilisation intensive d'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 détails sur l’utilisation 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 de disque (E/S) de SQL Server Moteur de base de données.

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 :

  • Toutes les opérations d'E/S s'effectuent 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, les 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 E/S longue peut être une lecture ou une écriture ; cela ne figure pas dans le message. 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, aucune intervention n’est nécessaire, mais l'administrateur système doit analyser les raisons de la lenteur de la demande d'E/S et si ce délai est justifié.

Causes de longues demandes d'E/S

Un long message d'E/S peut indiquer qu'une E/S est bloquée de manière permanente et ne se terminera jamais (E/S perdue), ou simplement 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 ;
  • L’analyseur de performances indique des latences de disque longues, des files d'attente de disque longues ou aucun temps 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 les réseaux à fibres optiques (en raison d'une mauvaise configuration ou d'une défaillance du 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 à priori aucun rapport avec les conditions décrites plus haut sont peut-être causées par un problème de matériel ou de pilote. Le journal d'événements système peut contenir un événement connexe qui permet de 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 dans la 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 les 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 de l'é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 les disques mécaniques, en raison de la vitesse 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 de SQL Server sont ciblées sur 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 SQL Server. Ils évitent les problèmes de performances liés à la recherche de stockage et à l’écriture en utilisant les différentes optimisations du contrôleur de mise en cache.

Remarque

Certains fournisseurs de stockage utilisent la mémoire persistante (PMEM) comme stockage 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’une mise en cache d’écriture (également appelée mise en cache 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 gestion de base de données transactionnelle critique (SGBD) de 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 sans interruption (ASI) externe n'est généralement pas suffisante, car des modes de défaillance non liés à l'alimentation peuvent se produire.

La mise en cache des contrôleurs et sous-systèmes de stockage peut être sécurisée pour une utilisation par SQL Server. La plupart des nouvelles plateformes de serveur conçues à usage unique 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 transactionnel (SGBDR) critique pour les données.

Journalisation WAL (Write-Ahead Logging)

Les instructions de modification des données SQL Server génèrent des écritures de pages logiques. Ce flux d’écritures peut être illustré à 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 en écriture anticipée (WAL).

Protocole de journalisation en écriture anticipée (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 Gestion de la 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 également 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 inclut dwFlagsAndAttributes l’option FILE_FLAG_WRITE_THROUGH lors de l’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 appareils 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 totalement appliquées ou totalement restaurées. Le journal des transactions de SQL Server en écriture anticipée 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, l’échec du système peut entraîner un long processus de récupération manuel dirigé par l’homme.

En revanche, le mécanisme de récupération de SQL Server est automatique et fonctionne sans intervention humaine. Par exemple, SQL Server peut prendre en charge une application de production critique et rencontrer une défaillance du système en raison d’une fluctuation de puissance momentanée. Lors de la restauration de l’alimentation, le matériel du serveur redémarre, le logiciel réseau charge et initialise, et SQL Server redémarre. À mesure que SQL Server initialise, il exécute automatiquement son processus de récupération en fonction des données dans le journal des transactions. Ce processus entier se produit sans intervention humaine. Chaque fois que les stations de travail clientes ont redémarré, les utilisateurs trouveraient 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.

Écrire la mise en cache et les contrôleurs d’appareil de stockage

La plupart des contrôleurs de mise en cache des appareils de stockage effectuent une mise en cache en é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 d’échecs 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 un problème matériel qui provoque une réinitialisation du système peut produire une interruption du système non contrôlée. 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, les é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, potentiellement nuisibles à la base de données.

Il est possible de concevoir un cache d’écriture matériel, qui prend en compte toutes les causes possibles de l’abandon des données de cache incorrectes, ce qui serait donc sûr pour une utilisation par un serveur de base de données. 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 à bord et la vérification des erreurs ou la vérification et la correction de la mémoire (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 fonctionnalités 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 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 différents points d’échec. Il s’agit souvent des propriétés ACID (Atomicity, Consistency, Isolation et Durability).

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 au mode sans échec alternatif :

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 de mise en cache à batterie fonctionnelle. Ces caches peuvent conserver les données dans le cache pendant plusieurs jours et même autoriser l’insertion 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 l’autorisation d’un accès supplémentaire aux données. La plupart d’entre eux permettent d’établir un pourcentage de cache de lecture et d’écriture pour 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 avec 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 une durabilité et une 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 décrit génériquement 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 fabriqués pour une utilisation intensive.
  • Sont généralement ciblés sur les implémentations multiutilisateurs et basées sur le serveur.
  • En règle générale, les taux d’échec sont plus élevés que d’autres implémentations.
  • Contiennent des heuristiques sophistiquées pour aider à prédire les défaillances imminentes.

Non-SCSI

Autres implémentations de lecteur, telles que l’IDE, ATA et SATA :

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

Les contrôleurs non SCSI, basés sur le bureau, nécessitent une bande passante de processeur (CPU) 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 : le bus ATA prend en charge deux appareils, 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 plus lent. Sauf si ces systèmes utilisent des conceptions avancées, leurs performances ne sont pas aussi efficaces que les performances des systèmes SCSI.

Considérations relatives au stockage

Il existe des situations dans lesquelles un lecteur ou un tableau basé sur le bureau est 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.

Les tailles des appareils de stockage continuent d’augmenter. Les 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 problèmes suivants :

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

Disques durs mécaniques

Les lecteurs mécaniques utilisent des plateaux magnétiques en rotation pour stocker les données. Elles 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 lourds 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. Par défaut, le cache du lecteur est activé. 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 le paramètre de cache du lecteur.

Remarque

Certains lecteurs ne respectent pas ce paramètre. 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.

Les avantages SAS incluent la mise en file d’attente avancée jusqu’à 256 niveaux, ainsi que la tête de file d’attente et de mise en file d’attente hors commande. Le backplan SAS est conçu de manière à permettre l’utilisation des lecteurs SAS et 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 différents lecteurs n’est pas un obstacle à SQL Server tant que le contrôleur fournisse les capacités de mise en cache des supports stables. 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 (épinglages), mais est susceptible d’être sensible à la plupart des mêmes modèles d’échec que les supports de rotation. 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 en rotation et assurez-vous que les mesures de protection appropriées sont en place en cas de panne de courant, telles qu'un contrôleur de mise en cache sur batterie.

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

  • bit corrompu : les enregistrements présentent des erreurs de bits aléatoires.
  • Écritures volantes : Les enregistrements bien formés se retrouvent dans un mauvais endroit.
  • Écritures de shorn : les opérations sont partiellement effectuées à un niveau inférieur à la taille attendue du secteur.
  • Corruption des métadonnées : les métadonnées dans FTL sont endommagées.
  • Appareil qui ne répond pas : L'appareil ne fonctionne pas du tout ou presque pas.
  • Insérialisabilité : 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 l’appareil de journal SQL Server peut générer des 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 peut 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 à semi-conducteurs est tout 1, ce qui fait qu’une lecture brute d’un bloc effacé est tout 0xFFs. Toutefois, il est inhabituel pour un utilisateur de lire un bloc effacé pendant les 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 dans l’ensemble du lecteur. Ensuite, 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 le système de stockage à semi-conducteurs. Les activités d’effacement et de RMW pour les écritures détruisent le modèle. L'activité de garbage collection (GC) du système de stockage à semi-conducteurs, le nivellement de 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 à rotation.

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 à rotation. De nombreux lecteurs utilisent plusieurs cœurs de traitement pour gérer les demandes entrantes et les activités de garbage collection. Veillez à ce que le micrologiciel de votre dispositif à semi-conducteurs soit à jour afin d'éviter les problèmes connus.

Données de lecture endommagement et nivellement de l'usure

Une approche courante du garbage collection (GC) pour le stockage sur semi-conducteurs permet d’éviter les dommages répétés et lus aux données. Lors de la lecture répétée de la même cellule, il est possible que l'activité des électrons s'échappe et endommage 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 le nivellement de l’usure. Le stockage sur semi-conducteurs effectue le suivi de l’activité de lecture et d’écriture sur l’appareil de stockage. Le garbage collection peut déterminer les zones réactives ou les emplacements portant plus rapidement que d’autres emplacements. Par exemple, le GC détermine qu’un bloc est en lecture seule depuis un certain temps et qu'il doit être déplacé. Ce mouvement se fait généralement sur un bloc plus usé, le bloc d'origine peut donc être utilisé pour les écritures. Cela permet d'équilibrer l'usure du disque, mais déplace les données en lecture seule vers un emplacement plus usé et augmente mathématiquement les risques de défaillance, même s'ils sont minimes.

Un autre effet secondaire du nivellement de l’usure peut se produire avec SQL Server. Supposons que vous exécutez 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 des erreurs supplémentaires ou différentes, car l'activité du GC du stockage sur semi-conducteurs peut être modifiée entre les deux exécutions DBCC CHECKDB.

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

Les supports en rotation 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 appareils à stockage sur 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 sur 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 les appareils de stockage sur semi-conducteurs.

Remarque

Le stockage sur 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 de 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.

  • Assurez-vous que les tailles de croissance des fichiers sont correctement dimensionnées.

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 les fichiers du serveur SQL..

Compression

Tant que le lecteur conserve l’intention d’un support stable, la compression peut allonger 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.
  • Maintenez votre micrologiciel à jour.
  • Écoutez attentivement les conseils du fabricant de votre matériel.

Considérations relatives au cache et SQLIOSim

Pour sécuriser entièrement vos données, vous devez vous assurer que toutes les mises en cache des données sont correctement gérées. Dans de nombreuses situations, cela signifie que vous devez désactiver la mise en cache d’écriture du lecteur.

Remarque

Vérifiez que tout autre mécanisme de mise en cache peut 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 lourde 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, c'est pourquoi vous devriez toujours le 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 les paramètres d’utilitaire ou de jumper appropriés pour 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 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 de disque (E/S) de SQL Server Moteur de base de données.

Contenu connexe