Basisprincipes van SQL Server I/O

Van toepassing op:SQL ServerAzure SQL Managed InstanceSQL Server op virtuele Azure-machines

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 stations 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 proces 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 bericht geeft momenteel niet aan welke. 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 helpen de systeembeheerder om de oorzaak van slechte SQL Server-reactietijden sneller te vinden en 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. U kunt niet uit het bericht zien welk scenario het geval is, hoewel een verloren I/O vaak leidt tot een time-out voor vergrendeling.

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.

Een onderdeel in het I/O-pad (bijvoorbeeld een stuurprogramma, controller of firmware) kan lange I/Os veroorzaken door een oude I/O-aanvraag voortdurend uit te stellen ten gunste van nieuwere aanvragen. Dit probleem kan optreden in onderling verbonden omgevingen, zoals iSCSI- en Fibre Channel-netwerken (vanwege een onjuiste configuratie of padfout). Het hulpprogramma Prestatiemeter kan dit probleem lastig te bevestigen maken omdat de meeste I/Os onmiddellijk worden onderhouden. Workloads die grote hoeveelheden sequentiële I/O uitvoeren, zoals back-up en herstel, tabelscans, sorteren, indexen maken, bulksgewijs laden en bestanden weghalen, kunnen lange I/O-aanvragen verergeren.

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 effectief zijn geschreven of niet goed zijn afgestemd op 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 beschreven over ongeveer 15 seconden I/O vaker voorkomt bij hardwareonderdelen, worden kortere I/O-vertragingen 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 geen cache gebruiken, kunnen veel langer duren op mechanische schijven vanwege de draaisnelheden van de harde schijf, de tijd die nodig is voor de mechanische beweging van de lees- en schrijfkoppen, en andere factoren die beperkingen opleggen. SQL Server-installaties zijn gericht op systemen die voorzien zijn van cachingcontrollers. 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.

Het gebruik van een opslagcontroller voor schrijven in cache (ook wel write-back caching genoemd) kan de prestaties van SQL Server verbeteren. Schrijfcachecontrollers en opslagsubsystemen zijn veilig voor SQL Server, als ze zijn ontworpen voor gebruik in een databasebeheersysteem (DBMS) voor gegevenskritieke transactionele databasebeheersystemen. Deze ontwerpfuncties moeten gegevens in de cache behouden als er een systeemfout optreedt. Het gebruik van een externe niet-onderbreekbare voeding (UPS) om deze beveiliging 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 controllers 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 datakritische transactionele relationele databasebeheersysteemomgeving (RDBMS).

Veiligheidsrichtlijnen voor cachesubsysteem

Cachingcontrollers voor write-back kunnen de prestaties verbeteren als ze voldoen aan specifieke veiligheidsvereisten:

• Neem battery-ondersteunde cache of niet-vluchtig geheugentype op, zoals NVDIMM of flash met supercondensatorondersteuning.
• Worden gecertificeerd door de leverancier voor gegevenskritieke OLTP-databaseomgevingen.
• Bescherming bieden die betrekking heeft op alle storingsomstandigheden, niet alleen op energieverlies.

Logboekregistratie voor write-ahead

Sql Server-instructies voor het wijzigen van gegevens genereren schrijfbewerkingen op logische pagina's. U kunt zich deze stroom van schrijfbewerkingen voorstellen als gaande naar twee plaatsen: het logboek en de database zelf. Om prestatieredenen worden schrijfbewerkingen naar de database uitgesteld via een eigen cachebuffersysteem. Het systeem stelt alleen tijdelijk schrijfbewerkingen naar de log uit tot COMMIT tijdstip. Deze schrijfbewerkingen worden niet op dezelfde manier in de cache opgeslagen als schrijfbewerkingen van gegevens. Omdat logboeken voor een bepaalde pagina altijd worden geschreven voordat de gegevens van de pagina worden weggeschreven, wordt het logboek soms aangeduid als een write-ahead-logboek (WAL).

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 schrijfbewerkingen nog steeds in de cache opslaan, maar kan ze niet met vertraging legen. 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. Deze functie is afgestemd op de specificatie van het PROTOCOL Write-Ahead Logging (WAL) om de gegevensintegriteit 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 schrijfacties garanderen bij stroomuitval 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 zijn atomische werkeenheden die volledig worden toegepast of volledig worden 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 herstel 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 clientwerkstations opnieuw worden opgestart, vinden gebruikers al hun gegevens die aanwezig zijn, tot aan 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 schrijfcachecontroller niet goed is ontworpen voor gebruik in een gegevenskritieke transactionele DBMS-omgeving, kan dit de herstelmogelijkheid van SQL Server in gevaar brengen, wat kan leiden tot mogelijke corruptie van de database. Dit probleem kan optreden als de controller SQL Server-transactielogboeken onderschept en deze buffert in een hardwarecache op de controllerkaart, maar de geschreven pagina's niet bewaart in geval van een systeemstoring.

