Resurshantering i Azure SQL Database

  • Artikel
  • 17 minuter för att läsa

GÄLLER FÖR: Azure SQL Database

Den här artikeln innehåller en översikt över resurshantering i Azure SQL Database. Den innehåller information om vad som händer när resursgränser nås och beskriver de resursstyrningsmekanismer som används för att tillämpa dessa gränser.

Specifika resursgränser per prisnivå (kallas även tjänstmål) för enskilda databaser finns i antingen DTU-baserade resursgränser för en enskild databas eller resursgränser baserade på virtuella kärnor för en enskild databas. Information om resursgränser för elastiska pooler finns i DTU-baserade resursgränser för elastisk pool eller resursgränser baserade på virtuella kärnor i elastisk pool.

Tips

Information om Azure Synapse Analytics-dedikerade SQL poolgränser finns i kapacitetsbegränsningar och gränser för minne och samtidighet.

Gränser för logisk server

Resurs Gräns
Databaser per logisk server 5000
Standardantal logiska servrar per prenumeration i en region 20
Maximalt antal logiska servrar per prenumeration i en region 250
DTU/eDTU-kvot per logisk server 54,000
vCore-kvot per logisk server 540
Maximalt antal elastiska pooler per logisk server Begränsas av antalet DTU:er eller virtuella kärnor. Om varje pool till exempel är 1 000 DTU:er kan en server ha stöd för 54 pooler.

Viktigt

När antalet databaser närmar sig gränsen per logisk server kan följande inträffa:

  • Ökad svarstid vid körning av frågor mot huvuddatabasen. Detta inkluderar vyer av resursanvändningsstatistik, till exempel sys.resource_stats.
  • Ökad svarstid i hanteringsåtgärder och återgivning av portalvyer som inbegriper uppräkning av databaser på servern.

Anteckning

Om du vill få mer DTU/eDTU-kvot, vCore-kvot eller fler logiska servrar än standardnumret skickar du en ny supportbegäran i Azure Portal. Mer information finns i Begära kvotökningar för Azure SQL Database.

Vad händer när resursgränserna nås

Beräknings-CPU

När processoranvändningen för databasberäkning blir hög ökar frågefördröjningen och frågor kan till och med överskrida tidsgränsen. Under dessa förhållanden kan frågor placeras i kö av tjänsten och tillhandahålls resurser för körning när resurser blir kostnadsfria. När du stöter på hög beräkningsanvändning omfattar åtgärdsalternativen:

Storage

När det datautrymme som används når den maximala datastorleksgränsen, antingen på databasnivå eller på elastisk poolnivå, infogas och uppdateras som ökar datastorleken och klienterna får ett felmeddelande. SELECT- och DELETE-uttryck påverkas inte.

I Premium och Affärskritisk tjänstnivåer får klienterna också ett felmeddelande om kombinerad lagringsförbrukning efter data, transaktionslogg och tempdb för en enskild databas eller en elastisk pool överskrider den maximala lokala lagringsstorleken. Mer information finns i Storage utrymmesstyrning.

När du stöter på hög utrymmesanvändning omfattar åtgärdsalternativen:

  • Öka den maximala datastorleken för databasen eller den elastiska poolen, eller skala upp till ett tjänstmål med en högre maximal datastorleksgräns. Se Skala resurser för en enskild databas och Skala elastiska poolresurser.
  • Om databasen finns i en elastisk pool kan du också flytta databasen utanför poolen, så att dess lagringsutrymme inte delas med andra databaser.
  • Krymp en databas för att frigöra outnyttjat utrymme. I elastiska pooler ger krympning av en databas mer lagringsutrymme för andra databaser i poolen. Mer information finns i Hantera filutrymme i Azure SQL Database.
  • Kontrollera om hög utrymmesanvändning beror på en topp i storleken på beständig versionslagring (PVS). PVS är en del av varje databas och används för att implementera accelererad databasåterställning. Information om hur du fastställer aktuell PVS-storlek finns i PVS-felsökning. En vanlig orsak till en stor PVS-storlek är en transaktion som är öppen under lång tid (timmar), vilket förhindrar rensning av äldre radversioner i PVS.
  • För databaser och elastiska pooler i Premium och Affärskritisk tjänstnivåer som förbrukar stora mängder lagringsutrymme kan du få ett fel om att det inte finns tillräckligt med utrymme även om använt utrymme i databasen eller den elastiska poolen ligger under den maximala datastorleksgränsen. Detta kan inträffa om tempdb eller transaktionsloggfiler använder en stor mängd lagringsutrymme mot den maximala lokala lagringsgränsen. Redundansväxla databasen eller den elastiska poolen för att återställa tempdb till den ursprungliga mindre storleken eller krympa transaktionsloggen för att minska den lokala lagringsförbrukningen.

