Grunderna i SQL Server I/O

Gäller för:SQL ServerAzure SQL Managed InstanceSQL Server på virtuella Azure-datorer

Det primära syftet med en SQL Server-databas är att lagra och hämta data, så intensiv diskinmatning/utdata (I/O) är en grundläggande egenskap hos databasmotorn. Eftersom disk-I/O-åtgärder kan förbruka många resurser och ta relativt lång tid att slutföra fokuserar SQL Server på att göra I/O mycket effektivt.

Lagringsundersystem för SQL Server tillhandahålls i flera formfaktorer, inklusive mekaniska enheter och solid state-lagring. Den här artikeln innehåller information om hur du använder principer för enhetscache för att förbättra I/O-prestanda hos databasmotorn.

SQL Server kräver att systemen stöder garanterad leverans till stabila medier enligt kraven för SQL Server I/O-tillförlitlighetsprogrammet. Mer information om indata- och utdatakraven för SQL Server Database Engine finns i KRAV för SQL Server Database Engine Disk Input/Output (I/O).

Disk I/O

Bufferthanteraren utför endast läsningar och skrivningar till databasen. Andra fil- och databasåtgärder som att öppna, stänga, utöka och krympa utförs av databashanteraren och filhanterarens komponenter.

Bufferthanterarens I/O-åtgärder för diskar har följande egenskaper:

• I/O utförs vanligtvis asynkront, vilket gör att den anropande tråden kan fortsätta bearbetningen medan I/O-åtgärden sker i bakgrunden. Under vissa omständigheter (till exempel feljusterad logg-I/O) kan synkrona I/Os inträffa.

• Alla I/Os utfärdas i anropstrådarna om inte I/O-alternativet för tillhörighet används. Alternativet tillhörighets-I/O-mask binder SQL Server-diskens I/O till en angiven delmängd av processorer. I avancerade OLTP-miljöer (Online TransactionAl Processing) i SQL Server kan det här tillägget förbättra prestandan för SQL Server-trådar som utfärdar I/Os.

• I/O för flera sidor utförs med punktinsamlings-I/O, vilket gör att data kan överföras till eller från icke-sammanhängande minnesområden. Det innebär att SQL Server snabbt kan fylla eller tömma buffertcachen samtidigt som flera fysiska I/O-begäranden undviks.

Långa I/O-begäranden

Bufferthanteraren rapporterar om alla I/O-begäranden som är utestående i minst 15 sekunder. Den här processen hjälper systemadministratören att skilja mellan SQL Server-problem och I/O-undersystemproblem. Felmeddelande MSSQLSERVER_833 rapporteras och visas i SQL Server-felloggen på följande sätt:

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.

En lång I/O kan vara antingen en läsning eller en skrivning. meddelandet anger för närvarande inte vilket. Långa I/O-meddelanden är varningar, inte fel. De tyder inte på problem med SQL Server utan med det underliggande I/O-systemet. Meddelandena hjälper systemadministratören att snabbare hitta orsaken till dåliga svarstider i SQL Server och att urskilja problem som ligger utanför SQL Servers kontroll. Därför kräver de ingen åtgärd, men systemadministratören bör undersöka varför I/O-begäran tog så lång tid och om tiden är berättigad.

Orsaker till långa I/O-begäranden

Ett långt I/O-meddelande kan indikera att en I/O blockeras permanent och aldrig slutförs (kallas förlorad I/O), eller bara att den inte är klar än. Du kan inte se i meddelandet vilket scenario som är fallet, även om ett förlorat I/O ofta leder till en tidsgräns för spärren.

Långa I/Os anger ofta en SQL Server-arbetsbelastning som är för intensiv för diskundersystemet. Ett otillräckligt diskundersystem kan anges när:

• Flera långa I/O-meddelanden visas i felloggen under en tung SQL Server-arbetsbelastning.
• Prestandaövervakarens räknare visar långa diskfördröjningar, långa diskköer eller ingen inaktiv disktid.

