Delen via

Basisprincipes van SQL Server I/O

Van toepassing op:SQL ServerAzure SQL Managed InstanceSQL Server op Azure VM

Het primaire doel van een SQL Server-database is het opslaan en ophalen van gegevens, dus intensieve schijfinvoer/uitvoer (I/O) is een kernkenmerk van de database-engine. Omdat I/O-bewerkingen van de schijf veel resources kunnen verbruiken en relatief lang kunnen duren, is SQL Server gericht op het zeer efficiënt maken van I/O.

Opslagsubsystemen voor SQL Server worden geleverd in meerdere vormfactoren, waaronder mechanische schijven en ssd-opslag. In dit artikel vindt u meer informatie over het gebruik van principes voor schijfcaching om de I/O van de Database Engine te verbeteren.

SQL Server vereist dat systemen gegarandeerde levering van stabiele media ondersteunen, zoals wordt beschreven in de vereisten van het SQL Server I/O-betrouwbaarheidsprogramma. Zie de I/O-vereisten (Disk Input/Output) voor SQL Server Database Engine voor meer informatie over de invoer- en uitvoervereisten voor de SQL Server Database Engine.

Schijf-I/O

De bufferbeheerder voert alleen lees- en schrijfbewerkingen uit naar de database. Andere bestands- en databasebewerkingen, zoals openen, sluiten, uitbreiden en verkleinen, worden uitgevoerd door de onderdelen van databasebeheer en bestandsbeheer.

Schijf-I/O-bewerkingen door bufferbeheer hebben de volgende kenmerken:

  • I/O wordt doorgaans asynchroon uitgevoerd, waardoor de aanroepende thread kan blijven verwerken terwijl de I/O-bewerking op de achtergrond plaatsvindt. Onder bepaalde omstandigheden (bijvoorbeeld verkeerd uitgelijnde logboek-I/O), kunnen synchrone I/Os optreden.

  • Alle I/O's worden uitgegeven in aanroepende threads, tenzij de affiniteit I/O-optie wordt gebruikt. De affiniteit I/O-maskeroptie bindt de schijf-I/O van SQL Server aan een gespecificeerde groep CPU's. In oltp-omgevingen (High-end SQL Server Online Transactional Processing) kan deze extensie de prestaties verbeteren van SQL Server-threads die I/Os uitgeven.

  • I/Os van meerdere pagina's worden uitgevoerd met scatter-gather I/O, waarmee gegevens kunnen worden overgebracht naar of uit niet-aaneengesloten geheugengebieden. Dit betekent dat SQL Server de buffercache snel kan vullen of leegmaken terwijl er meerdere fysieke I/O-aanvragen worden vermeden.

Lange I/O-aanvragen

De buffermanager rapporteert over een I/O-aanvraag die ten minste 15 seconden openstaand is. Dit helpt de systeembeheerder onderscheid te maken tussen problemen met SQL Server en problemen met het I/O-subsysteem. Foutbericht MSSQLSERVER_833 wordt gerapporteerd en wordt als volgt weergegeven in het SQL Server-foutenlogboek:

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.

Een lange I/O kan een lees- of schrijfbewerking zijn; het is momenteel niet aangegeven in het bericht. Long-I/O-berichten zijn waarschuwingen, geen fouten. Ze geven geen problemen aan met SQL Server, maar met het onderliggende I/O-systeem. De berichten worden gerapporteerd om de systeembeheerder te helpen de oorzaak van slechte REACTIEtijden van SQL Server sneller te vinden en om problemen te onderscheiden die buiten het beheer van SQL Server vallen. Daarom vereisen ze geen actie, maar de systeembeheerder moet onderzoeken waarom de I/O-aanvraag zo lang duurde en of de tijd rechtvaardig is.

Oorzaken van lange I/O-aanvragen

Een lang I/O-bericht kan erop wijzen dat een I/O permanent wordt geblokkeerd en nooit wordt voltooid (ook wel I/O verloren genoemd) of alleen dat het nog niet is voltooid. Het is niet mogelijk om uit het bericht te halen welk scenario het geval is, hoewel een verloren input/output vaak leidt tot een vergrendelings-time-out.