Sessioner, arbetare och begäranden

Sessioner, arbetare och begäranden definieras på följande sätt:

  • En session representerar en process som är ansluten till databasmotorn.
  • En begäran är en logisk representation av en fråga eller batch. En begäran utfärdas av en klient som är ansluten till en session. Med tiden kan flera begäranden utfärdas i samma session.
  • En arbetstråd, även kallad arbetstråd eller tråd, är en logisk representation av en operativsystemtråd. En begäran kan ha många arbetare när de körs med en parallell frågekörningsplan, eller en enda arbetare när den körs med en seriell (trådad) körningsplan. Arbetare måste också stödja aktiviteter utanför begäranden: till exempel krävs en arbetare för att bearbeta en inloggningsbegäran när en session ansluter.

Mer information om dessa begrepp finns i guiden Tråd- och uppgiftsarkitektur.

Det maximala antalet sessioner och arbetare bestäms av tjänstnivån och beräkningsstorleken. Nya begäranden avvisas när sessions- eller arbetsgränser nås och klienter får ett felmeddelande. Även om antalet anslutningar kan styras av programmet är antalet samtidiga arbetare ofta svårare att uppskatta och kontrollera. Detta gäller särskilt under perioder med hög belastning när databasresursgränser nås och arbetare staplas på grund av frågor som körs längre, stora blockeringskedjor eller överdriven frågeparallellitet.

Anteckning

Det första erbjudandet av Azure SQL Database endast stöd för en trådade frågor. Vid den tidpunkten motsvarades antalet begäranden alltid av antalet arbetare. Felmeddelandet 10928 i Azure SQL Database innehåller formuleringen "Begärandegränsen för databasen är N och har uppnåtts" i bakåtkompatibilitetssyfte. Gränsen är faktiskt antalet arbetsnoder. Om maxgraden för parallellitetsinställningen (MAXDOP) är lika med noll eller större än en, kan antalet arbetare vara mycket högre än antalet begäranden och gränsen kan nås mycket tidigare än när MAXDOP är lika med en. Läs mer om fel 10928 i Resursstyrningsfel.

Du kan undvika att arbets- eller sessionsgränser närmar sig eller överskrids genom att:

Hitta arbets- och sessionsgränser för Azure SQL Database efter tjänstnivå och beräkningsstorlek:

Läs mer om felsökning av specifika fel för sessions- eller arbetsgränser i Resursstyrningsfel.

Minne

Till skillnad från andra resurser (CPU, arbetare, lagring) påverkar inte minnesgränsen frågeprestanda negativt och orsakar inte fel. Som beskrivs i detalj i arkitekturguiden för minneshantering använder databasmotorn ofta allt tillgängligt minne, avsiktligt. Minnet används främst för cachelagring av data för att undvika långsammare lagringsåtkomst. Det innebär att en högre minnesanvändning vanligtvis ger bättre frågeprestanda eftersom läsningen görs från minnet (vilket går snabbare) och inte lagringen.

När databasmotorn har startats cachelagrar databasmotorn data i minnet när arbetsbelastningen börjar läsa data från lagring. Efter den här inledande ramp-up-perioden är det vanligt och förväntas att kolumnerna avg_memory_usage_percent och avg_instance_memory_percent i sys.dm_db_resource_stats vara nära eller lika med 100 %, särskilt för databaser som inte är inaktiva och inte passar helt i minnet.

