Resourcebeheer in Azure SQL Database

Van toepassing op: Azure SQL Database

Dit artikel bevat een overzicht van resourcebeheer in Azure SQL Database. Het biedt informatie over wat er gebeurt wanneer resourcelimieten worden bereikt en beschrijft mechanismen voor resourcebeheer die worden gebruikt om deze limieten af te dwingen.

Voor specifieke resourcelimieten per prijscategorie (ook wel servicedoelstelling genoemd) voor individuele databases raadpleegt u op DTU gebaseerde resourcelimieten voor individuele databases of vCore-resourcelimieten voor individuele databases. Raadpleeg voor resourcelimieten voor elastische pools de resourcelimieten op basis van DTU of resourcelimieten voor elastische pools op basis van vCore. Zie capaciteitslimieten en geheugen- en gelijktijdigheidslimieten voor toegewezen SQL-pools in Azure Synapse Analytics.

Limieten voor logische servers

¹ Databases en elastische pools die zijn ingericht met het DTU-aankoopmodel , worden ook meegeteld voor het vCore-quotum en omgekeerd. Elke verbruikte vCore wordt beschouwd als equivalent aan 100 DTU's die worden gebruikt voor het quotum op serverniveau.

² Dit omvat zowel de vCores die zijn geconfigureerd voor ingerichte rekendatabases/elastische pools als de 'max. vCores' die zijn geconfigureerd voor serverloze databases.

Wat gebeurt er wanneer resourcelimieten worden bereikt

CPU berekenen

Wanneer het CPU-gebruik van de database hoog wordt, neemt de querylatentie toe en kunnen query's zelfs een time-out veroorzaken. Onder deze voorwaarden kunnen query's in de wachtrij worden geplaatst door de service en worden resources geleverd voor uitvoering wanneer resources gratis worden. Als u een hoog rekengebruik ziet, zijn de risicobeperkingsopties onder andere:

• Verhoog de rekenkracht van de database of elastische pool om de database meer rekenresources te bieden. Zie Resources voor één database schalen en Elastische poolbronnen schalen.
• Query's optimaliseren om het CPU-resourcegebruik van elke query te verminderen. Zie Afstemmen van query's en query-hints voor meer informatie.

Storage

Wanneer de gebruikte gegevensruimte de maximale limiet voor gegevensgrootte bereikt, hetzij op databaseniveau of op het niveau van de elastische pool, voegt u in en werkt u updates die de gegevensgrootte vergroten, mislukken en ontvangen clients een foutbericht. SELECT- en DELETE-instructies blijven ongewijzigd.

In Premium- en Bedrijfskritiek-servicelagen ontvangen clients ook een foutbericht als het gecombineerde opslagverbruik per gegevens, transactielogboek en tempdb voor één database of een elastische pool de maximale lokale opslaggrootte overschrijdt. Zie Opslagruimtebeheer voor meer informatie.

Als u een hoog gebruik van opslagruimte bekijkt, zijn de risicobeperkingsopties onder andere:

• Verhoog de maximale gegevensgrootte van de database of elastische pool of schaal omhoog naar een servicedoelstelling met een hogere maximale gegevensgroottelimiet. Zie Resources voor één database schalen en Elastische poolbronnen schalen.
• Als de database zich in een elastische pool bevindt, kan de database ook buiten de pool worden verplaatst, zodat de opslagruimte niet wordt gedeeld met andere databases.
• Verklein een database om ongebruikte ruimte vrij te maken. In elastische pools biedt het verkleinen van een database meer opslagruimte voor andere databases in de pool. Zie Bestandsruimte beheren in Azure SQL Database voor meer informatie.
• Controleer of het gebruik van hoge ruimte wordt veroorzaakt door een piek in de grootte van Persistent Version Store (PVS). PVS maakt deel uit van elke database en wordt gebruikt voor het implementeren van versneld databaseherstel. Zie PVS-probleemoplossing om de huidige PVS-grootte te bepalen. Een veelvoorkomende reden voor grote PVS-grootte is een transactie die gedurende lange tijd (uren) is geopend, waardoor het opschonen van oudere versies van rijen in PVS wordt voorkomen.
• Voor databases en elastische pools in Premium- en Bedrijfskritiek-servicelagen die grote hoeveelheden opslagruimte verbruiken, kan er een out-of-space-fout optreden, ook al is de gebruikte ruimte in de database of elastische pool lager dan de maximale gegevensgroottelimiet. Dit kan gebeuren als tempdb of transactielogboekbestanden een grote hoeveelheid opslagruimte verbruiken voor de maximale lokale opslaglimiet. Voer een failover uit voor de database of elastische pool om de oorspronkelijke kleinere grootte te herstellen tempdb of verklein het transactielogboek om het lokale opslagverbruik te verminderen.

