Microsoft SQL Server I/O-undersystemkrav för tempdb-databasen

I den här artikeln beskrivs kraven för I/O-undersystemet för tempdb-databasen i SQL Server.

Ursprunglig produktversion: Microsoft SQL Server
Ursprungligt KB-nummer: 917047

Sammanfattning

Microsoft SQL Server kräver att I/O-undersystemet som används för att lagra system- och användardatabaser helt uppfyller wal-kraven (Write-Ahead Logging) via specifika I/O-huvudkonton. Dessa krav är nödvändiga för att uppfylla ACID-egenskaperna för transaktioner: Atomic, Consistent, Isolated och Durable. Information om I/O-undersystemsefterlevnadskrav finns i grunderna för SQL Server I/O.

Följande lista är en snabb sammanfattning av kraven:

• Skrivordningen måste upprätthållas.
• Beroende skrivkonsekvens måste upprätthållas.
• Skrivningar måste alltid skyddas i/på stabila medier.
• Ett trasigt I/O-skydd måste ske.

Hållbarhetsunderhåll är fortfarande viktigt för alla andra databaser, men kan vara avslappnat för tempdb-databasen. I följande tabell sammanfattas flera av de kritiska I/O-kraven för SQL Server-databaser.

Transaktionssektoromskrivningar omfattar fullständigt loggade åtgärder av undersystemet som tillåter att en sektor flyttas, ersätts eller återställs till den ursprungliga avbildningen. Dessa omskrivningar rekommenderas vanligtvis inte på grund av de ytterligare kostnader som krävs för att utföra sådana åtgärder. Ett exempel på detta är ett defragmentation verktyg som flyttar fildata. Den ursprungliga sektorn i filen kan inte ersättas med den nya sektorplatsen förrän den nya sektorn och data har säkrats. Ommappningen av sektorn måste ske på ett transaktionellt sätt så att eventuella fel, inklusive ett strömavbrott, gör att ursprungliga data återupprättas. Se till att du har tillgängliga låsmekanismer under den här typen av process för att förhindra ogiltig dataåtkomst och därmed upprätthålla de andra klientorganisationen för SQL Server I/O.

Överlevnad över avbrott

Tempdb-databasen är ett scratch-område för SQL Server och återskapas vid varje SQL Server-start. Initieringen ersätter alla behov av data för att överleva en omstart.

Transaktionssektoromskrivningsåtgärder

För att säkerställa att återställningsprocesserna lyckas, till exempel återställning och återställning av krascher, måste loggposterna lagras korrekt på stabila medier innan datasidan lagras och kan inte skrivas om utan att uppfylla transaktionsegenskaperna. Detta kräver att undersystemet och SQL Server underhåller specifika attribut, till exempel skrivordning, sektorjusterade och storleksanpassade skrivningar och andra sådana I/O-säkerhetsattribut som beskrivs i de tidigare nämnda dokumenten. För tempdb-databasen är kraschåterställningen onödig eftersom databasen alltid initieras under SQL Server-start. Tempdb-databasen kräver dock fortfarande återställningsfunktioner. Därför kan vissa attribut i WAL-protokollet vara avslappnade.

Lagringsplatsen för tempdb-databasen måste agera i strikt enlighet med etablerade diskenhetsprotokoll. På alla sätt måste enheten som tempdb-databasen lagras på visas och fungera som en fysisk disk som tillhandahåller läs- och skrivfunktioner. Transaktionssektorns omskrivningsåtgärder kan vara ytterligare ett krav för specifika implementeringar. SQL Server stöder till exempel inte databasändringar med hjälp av NTFS-filsystemkomprimering eftersom NTFS-komprimering kan skriva om sektorer i loggen som redan har skrivits och anses vara härdade. Ett fel under den här typen av omskrivning kan göra att databasen blir oanvändbar och skadar data som SQL Server redan anses vara säkra.

Transaktionssektorns omskrivningsåtgärder är relevanta för alla SQL Server-databaser som innehåller tempdb-databasen. En växande mängd utökade lagringstekniker använder enheter och verktyg som kan skriva om data som SQL Server anser vara säkra. Till exempel utför några av de nya teknikerna cachelagring i minnet eller datakomprimering. För att undvika allvarliga databasskador måste alla sektoromskrivningar ha fullständigt transaktionsstöd på ett sådant sätt att om ett fel inträffar återställs data till de tidigare sektorbilderna. Detta garanterar att SQL Server aldrig utsätts för ett oväntat avbrott eller dataskador.

Du kanske kan placera tempdb-databasen på specialundersystem, till exempel RAM-diskar, solid state eller andra höghastighetsimplementeringar som inte kan användas för andra databaser. De viktigaste faktorerna som visas i avsnittet Mer information måste dock beaktas när du utvärderar dessa alternativ.

Mer information