Förutom datacachen används minne i andra komponenter i databasmotorn. När det finns en efterfrågan på minne och allt tillgängligt minne har använts av datacachen minskar databasmotorn datacachestorleken dynamiskt för att göra minnet tillgängligt för andra komponenter och utökar datacachen dynamiskt när andra komponenter frigör minne.

I sällsynta fall kan en tillräckligt krävande arbetsbelastning göra att det inte finns tillräckligt med minne, vilket leder till minnesfel (slut på minne). Detta kan inträffa på alla nivåer av minnesanvändning mellan 0 % och 100 %. Detta är mer sannolikt för mindre beräkningsstorlekar som har proportionellt mindre minnesgränser och/eller med arbetsbelastningar som använder mer minne för frågebearbetning, till exempel i kompakta elastiska pooler.

När du stöter på minnesfel inkluderar åtgärdsalternativen:

Lösning Description
Minska storleken på minnestillslag Mer information om minnestillslag finns i blogginlägget Understanding SQL Server memory grant (Förstå SQL Server minnesbidrag). En vanlig lösning för att undvika alltför stora minnestillslag är att hålla statistiken uppdaterad. Detta resulterar i mer exakta uppskattningar av frågemotorns minnesförbrukning, vilket undviker onödigt stora minnestillslag.

I databaser som använder kompatibilitetsnivå 140 och senare kan databasmotorn som standard automatiskt justera storleken på minnesbidraget med hjälp av feedback om minnesåtergivning i Batch-läge. I databaser som använder kompatibilitetsnivå 150 och senare använder databasmotorn också feedback om minnesbidrag i radläge för vanligare frågor i radläge. Den här inbyggda funktionen hjälper till att undvika minnesfel på grund av onödigt stora minnestillslag.
Minska storleken på cacheminnet för frågeplan Databasmotorn cachelagrar frågeplaner i minnet för att undvika att kompilera en frågeplan för varje frågekörning. Om du vill undvika att cacheminnet för frågeplanen svälls på grund av cachelagringsplaner som bara används en gång ska du använda parametriserade frågor och överväga att aktivera OPTIMIZE_FOR_AD_HOC_WORKLOADS databasomfattande konfiguration.
Minska storleken på låsminnet Databasmotorn använder minne för lås. Undvik om möjligt stora transaktioner som kan hämta ett stort antal lås och orsaka hög minnesförbrukning för lås.

Resursförbrukning efter användararbetsbelastningar och interna processer

Azure SQL Database kräver beräkningsresurser för att implementera grundläggande tjänstfunktioner som hög tillgänglighet och haveriberedskap, säkerhetskopiering och återställning av databaser, övervakning, Query Store, automatisk justering osv. Systemet reserverar en viss begränsad del av de totala resurserna för dessa interna processer med hjälp av resursstyrningsmekanismer, vilket gör resten av resurserna tillgängliga för användararbetsbelastningar. När interna processer inte använder beräkningsresurser gör systemet dem tillgängliga för användararbetsbelastningar.

Total CPU- och minnesförbrukning efter användararbetsbelastningar och interna processer rapporteras i sys.dm_db_resource_stats och sys.resource_stats vyer, i avg_instance_cpu_percent och avg_instance_memory_percent kolumner. Dessa data rapporteras också via måtten sqlserver_process_core_percent och sqlserver_process_memory_percent Azure Monitor för enskilda databaser och elastiska pooler på poolnivå.

Processor- och minnesförbrukning efter användararbetsbelastningar i varje databas rapporteras i sys.dm_db_resource_stats och sys.resource_stats vyer, i avg_cpu_percent och avg_memory_usage_percent kolumner. För elastiska pooler rapporteras resursförbrukning på poolnivå i vyn sys.elastic_pool_resource_stats. Cpu-förbrukningen för användararbetsbelastningar rapporteras också via cpu_percent Azure Monitor-måttet för enskilda databaser och elastiska pooler på poolnivå.