En komponent i I/O-sökvägen (till exempel en drivrutin, styrenhet eller inbyggd programvara) kan orsaka långa I/Os genom att kontinuerligt skjuta upp servicen av en gammal I/O-begäran, till förmån för service av nyare begäranden. Det här problemet kan uppstå i sammankopplade miljöer, till exempel iSCSI - och Fibre Channel-nätverk (antingen på grund av felkonfiguration eller fel i sökvägen). Verktyget Prestandaövervakaren kan göra det här problemet svårt att bekräfta eftersom de flesta in- och utmatningar hanteras snabbt. Arbetsbelastningar som utför stora mängder sekventiell I/O, till exempel säkerhetskopiering och återställning, tabellgenomsökningar, sortering, skapande av index, massinläsningar och nollställning av filer, kan förvärra långa I/O-begäranden.

Isolerade långa I/Os som inte verkar relaterade till något av de tidigare villkoren kan orsakas av ett maskinvaru- eller drivrutinsproblem. Systemhändelseloggen kan innehålla en relaterad händelse som hjälper till att diagnostisera problemet.

I/O-prestandaproblem som orsakas av ineffektiva frågor eller filterdrivrutiner

Långsam I/O kan orsakas av frågor som inte skrivs effektivt eller justeras korrekt med index och statistik. En annan vanlig faktor i I/O-svarstiden är förekomsten av antivirusprogram eller andra säkerhetsprogram som söker igenom databasfiler. Den här genomsökningsprogramvaran kan utökas till nätverksskiktet, vilket lägger till nätverksfördröjning, vilket i sin tur indirekt påverkar databasfördröjningen. Även om scenariot som beskrivs om 15 sekunders I/O är vanligare med maskinvarukomponenter, observeras kortare I/O-fördröjningar oftare med ooptimerade frågor eller felkonfigurerade antivirusprogram.

Detaljerad information om hur du åtgärdar dessa problem finns i Felsöka långsamma SQL Server-prestanda som orsakas av I/O-problem.

Information om hur du konfigurerar antivirusskydd på SQL Server finns i Konfigurera antivirusprogram så att det fungerar med SQL Server.

Skriva cachelagring i lagringsstyrenheter

I/O-överföringar som inte använder en cache kan ta mycket längre tid på mekaniska enheter på grund av hårddiskspinnhastigheter, den mekaniska tid som krävs för att flytta enhetshuvudena och andra begränsande faktorer. SQL Server-installationer riktar sig mot system som tillhandahåller cache-enheter. Dessa styrenheter inaktiverar diskcacheminnen och tillhandahåller stabila mediecacheminnen för att uppfylla SQL Server I/O-kraven. De undviker prestandaproblem som rör lagringssökning och skrivtider med hjälp av de olika optimeringarna av cachelagringskontrollanten.

Användning av en skrivcachelagringskontroller (kallas även cachelagring med tillbakaskrivning) kan förbättra SQL Server-prestanda. Skrivcachekontrollanter och lagringsundersystem är säkra för SQL Server, om de är utformade för användning i en data-kritisk miljö för databashanteringssystem (DBMS). Dessa designfunktioner måste bevara cachelagrade data om ett systemfel inträffar. Att använda en extern avbrottsfri strömförsörjning (UPS) för att uppnå detta skydd är i allmänhet inte tillräckligt, eftersom fellägen som inte är relaterade till ström kan inträffa.

Cachelagringsstyrenheter och lagringsundersystem kan vara säkra för användning av SQL Server. De flesta nya specialbyggda serverplattformar som innehåller dessa styrenheter är säkra. Du bör dock kontrollera med maskinvaruleverantören att lagringsundersystemet har testats och godkänts för användning i en rdbMS-miljö (datakritiskt transaktionellt relationsdatabashanteringssystem).

Säkerhetsriktlinjer för cacheundersystem

Cachekontrollanter för tillbakaskrivning kan förbättra prestanda om de uppfyller specifika säkerhetskrav:

• Inkludera batteribaserad cache eller icke-flyktigt minne, till exempel NVDIMM eller superkondensatorbaserad blixt.
• Certifieras av leverantören för datakritiska OLTP-databasmiljöer.
• Ge skydd som omfattar alla feltillstånd, inte bara strömförlust.

Loggning före skrivning