Flera faktorer bör studeras noggrant när du utvärderar lagringsplatsen för tempdb-databasen. Till exempel omfattar tempdb-databasanvändningen, men är inte begränsad till minnesfotavtryck, frågeplan och I/O-beslut. Lämplig justering och implementering av tempdb-databasen kan förbättra systemets skalbarhet och svarstider. I det här avsnittet beskrivs de viktigaste faktorerna för att fastställa lagringsbehoven för tempdb-databasen.

Undersystem med hög hastighet

Det finns olika implementeringar av höghastighetsundersystem på marknaden som tillhandahåller krav för SQL Server I/O-undersystemprotokoll, men som inte ger mediet hållbarhet.

En RAM-disk är ett vanligt exempel på en sådan implementering. RAM-diskar installerar nödvändiga drivrutiner och gör att en del av huvud-RAM-disken visas som och fungerar som alla diskenheter som är anslutna till systemet. Alla I/O-undersystem bör ge fullständig kompatibilitet med SQL Server I/O-kraven. Det är dock uppenbart att en RAM-disk inte är hållbara medier. Därför kan en implementering, till exempel en RAM-disk, endast användas som plats för tempdb-databasen och kan inte användas för någon annan databas.

Nycklar att tänka på före implementering och distribution

Det finns olika saker att tänka på innan du distribuerar tempdb-databasen på den här typen av undersystem. I det här avsnittet används en RAM-disk som grund för diskussion, men liknande resultat uppstår i andra höghastighetsimplementeringar.

I/O-säkerhet

Efterlevnad av skrivningar efter skrivning och transaktionssektor är ett måste. Distribuera aldrig SQL Server på något system som inte helt stöder SQL Server I/O-kraven, eller så riskerar du att skada och förlora dina data.

Sidor som redan har cachelagrats (Dubbel RAM-cache)

Temporära tabeller är som alla andra tabeller i en databas. De cachelagras av buffertpoolen och hanteras av lata skrivåtgärder. Lagring av tillfälliga tabellsidor på en RAM-disk orsakar dubbel RAM-cachelagring, en i buffertpoolen och en på RAM-disken. Detta tar direkt bort från buffertpoolens totala möjliga storlek och minskar vanligtvis prestandan för SQL Server.

Ge upp RAM-minne

RAM-disken anger en del av huvud-RAM som namnet antyder. Det finns flera implementeringar av RAM-diskar och RAM-baserade cacheminnen. Vissa aktiverar även fysiska I/O-säkerhetskopieringsåtgärder. Nyckelelementet i den RAM-baserade filcachen är att den direkt tar bort från det fysiska minne som kan användas av SQL Server. Ha alltid starka bevis för att lägga till en RAM-baserad filcache förbättrar programmets prestanda och inte minskar andra fråge- eller programprestanda.

Justera först

Ett program bör justera för att ta bort onödiga och oönskade sorter och hashar som kan orsaka användning av tempdb-databasen. Många gånger kan tillägg av ett index ta bort behovet av sorteringen eller hashen i planen helt, vilket leder till optimala prestanda utan att tempdb-databasen behöver användas.

Möjliga förmånspunkter

Fördelarna med att placera tempdb-databasen i ett höghastighetssystem kan bara fastställas genom rigorös testning och mätningar av programarbetsbelastningarna. Arbetsbelastningen måste undersökas noggrant för de egenskaper som tempdb-databasen kan dra nytta av, och I/O-säkerheten måste bekräftas före distributionen.

Sorterings- och hashåtgärderna fungerar tillsammans med SQL Server-minneshanterare för att fastställa storleken på det minnesinterna scratch-området för varje sorterings- eller hash-åtgärd. Så snart sorterings- eller hashdata överskrider det allokerade minnesinterna scratch-området kan data skrivas till tempdb-databasen. Den här algoritmen har expanderats i SQL Server, vilket minskar kraven på tempdb-databasanvändning jämfört med tidigare versioner av SQL Server.

SQL Server använder tempdb-databasen för att hantera olika aktiviteter som omfattar sortering, hashvärden, radversionsarkivet och temporära tabeller:

• Tillfälliga tabeller underhålls av vanliga rutiner för buffertpooler för datasidor och uppvisar vanligtvis inte prestandafördelar med implementeringar av specialundersystem.
• Tempdb-databasen används som ett scratch-område för hashar och sortering. Det kan vara fördelaktigt att minska I/O-svarstiden för sådana åtgärder. Men vet att lägga till ett index för att undvika en hash eller en sortering kan ge en liknande fördel.

Kör baslinjer med och utan tempdb-databasen som lagras i det snabba undersystemet för att jämföra fördelar. En del av testningen bör omfatta frågor mot användardatabasen som inte omfattar sortering, hashvärden eller temporära tabeller och sedan bekräfta att dessa frågor inte påverkas negativt. När du utvärderar systemet kan följande prestandaindikatorer vara användbara.

Exempel på omskrivning av transaktionssektor