En mer detaljerad uppdelning av den senaste resursförbrukningen efter användararbetsbelastningar och interna processer rapporteras i vyerna sys.dm_resource_governor_resource_pools_history_ex och sys.dm_resource_governor_workload_groups_history_ex . Mer information om resurspooler och arbetsbelastningsgrupper som refereras i dessa vyer finns i Resursstyrning. Dessa vyer rapporterar om resursutnyttjande efter användararbetsbelastningar och specifika interna processer i associerade resurspooler och arbetsbelastningsgrupper.

När det gäller prestandaövervakning och felsökning är det viktigt att ta hänsyn till både användarens CPU-förbrukning (avg_cpu_percent, cpu_percent) och den totala CPU-förbrukningen efter användararbetsbelastningar och interna processer (avg_instance_cpu_percent,sqlserver_process_core_percent).

Användarens CPU-förbrukning beräknas som en procentandel av användararbetsbelastningsgränserna i varje tjänstmål. Användning av användar-CPU på 100 % anger att användararbetsbelastningen har nått gränsen för tjänstmålet. Men när den totala CPU-förbrukningen når intervallet 70–100 % går det att se hur dataflödet för användararbetsbelastningar planar ut och frågesvarstiden ökar, även om den rapporterade cpu-förbrukningen för användare ligger betydligt under 100 %. Detta är mer sannolikt när du använder mindre tjänstmål med en måttlig allokering av beräkningsresurser, men relativt intensiva användararbetsbelastningar, till exempel i täta elastiska pooler. Detta kan också inträffa med mindre tjänstmål när interna processer tillfälligt kräver ytterligare resurser, till exempel när du skapar en ny replik av databasen eller säkerhetskopierar databasen.

När den totala CPU-förbrukningen är hög är åtgärdsalternativen desamma som anges i avsnittet Beräknings-CPU och inkluderar ökning av tjänstmål och/eller optimering av användararbetsbelastningar.

Resursstyrning

För att framtvinga resursgränser använder Azure SQL Database en implementering av resursstyrning som baseras på SQL Server Resource Governor, ändras och utökas för att köras i molnet. I SQL Database tillhandahåller flera resurspooler och arbetsbelastningsgrupper, med resursgränser angivna på både pool- och gruppnivå, en balanserad databas som en tjänst. Användararbetsbelastningar och interna arbetsbelastningar klassificeras i separata resurspooler och arbetsbelastningsgrupper. Användararbetsbelastningen på de primära och läsbara sekundära replikerna, inklusive geo-repliker, klassificeras i resurspoolen SloSharedPool1 och UserPrimaryGroup.DBId[N] arbetsbelastningsgrupperna, där [N] står för databas-ID-värdet. Dessutom finns det flera resurspooler och arbetsbelastningsgrupper för olika interna arbetsbelastningar.

Förutom att använda Resource Governor för att styra resurser i databasmotorn använder Azure SQL Database även Windows jobbobjekt för resursstyrning på processnivå och Windows Filserver Resource Manager (FSRM) för lagringskvot Management.

Azure SQL Database resursstyrning är hierarkisk. Uppifrån och ned framtvingas begränsningar på operativsystemnivå och på lagringsvolymnivå med hjälp av mekanismer för styrning av operativsystemresurser och Resource Governor, sedan på resurspoolsnivå med Resource Governor och sedan på arbetsbelastningsgruppsnivå med hjälp av Resource Governor. Gällande resursstyrningsgränser för den aktuella databasen eller den elastiska poolen rapporteras i sys.dm_user_db_resource_governance vy.

Data-I/O-styrning

Data-I/O-styrning är en process i Azure SQL Database som används för att begränsa både läsning och skrivning av fysisk I/O mot datafiler i en databas. IOPS-gränser anges för varje tjänstnivå för att minimera effekten av "bullriga grannar", för att ge resursallokering rättvisa i en tjänst för flera innehavare och för att hålla sig inom funktionerna i den underliggande maskinvaran och lagringen.