Lange I/Os geven vaak een SQL Server-workload aan die te intensief is voor het schijfsubsysteem. Een ontoereikend schijfsubsysteem kan worden aangegeven wanneer:

  • Meerdere lange I/O-berichten worden weergegeven in het foutenlogboek tijdens een zware SQL Server-workload.
  • Prestatiemeteritems geven lange schijflatenties, lange schijfwachtrijen of geen niet-actieve schijftijd weer.

Lange I/Os kunnen ook worden veroorzaakt door een onderdeel in het I/O-pad (bijvoorbeeld een stuurprogramma, controller of firmware) dat voortdurend het afhandelen van een oude I/O-aanvraag uitstelt om nieuwere aanvragen voorrang te geven. Dit kan gebeuren in onderling verbonden omgevingen, zoals iSCSI- en fiber channel-netwerken (ofwel vanwege een onjuiste configuratie of padfout). Dit kan lastig zijn om te bevestigen met het hulpprogramma Prestatiemeter, omdat de meeste I/Os onmiddellijk worden onderhouden. Lange I/O-aanvragen kunnen worden verergerd door workloads die grote hoeveelheden sequentiële I/O uitvoeren, zoals back-up en herstel, tabelscans, sorteren, indexen maken, bulksgewijs laden en bestanden weghalen.

Geïsoleerde lange I/Os die niet gerelateerd zijn aan een van de vorige voorwaarden, kunnen worden veroorzaakt door een hardware- of stuurprogrammaprobleem. Het gebeurtenislogboek van het systeem kan een gerelateerde gebeurtenis bevatten waarmee het probleem kan worden vastgesteld.

I/O-prestatieproblemen veroorzaakt door inefficiënte query's of filterstuurprogramma's

Trage I/O kan worden veroorzaakt door query's die niet efficiënt zijn geschreven of niet goed zijn afgestemd met indexen en statistieken. Een andere veelvoorkomende factor in I/O-latentie is de aanwezigheid van antivirusprogramma's of andere beveiligingsprogramma's die databasebestanden scannen. Deze scansoftware kan worden uitgebreid naar de netwerklaag, waardoor netwerklatentie wordt toegevoegd, op zijn beurt indirect van invloed is op de databaselatentie. Hoewel het scenario dat wordt beschreven over ongeveer 15 seconden I/O vaker voorkomt bij hardwareonderdelen, wordt een kleinere I/O-latentie vaker waargenomen met niet-geoptimaliseerde query's of onjuist geconfigureerde antivirusprogramma's.

Zie Problemen met trage SQL Server-prestaties oplossen die worden veroorzaakt door I/O-problemen voor gedetailleerde informatie over het oplossen van deze problemen.

Zie Antivirussoftware configureren voor gebruik met SQL Server voor meer informatie over het configureren van antivirusbeveiliging op SQL Server.

Schrijven naar cache in opslagcontrollers

I/O-overdrachten die zonder het gebruik van een cache worden uitgevoerd, kunnen aanzienlijk meer tijd in beslag nemen in mechanische harde schijven, vanwege de draaisnelheden van de schijf, de tijd die nodig is om de schijfkoppen te verplaatsen en andere beperkende factoren. SQL Server-installaties zijn gericht op systemen die cachingcontrollers bieden. Deze controllers schakelen de caches op de schijf uit en bieden stabiele mediacaches om te voldoen aan de I/O-vereisten van SQL Server. Ze voorkomen prestatieproblemen met betrekking tot opslagzoek- en schrijftijden met behulp van de verschillende optimalisaties van de cachecontroller.

Opmerking

Sommige opslagleveranciers gebruiken permanent geheugen (PMEM) als opslag in plaats van een cache, waardoor de algehele prestaties kunnen worden verbeterd. Zie Permanente geheugen (PMEM) configureren voor SQL Server in Windows en Permanente geheugen configureren voor SQL Server in Linux voor meer informatie.