SQL Server-datamodifieringsinstruktioner genererar logiska sidskrivningar. Du kan föreställa dig att den här skrivströmmen går till två platser: loggen och själva databasen. Av prestandaskäl fördröjer SQL Server skrivningar till databasen genom sitt egna cachebuffertsystem. Systemet skjuter bara tillfälligt upp skrivningar till loggen tills COMMIT tiden. Den lagrar inte dessa skrivningar i cache på samma sätt som data-skrivningar. Eftersom loggskrivningar för en viss sida alltid kommer före sidans dataskrivningar kallas loggen ibland för en logg för framåtskrivning (WAL).

WAL-protokoll (loggning före skrivning)

Termprotokollet är ett utmärkt sätt att beskriva WAL. Den WAL som brukas av SQL Server kallas ARIES (Algorithm for Recovery and Isolation Exploiting Semantics). Mer information finns i Hantera accelererad databasåterställning.

Det är en specifik och definierad uppsättning implementeringssteg som krävs för att säkerställa att data lagras och utbyts korrekt och kan återställas till ett känt tillstånd i händelse av ett fel. Precis som ett nätverk innehåller ett definierat protokoll för att utbyta data på ett konsekvent och skyddat sätt, så beskriver WAL även protokollet för att skydda data. Alla versioner av SQL Server öppnar logg- och datafilerna med funktionen Win32 CreateFile . dwFlagsAndAttributes-medlemmen inkluderar FILE_FLAG_WRITE_THROUGH-alternativet när det öppnas av SQL Server.

FILE_FLAG_WRITE_THROUGH

SQL Server skapar sina databasfiler med hjälp av FILE_FLAG_WRITE_THROUGH flaggan. Det här alternativet instruerar systemet att skriva via en mellanliggande cache och gå direkt till lagringen. Systemet kan fortfarande cacha skrivåtgärder, men det kan inte fördröjt rensa dem. Mer information finns i CreateFileA.

Alternativet FILE_FLAG_WRITE_THROUGH säkerställer att när en skrivåtgärd returnerar slutförande lagras data korrekt i stabil lagring. Den här funktionen överensstämmer med protokollspecifikationen Write-Ahead loggning (WAL) för att säkerställa dataintegriteten. Många lagringsenheter (NVMe, PCIe, SATA, ATA, SCSI och IDE-baserade) innehåller inbyggda cacheminnen på 512 KB, 1 MB och större. Lagringscacheminnen förlitar sig vanligtvis på en kondensator och inte på en batteribaserad lösning. Dessa cachelagringsmekanismer kan inte garantera skrivningar över en effektcykel eller liknande felpunkt. De garanterar bara att sektorns skrivåtgärder slutförs. När lagringsenheterna fortsätter att växa i storlek blir cacheminnena större och de kan exponera större mängder data under ett fel.

Mer information om FUA-stöd för Linux-distribution och dess effekt på SQL Server finns i SQL Server On Linux: Forced Unit Access (FUA) Internals.

Transaktionsintegritet och SQL Server-återställning

Transaktionsintegritet är ett av de grundläggande begreppen i ett relationsdatabassystem. Transaktioner är atomära enheter av arbete som antingen helt tillämpas eller helt återställs. SQL Server-transaktionsloggen för skrivning framåt är en viktig komponent i implementeringen av transaktionsintegriteten.

Alla relationsdatabassystem måste också hantera ett begrepp som är nära relaterat till transaktionsintegritet, vilket är återställning från oplanerade systemfel. Flera icke-idealiska, verkliga effekter kan orsaka detta fel. På många databashanteringssystem kan systemfel resultera i en lång manuell återställningsprocess som riktas till människor.

Däremot är SQL Server-återställningsmekanismen automatisk och fungerar utan mänsklig inblandning. SQL Server kan till exempel stödja ett verksamhetskritiskt produktionsprogram och uppleva ett systemfel på grund av en tillfällig strömfluktuation. När strömmen återställs startas servermaskinvaran om, nätverksprogramvaran läses in och initieras och SQL Server startas om. När SQL Server initieras körs återställningsprocessen automatiskt baserat på data i transaktionsloggen. Hela processen sker utan mänsklig inblandning. När klientarbetsstationer startas om hittar användarna alla sina data, upp till den senaste transaktionen de angav.

