Grunderna i SQL Server I/O

Gäller för:SQL ServerAzure SQL Managed InstanceSQL Server på en virtuell Azure-dator

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 lagring i solid state. 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. Detta hjälper systemadministratören att skilja mellan PROBLEM med SQL Server och I/O-undersystem. 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; det anges för närvarande inte i meddelandet. 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 rapporteras för att hjälpa systemadministratören att identifiera orsaken till SQL Servers långsamma svarstider snabbare och avgöra 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 bara inte har slutförts ännu. Det går inte att se i meddelandet vilket scenario som är fallet, även om en förlorad 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.

Lång I/Os kan också orsakas av en komponent i I/O-sökvägen (till exempel en drivrutin, styrenhet eller inbyggd programvara) som kontinuerligt fördröjer behandlingen av en gammal I/O-begäran, till förmån för att behandla nyare begäranden. Detta kan inträffa i sammankopplade miljöer, till exempel iSCSI - och fiberkanalnätverk (antingen på grund av felkonfiguration eller fel i sökvägen). Det kan vara svårt att bekräfta med verktyget Prestandaövervakare eftersom de flesta I/Os hanteras snabbt. Långa I/O-begäranden kan förvärras av 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.

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 inte 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 en mindre I/O-svarstid 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 utförs utan användning av en cache kan vara betydligt längre i 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 riktas mot system som tillhandahåller cachelagringskontrollanter. 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. Skrivcachekontroller och lagringssystem är säkra för SQL Server, om de är utformade för användning i en kritisk databasdriftmiljö (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 ä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 är säkra. Du bör dock kontakta maskinvaruleverantören för att se till att lagringsundersystemet har testats och godkänts för användning i en RDBMS-miljö (Data Critical TransactionAl Relational Database Management System).

Loggning före skrivning

SQL Server-datamodifieringsinstruktioner genererar logiska sidskrivningar. Den här skrivströmmen kan föreställas gå till två ställen: loggen och själva databasen. Av prestandaskäl skjuter SQL Server upp skrivningar till databasen via sitt eget cachebuffertsystem. Skrivningar till loggen skjuts bara tillfälligt upp till COMMIT tiden. De cachelagras inte på samma sätt som dataskrivningar. Eftersom loggskrivningar för en viss sida alltid föregår 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 cachelagrat skrivåtgärder, men kan inte lätt tömma 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. Detta överensstämmer med protokollspecifikationen för Write Ahead Logging (WAL) för att säkerställa datasäkerheten. 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 anses vara atomiska arbetsenheter som antingen är helt tillämpade eller helt återställda. 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 klientarbetsstationerna startades om skulle användarna hitta alla sina data, upp till den senaste transaktionen som de angav.

Transaktionsintegritet och automatisk återställning i SQL Server utgör en kraftfull tids- och arbetsbesparingsfunktion. Om en cachelagringsstyrenhet för skrivning inte är korrekt utformad för användning i en datakritisk transaktionsmiljö med DBMS, kan det försämra SQL Servers förmåga att återhämta sig och därmed skada databasen. Detta kan inträffa om styrenheten fångar upp SQL Server-transaktionsloggens skrivningar och buffrar dem i en maskinvarucache på styrenhetens kort, men inte bevarar dessa skrivna sidor under ett systemfel.

Skrivcache och lagringsstyrenheter

De flesta cachelagringsstyrenheter för lagringsenheter utför skrivcachelagring. Skrivcachefunktionen kan inte alltid inaktiveras.

Även om servern använder en UPS garanterar detta 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 skrivcache för maskinvara, som tar hänsyn till alla möjliga orsaker till att ta bort felaktiga cachedata, vilket därmed skulle vara säkert för användning av en databasserver. Några av dessa designaspekter skulle omfatta avlyssning av RST-bussignalen för att undvika okontrollerad återställning av cachelagringsstyrenheten, inbyggd batteribackup och speglat eller felkontrollerande och korrigerande (ECC) minne. 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. Detta kallas ofta egenskaperna ACID (Atomicity, Consistency, Isolation och Durability).

Det här avsnittet behandlar konsekvenserna av lagringscache. Vi rekommenderar att du läser följande artiklar i Microsoft Knowledge Base för ytterligare förtydliganden om diskussioner om cachelagring och alternativt felläge:

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

Följande dokument rekommenderas också:

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

Dessa två dokument gäller för alla versioner av SQL Server som stöds för närvarande.

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. Många av dem tillåter att procentandelen läs- och skrivcache upprättas för optimala prestanda. Vissa innehåller stora minnesutrymmen. Vissa maskinvaruleverantörer tillhandahåller avancerade cachelagringssystem för batteridrivna enheter med flera gigabyte cacheminne. Dessa kan avsevärt förbättra databasens prestanda. Användning av cacheminne med batteribackup ger hållbarhet och datakonsekvens som SQL Server förväntar sig.

Implementeringar av lagringsundersystem

Det finns många typer av undersystemimplementeringar. RAID (redundant matris med oberoende diskar) och SAN (lagringsområdesnätverk) är två exempel på dessa typer av undersystemimplementeringar. Dessa system skapas vanligtvis med SCSI-baserade enheter. Det finns flera orsaker till detta. I följande avsnitt beskrivs allmänt lagringsöverväganden på hög nivå.

SCSI, SAS och NVMe

SCSI-, SAS- och NVMe-lagringsenheter:

• Tillverkas vanligtvis för tung användning.
• Är vanligtvis inriktade på serverbaserade implementeringar med flera användare.
• Vanligtvis har bättre mellantid 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:

• Tillverkas vanligtvis för lätt och medelbelastning.
• Är vanligtvis inriktade på enskilda användarbaserade program.

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. Detta lämnar en enhet inaktiv medan den andra enheten servar 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

Det finns situationer där en datorbaserad enhet eller lagringsarray är en lämplig lågkostnadslösning. Om du till exempel konfigurerar en skrivskyddad databas för rapportering bör du inte stöta på många av prestandafaktorerna för en OLTP-databas när diskcachelagring inaktiveras.

Lagringsenhetsstorlekarna fortsätter att öka. Låg kostnad, hög kapacitet enheter kan vara tilltalande. 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.

Cachelagring av enheter bör inaktiveras för att enheten ska kunna användas med SQL Server. Som standard är enhetens cache aktiverad. I Windows Server använder du fliken Diskegenskaper> för att komma åt fliken PolicyEgenskapsprincip> för att styra inställningen för enhetscache.

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

SAS-funktionerna inkluderar avancerade köfunktioner med upp till 256 nivåer, samt prioriterad köhantering och köhantering utan ordningsföljd. 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 i solid state

Solid State Storage har fördelar jämfört med mekaniska (snurrande) hårddiskar, men är mottaglig för många av samma felmönster som snurrande media. Solid State Storage är anslutet till servern med 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: Poster uppvisar 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 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 storage 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 teknik som vi använde tidigare är att skriva ett känt mönster till hela lagringsenheten. När vi sedan kör databasaktivitet på samma drive kan vi upptäcka felaktigt beteende (förlegad läsning, förlorad skrivning, läsning av felaktig förskjutning osv.) när mönstret oväntat dyker upp.

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 (Skräpinsamling av solid state-lagring), utjämning av slitage, proportionella och reserverade listblock och andra optimeringar tenderar att orsaka att skrivningar hamnar på olika fysiska platser, till skillnad från att återanvända sektor 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. Till exempel fastställer GC att ett block har varit i skrivskyddat tillstånd under en tidsperiod 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. Detta hjälper till att balansera slitaget på enheten, men flyttar skrivskyddade data till en plats som har mer slitage och matematiskt ökar risken för fel, även om det endast ä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 inte det fysiska huvudet, vilket eliminerar söktiden. Många solid state-enheter är utformade för att utföra parallella åtgärder på olika block samtidigt. Det innebär att defragmentering av solid state-media ä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. Detta kan förbättra prestanda, minska slitage på enheten och nivåerna av fysisk fragmentering.

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

• Kontrollera att filtillväxtstorlekarna är rätt storleksanpassade.

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 kan påverka prestandan 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 riktlinjer.

Cacheöverväganden och SQLIOSim

För att skydda dina data fullständigt bör du se till att all datacachelagring hanteras korrekt. I många situationer innebär det att du måste inaktivera enhetens skrivcachelagring.

Microsoft utförde tester på flera SCSI- och IDE-enheter med verktyget SQLIOSim . Det här verktyget simulerar tung asynkron läs-/skrivaktivitet till en simulerad dataenhet och loggenhet. Mer information om SQLIOSim finns i Använda SQLIOSim-verktyget för att simulera SQL Server-aktivitet i ett diskundersystem.

Många datortillverkare beställer enheterna med skrivcachen inaktiverad. Testningen visar dock att detta kanske inte alltid är fallet, så du bör alltid testa det helt. Om du har frågor om lagringsenhetens cachelagringsstatus kontaktar du tillverkaren och hämtar lämpliga inställningar för verktyg eller bygel för att inaktivera skrivcachelagringsåtgärder.

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

Relaterat innehåll

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