Sessies, werknemers en aanvragen

Sessies, werknemers en aanvragen worden als volgt gedefinieerd:

• Een sessie vertegenwoordigt een proces dat is verbonden met de database-engine.
• Een aanvraag is de logische weergave van een query of batch. Een aanvraag wordt uitgegeven door een client die is verbonden met een sessie. Na verloop van tijd kunnen er meerdere aanvragen worden uitgegeven in dezelfde sessie.
• Een werkrolthread, ook wel een werkrol of thread genoemd, is een logische weergave van een besturingssysteemthread. Een aanvraag kan veel werkrollen hebben wanneer deze wordt uitgevoerd met een parallel uitvoeringsplan voor query's of één werkrol wanneer deze wordt uitgevoerd met een serieel (één threaded) uitvoeringsplan. Werknemers zijn ook vereist om activiteiten buiten aanvragen te ondersteunen: een werknemer is bijvoorbeeld vereist om een aanmeldingsaanvraag te verwerken wanneer een sessie verbinding maakt.

Zie de handleiding thread- en taakarchitectuur voor meer informatie over deze concepten.

Het maximum aantal werkrollen wordt bepaald door de servicelaag en rekenkracht. Nieuwe aanvragen worden geweigerd wanneer sessie- of werklimieten zijn bereikt en de clients een foutbericht ontvangen. Hoewel het aantal verbindingen kan worden beheerd door de toepassing, is het aantal gelijktijdige werknemers vaak moeilijker te schatten en te beheren. Dit geldt met name tijdens piekbelastingsperioden wanneer databaseresourcelimieten worden bereikt en werkrollen zich opstapelen vanwege langere query's, grote blokkerende ketens of overmatige parallelle uitvoering van query's.

U kunt het benaderen of bereiken van werk- of sessielimieten beperken door:

• De servicelaag of rekenkracht van de database of elastische pool vergroten. Zie Resources voor één database schalen en Elastische poolbronnen schalen.
• Query's optimaliseren om het resourcegebruik te verminderen als de oorzaak van toegenomen werkrollen conflicten is voor rekenresources. Zie Afstemmen van query's en query-hints voor meer informatie.
• Optimaliseer de queryworkload om het aantal exemplaren en de duur van het blokkeren van query's te verminderen. Zie Azure SQL-blokkeringsproblemen begrijpen en oplossen voor meer informatie.
• Verminder de MAXDOP-instelling indien van toepassing.

Werkrol- en sessielimieten zoeken voor Azure SQL Database op servicelaag en rekenkracht:

• Resourcelimieten voor individuele databases met gebruikmaking van het vCore-aankoopmodel
• Resourcelimieten voor elastische pools met gebruikmaking van het vCore-aankoopmodel
• Resourcelimieten voor afzonderlijke databases met behulp van het DTU-aankoopmodel
• Resourceslimieten voor elastische pools met behulp van het DTU-aankoopmodel

Meer informatie over het oplossen van specifieke fouten voor sessie- of werkrollimieten in resourcebeheerfouten.

Externe verbindingen

Het aantal gelijktijdige verbindingen met externe eindpunten dat via sp_invoke_external_rest_endpoint wordt uitgevoerd, wordt beperkt tot 10% van de werkrolthreads, met een vaste limiet van maximaal 150 werkrollen.