Het gebruik van een opslagcontroller voor schrijven in cache (ook wel write-back caching genoemd) kan de prestaties van SQL Server verbeteren. Schrijfcachecontrollers en opslagonderdelen zijn veilig om te gebruiken met SQL Server, mits ze ontworpen zijn voor gebruik in een data-kritische transactionele databasebeheersysteemomgeving (DBMS). Deze ontwerpfuncties moeten gegevens in de cache behouden als er een systeemfout optreedt. Het gebruik van een externe niet-onderbreekbare voeding (UPS) om dit te bereiken is over het algemeen niet voldoende, omdat foutmodi die niet gerelateerd zijn aan stroom kunnen optreden.

Cachecontrollers en opslagsubsystemen kunnen veilig zijn voor gebruik door SQL Server. De meeste nieuwe doelgerichte serverplatforms die deze bevatten, zijn veilig. Neem echter contact op met uw hardwareleverancier om er zeker van te zijn dat het opslagsubsysteem is getest en goedgekeurd voor gebruik in een omgeving voor relationeel databasebeheersysteem (RDBMS) met transacties die data-kritisch zijn.

Logboekregistratie voor write-ahead

Sql Server-instructies voor het wijzigen van gegevens genereren schrijfbewerkingen op logische pagina's. Deze stroom schrijfbewerkingen kan op twee plaatsen worden weergegeven: het logboek en de database zelf. Om prestatieredenen stelt SQL Server schrijfbewerkingen naar de database uit via zijn eigen cachebuffersysteem. Schrijfbewerkingen naar het logboek worden slechts tijdelijk uitgesteld tot COMMIT de tijd. Ze worden niet op dezelfde manier in de cache opgeslagen als gegevensschrijfbewerkingen. Omdat logboekschrijfbewerkingen voor een bepaalde pagina altijd voorafgaan aan de gegevensschrijfbewerkingen van de pagina, wordt het logboek soms ook wel een write-ahead-logboek (WAL) genoemd.

WAL-protocol (Write-Ahead Logging)

Het termprotocol is een uitstekende manier om WAL te beschrijven. De WAL die door SQL Server wordt gebruikt, staat bekend als ARIES (Algorithm for Recovery and Isolation Exploiting Semantics). Zie Versneld databaseherstel beherenvoor meer informatie.

Het is een specifieke en gedefinieerde set implementatiestappen die nodig zijn om ervoor te zorgen dat gegevens correct worden opgeslagen en uitgewisseld en kunnen worden hersteld naar een bekende status in het geval van een storing. Net zoals een netwerk een gedefinieerd protocol bevat voor het uitwisselen van gegevens op een consistente en beveiligde manier, beschrijft de WAL ook het protocol om gegevens te beveiligen. Alle versies van SQL Server openen het logboek en gegevensbestanden met behulp van de Win32-functie CreateFile . Het dwFlagsAndAttributes lid bevat de FILE_FLAG_WRITE_THROUGH optie wanneer het wordt geopend door SQL Server.

FILE_FLAG_WRITE_THROUGH

SQL Server maakt de databasebestanden met behulp van de FILE_FLAG_WRITE_THROUGH vlag. Met deze optie wordt het systeem geïnstrueerd om door een tussenliggende cache te schrijven en rechtstreeks naar de opslag te gaan. Het systeem kan nog steeds schrijfbewerkingen in de cache opslaan, maar kan ze niet lui leegmaken. Zie CreateFileA voor meer informatie.

De FILE_FLAG_WRITE_THROUGH optie zorgt ervoor dat wanneer een schrijfbewerking een geslaagde voltooiing retourneert, de gegevens correct worden opgeslagen in stabiele opslag. Dit is afgestemd op de Write Ahead Logging (WAL) protocol-specificatie om de integriteit van de gegevens te waarborgen. Veel opslagapparaten (NVMe, PCIe, SATA, ATA, SCSI en IDE) bevatten onboardcaches van 512 KB, 1 MB en groter. Opslagcaches zijn meestal afhankelijk van een condensator en niet van een oplossing met batterijsteun. Deze cachingmechanismen kunnen geen schrijfbewerkingen garanderen voor een stroomcyclus of een vergelijkbaar storingspunt. Ze garanderen alleen de voltooiing van de schrijfbewerkingen in de sector. Naarmate de opslagapparaten steeds groter worden, worden de caches groter en kunnen ze grotere hoeveelheden gegevens blootstellen tijdens een fout.

