SQL Database resurs gränser och resurs styrningSQL Database resource limits and resource governance

Den här artikeln innehåller en översikt över SQL Database resurs gränser för en SQL Database Server som hanterar enskilda databaser och elastiska pooler.This article provides an overview of the SQL Database resource limits for a SQL Database server that manages single databases and elastic pools. Den innehåller information om vad som händer när dessa resurs gränser nåtts eller överskrids och beskriver de resurs styrnings mekanismer som används för att genomdriva dessa gränser.It provides information on what happens when those resource limits are hit or exceeded, and describes the resource governance mechanisms used to enforce these limits.

Anteckning

Begränsningar för hanterade instanser finns i SQL Database resurs gränser för hanterade instanser.For Managed Instance limits, see SQL Database resource limits for managed instances.

Högsta antal resurs gränserMaximum resource limits

ResursResource GränsLimit
Databaser per serverDatabases per server 50005000
Standard antal servrar per prenumeration i valfri regionDefault number of servers per subscription in any region 2020
Maximalt antal servrar per prenumeration i valfri regionMax number of servers per subscription in any region 200200
Kvot för DTU/eDTU per serverDTU / eDTU quota per server 54,00054,000
vCore-kvot per Server/instansvCore quota per server/instance 540540
Högsta antal pooler per serverMax pools per server Begränsas av antalet DTU: er eller virtuella kärnor.Limited by number of DTUs or vCores. Om varje pool till exempel är 1000 DTU: er, kan en server stödja 54-pooler.For example, if each pool is 1000 DTUs, then a server can support 54 pools.

Anteckning

För att få mer DTU/eDTU-kvot, vCore kvot eller fler servrar än standard beloppet kan en ny supportbegäran skickas i Azure Portal för prenumerationen med ärende typen "kvot".To obtain more DTU/eDTU quota, vCore quota, or more servers than the default amount, a new support request can be submitted in the Azure portal for the subscription with issue type “Quota”. Kvoten DTU/eDTU och databas begränsning per server begränsar antalet elastiska pooler per server.The DTU/eDTU quota and database limit per server constrains the number of elastic pools per server.

Viktigt

När antalet databaser närmar sig gränsen per SQL Database Server kan följande inträffa:As the number of databases approaches the limit per SQL Database server, the following can occur:

  • Ökande svars tid för att köra frågor mot huvud databasen.Increasing latency in running queries against the master database. Detta inkluderar vyer av statistik över resursutnyttjande, till exempel sys. resource_stats.This includes views of resource utilization statistics such as sys.resource_stats.
  • Ökande svars tid i hanterings åtgärder och åter givning av Portal synvinklar som innefattar att räkna upp databaser på servern.Increasing latency in management operations and rendering portal viewpoints that involve enumerating databases in the server.

Lagrings storlekStorage size

För resurs lagrings storlekar för enskilda databaser, referera till antingen DTU-baserade resurs gränser eller vCore resurs gränser för lagrings storleks gränser per pris nivå.For single databases resource storage sizes, refer to either DTU-based resource limits or vCore-based resource limits for the storage size limits per pricing tier.

Vad händer när databas resurs gränser nåsWhat happens when database resource limits are reached

Compute (DTU: er och eDTU: er/virtuella kärnor)Compute (DTUs and eDTUs / vCores)

När databas beräknings användningen (uppmätt av DTU: er och eDTU: er, eller virtuella kärnor) blir hög, ökar svars tiden för frågor och frågor kan till och med ta lång tid. Under dessa villkor kan frågor placeras i kö av tjänsten och de tillhandahålls resurser för att köras när resurser blir kostnads fria.When database compute utilization (measured by DTUs and eDTUs, or vCores) becomes high, query latency increases, and queries can even time out. Under these conditions, queries may be queued by the service and are provided resources for execution as resources become free. När du räknar med hög beräknings användning är följande alternativ för minskning:When encountering high compute utilization, mitigation options include:

LagringStorage

När databas utrymmet som används når den maximala storleks gränsen, infogas och uppdateras databasen som ökar data storleken och klienterna får ett fel meddelande.When database space used reaches the max size limit, database inserts and updates that increase the data size fail and clients receive an error message. SELECT-och DELETE-instruktioner fortsätter att fungera.SELECT and DELETE statements continue to succeed.