Geheugen

In tegenstelling tot andere resources (CPU, werkrollen, opslag), heeft het bereiken van de geheugenlimiet geen negatieve invloed op de queryprestaties en veroorzaakt dit geen fouten en fouten. Zoals beschreven in de architectuurhandleiding voor geheugenbeheer, gebruikt de database-engine vaak standaard al het beschikbare geheugen. Geheugen wordt voornamelijk gebruikt voor het opslaan van gegevens in de cache om tragere opslagtoegang te voorkomen. Daarom verbetert een hoger geheugengebruik doorgaans de queryprestaties, vanwege snellere leesbewerkingen vanuit het geheugen, in plaats van langzamere leesbewerkingen vanuit de opslag.

Na het opstarten van de database-engine, terwijl de workload begint met het lezen van gegevens uit de opslag, slaat de database-engine gegevens in het geheugen agressief op in de cache. Na deze eerste opstartperiode is het gebruikelijk dat de avg_memory_usage_percent kolommen avg_instance_memory_percent in sys.dm_db_resource_stats en de sql_instance_memory_percent metrische gegevens van Azure Monitor bijna 100% zijn, met name voor databases die niet inactief zijn en die niet volledig in het geheugen passen.

Naast de gegevenscache wordt geheugen gebruikt in andere onderdelen van de database-engine. Wanneer er behoefte is aan geheugen en al het beschikbare geheugen door de gegevenscache is gebruikt, vermindert de database-engine de grootte van de gegevenscache om geheugen beschikbaar te maken voor andere onderdelen en groeit de gegevenscache dynamisch wanneer andere onderdelen geheugen vrijlaten.

In zeldzame gevallen kan een zeer veeleisende workload zorgen voor onvoldoende geheugen, wat leidt tot fouten vanwege te weinig geheugen. Fouten met onvoldoende geheugen kunnen optreden op elk niveau van geheugengebruik tussen 0% en 100%. Onvoldoende geheugenfouten treden waarschijnlijk op bij kleinere rekenkracht die proportioneel kleinere geheugenlimieten hebben en/of met workloads die meer geheugen gebruiken voor het verwerken van query's, zoals in dichte elastische pools.

Als u fouten met onvoldoende geheugen krijgt, zijn de risicobeperkingsopties onder andere:

• Bekijk de details van de OOM-voorwaarde in sys.dm_os_out_of_memory_events.
• De servicelaag of rekenkracht van de database of elastische pool vergroten. Zie Resources voor één database schalen en Elastische poolbronnen schalen.
• Query's en configuratie optimaliseren om het geheugengebruik te verminderen. Algemene oplossingen worden beschreven in de volgende tabel.

Resourceverbruik door gebruikersworkloads en interne processen

Voor Azure SQL Database zijn rekenresources vereist voor het implementeren van kernservicefuncties zoals hoge beschikbaarheid en herstel na noodgevallen, back-up en herstel van databases, bewaking, Query Store, Automatisch afstemmen, enzovoort. Het systeem zet een beperkt deel van de totale resources voor deze interne processen opzij met behulp van mechanismen voor resourcebeheer , waardoor de rest van de resources beschikbaar is voor gebruikersworkloads. Op momenten dat interne processen geen rekenresources gebruiken, maakt het systeem deze beschikbaar voor gebruikersworkloads.

Het totale CPU- en geheugenverbruik door gebruikersworkloads en interne processen wordt gerapporteerd in de sys.dm_db_resource_stats en sys.resource_stats weergaven, in avg_instance_cpu_percent en avg_instance_memory_percent kolommen. Deze gegevens worden ook gerapporteerd via de sql_instance_cpu_percent metrische gegevens van sql_instance_memory_percent Azure Monitor voor individuele databases en elastische pools op poolniveau.