Transaktionsintegritet och automatisk återställning i SQL Server utgör en kraftfull tids- och arbetsbesparingsfunktion. Om en skrivcachekontroller inte är korrekt utformad för användning i en datakritisk transaktionsmiljö kan det äventyra SQL Servers förmåga att återställa, vilket kan leda till skada på databasen. Det här problemet kan inträffa om kontrollanten fångar upp skrivningar av SQL Server-transaktionsloggar och buffrar dem i en maskinvarucachen på styrenhetskortet, men inte bevarar dessa skrivna sidor under ett systemfel.

Risker med cachelagring på disk

De flesta cachelagringsstyrenheter för lagringsenheter utför skrivcachelagring. Du kan inte alltid inaktivera funktionen för skrivcachelagring.

Även om servern använder en UPS garanterar enheten inte säkerheten för cachelagrade skrivningar. Många typer av systemfel kan inträffa som en UPS inte hanterar. Till exempel kan ett minnesparitetsfel, en operativsystemsfälla (OS) eller ett maskinvarufel som orsakar en systemåterställning orsaka ett okontrollerat systemavbrott. Ett minnesfel i maskinvaruskrivningscacheminnet kan också leda till förlust av viktig logginformation.

Ett annat möjligt problem med en skrivcache-kontroller kan uppstå vid systemavstängning. Det är inte ovanligt att växla operativsystemet eller starta om systemet under konfigurationsändringar. Även om en försiktig operatör följer operativsystemets rekommendation att vänta tills all lagringsaktivitet upphör innan systemet startas om, kan cachelagrade skrivningar fortfarande finnas på kontrollanten. När tangentkombinationen Ctrl+Alt+Del trycks in eller en maskinvaruåterställningsknapp trycks in kan cachelagrade skrivningar ignoreras, vilket kan skada databasen.

Det är möjligt att utforma en hårdvarubaserad skrivarcache som tar hänsyn till alla möjliga orsaker till att ignorera smutsiga cachedata, vilket gör den säker att använda för en databasserver. Några av dessa designfunktioner inkluderar att fånga upp RST-busssignalen (återställning) för att undvika okontrollerad återställning av cachelagringsstyrenheten, inbyggd batterisäkerhetskopia och speglat minne eller felkontroll och korrigering (ECC). Kontakta maskinvaruleverantören för att se till att skrivcachen innehåller dessa och andra funktioner som krävs för att undvika dataförlust.

Använda lagringscacheminnen med SQL Server

Ett databassystem ansvarar först och främst för korrekt lagring och hämtning av data, även i händelse av oväntade systemfel.

systemet måste garantera transaktionernas atomicitet och beständighet, samtidigt som det tar hänsyn till aktuell körning, flera transaktioner och olika felpunkter. Den här egenskapen kallas ofta ACID-egenskaperna (Atomicitet, Konsistens, Isolering och Beständighet).

Det här avsnittet behandlar konsekvenserna av lagringscache. Mer information om diskussioner om cachelagring och alternativt felläge finns i följande artiklar:

• 86903 SQL Server och cachelagring av diskkontrollanter
• Beskrivning av loggnings- och datalagringsalgoritmer som utökar datatillförlitligheten i SQL Server

Granska även följande arkiverade innehåll:

• Grunderna för SQL Server 2000 I/O
• Sql Server I/O Basics Kapitel 2

Begreppen i dessa två artiklar är fortfarande allmänt tillämpliga på aktuella versioner av SQL Server.

Lösningar för batteribaserad cachelagring

Förbättrade system för cachelagringsstyrenhet inaktiverar cachelagring på disken och tillhandahåller en funktionell lösning för batteribaserad cachelagring. Dessa cacheminnen kan underhålla data i cacheminnet i flera dagar och till och med tillåta att cachelagringskortet placeras på en andra dator. När strömmen återställs korrekt, rensas den oskrivna datan helt innan ytterligare dataåtkomst tillåts. Med många av dessa system kan du upprätta en procentandel läs- och skrivcache för optimala prestanda. Vissa system innehåller stora minneslagringsområden. Vissa maskinvaruleverantörer tillhandahåller avancerade cachelagringssystem för batteridrivna enheter med flera gigabyte cacheminne. Dessa system kan avsevärt förbättra databasprestanda. Batteridrivna cachelagringslösningar ger den hållbarhet och stabilitet för data som SQL Server förväntar sig.