Risico's van schijf-cache voor schrijfbewerkingen

De meeste cachecontrollers voor opslagapparaten voeren schrijfcaching uit. U kunt de functie voor het schrijven naar de cache niet altijd uitschakelen.

Zelfs als de server gebruikmaakt van een UPS, garandeert het apparaat 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+Alt+Del 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 die rekening houdt met alle mogelijke oorzaken van het verwijderen van vuile cachegegevens, waardoor het veilig is voor gebruik door een databaseserver. Sommige van deze ontwerpfuncties omvatten het onderscheppen van het RST-bussignaal om een ongecontroleerde reset van de cachecontroller te voorkomen, een ingebouwde batterijbackup, en gespiegelde of ECC-geheugen voor foutcontrole en correctie. 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. Deze eigenschap wordt vaak de ACID-eigenschappen (Atomiciteit, Consistentie, Isolatie en Duurzaamheid) genoemd.

In deze sectie worden de gevolgen van opslagcaches besproken. Zie de volgende artikelen voor meer informatie over het opslaan in cache en alternatieve foutmodusdiscussies:

• 86903 SQL Server en caching van schijfcontrollers
• Beschrijving van algoritmen voor logboekregistratie en gegevensopslag waarmee de betrouwbaarheid van gegevens in SQL Server wordt uitgebreid

Bekijk ook de volgende gearchiveerde inhoud:

• Basisbeginselen van SQL Server 2000 I/O
• Basisbeginselen van SQL Server I/O, hoofdstuk 2

De concepten in deze twee artikelen blijven breed van toepassing op de huidige 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 van deze systemen bieden u de mogelijkheid om een percentage lees- en schrijfcache in te stellen voor optimale prestaties. Sommige systemen bevatten grote geheugenopslaggebieden. Sommige hardwareleveranciers bieden geavanceerde schijfcachesystemen met meerdere gigabytes cache. Deze systemen kunnen de databaseprestaties aanzienlijk verbeteren. Cacheoplossingen met batterijsteun bieden de duurzaamheid en consistentie van gegevens die sql Server verwacht.

Implementaties van het opslagsubsysteem

Opslagsubsystemen bestaan in veel typen. Twee veelvoorkomende voorbeelden zijn RAID (redundante matrix van onafhankelijke schijven) en SAN (Storage Area Network). Deze systemen maken doorgaans gebruik van SCSI-gebaseerde stations. In de volgende sectie worden overwegingen voor opslag op hoog niveau beschreven.

SCSI, SAS en NVMe

SCSI-, SAS- en NVMe-opslagapparaten:

• Zijn meestal ontworpen voor intensief gebruik.
• Zijn doorgaans gericht op implementaties met meerdere gebruikers, op servers gebaseerde implementaties.
• Normaal gesproken hebben we een betere gemiddelde tijd voor storingsfrequenties dan andere implementaties.
• Bevat geavanceerde heuristieken om aanstaande fouten te voorspellen.

Niet-SCSI

Andere typen schijven, zoals IDE, ATA en SATA:

• Zijn doorgaans ontworpen voor licht tot gemiddeld gebruik.
• Zijn doorgaans gericht op toepassingen met éé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. Deze beperking laat één station inactief terwijl de andere station de opdracht uitvoert. 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

Een bureaublad-gebaseerde schijf of aandrijving kan in sommige situaties een goedkope oplossing zijn. Als u bijvoorbeeld een alleen-lezen database instelt voor rapportage, ondervindt u niet veel van de prestatiefactoren van een OLTP-database wanneer schijfcaching is uitgeschakeld.

De grootte van opslagapparaten blijft toenemen. Voordelige schijven met hoge capaciteit kunnen aantrekkelijk zijn. Houd echter rekening met de volgende overwegingen wanneer u de schijf configureert voor SQL Server en de reactietijd van uw bedrijf:

• 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.

IDE- en ATA-systemen kunnen hostopdrachten uitstellen wanneer ze activiteiten uitvoeren, zoals slechte blokaanpassing, wat leidt tot perioden van vastgelopen I/O-activiteit.

SAS-voordelen omvatten geavanceerde wachtrijfuncties met tot 256 niveaus, evenals 'head-of-queue' en 'out-of-order' wachtrijverwerking. 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.

Solid-state storage