Zie voor meer informatie over FUA-ondersteuning door Linux-distributie en het effect ervan op SQL Server SQL Server on Linux: Forced Unit Access (FUA) Internals.

Transactionele integriteit en SQL Server-herstel

Transactionele integriteit is een van de fundamentele concepten van een relationeel databasesysteem. Transacties worden beschouwd als atomische werkeenheden die in hun geheel worden uitgevoerd of teruggedraaid. Het SQL Server-transactielogboek voor write-ahead is een essentieel onderdeel bij het implementeren van transactionele integriteit.

Elk relationeel databasesysteem moet ook omgaan met een concept dat nauw samenhangt met transactionele integriteit. Dit is herstel na niet-geplande systeemfouten. Verschillende niet-ideale, echte effecten kunnen deze fout veroorzaken. Op veel databasebeheersystemen kan een systeemfout leiden tot een langdurig, door mensen geleid handmatig herstelproces.

Het SQL Server-herstelmechanisme is daarentegen automatisch en werkt zonder menselijke tussenkomst. SQL Server ondersteunt bijvoorbeeld een bedrijfskritieke productietoepassing en ondervindt een systeemfout vanwege een tijdelijke stroomschommeling. Na het herstellen van stroom wordt de serverhardware opnieuw opgestart, worden netwerksoftware geladen en geïnitialiseerd en wordt SQL Server opnieuw opgestart. Wanneer SQL Server initialiseert, wordt het herstelproces automatisch uitgevoerd op basis van gegevens in het transactielogboek. Dit hele proces vindt plaats zonder menselijke tussenkomst. Wanneer de clientwerkstations opnieuw worden opgestart, vinden gebruikers al hun gegevens aanwezig tot de laatste transactie die ze hebben ingevoerd.

Transactionele integriteit en automatisch herstel in SQL Server vormen een krachtige functie voor het besparen van tijd en arbeid. Als een controller voor schrijfcaching niet goed is ontworpen voor gebruik in een transactieverwerkende, datakritieke DBMS-omgeving, kan dit de mogelijkheid van SQL Server om te herstellen aantasten, waardoor de database kan worden beschadigd. Dit kan gebeuren als de controller sql Server-transactielogboek schrijft en buffert in een hardwarecache op het controllerbord, maar deze geschreven pagina's niet bewaart tijdens een systeemfout.

Cache- en opslagapparaatcontrollers schrijven

De meeste cachecontrollers voor opslagapparaten voeren schrijfcaching uit. De functie voor het opslaan in de schrijfcache kan niet altijd worden uitgeschakeld.

Zelfs als de server gebruikmaakt van een UPS, garandeert dit niet de beveiliging van de schrijfbewerkingen in de cache. Er kunnen veel soorten systeemfouten optreden die niet door een UPS worden aangepakt. Een geheugenpariteitsfout, een besturingssysteemtrap (OS) of een hardwarestoring waardoor het systeem opnieuw wordt ingesteld, kan bijvoorbeeld een onbeheerde systeemonderbreking veroorzaken. Een geheugenfout in de hardwareschrijfcache kan ook leiden tot verlies van essentiële logboekgegevens.

Een ander mogelijk probleem met betrekking tot een controller voor write-caching kan optreden bij het afsluiten van het systeem. Het is niet ongebruikelijk dat het besturingssysteem wordt gecyclusd of het systeem opnieuw wordt opgestart tijdens configuratiewijzigingen. Zelfs als een zorgvuldige operator de aanbeveling van het besturingssysteem volgt om te wachten totdat alle opslagactiviteit stopt voordat het systeem opnieuw wordt opgestart, kunnen schrijfbewerkingen in de cache nog steeds aanwezig zijn in de controller. Wanneer de Ctrl++AltDel toetsencombinatie wordt ingedrukt of een knop voor het opnieuw instellen van hardware wordt ingedrukt, kunnen schrijfbewerkingen in de cache worden verwijderd, waardoor de database mogelijk wordt beschadigd.

