Deze browser wordt niet meer ondersteund.
Upgrade naar Microsoft Edge om te profiteren van de nieuwste functies, beveiligingsupdates en technische ondersteuning.
van toepassing op:
Azure SQL Database-
Dit artikel bevat een overzicht van het aankoopmodel op basis van DTU voor Azure SQL Database. Het aankoopmodel op basis van DTU is een eenvoudige, gebundelde meting van reken-, opslag- en I/O-resources. Het is het meest geschikt voor de meeste klanten met typische workloads. Het aankoopmodel op basis van DTU is beschikbaar in de servicelagen Basic, Standard en Premium. Het aankoopmodel op basis van DTU is ook beschikbaar voor elastische pools.
Het aankoopmodel op basis van DTU verschilt van het aankoopmodel op basis van vCore, zodat u aankoopmodellen kunt vergelijken.
Een database transaction unit (DTU) vertegenwoordigt een gemengde meting van CPU, geheugen, leesbewerkingen en schrijfbewerkingen. Servicelagen in het aankoopmodel op basis van DTU worden onderscheiden door een reeks rekengrootten met een vaste hoeveelheid inbegrepen opslag, vaste bewaarperiode voor back-ups en vaste prijs. Alle service-niveaus in het op DTU gebaseerde aankoopmodel bieden flexibiliteit bij het wijzigen van rekengrootten met minimale downtime; er is echter een overgangsperiode waarin de verbinding met de database voor korte tijd verloren gaat, wat kan worden beperkt met behulp van opnieuw proberen-logica. Individuele databases en elastische pools worden elk uur gefactureerd op basis van de servicelaag en rekenkracht.
Voor één database met een specifieke rekenkracht binnen een servicelaaggarandeert Azure SQL Database een bepaald niveau van resources voor die database (onafhankelijk van een andere database). Deze garantie biedt een voorspelbaar prestatieniveau. De hoeveelheid resources die voor een database zijn toegewezen, wordt berekend als een aantal DTU's en is een gebundelde meting van reken-, opslag- en I/O-resources.
De verhouding tussen deze resources wordt oorspronkelijk bepaald door een OLTP-benchmarkworkload (Online Transaction Processing) ontworpen om typisch te zijn voor echte OLTP-workloads. Wanneer uw workload de hoeveelheid van deze resources overschrijdt, wordt uw doorvoer beperkt, wat resulteert in tragere prestaties en time-outs.
Voor individuele databases zijn de resources die door uw workload worden gebruikt, niet van invloed op de resources die beschikbaar zijn voor andere databases in de Azure-cloud. Op dezelfde manier hebben de resources die door andere workloads worden gebruikt, geen invloed op de resources die beschikbaar zijn voor uw database.
DTU's zijn het handigst om inzicht te krijgen in de relatieve resources die zijn toegewezen voor databases met verschillende rekengrootten en servicelagen. Bijvoorbeeld:
Als u meer inzicht wilt krijgen in het DTU-verbruik (resourceverbruik) van uw workload, gebruikt u inzichten in queryprestaties om het volgende te doen:
In plaats van een toegewezen set middelen (DTU's) te bieden die mogelijk niet altijd nodig zijn, kunt u deze databases in een elastic poolplaatsen. De databases in een elastische pool gebruiken één exemplaar van de database-engine en delen dezelfde groep resources.
De gedeelde resources in een elastische pool worden gemeten door eDTU's (Elastic Database Transaction Units). Elastische pools bieden een eenvoudige, rendabele oplossing voor het beheren van prestatiedoelen voor meerdere databases met veel verschillende en onvoorspelbare gebruikspatronen. Een elastische pool garandeert dat alle resources niet kunnen worden gebruikt door één database in de pool, terwijl ervoor wordt gezorgd dat elke database in de pool altijd een minimale hoeveelheid benodigde resources heeft.
Een groep krijgt een vast aantal eDTU's voor een vaste prijs. In de elastische pool kunnen afzonderlijke databases automatisch worden geschaald binnen de geconfigureerde grenzen. Een database onder een zwaardere belasting verbruikt meer eDTU's om aan de vraag te voldoen. Databases onder lichtere belastingen verbruiken minder eDTU's. Databases zonder belasting verbruiken geen eDTU's. Omdat resources worden ingericht voor de hele pool, in plaats van per database, vereenvoudigen elastische pools uw beheertaken en bieden ze een voorspelbaar budget voor de pool.
U kunt meer eDTU's toevoegen aan een bestaande pool met minimale downtime van de database. Als u geen extra eDTU's meer nodig hebt, verwijdert u deze op elk gewenst moment uit een bestaande pool. U kunt ook op elk gewenst moment databases toevoegen aan of verwijderen uit een pool. Beperk het aantal eDTU's dat databases kunnen gebruiken onder zware belasting om eDTU's voor andere databases te reserveren. Als een database consistent hoog resourcegebruik heeft dat van invloed is op andere databases in de pool, verplaatst u deze uit de pool en configureert u deze als één database met een voorspelbare hoeveelheid vereiste resources.
Pools zijn zeer geschikt voor databases met een laag resourcegebruiksgemiddelde en relatief onregelmatige gebruikspieken. Zie Elastische pools in Azure SQL Database voor meer informatie
Als u een bestaande workload van een on-premises of sql Server-VM wilt migreren naar SQL Database, raadpleegt u aanbevelingen voor SKU's om het aantal benodigde DTU's bij benadering te bepalen. Voor een bestaande SQL Database-workload gebruikt u inzichten in queryprestaties om inzicht te krijgen in uw database-resourceverbruik (DTU's) en meer inzicht te krijgen in het optimaliseren van uw workload. Met de sys.dm_db_resource_stats dynamische beheerweergave (DMV) kunt u het resourceverbruik voor het afgelopen uur bekijken. De sys.resource_stats catalogusweergave geeft het resourceverbruik weer voor de afgelopen 14 dagen, maar met een lagere kwaliteit van gemiddelden van vijf minuten.
Gebruik de volgende formule om het gemiddelde percentage DTU/eDTU-gebruik te bepalen ten opzichte van de DTU/eDTU-limiet van een database of een elastische pool:
avg_dtu_percent = MAX(avg_cpu_percent, avg_data_io_percent, avg_log_write_percent)
De invoerwaarden voor deze formule kunnen worden verkregen uit sys.dm_db_resource_stats, sys.resource_statsen sys.elastic_pool_resource_stats DMV's. Met andere woorden, om het percentage DTU/eDTU-gebruik te bepalen voor de DTU/eDTU-limiet van een database of een elastische pool, kiest u de grootste percentagewaarde uit het volgende: avg_cpu_percent, avg_data_io_percenten avg_log_write_percent op een bepaald moment.
Notitie
De DTU-limiet van een database wordt bepaald door CPU, leesbewerkingen, schrijfbewerkingen en geheugen die beschikbaar zijn voor de database. Omdat de SQL Database-engine doorgaans echter al het beschikbare geheugen voor de gegevenscache gebruikt om de prestaties te verbeteren, is de waarde avg_memory_usage_percent meestal bijna 100 procent, ongeacht de huidige databasebelasting. Hoewel geheugen indirect invloed heeft op de DTU-limiet, wordt deze dus niet gebruikt in de formule DTU-gebruik.
In het aankoopmodel op basis van DTU kunnen klanten niet de hardwareconfiguratie kiezen die voor hun databases wordt gebruikt. Hoewel een bepaalde database meestal gedurende lange tijd op een specifiek type hardware blijft (meestal voor meerdere maanden), zijn er bepaalde gebeurtenissen die ertoe kunnen leiden dat een database naar verschillende hardware wordt verplaatst.
Een database kan bijvoorbeeld worden verplaatst naar verschillende hardware als deze omhoog of omlaag wordt geschaald naar een andere servicedoelstelling, of als de huidige infrastructuur in een datacenter de capaciteitslimieten nadert of als de momenteel gebruikte hardware buiten gebruik wordt gesteld vanwege het einde van de levensduur.
Als een database naar verschillende hardware wordt verplaatst, kunnen de prestaties van de werkbelasting veranderen. Het DTU-model garandeert dat de doorvoer- en reactietijd van de DTU-benchmark workload aanzienlijk identiek blijft wanneer de database wordt verplaatst naar een ander hardwaretype, zolang de servicedoelstelling (het aantal DTU's) hetzelfde blijft.
In het brede spectrum van klantworkloads die worden uitgevoerd in Azure SQL Database, kan de impact van het gebruik van verschillende hardware voor dezelfde servicedoelstelling echter duidelijker zijn. Verschillende workloads kunnen profiteren van verschillende hardwareconfiguraties en -functies. Daarom is het voor andere workloads dan de DTU-benchmarkmogelijk om prestatieverschillen te zien als de database van het ene type hardware naar het andere wordt verplaatst.
Klanten kunnen het vCore--model gebruiken om hun voorkeurshardwareconfiguratie te kiezen tijdens het maken en schalen van de database. In het vCore-model worden gedetailleerde resourcelimieten van elke servicedoelstelling in elke hardwareconfiguratie gedocumenteerd voor individuele databases en elastische pools. Zie Hardwareconfiguratievoor meer informatie.
Notitie
U kunt een gratis database in Azure SQL Database verkrijgen in de Basic-servicelaag met een gratis Azure-account. Zie Een beheerde clouddatabase maken met uw gratis Azure-accountvoor meer informatie.
Het kiezen van een servicelaag is voornamelijk afhankelijk van bedrijfscontinuïteit, opslag en prestatievereisten.
| Basisch | Standaard | Premie | |
|---|---|---|---|
| doelwerklast | Ontwikkeling en productie | Ontwikkeling en productie | Ontwikkeling en productie |
| SLA-voor uptime | 99.99% | 99.99% | 99.99% |
| back-up | U kunt kiezen voor geografisch redundante, zone-redundante of lokaal redundante back-upopslag met een bewaartermijn van 1-7 dagen (standaard is 7 dagen). Langetermijnretentie beschikbaar tot 10 jaar |
Een keuze uit geografisch redundante, zone-redundante of lokaal redundante back-upopslag, met een bewaarduur van 1-35 dagen (bij standaardinstelling 7 dagen) Langetermijnretentie beschikbaar tot 10 jaar |
Een keuze uit lokaal redundante opslag (LRS), zone-redundant (ZRS) of geografisch redundante opslag (GRS) Retentie van 1-35 dagen (standaard 7 dagen), met maximaal 10 jaar langetermijnretentie beschikbaar |
| CPU | Laag | Laag, Gemiddeld, Hoog | Gemiddeld, hoog |
| IOPS (bij benadering)1 | 1-4 IOPS per DTU | 1-4 IOPS per DTU | >25 IOPS per DTU |
| IO-latentie (bij benadering) | 5 ms (lezen), 10 ms (schrijven) | 5 ms (lezen), 10 ms (schrijven) | 2 ms (lezen/schrijven) |
| Columnstore-indexering2 | N.V.T | Standard S3 en hoger | Ondersteund |
| OLTP- in het geheugen | N.V.T. | Niet van Toepassing | Ondersteund |
1 Alle IOPS voor lezen en schrijven op gegevensbestanden, inclusief achtergrond-IO (controlepunt en luie schrijver).
2 Zie Servicelagen van databases wijzigen met columnstore-indexenvoor meer informatie.
Belangrijk
De servicedoelstellingen Basic, S0, S1 en S2 bieden minder dan één vCore (CPU). Voor CPU-intensieve workloads wordt een servicedoelstelling van S3 of hoger aanbevolen.
In de servicedoelstellingen Basic, S0 en S1 worden databasebestanden opgeslagen in Azure Standard Storage, die gebruikmaakt van opslagmedia op basis van harde schijven (HDD). Deze servicedoelstellingen zijn het meest geschikt voor ontwikkeling, testen en andere niet-frequent geopende workloads die minder gevoelig zijn voor de variabiliteit van de prestaties.
Tip
Als u de werkelijke resourcebeheer wilt bekijken limieten voor een database of elastische pool, voert u een query uit op de sys.dm_user_db_resource_governance weergave. Voor één database wordt één rij geretourneerd. Voor een database in een elastische pool wordt een rij geretourneerd voor elke database in de pool.
Resourcelimieten verschillen voor individuele en pooldatabases.
In Azure SQL Database worden rekengrootten uitgedrukt in DTU's (Database Transaction Units) voor individuele databases en eDTU's (Elastic Database Transaction Units) voor elastische pools. Raadpleeg Resourcelimieten voor individuele databasesvoor meer informatie.
| Basisch | Standaard | Premie | |
|---|---|---|---|
| Maximale opslagruimte | 2 GB | 1 TB | 4 TB |
| maximaal aantal DTUs | 5 | 3000 | 4000 |
Belangrijk
In sommige gevallen moet u een database mogelijk verkleinen om ongebruikte ruimte vrij te maken. Zie Bestandsruimte voor databases beheren in Azure SQL Databasevoor meer informatie.
Raadpleeg Resourcelimieten voor elastische pools met behulp van het DTU-aankoopmodelvoor meer informatie.
| Basis- | Standard | Premium | |
|---|---|---|---|
| Maximale opslaggrootte per database | 2 GB | 1 TB | 1 TB |
| Maximale opslaggrootte per pool | 156 GB | 4 TB | 4 TB |
| Maximum aantal eDTUs per database | 5 | 3000 | 4000 |
| Maximum aantal eDTU's per groep | 1600 | 3000 | 4000 |
| Maximum aantal databases per pool | 500 | 500 | 100 |
Belangrijk
Meer dan 1 TB opslagruimte in de Premium-laag is momenteel beschikbaar in alle regio's, met uitzondering van: China - oost, China - noord, Duitsland - centraal en Duitsland - noordoost. In deze regio's is de opslaglimiet in de Premium-laag beperkt tot 1 TB. Zie P11-P15 huidige beperkingenvoor meer informatie.
Belangrijk
In sommige gevallen moet u een database mogelijk verkleinen om ongebruikte ruimte vrij te maken. Zie bestandsruimte beheren in Azure SQL Databasevoor meer informatie.
Fysieke kenmerken (CPU, geheugen, IO) die aan elke DTU-meting zijn gekoppeld, worden gekalibreerd met behulp van een benchmark die de werkelijke databaseworkload simuleert.
Meer informatie over het schema, gebruikte transactietypen, workloadmix, gebruikers en pacing, schaalregels en metrische gegevens die zijn gekoppeld aan de DTU-benchmark.
Hoewel het aankoopmodel op basis van DTU is gebaseerd op een gebundelde meting van reken-, opslag- en I/O-resources, kunt u met behulp van het aankoopmodel voor vCore voor Azure SQL Database onafhankelijk reken- en opslagresources kiezen en schalen.
Met het aankoopmodel op basis van vCore kunt u ook Azure Hybrid Benefit- voor SQL Server gebruiken om kosten te besparen en biedt serverloze rekenlaag voor Azure SQL Database en Hyperscale-servicelaag opties voor Azure SQL Database die niet beschikbaar zijn in het aankoopmodel op basis van DTU.
Leer meer in over het vergelijken van vCore- en DTU-gebaseerde aankoopmodellen van Azure SQL Database.
Training
Module
SQL Server-resources configureren voor optimale prestaties - Training
SQL Server-resources configureren voor optimale prestaties
Certificering
Microsoft Certified: Azure Database Administrator Associate - Certifications
Beheer een SQL Server-databaseinfrastructuur voor cloud-, on-premises en hybride relationele databases met behulp van de relationele Microsoft PaaS-databaseaanbiedingen.
Documentatie
Aankoopmodel voor vCore - Azure SQL Database
Met het vCore-aankoopmodel kunt u reken- en opslagresources onafhankelijk schalen, overeenkomen met de on-premises prestaties en de prijs optimaliseren voor Azure SQL Database
Aankoopmodellen - Azure SQL Database
Meer informatie over de aankoopmodellen die beschikbaar zijn voor Azure SQL Database: het vCore-aankoopmodel en het DTU-aankoopmodel.
Migreren van DTU naar vCore - Azure SQL Database
Migreer een database in Azure SQL Database van het DTU-model naar het vCore-model. Migreren naar vCore is vergelijkbaar met upgraden of downgraden tussen de standard- en Premium-lagen.