Implementeringar av lagringsundersystem

Lagringsundersystem finns i många typer. Två vanliga exempel är RAID (redundant matris med oberoende diskar) och SAN (lagringsområdesnätverk). Dessa system använder vanligtvis SCSI-baserade enheter. I följande avsnitt beskrivs lagringsöverväganden på hög nivå.

SCSI, SAS och NVMe

SCSI-, SAS- och NVMe-lagringsenheter:

• Är vanligtvis utformade för tung användning.
• Är vanligtvis inriktade på serverbaserade implementeringar med flera användare.
• Normalt har bättre genomsnittlig tid till felfrekvenser än andra implementeringar.
• Innehåller avancerade heuristiker för att förutsäga överhängande fel.

Icke-SCSI

Andra enhetsimplementeringar, till exempel IDE, ATA och SATA:

• Är vanligtvis utformade för lätt till medeltung användning.
• Är vanligtvis inriktade på program med en användare.

Stationära styrenheter som inte är SCSI kräver mer processorbandbredd (CPU) och begränsas ofta av ett enda aktivt kommando. När till exempel en icke-SCSI-enhet justerar ett felaktigt block kräver enheten att värdkommandona väntar. ATA-bussen visar ett annat exempel: ATA-bussen stöder två enheter, men endast ett enda kommando kan vara aktivt. Den här begränsningen lämnar en hårddisk inaktiv medan den andra hårddisken hanterar det väntande kommandot. RAID-system som bygger på skrivbordstekniker kan alla uppleva dessa symtom och påverkas i hög grad av den långsammaste svarsfunktionen. Om inte dessa system använder avancerad design är deras prestanda inte lika effektiva som prestandan för SCSI-baserade system.

Överväganden för lagring

En skrivbordsbaserad hårddisk eller diskkonfiguration kan vara en billig lösning för vissa situationer. Om du till exempel konfigurerar en skrivskyddad databas för rapportering stöter du inte på många av prestandafaktorerna i en OLTP-databas när diskcachelagring inaktiveras.

Lagringsenhetsstorlekarna fortsätter att öka. Billiga lagringsenheter med hög kapacitet är lockande. Men när du konfigurerar enheten för SQL Server och dina behov av affärssvarstid bör du noga överväga följande problem:

• Design av åtkomstväg
• Kravet på att inaktivera diskcacheminnet

Mekaniska hårddiskar

Mekaniska drivmedel använder roterande magnetiska skivor för att lagra data. De är tillgängliga i flera kapaciteter och formfaktorer, till exempel IDE, SATA, SCSI och Serial Attached SCSI (SAS). Vissa SATA-enheter innehåller konstruktioner för felförutsägelse. SCSI-hårddiskar är utformade för tyngre arbetscykler och minskad felfrekvens.

IDE- och ATA-baserade system kan skjuta upp värdkommandon när de utför aktiviteter som felaktig blockjustering, vilket leder till perioder med stoppad I/O-aktivitet.

SAS-förmånerna omfattar avancerade köer med upp till 256 nivåer samt huvud-vid-kön och oordnad kö från kö. SAS-backplanen är utformad på ett sätt som möjliggör användning av både SAS- och SATA-enheter i samma system.

Din SQL Server-installation beror på kontrollantens förmåga att inaktivera diskcacheminnet och tillhandahålla en stabil I/O-cache. Att skriva data i fel ordning till olika enheter är inte ett hinder för SQL Server så länge kontrollanten har rätt funktioner för stabil mediecachelagring. Komplexiteten i kontrollantdesignen ökar med avancerade datasäkerhetstekniker, till exempel spegling.

Lagring med fast tillstånd

Solid State Storage har fördelar jämfört med mekaniska (snurrande) hårddiskar, men det är mottagligt för många av samma felmönster som snurrande media. Du kan ansluta solid state-lagring till servern med hjälp av olika gränssnitt, inklusive NVM Express (NVMe), PCI Express (PCIe) och SATA. Behandla solid state-media som du skulle göra med snurrande media och se till att lämpliga skyddsåtgärder finns på plats för strömavbrott, till exempel en batteribaserad cachelagringsstyrenhet.