CPU- en geheugenverbruik door gebruikersworkloads in elke database worden gerapporteerd in de sys.dm_db_resource_stats en sys.resource_stats weergaven, in avg_cpu_percent en avg_memory_usage_percent kolommen. Voor elastische pools wordt resourceverbruik op poolniveau gerapporteerd in de sys.elastic_pool_resource_stats weergave (voor historische rapportagescenario's) en in sys.dm_elastic_pool_resource_stats voor realtime bewaking. Cpu-verbruik van gebruikersworkloads wordt ook gerapporteerd via de cpu_percent metrische gegevens van Azure Monitor voor individuele databases en elastische pools op poolniveau.

Een gedetailleerdere uitsplitsing van recent resourceverbruik door gebruikersworkloads en interne processen wordt gerapporteerd in de sys.dm_resource_governor_resource_pools_history_ex - en sys.dm_resource_governor_workload_groups_history_ex weergaven. Zie Resourcebeheer voor meer informatie over resourcegroepen en workloadgroepen waarnaar in deze weergaven wordt verwezen. Deze weergaven rapporteren over resourcegebruik door gebruikersworkloads en specifieke interne processen in de bijbehorende resourcegroepen en workloadgroepen.

Cpu-verbruik van gebruikers wordt gedefinieerd als een percentage voor de CPU-limiet van de gebruikersworkload in elke servicedoelstelling. Op dezelfde manier wordt het totale CPU-verbruik gedefinieerd als het percentage voor de CPU-limiet voor alle workloads. Omdat de twee limieten verschillen, worden de gebruiker en het totale CPU-verbruik gemeten op verschillende schalen en zijn ze niet rechtstreeks vergelijkbaar met elkaar.

Als het CPU-verbruik van de gebruiker 100% bereikt, betekent dit dat de gebruikersworkload volledig gebruikmaakt van de CPU-capaciteit die beschikbaar is in de geselecteerde servicedoelstelling, zelfs als het totale CPU-verbruik lager blijft dan 100%.

Wanneer het totale CPU-verbruik het bereik van 70-100% bereikt, is het mogelijk om de doorvoer van gebruikersworkloads af te vlakken en querylatentie te verhogen, zelfs als het CPU-verbruik van de gebruiker aanzienlijk lager is dan 100%. Dit is waarschijnlijker wanneer u kleinere servicedoelstellingen gebruikt met een gemiddelde toewijzing van rekenresources, maar relatief intensieve gebruikersworkloads, zoals in dichte elastische pools. Dit kan ook gebeuren met kleinere servicedoelstellingen wanneer voor interne processen tijdelijk extra resources nodig zijn, bijvoorbeeld bij het maken van een nieuwe replica van de database of het maken van een back-up van de database.

Ook wanneer het CPU-verbruik van de gebruiker het bereik van 70-100% bereikt, wordt de doorvoer van gebruikersworkloads afgevlakt en neemt de querylatentie toe, ook al is het totale CPU-verbruik mogelijk ruim onder de limiet.

Wanneer het CPU-verbruik van de gebruiker of het totale CPU-verbruik hoog is, zijn de risicobeperkingsopties hetzelfde als in de sectie Cpu-rekenkracht en omvatten het verhogen van de servicedoelstelling en/of optimalisatie van gebruikersworkloads.

Resourcebeheer

Voor het afdwingen van resourcelimieten maakt Azure SQL Database gebruik van een implementatie van resourcebeheer die is gebaseerd op SQL Server Resource Governor, gewijzigd en uitgebreid voor uitvoering in de cloud. In SQL Database bieden meerdere resourcegroepen en workloadgroepen, met resourcelimieten die zijn ingesteld op groep- en groepsniveaus, een evenwichtige Database-as-a-Service. Gebruikersworkloads en interne workloads worden geclassificeerd in afzonderlijke resourcegroepen en workloadgroepen. De werkbelasting van de gebruiker op de primaire en leesbare secundaire replica's, inclusief geo-replica's, wordt geclassificeerd in de SloSharedPool1 resourcegroep en UserPrimaryGroup.DBId[N] workloadgroepen, waar [N] de database-id-waarde staat. Daarnaast zijn er meerdere resourcegroepen en workloadgroepen voor verschillende interne workloads.

Naast het gebruik van Resource Governor om resources binnen de database-engine te beheren, maakt Azure SQL Database ook gebruik van Windows-taakobjecten voor resourcebeheer op procesniveau en Windows File Server Resource Manager (FSRM) voor opslagquotumbeheer.

Azure SQL Database-resourcebeheer is hiërarchisch van aard. Van boven naar beneden worden limieten afgedwongen op besturingssysteemniveau en op het niveau van het opslagvolume met behulp van mechanismen voor besturingssysteemresourcebeheer en Resource Governor, vervolgens op resourcegroepniveau met behulp van Resource Governor en vervolgens op het niveau van de workloadgroep met behulp van Resource Governor. Resourcebeheerlimieten die van kracht zijn voor de huidige database of elastische pool, worden gerapporteerd in de weergave sys.dm_user_db_resource_governance .

Gegevens-I/O-governance

Gegevens-I/O-beheer is een proces in Azure SQL Database dat wordt gebruikt om zowel lees- als schrijf-I/O te beperken voor gegevensbestanden van een database. IOPS-limieten worden ingesteld voor elk serviceniveau om het effect 'lawaaierige buren' te minimaliseren, om resourcetoewijzing eerlijk te maken in een service met meerdere tenants en om binnen de mogelijkheden van de onderliggende hardware en opslag te blijven.

Voor individuele databases worden limieten voor workloadgroepen toegepast op alle opslag-I/O's voor de database. Voor elastische pools gelden limieten voor werkbelastinggroepen voor elke database in de pool. Daarnaast is de limiet voor de resourcegroep ook van toepassing op de cumulatieve I/O van de elastische pool. In tempdb, I/O is onderworpen aan werkbelastinggroepslimieten, met uitzondering van de servicelaag Basic, Standard en Algemeen gebruik, waar hogere tempdb I/O-limieten van toepassing zijn. Over het algemeen kunnen resourcegroeplimieten mogelijk niet worden bereikt door de workload op basis van een database (enkel of gegroepeerd), omdat de limieten van de werkbelastinggroep lager zijn dan de limieten van de resourcegroep en de IOPS/doorvoer sneller beperken. Poollimieten kunnen echter worden bereikt door de gecombineerde workload ten opzichte van meerdere databases in dezelfde pool.

Als een query bijvoorbeeld 1000 IOPS genereert zonder I/O-resourcebeheer, maar de maximale IOPS-limiet voor de workloadgroep is ingesteld op 900 IOPS, kan de query niet meer dan 900 IOPS genereren. Als de maximale IOPS-limiet voor de resourcegroep echter is ingesteld op 1500 IOPS en de totale I/O van alle workloadgroepen die aan de resourcegroep zijn gekoppeld, groter is dan 1500 IOPS, kan de I/O van dezelfde query worden verminderd onder de werkgroeplimiet van 900 IOPS.

De IOPS- en doorvoerlimietwaarden die worden geretourneerd door de sys.dm_user_db_resource_governance weergave fungeren als limieten/limieten, niet als garanties. Bovendien garandeert resourcebeheer geen specifieke opslaglatentie. De best haalbare latentie, IOPS en doorvoer voor een bepaalde gebruikersworkload zijn niet alleen afhankelijk van I/O-resourcebeheerlimieten, maar ook van de combinatie van gebruikte I/O-grootten en de mogelijkheden van de onderliggende opslag. SQL Database maakt gebruik van I/O-bewerkingen die variëren in grootte tussen 512 bytes en 4 MB. Voor het afdwingen van IOPS-limieten wordt elke I/O verantwoordelijk, ongeacht de grootte, met uitzondering van databases met gegevensbestanden in Azure Storage. In dat geval worden IOS's die groter zijn dan 256 kB als meerdere I/Os van 256 kB opgegeven om te worden afgestemd op Azure Storage I/O-boekhouding.

Voor Basic-, Standard- en Algemeen gebruiksdatabases, die gebruikmaken van gegevensbestanden in Azure Storage, is de primary_group_max_io waarde mogelijk niet haalbaar als een database niet voldoende gegevensbestanden heeft om dit aantal IOPS cumulatief op te geven, of als gegevens niet gelijkmatig over bestanden worden gedistribueerd, of als de prestatielaag van onderliggende blobs IOPS/doorvoer onder de limieten voor resourcebeheer beperkt. Op dezelfde manier kunnen kleine I/O-bewerkingen voor logboeken die worden gegenereerd door frequente doorvoeringen van transacties, de primary_max_log_rate waarde mogelijk niet worden bereikt door een workload vanwege de IOPS-limiet voor de onderliggende Azure Storage-blob. Voor databases met Azure Premium Storage gebruikt Azure SQL Database voldoende grote opslagblobs om de benodigde IOPS/doorvoer te verkrijgen, ongeacht de grootte van de database. Voor grotere databases worden meerdere gegevensbestanden gemaakt om de totale IOPS-/doorvoercapaciteit te verhogen.

Waarden voor resourcegebruik, zoals avg_data_io_percent en avg_log_write_percent, gerapporteerd in de sys.dm_db_resource_stats, sys.resource_stats, sys.dm_elastic_pool_resource_stats en sys.elastic_pool_resource_stats weergaven, worden berekend als percentages van maximale resourcebeheerlimieten. Daarom is het mogelijk om, wanneer andere factoren dan resourcebeheer IOPS/doorvoer beperken, IOPS/doorvoer afvlakken en latenties toenemen naarmate de workload toeneemt, ook al blijft het gerapporteerde resourcegebruik lager dan 100%.

Gebruik de functie sys.dm_io_virtual_file_stats() om de IOPS, doorvoer en latentie per databasebestand te controleren. Met deze functie wordt alle I/O voor de database weergegeven, inclusief achtergrond-I/O die niet is verantwoordelijk voor avg_data_io_percent, maar IOPS en doorvoer van de onderliggende opslag gebruikt, en kan dit van invloed zijn op waargenomen opslaglatentie. De functie rapporteert extra latentie die kan worden geïntroduceerd door I/O-resourcebeheer voor lees- en schrijfbewerkingen, respectievelijk in de io_stall_queued_read_ms en io_stall_queued_write_ms kolommen.

Beheer van transactielogboeksnelheid

Beheer van transactielogboeksnelheid is een proces in Azure SQL Database dat wordt gebruikt om hoge opnamesnelheden te beperken voor workloads zoals bulksgewijs invoegen, SELECT INTO en index builds. Deze limieten worden bijgehouden en afgedwongen op het niveau van de subseconde tot de snelheid van het genereren van logboekrecords, waardoor de doorvoer wordt beperkt, ongeacht het aantal IOS's dat kan worden uitgegeven voor gegevensbestanden. Het genereren van transactielogboeken wordt momenteel lineair geschaald tot een punt dat afhankelijk is van hardwareafhankelijke en servicelaagafhankelijk.

Logboeksnelheden worden zo ingesteld dat ze in verschillende scenario's kunnen worden bereikt en ondersteund, terwijl het algehele systeem de functionaliteit kan behouden met een geminimaliseerde impact op de gebruikersbelasting. Beheer van logboeksnelheid zorgt ervoor dat back-ups van transactielogboeken binnen gepubliceerde SLA's voor herstelmogelijkheden blijven. Deze governance voorkomt ook een overmatige achterstand op secundaire replica's die anders leiden tot langere dan verwachte downtime tijdens failovers.

De werkelijke fysieke IOs voor transactielogboekbestanden zijn niet beheerd of beperkt. Wanneer logboekrecords worden gegenereerd, wordt elke bewerking geëvalueerd en beoordeeld of deze moet worden vertraagd om een maximale gewenste logboeksnelheid (MB/s per seconde) te behouden. De vertragingen worden niet toegevoegd wanneer de logboekrecords worden leeggemaakt naar de opslag, maar beheer van logboeksnelheid wordt toegepast tijdens het genereren van logboeksnelheid zelf.

De werkelijke snelheid voor het genereren van logboeken tijdens runtime kan ook worden beïnvloed door feedbackmechanismen, waardoor de toegestane logboeksnelheden tijdelijk worden verminderd, zodat het systeem zich kan stabiliseren. Beheer van de ruimte voor logboekbestanden, om te voorkomen dat er onvoldoende ruimte is voor logboeken en mechanismen voor gegevensreplicatie kunnen de algemene systeemlimieten tijdelijk verlagen.

Het vormgeven van verkeer van logboeksnelheid wordt weergegeven via de volgende wachttypen (weergegeven in de sys.dm_exec_requests en sys.dm_os_wait_stats weergaven):

Houd rekening met de volgende opties bij het tegenkomen van een logboeksnelheidslimiet die de gewenste schaalbaarheid belemmert:

• Schaal omhoog naar een hoger serviceniveau om de maximale logboeksnelheid van een servicelaag te verkrijgen of over te schakelen naar een andere servicelaag. De Hyperscale-servicelaag biedt een logboeksnelheid van 100 MB/s per database en 125 MB/s per elastische pool, ongeacht het gekozen serviceniveau.

  Notitie

  Elastische pools voor Hyperscale zijn momenteel beschikbaar als preview-versie.

• Als de gegevens die worden geladen, tijdelijk zijn - zoals faseringsgegevens in een ETL-proces - kunnen ze worden geladen in tempdb (wat minimaal wordt vastgelegd).

• Voor analysescenario's laadt u in een geclusterde tabel columnstore of een tabel met indexen die gegevenscompressie gebruiken. Dit vermindert de vereiste logboeksnelheid. Deze techniek verhoogt het CPU-gebruik en is alleen van toepassing op gegevenssets die profiteren van geclusterde columnstore-indexen of gegevenscompressie.

Governance van opslagruimte

In Premium- en Bedrijfskritiek-servicelagen worden klantgegevens, waaronder gegevensbestanden, transactielogboekbestanden en tempdb bestanden, opgeslagen op de lokale SSD-opslag van de computer die als host fungeert voor de database of elastische pool. Lokale SSD-opslag biedt hoge IOPS en doorvoer en lage I/O-latentie. Naast klantgegevens wordt lokale opslag gebruikt voor het besturingssysteem, beheersoftware, bewakingsgegevens en logboeken en andere bestanden die nodig zijn voor systeembewerking.

De grootte van lokale opslag is eindig en is afhankelijk van de hardwaremogelijkheden, die de maximale lokale opslaglimiet bepalen of lokale opslag die is gereserveerd voor klantgegevens. Deze limiet is ingesteld om de opslag van klantgegevens te maximaliseren, terwijl veilige en betrouwbare systeembewerkingen worden gegarandeerd. Zie de documentatie voor resourcelimieten voor individuele databases en elastische pools om de maximale lokale opslagwaarde voor elke servicedoelstelling te vinden.

U kunt deze waarde ook vinden en de hoeveelheid lokale opslag die momenteel wordt gebruikt door een bepaalde database of elastische pool, met behulp van de volgende query:

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();

Deze query moet worden uitgevoerd in de gebruikersdatabase, niet in de master database. Voor elastische pools kan de query worden uitgevoerd in elke database in de pool. Gerapporteerde waarden zijn van toepassing op de hele pool.

Lokale SSD-opslag wordt ook gebruikt door databases in andere servicelagen dan Premium en Bedrijfskritiek voor de tempdb database en Hyperscale RBPEX-cache. Naarmate databases worden gemaakt, verwijderd en groter of kleiner worden, fluctueert het totale lokale opslagverbruik op een machine in de loop van de tijd. Als het systeem detecteert dat de beschikbare lokale opslag op een computer laag is en een database of elastische pool geen ruimte meer heeft, verplaatst het de database of elastische pool naar een andere computer met voldoende lokale opslag.

Deze verplaatsing vindt plaats op een online manier, vergelijkbaar met een databaseschaalbewerking en heeft een vergelijkbare impact, waaronder een korte (seconden) failover aan het einde van de bewerking. Met deze failover worden geopende verbindingen beëindigd en worden transacties teruggedraaid die mogelijk van invloed zijn op toepassingen die de database op dat moment gebruiken.

Omdat alle gegevens worden gekopieerd naar lokale opslagvolumes op verschillende computers, kan het verplaatsen van grotere databases in Premium- en Bedrijfskritiek servicelagen een aanzienlijke hoeveelheid tijd vergen. Als het verbruik van lokale ruimte door een database of elastische pool of door de tempdb database in die periode snel toeneemt, neemt het risico op onvoldoende ruimte toe. Het systeem initieert databaseverplaatsing op een evenwichtige manier om out-of-space-fouten te minimaliseren en onnodige failovers te voorkomen.

tempdb Maten

Groottelimieten voor tempdb in Azure SQL Database zijn afhankelijk van het aankoop- en implementatiemodel.

Bekijk tempdb de groottelimieten voor meer informatie voor:

• Aankoopmodel voor vCore: individuele databases, pooldatabases
• DTU-aankoopmodel: individuele databases, pooldatabases.

Eerder beschikbare hardware

Deze sectie bevat details over eerder beschikbare hardware.

• Gen4-hardware is buiten gebruik gesteld en is niet beschikbaar voor inrichting, schaalaanpassing of omlaag schalen. Migreer uw database naar een ondersteunde hardwaregeneratie voor een breder scala aan schaalbaarheid van vCore en opslag, versneld netwerken, de beste I/O-prestaties en minimale latentie. Zie Ondersteuning is beëindigd voor Gen 4-hardware in Azure SQL Database voor meer informatie.

U kunt Azure Resource Graph Explorer gebruiken om alle Azure SQL Database-resources te identificeren die momenteel gebruikmaken van Gen4-hardware, of u kunt de hardware controleren die wordt gebruikt door resources voor een specifieke logische server in Azure Portal.

U moet ten minste read machtigingen hebben voor het Azure-object of de objectgroep om resultaten te kunnen zien in Azure Resource Graph Explorer.

Als u Resource Graph Explorer wilt gebruiken om Azure SQL-resources te identificeren die nog steeds gebruikmaken van Gen4-hardware, voert u de volgende stappen uit:

1. Ga naar de Azure-portal.

2. Resource graph Zoek in het zoekvak en kies de Resource Graph Explorer-service in de zoekresultaten.

3. Typ in het queryvenster de volgende query en selecteer query uitvoeren:

   resources
   | where type contains ('microsoft.sql/servers')
   | where sku['family'] == "Gen4"
   

4. In het deelvenster Resultaten worden alle momenteel geïmplementeerde resources in Azure weergegeven die gebruikmaken van Gen4-hardware.

   

Voer de volgende stappen uit om de hardware te controleren die wordt gebruikt door resources voor een specifieke logische server in Azure:

1. Ga naar de Azure-portal.
2. SQL servers Zoek in het zoekvak en kies SQL-servers in de zoekresultaten om de pagina SQL-servers te openen en alle servers voor de gekozen abonnementen weer te geven.
3. Selecteer de gewenste server om de pagina Overzicht voor de server te openen.
4. Schuif omlaag naar de beschikbare resources en controleer de kolom Prijscategorie voor resources die gebruikmaken van gen4-hardware.

Als u resources wilt migreren naar hardware uit de standard-serie, raadpleegt u Hardware wijzigen.

Volgende stappen

• Zie Azure-abonnements- en servicelimieten, quota en beperkingen voor meer informatie over algemene Azure-limieten.
• Zie DTU's en eDTU's voor informatie over DTU's en eDTU's.
• Zie individuele vCore-databases, gegroepeerde vCore-databases, individuele DTU-databases en pooldatabases voor meer informatie over tempdb groottelimieten.