Het is mogelijk om een hardwareschrijfcache te ontwerpen, waarbij rekening wordt gehouden met alle mogelijke oorzaken van het verwijderen van vuile cachegegevens, die dus veilig zijn voor gebruik door een databaseserver. Sommige van deze ontwerpfuncties zijn het onderscheppen van het RST-bussignaal om een ​​onbeheerde reset van de cachecontroller te voorkomen, batterij-back-up aan boord, en gespiegelde of foutcontrole en correctie (ECC) van het geheugen. Neem contact op met uw hardwareleverancier om ervoor te zorgen dat de schrijfcache deze en eventuele andere functies bevat die nodig zijn om gegevensverlies te voorkomen.

Opslagcaches gebruiken met SQL Server

Een databasesysteem is in de eerste plaats verantwoordelijk voor de nauwkeurige opslag en het ophalen van gegevens, zelfs in geval van onverwachte systeemfouten.

Het systeem moet de atomiciteit en duurzaamheid van transacties garanderen, terwijl rekening wordt houden met de huidige uitvoering, meerdere transacties en verschillende storingspunten. Dit wordt vaak de acid-eigenschappen (atomiciteit, consistentie, isolatie en duurzaamheid) genoemd.

In deze sectie worden de gevolgen van opslagcaches besproken. Het is raadzaam om de volgende artikelen in de Microsoft Knowledge Base te lezen voor meer informatie over het opslaan in cache en alternatieve foutmodusdiscussies:

De volgende documenten worden ook aanbevolen:

Deze twee documenten zijn van toepassing op alle momenteel ondersteunde versies van SQL Server.

Cacheoplossingen met batterijsteun

Verbeterde cachecontrollersystemen schakelen cache op schijf uit en bieden een functionele oplossing voor caching met batterij. Deze caches kunnen de gegevens enkele dagen in de cache onderhouden en zelfs toestaan dat de cachekaart op een tweede computer wordt geplaatst. Wanneer de stroom correct wordt hersteld, worden de ongeschreven gegevens volledig leeggemaakt voordat verdere gegevenstoegang is toegestaan. Veel daarvan maken het mogelijk om het percentage lees- en schrijfcache tot stand te brengen voor optimale prestaties. Sommige bevatten grote geheugenopslaggebieden. Sommige hardwareleveranciers bieden geavanceerde schijfcachesystemen met meerdere gigabytes cache. Deze kunnen de databaseprestaties aanzienlijk verbeteren. Het gebruik van cachingoplossingen met batterijsteun biedt duurzaamheid en consistentie van gegevens die sql Server verwacht.

Implementaties van het opslagsubsysteem

Er zijn veel soorten subsysteem-implementaties. RAID (redundante matrix van onafhankelijke schijven) en SAN (storage area network) zijn twee voorbeelden van deze typen subsysteem-implementaties. Deze systemen worden doorgaans gebouwd met SCSI-gebaseerde schijven. Er zijn verschillende redenen hiervoor. In de volgende sectie worden algemene overwegingen voor opslag op hoog niveau beschreven.

SCSI, SAS en NVMe

SCSI-, SAS- en NVMe-opslagapparaten:

  • Worden doorgaans vervaardigd voor intensief gebruik.
  • Zijn doorgaans gericht op implementaties met meerdere gebruikers, op servers gebaseerde implementaties.
  • Over het algemeen hebben ze betere tijdsduren tot falen dan andere implementaties.
  • Bevat geavanceerde heuristieken om aanstaande fouten te voorspellen.

Niet-SCSI

Andere typen schijven, zoals IDE, ATA en SATA:

  • Worden doorgaans vervaardigd voor licht en gemiddeld gebruik.
  • Zijn doorgaans gericht op toepassingen op basis van één gebruiker.

Niet-SCSI- en desktopcontrollers vereisen meer cpu-bandbreedte (main processor) en worden vaak beperkt door één actieve opdracht. Als een niet-SCSI-station bijvoorbeeld een defect blok aanpast, moeten de hostopdrachten wachten. De ATA-bus biedt een ander voorbeeld: de ATA-bus ondersteunt twee apparaten, maar slechts één opdracht kan actief zijn. Hierdoor blijft één station inactief terwijl de andere station de opdracht verwerkt. RAID-systemen die zijn gebouwd op desktoptechnologieën kunnen allemaal deze symptomen ervaren en sterk worden beïnvloed door de langzaamste reactie. Tenzij deze systemen geavanceerde ontwerpen gebruiken, zijn hun prestaties niet zo efficiënt als de prestaties van op SCSI gebaseerde systemen.