Vanliga problem som orsakas av ett energifel är:

• Bitskada: Register visar slumpmässiga bitfel.
• Flytande anteckningar: Välgjorda dokument hamnar på fel plats.
• Shorn skriver: Operationerna utförs delvis på en nivå under den förväntade sektorstorleken.
• Skadade metadata: Metadata i flashöversättningsskiktet (FTL) är skadade.
• Enhet som inte svarar: Enheten fungerar inte alls eller fungerar oftast inte.
• Icke-serializabilitet: Lagringens slutliga tillstånd leder inte till en operationsordning som är serialiserbar.

512e

De flesta solid state-lagringsenheter rapporterar sektorstorlekar på 512 byte men använder 4 KB-sidor i raderingsblocken på 1 MB. Om du använder 512 byte justerade sektorer för SQL Server-loggenheten kan fler read/modify/write-aktiviteter (RMW) genereras, vilket kan bidra till långsammare prestanda och ökad enhetsförslitning.

Rekommendation: Se till att cachekontrollern är medveten om rätt sidstorlek för lagringsenheten och kan anpassa fysiska skrivprocesser korrekt med SSD-infrastrukturen.

0xFFFFFFFF

En nyligen formaterad enhet innehåller vanligtvis alla nollor. Ett raderat block av en solid-state-enhet består endast av 1s, vilket innebär att en rå avläsning av ett raderat block består endast av 0xFF-symboler. Det är dock ovanligt att en användare läser ett raderat block under normala I/O-åtgärder.

Mönsterstämpling

En metod som användes tidigare är att skriva ett känt mönster till hela hårddisken. När databasaktiviteten sedan körs mot samma enhet kan felaktigt beteende (inaktuell läsning, förlorad skrivning eller läsning av felaktig förskjutning) identifieras när mönstret oväntat visas.

Den här tekniken fungerar inte bra på solid state-lagring. Raderings- och RMW-aktiviteterna för skrivningar förstör mönstret. GC-aktiviteten (Garbage Collection för solid-state-lagring), utjämning av slitage, proportionella/avsatta listblock och andra optimeringar tenderar att resultera i att skrivningar hamnar på olika fysiska platser, till skillnad från sektoråteranvändning i roterande medier.

Inbyggd programvara

Den inbyggda programvaran som används i solid state-lagring tenderar att vara komplex jämfört med snurrande mediemotsvarigheter. Många enheter använder flera bearbetningskärnor för att hantera inkommande begäranden och skräpinsamlingsaktiviteter. Se till att hålla den fasta enhetens inbyggda programvara uppdaterad för att undvika kända problem.

Läs dataskador och slitageutjämning

En vanlig metod för skräpinsamling (GC) för solid state storage hjälper till att förhindra upprepade, läsbara dataskador. När du läser samma cell upprepade gånger är det möjligt att elektronaktiviteten kan läcka och orsaka skador på närliggande celler. Solid State Storage skyddar data med olika nivåer av felkorrigeringskod (ECC) och andra mekanismer.

En sådan mekanism avser slitageutjämning. Solid State Storage håller reda på läs- och skrivaktiviteten på lagringsenheten. Sophämtningen kan fastställa problemområden eller platser som slits snabbare än andra platser. GC avgör till exempel att ett block är i skrivskyddat tillstånd och måste flyttas. Den här överföringen sker vanligtvis till ett block med mer slitage, så det ursprungliga blocket kan användas för att skriva. Den här processen hjälper till att balansera slitaget på enheten, men den flyttar endast läsdata till en plats som är mer sliten och matematiskt ökar risken för fel, även om det är något.

En annan bieffekt av förslitningsutjämning kan inträffa med SQL Server. Anta att du kör DBCC CHECKDB och rapporterar ett fel. Om du kör det en andra gång finns det en liten risk att DBCC CHECKDB rapporterar ytterligare eller ett annat mönster av fel, eftersom GC-aktiviteten för solid state-lagring kan ske ändringar mellan körningarna DBCC CHECKDB.

OS-fel 665 och defragmentering