När du ska räkna med hög användnings utrymme är alternativen för minskning:When encountering high space utilization, mitigation options include:

Sessioner och arbetare (begär Anden)Sessions and workers (requests)

Det maximala antalet sessioner och arbets tagare bestäms av tjänst nivån och beräknings storleken (DTU: er/eDTU: er eller virtuella kärnor.The maximum number of sessions and workers are determined by the service tier and compute size (DTUs/eDTUs or vCores. Nya begär Anden avvisas när sessioner eller arbets gränser nås och klienter får ett fel meddelande.New requests are rejected when session or worker limits are reached, and clients receive an error message. Även om antalet tillgängliga anslutningar kan styras av programmet är antalet samtidiga arbetare ofta svårare att uppskatta och kontrol lera.While the number of connections available can be controlled by the application, the number of concurrent workers is often harder to estimate and control. Detta gäller särskilt under belastnings perioder när databas resurs gränser har nåtts och arbets grupper registreras på grund av längre körnings frågor, stora spärrnings kedjor eller alltför lång frågans parallellitet.This is especially true during peak load periods when database resource limits are reached and workers pile up due to longer running queries, large blocking chains, or excessive query parallelism.

När du räknar med hög arbets belastning eller arbets belastning, är alternativ för minskning följande:When encountering high session or worker utilization, mitigation options include:

ResursstyrningResource governance

Om du vill framtvinga resurs gränserna använder Azure SQL Database en resurs styrnings implementering som baseras på SQL Server Resource Governor, modifierad och utökad för att köra en SQL Server databas tjänst i Azure.To enforce resource limits, Azure SQL Database uses a resource governance implementation that is based on SQL Server Resource Governor, modified and extended to run a SQL Server database service in Azure. På varje SQL Server instans i tjänsten finns det flera resurspooler och arbets belastnings grupper, med resurs gränser inställda på både pool-och grupp nivåer för att tillhandahålla en bal anse rad databas som en tjänst.On each SQL Server instance in the service, there are multiple resource pools and workload groups, with resource limits set at both pool and group levels to provide a balanced Database-as-a-Service. Användarens arbets belastning och interna arbets belastningar klassificeras till separata resurspooler och arbets belastnings grupper.User workload and internal workloads are classified into separate resource pools and workload groups. Användarens arbets belastning på de primära och läsbara sekundära replikerna, inklusive geo-replikeringar, klassificeras i SloSharedPool1 resurspoolen och UserPrimaryGroup.DBId[N] arbets belastnings gruppen där N står för databas-ID-värdet.User workload on the primary and readable secondary replicas, including geo-replicas, is classified into the SloSharedPool1 resource pool and UserPrimaryGroup.DBId[N] workload group, where N stands for the database ID value. Det finns dessutom flera resurspooler och arbets belastnings grupper för olika interna arbets belastningar.In addition, there are multiple resource pools and workload groups for various internal workloads.

Förutom att använda Resource Governor för att styra resurser inom SQL Servers processen, använder Azure SQL Database även Windows- jobb objekt för resurs styrning på processnivå och Windows hanteraren för fil server resurser (FSRM) för lagrings kvot hantering.In addition to using Resource Governor to govern resources within the SQL Server process, Azure SQL Database also uses Windows Job Objects for process level resource governance, and Windows File Server Resource Manager (FSRM) for storage quota management.

Azure SQL Database resurs styrning är hierarkiskt beslagen.Azure SQL Database resource governance is hierarchical in nature. Uppifrån och ned tillämpas gränser på OS-nivå och på lagrings volym nivå med hjälp av mekanismer för styrning av operativ system resurser och Resource Governor, sedan på resurspoolen med Resource Governor och sedan på arbets belastnings grupps nivå med Resource Governor.From top to bottom, limits are enforced at the OS level and at the storage volume level using operating system resource governance mechanisms and Resource Governor, then at the resource pool level using Resource Governor, and then at the workload group level using Resource Governor. Resurs styrnings gränser som gäller för den aktuella databasen eller den elastiska poolen visas i vyn sys. dm_user_db_resource_governance .Resource governance limits in effect for the current database or elastic pool are surfaced in the sys.dm_user_db_resource_governance view.

Data IO-styrningData IO governance

Data IO-styrning är en process i Azure SQL Database som används för att begränsa både Läs-och skriv fysisk IO mot datafiler i en databas.Data IO governance is a process in Azure SQL Database used to limit both read and write physical IO against data files of a database. IOPS-gränser ställs in för varje service nivå för att minimera effekterna "störnings Grans kraft", för att tillhandahålla skälighet i tjänsten för flera innehavare och för att hålla sig inom funktionerna i den underliggande maskin varan och lagringen.IOPS limits are set for each service level to minimize the "noisy neighbor" effect, to provide resource allocation fairness in the multi-tenant service, and to stay within the capabilities of the underlying hardware and storage.

För enskilda databaser tillämpas gränser för arbets belastnings grupper för alla lagrings-i/o mot databasen, medan gränserna för resurspooler gäller för all lagrings-i/o för alla databaser på samma SQL Server instans, inklusive tempdb-databasen.For single databases, workload group limits are applied to all storage IO against the database, while resource pool limits apply to all storage IO against all databases on the same SQL Server instance, including the tempdb database. För elastiska pooler gäller begränsningarna för arbets belastnings gruppen för varje databas i poolen, medan gränsen för resurspooler gäller hela den elastiska poolen, inklusive tempdb databasen, som delas mellan alla databaser i poolen.For elastic pools, workload group limits apply to each database in the pool, whereas resource pool limit applies to the entire elastic pool, including the tempdb database, which is shared among all databases in the pool. I allmänhet är det inte säkert att gränserna för resurspooler kan uppnås av arbets belastningen mot en databas (antingen en eller en pool), eftersom gränserna för arbets belastnings gruppen är lägre än begränsningen för resurspool och begränsar IOPS/genomflöde tidigare.In general, resource pool limits may not be achievable by the workload against a database (either single or pooled), because workload group limits are lower than resource pool limits and limit IOPS/throughput sooner. Pool gränser kan dock nås av den kombinerade arbets belastningen mot flera databaser på samma SQL Server instans.However, pool limits may be reached by the combined workload against multiple databases on the same SQL Server instance.

Om en fråga till exempel genererar 1000 IOPS utan någon IO-resurs styrning, men den högsta IOPS-gränsen för arbets belastnings gruppen är inställd på 900 IOPS, kan inte frågan generera mer än 900 IOPS.For example, if a query generates 1000 IOPS without any IO resource governance, but the workload group maximum IOPS limit is set to 900 IOPS, the query will not be able to generate more than 900 IOPS. Men om max antalet IOPS för resurspoolen är inställt på 1500 IOPS och total i/o från alla arbets belastnings grupper som är associerade med resurspoolen överskrider 1500 IOPS, kan i/o för samma fråga minskas under arbets gruppens gräns på 900 IOPS.However, if the resource pool maximum IOPS limit is set to 1500 IOPS, and the total IO from all workload groups associated with the resource pool exceeds 1500 IOPS, then the IO of the same query may be reduced below the workgroup limit of 900 IOPS.

Värdena för IOPS och data flöde som returnerades av sys. dm_user_db_resource_governance -vyn fungerar som gränser/versaler, inte som garantier.The IOPS and throughput min/max values returned by the sys.dm_user_db_resource_governance view act as limits/caps, not as guarantees. Vidare garanterar resurs styrning inte någon bestämd lagrings fördröjning.Further, resource governance does not guarantee any specific storage latency. Den bästa tillgängliga svars tiden, IOPS och data flödet för en specifik användar arbets belastning är beroende inte bara av gränser för i/o-resursens styrning, utan även på den kombination av IO-storlek som används och på funktionerna i det underliggande lagrings utrymmet.The best achievable latency, IOPS, and throughput for a given user workload depend not only on IO resource governance limits, but also on the mix of IO sizes used, and on the capabilities of the underlying storage. SQL Server använder IOs som varierar i storlek mellan 512 KB och 4 MB.SQL Server uses IOs that vary in size between 512 KB and 4 MB. I syfte att framtvinga IOPS-gränser redovisas varje IO oavsett storlek, med undantag för databaser med datafiler i Azure Storage.For the purposes of enforcing IOPS limits, every IO is accounted regardless of its size, with the exception of databases with data files in Azure Storage. I så fall redovisas IOs som är större än 256 KB som flera 256 KB IOs, för att justera med Azure Storage i/o-redovisning.In that case, IOs larger than 256 KB are accounted as multiple 256 KB IOs, to align with Azure Storage IO accounting.

För Basic-, standard-och Generell användning-databaser, som använder datafiler i Azure Storage, kanske primary_group_max_io svärdet inte kan nås om en databas inte har tillräckligt med datafiler för att ackumulera antalet IOPS, eller om data inte fördelas jämnt över filer, eller om prestanda nivån för underliggande blobbar begränsar IOPS/data flödet under resurs styrnings gränsen.For Basic, Standard, and General Purpose databases, which use data files in Azure Storage, the primary_group_max_io value may not be achievable if a database does not have enough data files to cumulatively provide this number of IOPS, or if data is not distributed evenly across files, or if the performance tier of underlying blobs limits IOPS/throughput below the resource governance limit. På samma sätt kan primary_max_log_rate-värdet inte uppnås av en arbets belastning på grund av IOPS-gränsen för den underliggande Azure Storage-blobben, med en liten logg-IOs som genereras av transaktions överföringen ofta.Similarly, with small log IOs generated by frequent transaction commit, the primary_max_log_rate value may not be achievable by a workload due to the IOPS limit on the underlying Azure storage blob.

Värdena för resursutnyttjande, till exempel avg_data_io_percent och avg_log_write_percent, som rapporteras i vyerna sys. dm_db_resource_stats, sys. resource_statsoch sys. elastic_pool_resource_stats beräknas som procent andelar av maximala resurs styrnings gränser.Resource utilization values such as avg_data_io_percent and avg_log_write_percent, reported in the sys.dm_db_resource_stats, sys.resource_stats, and sys.elastic_pool_resource_stats views, are calculated as percentages of maximum resource governance limits. När andra faktorer än resurs styrningen begränsar IOPS/data flödet, är det möjligt att se att utökningar av IOPS/genom strömning och fördröjning ökar när arbets belastningen ökar, även om rapporterat resursutnyttjande är lägre än 100%.Therefore, when factors other than resource governance limit IOPS/throughput, it is possible to see IOPS/throughput flattening out and latencies increasing as the workload increases, even though reported resource utilization remains below 100%.

Om du vill se läsa och skriva IOPS, data flöde och svars tid per databas fil använder du funktionen sys. dm_io_virtual_file_stats () .To see read and write IOPS, throughput, and latency per database file, use the sys.dm_io_virtual_file_stats() function. Den här funktionen delar alla IO: t i databasen, inklusive Background IO som inte redovisas mot avg_data_io_percent, men använder IOPS och data flödet för den underliggande lagringen och kan påverka observerad lagrings fördröjning.This function surfaces all IO against the database, including background IO that is not accounted towards avg_data_io_percent, but uses IOPS and throughput of the underlying storage, and can impact observed storage latency. Funktionen hämtar också ytterligare latens som kan introduceras av i/o-resursens styrning för läsningar och skrivningar, i io_stall_queued_read_ms respektive io_stall_queued_write_ms kolumner.The function also surfaces additional latency that may be introduced by IO resource governance for reads and writes, in the io_stall_queued_read_ms and io_stall_queued_write_ms columns respectively.

Hastighets styrning för transaktions loggTransaction log rate governance

Styrning av transaktions logg hastighet är en process i Azure SQL Database som används för att begränsa hög förbruknings frekvens för arbets belastningar som Mass infogning, SELECT INTO och indexe build.Transaction log rate governance is a process in Azure SQL Database used to limit high ingestion rates for workloads such as bulk insert, SELECT INTO, and index builds. Dessa gränser spåras och framtvingas på den andra nivån till frekvensen för genereringen av logg poster, vilket begränsar data flödet, oavsett hur många IOs som kan utfärdas mot datafiler.These limits are tracked and enforced at the subsecond level to the rate of log record generation, limiting throughput regardless of how many IOs may be issued against data files. Taxan för transaktions logg skapande skalas linjärt upp till en punkt som är maskin vara beroende av, med den högsta logg frekvensen som tillåts som 96 MB/s med vCore inköps modell.Transaction log generation rates currently scale linearly up to a point that is hardware-dependent, with the maximum log rate allowed being 96 MB/s with the vCore purchasing model.

Anteckning

Faktiska fysiska IOs till transaktionsloggfiler är inte reglerade eller begränsade.The actual physical IOs to transaction log files are not governed or limited.

Logg taxan ställs in så att de kan uppnås och hanteras i flera olika scenarier, medan det övergripande systemet kan underhålla sin funktionalitet med minimerad påverkan på användar belastningen.Log rates are set such that they can be achieved and sustained in a variety of scenarios, while the overall system can maintain its functionality with minimized impact to the user load. Styrning av logg hastighet säkerställer att säkerhets kopior av transaktions loggar stannar inom publicerings service avtal.Log rate governance ensures that transaction log backups stay within published recoverability SLAs. Denna styrning förhindrar också en alltför lång efter släpning på sekundära repliker.This governance also prevents an excessive backlog on secondary replicas.

När logg poster skapas utvärderas och utvärderas varje åtgärd för om den ska fördröjas för att upprätthålla den högsta önskade logg frekvensen (MB/s per sekund).As log records are generated, each operation is evaluated and assessed for whether it should be delayed in order to maintain a maximum desired log rate (MB/s per second). Fördröjningarna läggs inte till när logg posterna töms på lagringen, i takt med att logg takts styrningen används vid själva genereringen av logg hastighet.The delays are not added when the log records are flushed to storage, rather log rate governance is applied during log rate generation itself.

De faktiska taxan för logg skapande som påförs vid körning kan också påverkas av feedback-mekanismer, vilket tillfälligt minskar de tillåtna logg priserna så att systemet kan stabiliseras.The actual log generation rates imposed at run time may also be influenced by feedback mechanisms, temporarily reducing the allowable log rates so the system can stabilize. Hantering av logg fil utrymme, Undvik att köra i slut på logg utrymmes villkor och replikering av tillgänglighets grupper kan tillfälligt minska de totala system gränserna.Log file space management, avoiding running into out of log space conditions and Availability Group replication mechanisms can temporarily decrease the overall system limits.

Trafikstyrningen för logg hastighets styrning sker via följande vänte typer (visas i sys. dm_db_wait_stats DMV):Log rate governor traffic shaping is surfaced via the following wait types (exposed in the sys.dm_db_wait_stats DMV):

Wait-typWait Type AnteckningarNotes
LOG_RATE_GOVERNORLOG_RATE_GOVERNOR Databas begränsningDatabase limiting
POOL_LOG_RATE_GOVERNORPOOL_LOG_RATE_GOVERNOR Begränsning av poolPool limiting
INSTANCE_LOG_RATE_GOVERNORINSTANCE_LOG_RATE_GOVERNOR Begränsning på instans nivåInstance level limiting
HADR_THROTTLE_LOG_RATE_SEND_RECV_QUEUE_SIZEHADR_THROTTLE_LOG_RATE_SEND_RECV_QUEUE_SIZE Feedback-kontroll, fysisk replikering för tillgänglighets grupp i Premium/Affärskritisk inte hålla sig uppdateradFeedback control, availability group physical replication in Premium/Business Critical not keeping up
HADR_THROTTLE_LOG_RATE_LOG_SIZEHADR_THROTTLE_LOG_RATE_LOG_SIZE Feedback-kontroll, begränsa priser för att undvika ett slut på logg utrymmes villkorFeedback control, limiting rates to avoid an out of log space condition

När du påträffar en logg hastighets gräns som hindrar önskad skalbarhet, bör du överväga följande alternativ:When encountering a log rate limit that is hampering desired scalability, consider the following options:

  • Skala upp till en högre service nivå för att få maximal logg hastighet på 96 MB/s.Scale up to a higher service level in order to get the maximum 96 MB/s log rate.
  • Om data som läses in är tillfälliga, till exempel mellanlagring av data i en ETL-process, kan den läsas in i tempdb (som är minimalt loggad).If data being loaded is transient, such as staging data in an ETL process, it can be loaded into tempdb (which is minimally logged).
  • För analys scenarier läser du in i en klustrad columnstore-tabell.For analytic scenarios, load into a clustered columnstore covered table. Detta minskar den nödvändiga logg frekvensen på grund av komprimering.This reduces the required log rate due to compression. Den här tekniken ökar processor användningen och gäller endast för data uppsättningar som drar nytta av klustrade columnstore-index.This technique does increase CPU utilization and is only applicable to data sets that benefit from clustered columnstore indexes.

Nästa stegNext steps