Overwegingen voor opslag

Er zijn situaties waarin een desktop-gebaseerde schijf of opslagsysteem een geschikte oplossing tegen lage kosten is. Als u bijvoorbeeld een alleen-lezen database instelt voor rapportage, moet u niet veel van de prestatiefactoren van een OLTP-database tegenkomen wanneer schijfcaching is uitgeschakeld.

De grootte van opslagapparaten blijft toenemen. Lage kosten, hoge capaciteitsstations kunnen aantrekkelijk zijn. Maar wanneer u de schijf configureert voor SQL Server en de responstijdbehoeften van uw bedrijf, moet u zorgvuldig rekening houden met de volgende problemen:

  • Ontwerp van toegangspad
  • De vereiste om de cache op schijf uit te schakelen

Mechanische harde schijven

Mechanische schijven maken gebruik van draaiende magnetische platters voor het opslaan van gegevens. Ze zijn beschikbaar in verschillende capaciteiten en vormfactoren, zoals IDE, SATA, SCSI en Serial Attached SCSI (SAS). Sommige SATA-stations bevatten constructies voor het voorspellen van fouten. SCSI-schijven zijn ontworpen voor zwaardere gebruikscycli en verminderde uitvalpercentages.

De schijfcache moet worden uitgeschakeld om de schijf met SQL Server te kunnen gebruiken. De schijfcache is standaard ingeschakeld. Gebruik in Windows Server het tabblad Schijfeigenschappenhardware> om toegang te krijgen tot het tabbladEigenschappenbeleid> om de instelling van de schijfcache te beheren.

Opmerking

Sommige stations respecteren deze instelling niet. Voor deze schijven is een hulpprogramma van de specifieke fabrikant vereist om de cache uit te schakelen.

IDE- en ATA-systemen kunnen hostopdrachten uitstellen tijdens activiteiten zoals het aanpassen van defecte blokken. Dit kan leiden tot perioden van vastgelopen I/O-activiteit.

SAS-voordelen zijn geavanceerde wachtrijmanagement tot 256 niveaus, en wachtrijmanagement en wachtrij zonder vaste volgorde. Het SAS-backplane is ontworpen op een manier die het gebruik van zowel SAS- als SATA-stations binnen hetzelfde systeem mogelijk maakt.

Uw SQL Server-installatie is afhankelijk van de mogelijkheid van de controller om de cache op schijf uit te schakelen en een stabiele I/O-cache te bieden. Het schrijven van gegevens uit volgorde op verschillende stations is geen belemmering voor SQL Server zolang de controller de juiste stabiele mediacachingcapaciteiten biedt. De complexiteit van het controllerontwerp neemt toe met geavanceerde technieken voor gegevensbeveiliging, zoals spiegelen.

Ssd-opslag

Solid-state-opslag heeft voordelen ten opzichte van mechanische (draaiende) harde schijven, maar is vatbaar voor veel van dezelfde foutpatronen als draaiende media. Solid-state-opslag is verbonden met uw server met behulp van verschillende interfaces, waaronder NVM Express (NVMe), PCI Express (PCIe) en SATA. Behandel de solid-state media zoals u draaiende media zou behandelen en zorg ervoor dat de juiste beveiligingsmaatregelen aanwezig zijn voor stroomstoringen, zoals een batterij-ondersteunde cachecontroller.

Veelvoorkomende problemen die worden veroorzaakt door een stroomfout zijn onder andere:

  • Bitbeschadiging: gegevens vertonen willekeurige bitfouten.
  • Vliegende schrijfbewerkingen: Correct gevormde gegevens komen op de verkeerde plaats terecht.
  • Shorn schrijft: De bewerkingen worden gedeeltelijk uitgevoerd op een lager niveau dan de verwachte sectorgrootte.
  • Beschadiging van metagegevens: metagegevens in FTL zijn beschadigd.
  • Niet-reagerend apparaat: het apparaat werkt helemaal niet of werkt meestal niet.
  • Onverserialiseerdheid: de uiteindelijke opslagstatus is niet het gevolg van een serialiseerbare bewerkingsvolgorde.