För enskilda databaser tillämpas arbetsbelastningsgruppens gränser på alla lagrings-I/O mot databasen. För elastiska pooler gäller begränsningar för arbetsbelastningsgrupper för varje databas i poolen. Dessutom gäller resurspoolgränsen för den elastiska poolens kumulativa I/O. I tempdbomfattas I/O av begränsningar för arbetsbelastningsgrupper, med undantag för tjänstnivån Basic, Standard och Generell användning, där högre tempdb I/O-gränser gäller. I allmänhet kanske resurspoolsgränser inte kan uppnås av arbetsbelastningen mot en databas (antingen enskild eller poolad), eftersom arbetsbelastningsgruppens gränser är lägre än resurspoolens gränser och begränsar IOPS/dataflöde tidigare. Poolgränser kan dock nås av den kombinerade arbetsbelastningen mot flera databaser i samma pool.

Om en fråga till exempel genererar 1 000 IOPS utan I/O-resursstyrning, men arbetsbelastningsgruppens maximala IOPS-gräns är inställd på 900 IOPS, kan frågan inte generera mer än 900 IOPS. Men om den maximala IOPS-gränsen för resurspoolen är inställd på 1 500 IOPS och den totala I/O från alla arbetsbelastningsgrupper som är associerade med resurspoolen överskrider 1 500 IOPS, kan I/O för samma fråga minskas under arbetsgruppsgränsen på 900 IOPS.

Maxvärdena för IOPS och dataflöde som returneras av sys.dm_user_db_resource_governance-vyn fungerar som gränser/tak, inte som garantier. Dessutom garanterar resursstyrning inte någon specifik lagringsfördröjning. Den bästa möjliga svarstiden, IOPS och dataflödet för en viss användararbetsbelastning beror inte bara på I/O-resursstyrningsgränser, utan även på blandningen av I/O-storlekar som används och på funktionerna i den underliggande lagringen. SQL Database använder I/Os som varierar i storlek mellan 512 KB och 4 MB. För att framtvinga IOPS-gränser redovisas varje I/O oavsett storlek, med undantag för databaser med datafiler i Azure Storage. I så fall redovisas IO:er som är större än 256 kB som flera I/Os på 256 kB, så att de överensstämmer med Azure Storage I/O-redovisning.

För basic-, standard- och Generell användning-databaser, som använder datafiler i Azure Storage, primary_group_max_io kanske värdet inte kan uppnås om en databas inte har tillräckligt med datafiler för att kumulativt ange det här antalet IOPS, eller om data inte fördelas jämnt mellan filer, eller om prestandanivån för underliggande blobar begränsar IOPS/dataflöde under resursstyrningsgränserna. På samma sätt kan värdet inte uppnås av en arbetsbelastning på grund av IOPS-gränsen för den underliggande Azure Storage bloben med primary_max_log_rate små logg-IOS:er som genereras av frekventa transaktionsgenomcheckningar. För databaser som använder Azure Premium Storage använder Azure SQL Database tillräckligt stora lagringsblobar för att få nödvändig IOPS/dataflöde, oavsett databasstorlek. För större databaser skapas flera datafiler för att öka den totala IOPS/dataflödeskapaciteten.

Resursanvändningsvärden som och avg_log_write_percent, som avg_data_io_percent rapporteras i sys.dm_db_resource_stats, sys.resource_stats och sys.elastic_pool_resource_stats vyer, beräknas som procentandelar av maximala resursstyrningsgränser. När andra faktorer än resursstyrning begränsar IOPS/dataflöde är det därför möjligt att se att IOPS/dataflödet planar ut och svarstiderna ökar när arbetsbelastningen ökar, även om den rapporterade resursanvändningen ligger kvar under 100 %.