Roterande lagring behöver hålla block nära varandra för att minska diskens läs-/skrivhuvudrörelse och öka prestandan. Solid State Storage har inget fysiskt huvud, vilket eliminerar söktiden. Många solid state-enheter är utformade för att tillåta parallella åtgärder på olika block. Defragmentering av solid state-media är därför onödigt. Serieaktiviteter är de bästa I/O-mönstren för att maximera I/O-dataflödet på solid state-lagringsenheter.

rekommendationer:

• Använd en lämplig, batteribackad styrenhet som är utformad för att optimera skrivaktiviteter. Det här valet kan förbättra prestanda, minska slitage på enheten och reducera de fysiska fragmenteringsnivåerna.

• Överväg att använda ReFS-filsystemet för att undvika NTFS-attributbegränsningarna.

• Kontrollera att inställningarna för filtillväxt är lämpliga.

Mer information om hur du felsöker OS-fel 665 när det gäller fragmentering finns i OS-felen 665 och 1450 rapporteras för SQL Server-filer.

Komprimering

Så länge enheten bibehåller avsikten med stabila medier kan komprimering förlänga enhetens livslängd och påverka prestanda positivt. En del inbyggd programvara kanske dock redan komprimerar data osynligt. Kom ihåg att testa nya lagringsscenarier innan du distribuerar dem till din produktionsmiljö.

Sammanfattning

• Underhåll korrekta procedurer och processer för säkerhetskopiering och haveriberedskap.
• Håll den inbyggda programvaran uppdaterad.
• Lyssna noga på maskinvarutillverkarens vägledning.

Konfiguration av diskcache

Om du vill använda en enhet med SQL Server inaktiverar du cachelagring av enheter. Som standard är enhetens cache aktiverad. I Windows Server använder du fliken Diskegenskaper>Maskinvarupolicy>Policy för att inaktivera skrivcachelagring på OS-nivå.

Förlita dig inte enbart på operativsystemnivåinställningar. Vissa hårddiskar ignorerar Windows-inställningar och kräver verktyg från tillverkaren eller firmware-inställningar för att inaktivera skrivcache. Bekräfta med hjälp av leverantörsverktyg att skrivcache faktiskt är inaktiverad.

Cacheöverväganden och SQLIOSim

Bekräfta garantier för transaktionshållbarhet genom att verifiera I/O-undersystemet med hjälp av SQLIOSim innan du går över till produktion. Det här verktyget simulerar tung asynkron läs- och skrivaktivitet till en simulerad dataenhet och loggenhet. Mer information finns i Använda SQLIOSim-verktyget för att simulera SQL Server-aktivitet på ett diskundersystem.

Många datortillverkare beställer enheterna med skrivcachen inaktiverad. Testning visar dock att det här villkoret kanske inte alltid är fallet, så du bör alltid testa det fullt ut. Om du har frågor om cachelagringsstatusen för lagringsenheten kontaktar du tillverkaren och hämtar lämpligt verktyg för att inaktivera cachelagringsåtgärder för skrivning. På äldre lagringsmedia kan du också behöva konfigurera bygelinställningar.

SQL Server kräver system som stöder garanterad leverans till stabila medier, enligt kraven för SQL Server I/O-tillförlitlighetsprogrammet. Mer information om indata- och utdatakraven för SQL Server Database Engine finns i KRAV för SQL Server Database Engine Disk Input/Output (I/O).

Felaktig cachelagring vid skrivning kan medföra risker

När du aktiverar skrivcache utan lämpliga säkerhetsåtgärder bekräftar vissa lagringsundersystem skrivåtgärder som slutförda innan data skrivs på ett säkert sätt till bestående medier. Om en strömförlust eller ett systemfel inträffar kan det här villkoret resultera i:

• Dataförlust, där bekräftade transaktioner aldrig bevaras.
• Databasskada på grund av brutna skrivordningsgarantier.

Relaterat innehåll

• arkitekturguide för sidor och utsträckningar
• Minneshanteringsarkitekturguide
• Lagring: Metodtips för prestanda för SQL Server på virtuella Azure-datorer
• SQL Server på Linux: Interna mekanismer för tvingad enhetsåtkomst (FUA)
• Sql Server I/O Basics, kapitel 2