512e

De meeste solid-state storage rapporteert 512 bytesectorgrootten, maar gebruik 4 KB-pagina's binnen de verwijderingsblokken van 1 MB. Met behulp van 512 byte uitgelijnde sectoren voor het SQL Server-logboekapparaat kunnen meer LEES-/wijzigings-/schrijfactiviteiten (RMW) worden gegenereerd, wat kan bijdragen aan tragere prestaties en schijf slijtage.

Aanbeveling: zorg ervoor dat de cachecontroller op de hoogte is van de juiste paginagrootte van het opslagapparaat en fysieke schrijfbewerkingen kan afstemmen op de solid-state-opslaginfrastructuur.

0xFFFFFFFF

Een nieuw geformatteerde schijf staat meestal vol met nullen. Een gewist blok van een solid-state apparaat bestaat volledig uit 1s, leidend tot een onbewerkte uitlezing van een gewist blok met uitsluitend 0xFF tekens. Het is echter ongebruikelijk dat een gebruiker een gewist blok leest tijdens normale I/O-bewerkingen.

Patroonstempel

Een techniek die we in het verleden hebben gebruikt, is het schrijven van een bekend patroon naar de hele schijf. Als we vervolgens databaseactiviteiten uitvoeren op diezelfde schijf, kunnen we onjuist gedrag detecteren (verouderde lezing / verloren schrijfbewerking / lezing van verkeerde offset / etc.) wanneer het patroon onverwacht verschijnt.

Deze techniek werkt niet goed voor solid-state storage. De verwijderings- en RMW-activiteiten voor schrijfbewerkingen vernietigen het patroon. De garbagecollectionactiviteit van solid-state opslag, slijtagevereffening, proportionele/set-aside-lijstblokken en andere optimalisaties leiden er meestal toe dat schrijfbewerkingen naar verschillende fysieke locaties worden verplaatst, in tegenstelling tot het hergebruik van sectoren bij draaiende media.

firmware

De firmware die wordt gebruikt in solid-state-opslag, is meestal complex in vergelijking met draaiende media-tegenhangers. Veel schijven gebruiken meerdere verwerkingskernen om binnenkomende aanvragen en garbage collection-activiteiten te verwerken. Zorg ervoor dat u de firmware van uw solid-state apparaat up-to-date houdt om bekende problemen te voorkomen.

Gegevensschade en slijtage-nivellering lezen

Een gebruikelijke benadering voor vuilnisophaling (GC) voor solid-state-opslag helpt herhaalde schade aan gelezen gegevens te voorkomen. Wanneer dezelfde cel herhaaldelijk wordt gelezen, kan de elektronactiviteit lekken en schade aan aangrenzende cellen veroorzaken. Solid-state Storage beveiligt de gegevens met verschillende niveaus van foutcodecorrectiecode (ECC) en andere mechanismen.

Een dergelijk mechanisme heeft betrekking op slijtagevereffening. Solid-state Storage houdt de lees- en schrijfactiviteit op het opslagapparaat bij. De vuilnisinzameling kan de knelpunten of locaties bepalen die sneller slijten dan andere locaties. De GC bepaalt bijvoorbeeld dat een blok gedurende een bepaalde periode de status Alleen-lezen heeft en moet worden verplaatst. Deze beweging is meestal naar een blok met meer slijtage, zodat het oorspronkelijke blok voor schrijven kan worden gebruikt. Dit helpt de slijtage op de schijf te verdelen, maar verplaatst alleen-lezen gegevens naar een locatie met meer slijtage en verhoogt wiskundig de faalkans, ook al is het iets.