Använd funktionen sys.dm_io_virtual_file_stats() för att fastställa läsning och skrivning av IOPS, dataflöde och svarstid per databasfil. Den här funktionen visar all I/O mot databasen, inklusive bakgrunds-I/O som inte redovisas mot avg_data_io_percent, men som använder IOPS och dataflöde för den underliggande lagringen och kan påverka observerad lagringsfördröjning. Funktionen rapporterar ytterligare svarstid som kan introduceras av I/O-resursstyrning för läsningar och skrivningar i kolumnerna io_stall_queued_read_ms och io_stall_queued_write_ms .

Styrning av transaktionslogghastighet

Styrning av transaktionslogghastighet är en process i Azure SQL Database som används för att begränsa höga inmatningshastigheter för arbetsbelastningar som massinfogning, SELECT INTO och indexversioner. Dessa gränser spåras och framtvingas på undersekundersnivå till genereringshastigheten för loggposter, vilket begränsar dataflödet oavsett hur många IO:er som kan utfärdas mot datafiler. Genereringshastigheter för transaktionsloggar skalas för närvarande linjärt upp till en punkt som är maskinvaruberoende och tjänstnivåberoende.

Logghastigheter anges så att de kan uppnås och upprätthållas i en mängd olika scenarier, medan det övergripande systemet kan behålla sina funktioner med minimerad inverkan på användarbelastningen. Logghastighetsstyrning säkerställer att säkerhetskopior av transaktionsloggar håller sig inom publicerade serviceavtal för återställning. Den här styrningen förhindrar också överdriven kvarvarande uppgifter på sekundära repliker, vilket annars kan leda till längre stilleståndstid än förväntat under redundansväxlingar.

De faktiska fysiska I/O:erna till transaktionsloggfilerna styrs inte eller begränsas. När loggposter genereras utvärderas och utvärderas varje åtgärd för om den ska fördröjas för att upprätthålla en maximal önskad logghastighet (MB/s per sekund). Fördröjningarna läggs inte till när loggposterna töms till lagring, snarare tillämpas logghastighetsstyrning under själva logghastighetsgenereringen.

De faktiska logggenereringshastigheterna som tillämpas vid körning kan också påverkas av feedbackmekanismer, vilket tillfälligt minskar de tillåtna logghastigheterna så att systemet kan stabiliseras. Loggfilsutrymmeshantering, undvika att få slut på loggutrymmesvillkor och datareplikeringsmekanismer kan tillfälligt minska de övergripande systemgränserna.

Trafikformningen för logghastighetsregulatorn visas via följande väntetyper (exponeras i sys.dm_exec_requests och sys.dm_os_wait_stats vyer):

Väntetyp Kommentarer
LOG_RATE_GOVERNOR Databasbegränsning
POOL_LOG_RATE_GOVERNOR Poolbegränsning
INSTANCE_LOG_RATE_GOVERNOR Instansnivåbegränsning
HADR_THROTTLE_LOG_RATE_SEND_RECV_QUEUE_SIZE Feedbackkontroll, fysisk replikering av tillgänglighetsgrupp i Premium/Affärskritisk håller inte jämna steg
HADR_THROTTLE_LOG_RATE_LOG_SIZE Feedbackkontroll, begränsningsfrekvens för att undvika ett fel i loggutrymmet
HADR_THROTTLE_LOG_RATE_MISMATCHED_SLO Feedbackkontroll för geo-replikering, begränsa loggfrekvensen för att undvika hög datasvarstid och otillgänglighet för geo-sekundärfiler

När du stöter på en logghastighetsgräns som hämmar önskad skalbarhet bör du överväga följande alternativ:

  • Skala upp till en högre tjänstnivå för att få den maximala logghastigheten för en tjänstnivå eller växla till en annan tjänstnivå. Tjänstnivån Hyperskala ger en loggfrekvens på 100 MB/s oavsett vilken tjänstnivå som valts.
  • Om data som läses in är tillfälliga, till exempel mellanlagring av data i en ETL-process, kan de läsas in i tempdb (som är minimalt loggade).
  • För analysscenarier läser du in i en grupperad kolumnlagringstabell eller en tabell med index som använder datakomprimering. Detta minskar logghastigheten som krävs. Den här tekniken ökar processoranvändningen och gäller endast för datauppsättningar som drar nytta av grupperade kolumnlagringsindex eller datakomprimering.