Solid-state storage heeft voordelen ten opzichte van mechanische (draaiende) harde schijven, maar het is gevoelig voor veel van dezelfde foutpatronen als het draaien van media. U kunt solid-state storage verbinden 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: records geven willekeurige bitfouten weer.
• 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 de flash translation layer (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-opslagapparaten rapporteren 512 bytesectorgrootten, maar gebruiken 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 in het verleden werd gebruikt, is het schrijven van een bekend patroon over de hele schijf. Wanneer de databaseactiviteit vervolgens wordt uitgevoerd op hetzelfde station, kan onjuist gedrag (verouderde lees-, verloren schrijf- of leesbewerking van onjuiste offset) worden gedetecteerd wanneer het patroon onverwacht optreedt.

Deze techniek werkt niet goed voor solid-state storage. De verwijderings- en RMW-activiteiten bij schrijfbewerkingen vernietigen het patroon. De garbagecollectieactiviteit, slijtagevereffening, proportionele/set-aside-lijstblokken en andere optimalisaties zorgen er meestal voor dat schrijfbewerkingen verschillende fysieke locaties krijgen, in tegenstelling tot het hergebruik van sectoren in 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. Bijvoorbeeld, de GC bepaalt dat een blok in een Alleen-lezen status verkeert en moet worden verplaatst. Deze beweging is meestal naar een blok met meer slijtage, zodat het oorspronkelijke blok voor schrijven kan worden gebruikt. Dit proces helpt bij het verdelen van de slijtage van het opslagmedium, maar het verplaatst gegevens die alleen-lezen zijn naar een locatie met meer slijtage en verhoogt wiskundig de kans op fouten, ook al is het maar een beetje.

Een ander neveneffect van slijtage-uitvlakking kan zich voordoen bij 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 heeft geen fysiek hoofd, waardoor zoektijd wordt geëlimineerd. Veel solid-state-apparaten zijn ontworpen om parallelle bewerkingen op verschillende blokken toe te staan. Defragmentatie van solid-state media is daarom overbodig. Seriële activiteiten zijn de beste I/O-patronen om I/O-doorvoer te maximaliseren op solid-state opslagapparaten.

Aanbevelingen:

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

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

• Zorg ervoor dat de instellingen voor bestandsgroei juist zijn.

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 intentie van stabiliteit behoudt, kan compressie de levensduur van de schijf verlengen en de prestaties positief beïnvloeden. Sommige firmware kan echter al gegevens onzichtbaar comprimeren. Vergeet niet om nieuwe opslagscenario's te testen voordat u ze 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 de hardwarefabrikant.

Configuratie van schijfcache

Om een schijf met SQL Server te gebruiken, schakelt u schijfcaching uit. De schijfcache is standaard ingeschakeld. Gebruik in Windows Server het tabbladHardwarebeleid>voor schijfeigenschappen> om schrijfcaching op besturingssysteemniveau uit te schakelen.

Vertrouw niet alleen op instellingen op besturingssysteemniveau. Sommige schijven negeren Windows-instellingen en vereisen hulpprogramma's of firmware-aanpassingen van de fabrikant om de schrijfcache uit te schakelen. Bevestig via leveranciershulpprogramma's dat schrijfcaching daadwerkelijk is uitgeschakeld.

Overwegingen voor cache en SQLIOSim

Valideer uw I/O-subsysteem met behulp van SQLIOSim voordat u naar de productie gaat om de garanties voor transactionele duurzaamheid te bevestigen. Dit hulpprogramma simuleert zware asynchrone lees- en schrijfactiviteit naar een gesimuleerd gegevensapparaat en logboekapparaat. Zie Het hulpprogramma SQLIOSim gebruiken voor het simuleren van SQL Server-activiteit op een schijfsubsysteem voor meer informatie.

Veel pc-fabrikanten bestellen de stations met de schrijfcache uitgeschakeld. Uit het testen blijkt echter dat deze voorwaarde mogelijk niet altijd het geval is, dus u moet deze altijd volledig testen. Als u vragen hebt over de cachestatus van uw opslagapparaat, neemt u contact op met de fabrikant en verkrijgt u het juiste hulpprogramma om schrijfcachingbewerkingen uit te schakelen. Op oudere opslagmedia kunt u ook jumper instellingen nodig hebben.

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.

Onjuiste risico's van schrijfcaching

Wanneer u schrijfcaching inschakelt zonder de juiste beveiliging, bevestigen sommige opslagsubsystemen schrijfbewerkingen als voltooid voordat gegevens veilig naar duurzame media worden geschreven. Als er een stroomverlies of systeemstoring optreedt, kan deze voorwaarde leiden tot:

• Gegevensverlies, waarbij vastgelegde transacties nooit worden bewaard.
• Databasebeschadiging vanwege beschadigde garanties voor schrijfvolgorde.

Verwante inhoud

• Architectuurhandleiding voor pagina's en extenties
• Geheugenbeheer Architectuurhandleiding
• Opslag: Best practices voor prestaties voor SQL Server op Azure-VM's
• SQL Server op Linux: Geforceerde eenheidstoegang (FUA) Internals
• Basisbeginselen van SQL Server I/O, hoofdstuk 2