Een ander neveneffect van slijtagevereffening kan optreden bij het gebruik van SQL Server. Stel dat u DBCC CHECKDB uitvoert en er een fout wordt gerapporteerd. Als u deze een tweede keer uitvoert, is er een kleine kans dat DBCC CHECKDB er extra of een ander foutenpatroon wordt gerapporteerd, omdat de GC-activiteit voor solid-state-opslag wijzigingen kan aanbrengen tussen de DBCC CHECKDB uitvoeringen.

Besturingssysteemfout 665 en defragmentatie

Draaiende media moeten blokken dicht bij elkaar houden om de hoofdbeweging van het station te verminderen en de prestaties te verbeteren. Solid-state-opslag beschikt niet over de fysieke kop, waardoor zoektijd wordt geëlimineerd. Veel solid-state-apparaten zijn ontworpen om parallelle bewerkingen op verschillende blokken parallel toe te staan. Dit betekent dat defragmentatie van solid-state media onnodig is. Seriële activiteiten zijn de beste I/O-patronen om I/O-doorvoer te maximaliseren op solid-state opslagapparaten.

Opmerking

Solid-state Storage profiteert van de trimfunctie , een opdracht op besturingssysteemniveau waarmee blokken worden gewist die als niet meer in gebruik worden beschouwd. Gebruik in Windows het programma Schijven optimaliseren om een wekelijks schema te plannen voor het optimaliseren van schijven.

Aanbevelingen:

  • Gebruik een geschikte controller met batterijsteun die is ontworpen om schrijfactiviteiten te optimaliseren. Dit kan de prestaties verbeteren, de slijtage van schijven en fysieke fragmentatieniveaus verminderen.

  • Overweeg het ReFS-bestandssysteem te gebruiken om de beperkingen van het NTFS-kenmerk te voorkomen.

  • Verzeker dat het groeiformaat van bestanden passend is geconfigureerd.

Zie Besturingssystemen fouten 665 en 1450 voor SQL Server-bestanden voor meer informatie over het oplossen van problemen met besturingssysteemfout 665 in verband met fragmentatie.

Compressie

Zolang de schijf de functie van stabiele opslagmedia behoudt, kan compressie de levensduur verlengen en mogelijk de prestaties positief beïnvloeden. Sommige firmware kan echter al gegevens onzichtbaar comprimeren. Vergeet niet om nieuwe opslagscenario's te testen voordat u deze implementeert in uw productieomgeving.

Samenvatting

  • Behoud de juiste procedures en processen voor back-up en herstel na noodgevallen.
  • Houd uw firmware up-to-date.
  • Luister goed naar de richtlijnen van uw hardwarefabrikanten.

Overwegingen voor cache en SQLIOSim

Als u uw gegevens volledig wilt beveiligen, moet u ervoor zorgen dat alle gegevenscache correct worden verwerkt. In veel situaties betekent dit dat u de schrijfcache van het station moet uitschakelen.

Opmerking

Zorg ervoor dat elk alternatief cachingmechanisme meerdere typen fouten correct kan verwerken.

Microsoft heeft tests uitgevoerd op verschillende SCSI- en IDE-stations met behulp van het HULPPROGRAMMA SQLIOSim . Dit hulpprogramma simuleert zware asynchrone lees-/schrijfactiviteit naar een gesimuleerd gegevensapparaat en logboekapparaat. Zie Het hulpprogramma SQLIOSim gebruiken om SQL Server-activiteit op een schijfsubsysteem te simuleren voor meer informatie en details over SQLIOSim.

Veel pc-fabrikanten bestellen de stations met de schrijfcache uitgeschakeld. Uit testen blijkt echter dat dit mogelijk niet altijd het geval is, dus u moet het altijd volledig testen. Als u vragen hebt over de cachestatus van uw opslagapparaat, neemt u contact op met de fabrikant en verkrijgt u de juiste hulpprogramma- of jumperinstellingen om schrijfcachingbewerkingen uit te schakelen.

SQL Server vereist dat systemen ondersteuning bieden voor gegarandeerde levering aan stabiele media, zoals wordt beschreven in de vereisten van het SQL Server I/O-betrouwbaarheidsprogramma. Zie de I/O-vereisten (Disk Input/Output) voor SQL Server Database Engine voor meer informatie over de invoer- en uitvoervereisten voor de SQL Server Database Engine.

Verwante inhoud