I följande exempel beskrivs den datasäkerhet som krävs av SQL Server-databaser.

Anta att en RAM-diskleverantör använder en minnesintern komprimeringsimplementering. Implementeringen måste vara korrekt inkapslad genom att tillhandahålla det fysiska utseendet på filströmmen som om sektorn var justerad och storleksanpassad så att SQL Server är omedveten och korrekt skyddad från den underliggande implementeringen. Titta närmare på komprimeringsexemplet.

• Sektor 1 skrivs till enheten och komprimeras för att spara utrymme.
• Sektor 2 skrivs till enheten och komprimeras med sektor 1 för att spara utrymme.

Enheten kan utföra följande åtgärder för att skydda sektor 1:s data när den kombineras med sektor 2:s data.

• Blockera alla skrivningar till sektorer 1 och 2.
• Avkomprimera sektor 1 till ett repområde, vilket lämnar den aktuella sektorn 1 lagring som aktiva data som ska hämtas.
• Komprimera sektorer 1 och 2 till ett nytt lagringsformat.
• Blockera alla läsningar och skrivningar i sektorer 1 och 2.
• Byt ut gammal lagring för sektorer 1 och 2 med ny lagring. Om utbytesförsöket misslyckas (återställning):
  • Återställ den ursprungliga lagringen för sektorer 1 och 2.
  • Ta bort sektorerna 1 och 2 kombinerade data från scratch-området.
  • Det gick inte att skriva sektor 2.
• Avblockera läsningar och skrivningar för sektorer 1 och 2.

Möjligheten att tillhandahålla låsningsmekanismer kring sektorändringar och återställa ändringarna när sektorutbytesförsöket misslyckas anses vara övergångskompatibelt. För implementeringar som använder fysisk lagring för utökad säkerhetskopiering skulle det innehålla lämpliga transaktionsloggaspekter för att skydda och återställa ändringar som tillämpades på diskstrukturerna för att upprätthålla integriteten för SQL Server-databasfilerna.

Alla enheter som möjliggör omskrivning av sektorer måste ha stöd för omskrivningarna på ett transaktionellt sätt så att SQL Server inte exponeras för dataförlust.

Var försiktig när du flyttar tempdb-databasen

Var försiktig när du flyttar tempdb-databasen eftersom SQL Server inte startar om tempdb-databasen inte kan skapas. Om tempdb-databasen inte kan skapas startar du SQL Server med startparametern (-f) och flyttar tempdb-databasen till en giltig plats.

Följ dessa steg om du vill ändra den fysiska platsen för tempdb-databasen:

1. Använd instruktionen ALTER DATABASEMODIFY FILE och -satsen för att ändra de fysiska filnamnen för varje fil i tempdb-databasen för att referera till den nya fysiska platsen, till exempel den nya disken.

   ALTER DATABASE tempdb MODIFY FILE 
   (name = tempdev, filename = 'C:\MyPath\tempdb.mdf')
   
   ALTER DATABASE tempdb MODIFY FILE 
   (name = templog, filename = 'C:\MyPath\templog.ldf')
   

2. Stoppa och starta sedan om SQL Server.

Certifieringar av partnerprodukter är inte en garanti för kompatibilitet eller säkerhet

En tredjepartsprodukt eller en viss leverantör kan få en Microsoft-logotypcertifiering. Partnercertifiering eller en specifik Microsoft-logotyp certifierar dock inte kompatibilitet eller lämplighet för ett visst syfte i SQL Server.

Stöd

Om du använder ett undersystem med SQL Server som stöder I/O-garantierna för transaktionsdatabasanvändning enligt beskrivningen i den här artikeln kommer Microsoft att ge stöd för SQL Server- och SQL Server-baserade program. Problem med eller orsakas av undersystemet hänvisas dock till tillverkaren.

För tempdb-databasrelaterade problem ber Microsoft Support Services dig att flytta tempdb-databasen. Kontakta enhetsleverantören för att kontrollera att du har distribuerat och konfigurerat enheten för transaktionsdatabasanvändning.

Microsoft certifierar eller verifierar inte att produkter från tredje part fungerar korrekt med SQL Server. Dessutom tillhandahåller Microsoft inte någon garanti, garanti eller instruktion om någon tredjepartsprodukts lämplighet för användning med SQL Server.

Referenser

Mer information finns i:

• Felmeddelande 823 kan tyda på maskinvaruproblem eller systemproblem i SQL Server

• Använda cachelagring av diskenheter med SQL Server

• Beskrivning av stöd för nätverksdatabasfiler i SQL Server

• Microsoft intygar inte att produkter från tredje part fungerar med Microsoft SQL Server

• Prestandariktlinjer för SQL Server på virtuella Azure-datorer

• Optimera dina frågeplaner med SQL Server 2014 Cardinality Estimator

• Frågeprestanda

• Disk Input/Output (I/O)-krav för SQL Server Database Engine