Storage utrymmesstyrning

I Premium och Affärskritisk tjänstnivåer lagras kunddata, inklusive datafiler, transaktionsloggfiler och tempdb-filer på den lokala SSD-lagringen på den dator som är värd för databasen eller den elastiska poolen. Lokal SSD-lagring ger hög IOPS och dataflöde och låg I/O-svarstid. Förutom kunddata används lokal lagring för operativsystemet, hanteringsprogram, övervakningsdata och loggar samt andra filer som krävs för systemdrift.

Storleken på lokal lagring är begränsad och beror på maskinvarufunktioner, som avgör den maximala lokala lagringsgränsen eller lokal lagring som reserverats för kunddata. Den här gränsen är inställd för att maximera kundens datalagring, samtidigt som säker och tillförlitlig systemdrift säkerställs. Information om hur du hittar det högsta lokala lagringsvärdet för varje tjänstmål finns i dokumentationen om resursbegränsningar för enskilda databaser och elastiska pooler.

Du kan också hitta det här värdet och mängden lokal lagring som för närvarande används av en viss databas eller elastisk pool med hjälp av följande fråga:

SELECT server_name, database_name, slo_name, user_data_directory_space_quota_mb, user_data_directory_space_usage_mb
FROM sys.dm_user_db_resource_governance
WHERE database_id = DB_ID();
Kolumn Beskrivning
server_name Namn på logisk server
database_name Databasnamn
slo_name Namn på tjänstmål, inklusive maskinvarugenerering
user_data_directory_space_quota_mb Maximal lokal lagring i MB
user_data_directory_space_usage_mb Aktuell lokal lagringsförbrukning efter datafiler, transaktionsloggfiler och tempdb filer i MB. Uppdaterad var femte minut.

Den här frågan ska köras i användardatabasen, inte i huvuddatabasen. För elastiska pooler kan frågan köras i valfri databas i poolen. Rapporterade värden gäller för hela poolen.

Viktigt

Om arbetsbelastningen i Premium och Affärskritisk tjänstnivåer försöker öka den kombinerade lokala lagringsförbrukningen efter datafiler, transaktionsloggfiler och tempdb filer över den maximala lokala lagringsgränsen uppstår ett fel som inte är tillgängligt.

Lokal SSD-lagring används också av databaser på andra tjänstnivåer än Premium och Affärskritisk för tempdb-databasen och Hyperskala RBPEX-cachen. När databaser skapas, tas bort och ökar eller minskar i storlek varierar den totala lokala lagringsförbrukningen på en dator över tid. Om systemet upptäcker att den tillgängliga lokala lagringen på en dator är låg och en databas eller en elastisk pool riskerar att få slut på utrymme, flyttas databasen eller den elastiska poolen till en annan dator med tillräckligt med lokalt lagringsutrymme tillgängligt.

Den här flytten sker online, på samma sätt som en databasskalningsåtgärd, och har en liknande inverkan, inklusive en kort (sekunder) redundansväxling i slutet av åtgärden. Den här redundansväxlingen avslutar öppna anslutningar och återställer transaktioner, vilket kan påverka program som använder databasen vid den tidpunkten.

Eftersom alla data kopieras till lokala lagringsvolymer på olika datorer kan det ta lång tid att flytta större databaser i Premium och Affärskritisk tjänstnivåer. Om den lokala utrymmesförbrukningen för en databas eller en elastisk pool, eller av tempdb databasen växer snabbt, ökar risken för att utrymmet börjar ta slut under den tiden. Systemet initierar databasflytt på ett balanserat sätt för att minimera out-of-space-fel samtidigt som onödiga redundansväxlingar undviks.

Tempdb-storlekar

Storleksgränserna för tempdb i Azure SQL Database beror på inköps- och distributionsmodellen.

Mer information finns i storleksgränser tempdb för:

Nästa steg