Azure SQL Database bez serveruAzure SQL Database serverless

platí pro: Azure SQL Database

Bez serveru je výpočetní vrstva pro izolované databáze v Azure SQL Database, která automaticky škáluje výpočetní výkon na základě požadavků na zatížení a faktur na množství výpočetního využití za sekundu.Serverless is a compute tier for single databases in Azure SQL Database that automatically scales compute based on workload demand and bills for the amount of compute used per second. Výpočetní vrstva bez serveru taky automaticky pozastaví databáze během neaktivních období, kdy se účtují jenom úložiště, a automaticky obnoví databáze při návratu aktivity.The serverless compute tier also automatically pauses databases during inactive periods when only storage is billed and automatically resumes databases when activity returns.

Bezserverová výpočetní úroveňServerless compute tier

Výpočetní vrstva bez serveru pro izolovanou databázi v Azure SQL Database je parametrizovaná pomocí rozsahu automatického škálování COMPUTE a prodlevy automatického pozastavení.The serverless compute tier for single databases in Azure SQL Database is parameterized by a compute autoscaling range and an autopause delay. Konfigurace těchto parametrů tvaruje možnosti výkonu databáze a náklady na výpočetní výkon.The configuration of these parameters shapes the database performance experience and compute cost.

fakturace bez serveru

Konfigurace výkonuPerformance configuration

  • Minimální virtuální jádra a Maximální virtuální jádra jsou konfigurovatelné parametry, které definují rozsah výpočetní kapacity dostupné pro databázi.The minimum vCores and maximum vCores are configurable parameters that define the range of compute capacity available for the database. Limity paměti a vstupně-výstupních operací jsou úměrné zadanému rozsahu vCore.Memory and IO limits are proportional to the vCore range specified.
  • Prodleva automatického pozastavení je konfigurovatelný parametr definující časové období, po které musí být databáze neaktivní, než bude automaticky pozastavena.The autopause delay is a configurable parameter that defines the period of time the database must be inactive before it is automatically paused. Databáze se automaticky obnoví, když dojde k dalšímu přihlášení nebo jiné aktivitě.The database is automatically resumed when the next login or other activity occurs. Alternativně je možné zakázat autopauzu.Alternatively, autopausing can be disabled.

NákladyCost

  • Náklady na databázi bez serveru jsou součtem nákladů na výpočetní prostředky a náklady na úložiště.The cost for a serverless database is the summation of the compute cost and storage cost.
  • Pokud je využití COMPUTE mezi nakonfigurovanými minimálními a maximálními limity, náklady na výpočetní výkon vycházejí z vCore a využité paměti.When compute usage is between the min and max limits configured, the compute cost is based on vCore and memory used.
  • Pokud je využití COMPUTE pod nakonfigurovaným minimálním limitem, náklady na výpočetní výkon vycházejí z nakonfigurované minimální virtuální jádra a minimální paměti.When compute usage is below the min limits configured, the compute cost is based on the min vCores and min memory configured.
  • Při pozastavení databáze jsou výpočetní náklady nulové a účtují se jenom náklady na úložiště.When the database is paused, the compute cost is zero and only storage costs are incurred.
  • Náklady na úložiště se určují stejným způsobem jako ve zřízené výpočetní úrovni.The storage cost is determined in the same way as in the provisioned compute tier.

Další informace o cenách najdete v tématu fakturace.For more cost details, see Billing.

ScénářeScenarios

Bezserverová architektura nabízí optimální poměr cena/výkon pro jednoúčelové databáze s přerušovanými a nepředvídatelnými vzory využití, které si můžou dovolit určité zpoždění při přípravě výpočetních prostředků po obdobích nečinnosti.Serverless is price-performance optimized for single databases with intermittent, unpredictable usage patterns that can afford some delay in compute warm-up after idle usage periods. Naproti tomu úroveň zřízených výpočetních prostředků nabízí optimální poměr cena/výkon pro jednoúčelové databáze nebo více databází v elastických fondech s vyšším průměrným využitím, které si nemůžou dovolit žádné zpoždění při přípravě výpočetních prostředků.In contrast, the provisioned compute tier is price-performance optimized for single databases or multiple databases in elastic pools with higher average usage that cannot afford any delay in compute warm-up.

Scénáře vhodné pro výpočetní prostředky bez serveruScenarios well-suited for serverless compute

  • Izolované databáze s přerušovaným a nepředvídatelným vzorem použití prodávanými po dobu neaktivity a nižším průměrem využití výpočetních prostředků v průběhu času.Single databases with intermittent, unpredictable usage patterns interspersed with periods of inactivity and lower average compute utilization over time.
  • Izolované databáze v zřízené výpočetní úrovni, které se často mění a zákazníci, kteří preferují delegování výpočetního škálování na službu.Single databases in the provisioned compute tier that are frequently rescaled and customers who prefer to delegate compute rescaling to the service.
  • Nové izolované databáze bez historie využití, ve kterých je výpočet velikosti obtížné nebo není možné odhadnout před nasazením v SQL Database.New single databases without usage history where compute sizing is difficult or not possible to estimate prior to deployment in SQL Database.

Scénáře vhodné pro zřízené výpočetní prostředkyScenarios well-suited for provisioned compute

  • Izolované databáze s pravidelnými a předvídatelnými způsoby použití a vyšším využitím výpočetního využití v průběhu času.Single databases with more regular, predictable usage patterns and higher average compute utilization over time.
  • Databáze, které nemůžou tolerovat kompromisy na výkonu, což vede k častému oříznutí paměti nebo zpoždění při automatického obnovení z pozastaveného stavu.Databases that cannot tolerate performance trade-offs resulting from more frequent memory trimming or delay in autoresuming from a paused state.
  • Víc databází s přerušovanými a nepředvídatelnými vzorci použití, které se dají konsolidovat do elastických fondů pro lepší optimalizaci cen.Multiple databases with intermittent, unpredictable usage patterns that can be consolidated into elastic pools for better price-performance optimization.

Porovnání se zřízenou výpočetní vrstvouComparison with provisioned compute tier

Následující tabulka shrnuje rozdíly mezi výpočetní a zřízenou výpočetní úrovní bez serveru:The following table summarizes distinctions between the serverless compute tier and the provisioned compute tier:

Bezserverové výpočetní prostředíServerless compute Zřízené výpočetní prostředkyProvisioned compute
Vzor využití databázeDatabase usage pattern Občasné, nepředvídatelné využití s nižším průměrem využití výpočetních prostředků v průběhu času.Intermittent, unpredictable usage with lower average compute utilization over time. Efektivnější vzorce použití s vyšším průměrem využití výpočetních prostředků v průběhu času nebo více databází pomocí elastických fondů.More regular usage patterns with higher average compute utilization over time, or multiple databases using elastic pools.
Úsilí řízení výkonuPerformance management effort NižšíLower VyššíHigher
Škálování na výpočetní výkonCompute scaling AutomatickyAutomatic RučníManual
Výpočetní rychlost odezvyCompute responsiveness Nižší po neaktivních obdobíchLower after inactive periods ProjevImmediate
Členitost fakturaceBilling granularity Za sekunduPer second Za hodinuPer hour

Nákup modelu a úrovně služebPurchasing model and service tier

SQL Database bez serveru se aktuálně podporuje jenom v Pro obecné účely vrstvě na hardwaru generace 5 v modelu nákupu vCore.SQL Database serverless is currently only supported in the General Purpose tier on Generation 5 hardware in the vCore purchasing model.

Automatické škálováníAutoscaling

Škálování rychlosti odezvyScaling responsiveness

Obecně platí, že databáze bez serveru běží na počítači s dostatečnou kapacitou ke splnění požadavků na prostředky bez přerušení pro jakékoli množství COMPUTE vyžádané v rámci omezení nastavené maximální hodnotou virtuální jádra.In general, serverless databases are run on a machine with sufficient capacity to satisfy resource demand without interruption for any amount of compute requested within limits set by the max vCores value. Vyrovnávání zatížení se občas může vyskytnout automaticky, pokud počítač nemůže během několika minut splnit požadavky na prostředky.Occasionally, load balancing automatically occurs if the machine is unable to satisfy resource demand within a few minutes. Pokud je třeba požadavek na prostředek 4 virtuální jádra, ale k dispozici je jenom 2 virtuální jádra, může trvat až několik minut, než se doplní 4 virtuální jádra.For example, if the resource demand is 4 vCores, but only 2 vCores are available, then it may take up to a few minutes to load balance before 4 vCores are provided. Databáze zůstane během vyrovnávání zatížení online, s výjimkou krátkého období na konci operace, když jsou připojení vyřazená.The database remains online during load balancing except for a brief period at the end of the operation when connections are dropped.

Správa pamětiMemory management

Paměť pro databáze bez serveru se uvolní častěji než u zřízených výpočetních databází.Memory for serverless databases is reclaimed more frequently than for provisioned compute databases. Toto chování je důležité řídit náklady bez serveru a může mít vliv na výkon.This behavior is important to control costs in serverless and can impact performance.

Recyklace mezipamětiCache reclamation

Na rozdíl od zřízených výpočetních databází je paměť z mezipaměti SQL uvolněna z databáze bez serveru, pokud je nízká úroveň využití procesoru nebo aktivní mezipaměti.Unlike provisioned compute databases, memory from the SQL cache is reclaimed from a serverless database when CPU or active cache utilization is low.

  • Využití aktivní mezipaměti se považuje za nepatrné, pokud celková velikost naposledy použitých položek mezipaměti klesne pod prahovou hodnotu po určitou dobu.Active cache utilization is considered low when the total size of the most recently used cache entries falls below a threshold for a period of time.
  • Při aktivaci opětovného získání mezipaměti se cílová velikost mezipaměti zmenší přírůstkově na zlomek její předchozí velikosti a obnovení bude pokračovat pouze v případě, že je využití nízké.When cache reclamation is triggered, the target cache size is reduced incrementally to a fraction of its previous size and reclaiming only continues if usage remains low.
  • Když dojde k recyklování mezipaměti, zásada pro výběr položek mezipaměti k vyřazení je stejná jako zásada výběru pro zřízené výpočetní databáze, pokud je tlak paměti vysoký.When cache reclamation occurs, the policy for selecting cache entries to evict is the same selection policy as for provisioned compute databases when memory pressure is high.
  • Velikost mezipaměti se nikdy nesnižuje pod minimálním limitem paměti definovaným min virtuální jádra, který se dá nakonfigurovat.The cache size is never reduced below the min memory limit as defined by min vCores which can be configured.

V neserverových a zřízených výpočetních databázích se můžou položky mezipaměti vyřadit, pokud se použije veškerá dostupná paměť.In both serverless and provisioned compute databases, cache entries may be evicted if all available memory is used.

Všimněte si, že pokud je využití procesoru nízké, může využití aktivní mezipaměti zůstat vysoké v závislosti na způsobu použití a zabránit recyklaci paměti.Note that when CPU utilization is low, active cache utilization can remain high depending on the usage pattern and prevent memory reclamation. V důsledku pravidelného zpracování na pozadí reaguje na předchozí činnost uživatele může také docházet k dalšímu zpoždění po zastavení aktivity uživatele před tím, než dojde k opakovanému získávání paměti.Also, there can be additional delay after user activity stops before memory reclamation occurs due to periodic background processes responding to prior user activity. Například úlohy odstranit operace a vyčištění QDS generují opuštěné záznamy, které jsou označené k odstranění, ale nejsou fyzicky smazány, dokud se nespustí proces čištění Ghost, který může zahrnovat čtení datových stránek do mezipaměti.For example, delete operations and QDS cleanup tasks generate ghost records that are marked for deletion, but are not physically deleted until the ghost cleanup process runs which can involve reading data pages into cache.

Vysazování mezipamětiCache hydration

Mezipaměť SQL roste, protože data se načítají z disku stejným způsobem a se stejnou rychlostí jako u zřízených databází.The SQL cache grows as data is fetched from disk in the same way and with the same speed as for provisioned databases. Pokud je databáze zaneprázdněná, může být velikost mezipaměti až do maximálního limitu paměti neomezená.When the database is busy, the cache is allowed to grow unconstrained up to the max memory limit.

Autopozastavování a autoobnovováníAutopausing and autoresuming

AutopozastavováníAutopausing

Automatické pauzy se aktivují, pokud jsou splněné všechny následující podmínky po dobu trvání prodlevy při automatickém pozastavení:Autopausing is triggered if all of the following conditions are true for the duration of the autopause delay:

  • Počet relací = 0Number sessions = 0
  • CPU = 0 pro úlohy uživatele běžící ve fondu uživatelůCPU = 0 for user workload running in the user pool

V případě potřeby je k dispozici možnost pro vypnutí autopauzy.An option is provided to disable autopausing if desired.

Následující funkce nepodporují automatické pozastavení, ale podporují automatické škálování.The following features do not support autopausing, but do support auto-scaling. Pokud použijete některou z následujících funkcí, je třeba zakázat možnost autopozastavit a databáze zůstane online bez ohledu na dobu nečinnosti databáze:If any of the following features are used, then autopausing should be disabled and the database will remain online regardless of the duration of database inactivity:

  • Geografická replikace (aktivní geografická replikace a skupiny s automatickým převzetím služeb při selhání).Geo-replication (active geo-replication and auto-failover groups).
  • Dlouhodobé uchovávání záloh (LTR).Long-term backup retention (LTR).
  • Synchronizovaná databáze použitá v synchronizaci dat SQL Na rozdíl od synchronizace databází databáze hub a členské databáze podporují automatické pozastavení.The sync database used in SQL data sync. Unlike sync databases, hub and member databases support autopausing.
  • Aliasy DNSDNS aliasing
  • Databáze úlohy používaná v elastických úlohách (Preview).The job database used in Elastic Jobs (preview).

Při nasazování některých aktualizací služby, které vyžadují databázi online, se dočasně brání v dočasném pozastavení.Autopausing is temporarily prevented during the deployment of some service updates which require the database be online. V takových případech se po dokončení aktualizace služby znovu povolí opětovné pozastavení.In such cases, autopausing becomes allowed again once the service update completes.

Probíhá autoobnovováníAutoresuming

Automatické obnovení se aktivuje, pokud platí kterákoli z následujících podmínek v libovolnou dobu:Autoresuming is triggered if any of the following conditions are true at any time:

DoporučenéFeature Aktivační událost autoresumeAutoresume trigger
Ověřování a autorizaceAuthentication and authorization PřihlášeníLogin
Detekce hrozebThreat detection Povolení nebo zakázání nastavení detekce hrozeb na úrovni databáze nebo serveru.Enabling/disabling threat detection settings at the database or server level.
Úprava nastavení detekce hrozeb na úrovni databáze nebo serveru.Modifying threat detection settings at the database or server level.
Zjišťování a klasifikace datData discovery and classification Přidávání, úpravy, odstraňování nebo zobrazování popisků citlivostiAdding, modifying, deleting, or viewing sensitivity labels
AuditováníAuditing Zobrazení záznamů auditu.Viewing auditing records.
Probíhá aktualizace nebo zobrazení zásad auditování.Updating or viewing auditing policy.
Maskování datData masking Přidání, úprava, odstranění nebo zobrazení pravidel maskování datAdding, modifying, deleting, or viewing data masking rules
Transparentní šifrování datTransparent data encryption Zobrazení stavu nebo stavu transparentního šifrování datView state or status of transparent data encryption
Posouzení ohrožení zabezpečeníVulnerability assessment Kontroly ad hoc a pravidelné kontroly, pokud je povolenoAd hoc scans and periodic scans if enabled
Dotaz (výkon) úložiště datQuery (performance) data store Úprava nebo zobrazení nastavení úložiště dotazůModifying or viewing query store settings
Automatického laděníAutotuning Aplikace a ověření doporučení automatického ladění, jako je automatické indexováníApplication and verification of autotuning recommendations such as auto-indexing
Kopírování databázeDatabase copying Vytvoří databázi jako kopii.Create database as copy.
Exportujte do souboru BACPAC.Export to a BACPAC file.
Synchronizace dat SQLSQL data sync Synchronizace mezi centrem a členskými databázemi, které se spouští podle konfigurovatelného plánu, nebo se provádí ručněSynchronization between hub and member databases that run on a configurable schedule or are performed manually
Úprava určitých metadat databázeModifying certain database metadata Přidávání nových značek databáze.Adding new database tags.
Změna maximálního virtuální jádra, minimální virtuální jádra nebo prodlevy při autopauze.Changing max vCores, min vCores, or autopause delay.
SQL Server Management Studio (SSMS)SQL Server Management Studio (SSMS) Při použití verzí SSMS starších než 18,1 a otevření nového okna dotazu pro všechny databáze na serveru bude obnovena veškerá automaticky pozastavená databáze na stejném serveru.Using SSMS versions earlier than 18.1 and opening a new query window for any database in the server will resume any auto-paused database in the same server. K tomuto chování nedochází, pokud používáte SSMS verze 18,1 nebo novější.This behavior does not occur if using SSMS version 18.1 or later.

Monitorování, Správa nebo jiná řešení provádějící jakoukoli z výše uvedených operací spustí automatické obnovení.Monitoring, management, or other solutions performing any of the operations listed above will trigger auto-resuming.

Automatické obnovení se také aktivuje při nasazení některých aktualizací služby, které vyžadují, aby byla databáze online.Autoresuming is also triggered during the deployment of some service updates which require the database be online.

Možnosti připojeníConnectivity

Pokud je databáze bez serveru pozastavená, pak se při prvním přihlášení obnoví databáze a vrátí se chyba s oznámením, že databáze není k dispozici, kód chyby 40613.If a serverless database is paused, then the first login will resume the database and return an error stating that the database is unavailable with error code 40613. Po obnovení databáze se přihlašovací jméno musí znovu pokusit o navázání připojení.Once the database is resumed, the login must be retried to establish connectivity. Klienti databáze s logikou opakování připojení by nemuseli upravovat.Database clients with connection retry logic should not need to be modified.

LatenceLatency

Latence pro autoresume a autopauza databáze bez serveru je obvykle na hodnotu 1 minuta k autoresume a 1-10 minut pro autopauzu.The latency to autoresume and autopause a serverless database is generally order of 1 minute to autoresume and 1-10 minutes to autopause.

Transparentní šifrování dat spravované zákazníkem (BYOK)Customer managed transparent data encryption (BYOK)

Pokud používáte transparentní šifrování dat (BYOK) spravované zákazníkem a databáze bez serveru se při odstraňování nebo odvolávání klíčů automaticky pozastavila, databáze zůstane ve stavu automatického pozastavení.If using customer managed transparent data encryption (BYOK) and the serverless database is auto-paused when key deletion or revocation occurs, then the database remains in the auto-paused state. V takovém případě bude databáze po příštím obnovení databáze nepřístupná do přibližně 10 minut.In this case, after the database is next resumed, the database becomes inaccessible within approximately 10 minutes. Jakmile bude databáze nepřístupná, proces obnovení bude stejný jako u zřízených výpočetních databází.Once the database becomes inaccessible, the recovery process is the same as for provisioned compute databases. Pokud je databáze bez serveru online, když dojde k odstranění klíče nebo k odvolání, bude databáze také nepřístupná během přibližně 10 minut stejným způsobem jako u zřízené výpočetní databáze.If the serverless database is online when key deletion or revocation occurs, then the database also becomes inaccessible within approximately 10 minutes in the same way as with provisioned compute databases.

Připojování do výpočetní úrovně bez serveruOnboarding into serverless compute tier

Vytvoření nové databáze nebo přesunutí existující databáze do výpočetní úrovně bez serveru se řídí stejným vzorem jako vytvoření nové databáze v zřízené výpočetní úrovni a zahrnuje následující dva kroky.Creating a new database or moving an existing database into a serverless compute tier follows the same pattern as creating a new database in provisioned compute tier and involves the following two steps.

  1. Zadejte cíl služby.Specify the service objective. Cíl služby stanoví úroveň služby, generování hardwaru a maximální virtuální jádra.The service objective prescribes the service tier, hardware generation, and max vCores. Možnosti cíle služby najdete v tématu omezení prostředků bez serveru .For service objective options, see serverless resource limits

  2. Volitelně můžete zadat minimální virtuální jádra a prodlevu při pauze pro změnu jejich výchozích hodnot.Optionally, specify the min vCores and autopause delay to change their default values. V následující tabulce jsou uvedeny dostupné hodnoty pro tyto parametry.The following table shows the available values for these parameters.

    ParametrParameter Volby hodnotyValue choices Výchozí hodnotaDefault value
    Minimální virtuální jádraMin vCores Závisí na maximální virtuální jádra konfiguraci – viz omezení prostředků.Depends on max vCores configured - see resource limits. 0,5 virtuální jádra0.5 vCores
    Prodleva při autopauzeAutopause delay Minimálně: 60 minut (1 hodina)Minimum: 60 minutes (1 hour)
    Maximum: 10080 minut (7 dní)Maximum: 10080 minutes (7 days)
    Zvýšení: 10 minutIncrements: 10 minutes
    Zakázat automatického pozastavení:-1Disable autopause: -1
    60 minut60 minutes

Vytvoření nové databáze na výpočetní úrovni bez serveruCreate a new database in the serverless compute tier

V následujících příkladech se vytvoří nová databáze na výpočetní úrovni bez serveru.The following examples create a new database in the serverless compute tier.

Použití webu Azure PortalUse the Azure portal

Informace najdete v tématu rychlý Start: vytvoření izolované databáze v Azure SQL Database pomocí Azure Portal.See Quickstart: Create a single database in Azure SQL Database using the Azure portal.

Použití prostředí PowerShellUse PowerShell

New-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName -DatabaseName $databaseName `
  -ComputeModel Serverless -Edition GeneralPurpose -ComputeGeneration Gen5 `
  -MinVcore 0.5 -MaxVcore 2 -AutoPauseDelayInMinutes 720

Použití Azure CLIUse the Azure CLI

az sql db create -g $resourceGroupName -s $serverName -n $databaseName `
  -e GeneralPurpose -f Gen5 -min-capacity 0.5 -c 2 --compute-model Serverless --auto-pause-delay 720

Použití jazyka Transact-SQL (T-SQL)Use Transact-SQL (T-SQL)

Při použití T-SQL se výchozí hodnoty aplikují na minimum virtuální jádra a prodleva automatického pozastavení.When using T-SQL, default values are applied for the min vcores and autopause delay.

CREATE DATABASE testdb
( EDITION = 'GeneralPurpose', SERVICE_OBJECTIVE = 'GP_S_Gen5_1' ) ;

Podrobnosti najdete v tématu Vytvoření databáze.For details, see CREATE DATABASE.

Přesun databáze ze zřízené výpočetní vrstvy do výpočetní vrstvy bez serveruMove a database from the provisioned compute tier into the serverless compute tier

V následujících příkladech přesunete databázi ze zřízené výpočetní vrstvy do výpočetní vrstvy bez serveru.The following examples move a database from the provisioned compute tier into the serverless compute tier.

Použití prostředí PowerShellUse PowerShell

Set-AzSqlDatabase -ResourceGroupName $resourceGroupName -ServerName $serverName -DatabaseName $databaseName `
  -Edition GeneralPurpose -ComputeModel Serverless -ComputeGeneration Gen5 `
  -MinVcore 1 -MaxVcore 4 -AutoPauseDelayInMinutes 1440

Použití Azure CLIUse the Azure CLI

az sql db update -g $resourceGroupName -s $serverName -n $databaseName `
  --edition GeneralPurpose --min-capacity 1 --capacity 4 --family Gen5 --compute-model Serverless --auto-pause-delay 1440

Použití jazyka Transact-SQL (T-SQL)Use Transact-SQL (T-SQL)

Při použití T-SQL se výchozí hodnoty aplikují na minimum virtuální jádra a prodleva automatického pozastavení.When using T-SQL, default values are applied for the min vcores and autopause delay.

ALTER DATABASE testdb 
MODIFY ( SERVICE_OBJECTIVE = 'GP_S_Gen5_1') ;

Podrobnosti najdete v tématu ALTER DATABASE.For details, see ALTER DATABASE.

Přesun databáze z výpočetní vrstvy bez serveru do zřízené výpočetní vrstvyMove a database from the serverless compute tier into the provisioned compute tier

Databáze bez serveru se dá přesunout do zřízené výpočetní vrstvy stejným způsobem jako přesun zřízené výpočetní databáze do výpočetní vrstvy bez serveru.A serverless database can be moved into a provisioned compute tier in the same way as moving a provisioned compute database into a serverless compute tier.

Úprava konfigurace bez serveruModifying serverless configuration

Použití prostředí PowerShellUse PowerShell

Změna maximálního nebo minimálního zpoždění virtuální jádra a prodlevy automatického pozastavení se provádí pomocí příkazu set-AzSqlDatabase v PowerShellu pomocí MaxVcore argumentů, MinVcore a AutoPauseDelayInMinutes .Modifying the maximum or minimum vCores, and autopause delay, is performed by using the Set-AzSqlDatabase command in PowerShell using the MaxVcore, MinVcore, and AutoPauseDelayInMinutes arguments.

Použití Azure CLIUse the Azure CLI

Změna maximálního nebo minimálního zpoždění virtuální jádra a prodlevy při automatickém pozastavení se provádí pomocí příkazu AZ SQL DB Update v Azure CLI pomocí capacity min-capacity argumentů, a auto-pause-delay .Modifying the maximum or minimum vCores, and autopause delay, is performed by using the az sql db update command in Azure CLI using the capacity, min-capacity, and auto-pause-delay arguments.

MonitorováníMonitoring

Využité a fakturované prostředkyResources used and billed

Prostředky databáze bez serveru jsou zapouzdřeny pomocí balíčku aplikace, instance SQL a entit fondu prostředků uživatele.The resources of a serverless database are encapsulated by app package, SQL instance, and user resource pool entities.

Balíček aplikaceApp package

Balíček aplikace je vnější největší hranice správy prostředků pro databázi bez ohledu na to, jestli je databáze v neserverové nebo zřízené výpočetní úrovni.The app package is the outer most resource management boundary for a database, regardless of whether the database is in a serverless or provisioned compute tier. Balíček aplikace obsahuje instanci SQL a externí služby, které společně připadají do oboru všechny uživatelské a systémové prostředky používané databází v SQL Database.The app package contains the SQL instance and external services that together scope all user and system resources used by a database in SQL Database. Příklady externích služeb zahrnují R a fulltextové vyhledávání.Examples of external services include R and full-text search. Instance SQL všeobecně rozchází z celkového využití prostředků napříč balíčkem aplikace.The SQL instance generally dominates the overall resource utilization across the app package.

Fond zdrojů uživateleUser resource pool

Fond zdrojů uživatele je vnitřní hranice správy prostředků pro databázi bez ohledu na to, jestli je databáze v neserverové nebo zřízené výpočetní úrovni.The user resource pool is the inner most resource management boundary for a database, regardless of whether the database is in a serverless or provisioned compute tier. Fond zdrojů uživatele obor a vstupně-výstupní operace pro uživatelské zatížení generované dotazy DDL, jako je například vytváření a změny a dotazy DML, jako je například SELECT, INSERT, UPDATE a DELETE.The user resource pool scopes CPU and IO for user workload generated by DDL queries such as CREATE and ALTER and DML queries such as SELECT, INSERT, UPDATE, and DELETE. Tyto dotazy obvykle reprezentují nejvýznamnější podíl využití v rámci balíčku aplikace.These queries generally represent the most substantial proportion of utilization within the app package.

MetrikyMetrics

Metriky pro monitorování využití prostředků balíčku aplikace a fondu uživatelů v databázi bez serveru jsou uvedené v následující tabulce:Metrics for monitoring the resource usage of the app package and user pool of a serverless database are listed in the following table:

EntitaEntity MetrikaMetric PopisDescription JednotkyUnits
Balíček aplikaceApp package app_cpu_percentapp_cpu_percent Procento virtuální jádra, které aplikace používá vzhledem k maximálnímu virtuální jádra povolenému pro aplikaciPercentage of vCores used by the app relative to max vCores allowed for the app. ProcentoPercentage
Balíček aplikaceApp package app_cpu_billedapp_cpu_billed Množství COMPUTE, které aplikace účtuje během období generování sestav.The amount of compute billed for the app during the reporting period. Částka placená během tohoto období je produktem této metriky a Jednotková cena vCore.The amount paid during this period is the product of this metric and the vCore unit price.

Hodnoty této metriky se určují tak, že se v průběhu času vyhodnotí maximální využití procesoru a využitá paměť každou sekundu.Values of this metric are determined by aggregating over time the maximum of CPU used and memory used each second. Pokud je využité množství menší než minimální zajištěné množství, které je stanoveno minimálním virtuální jádra a minimální pamětí, účtuje se minimální stanovený objem.If the amount used is less than the minimum amount provisioned as set by the min vCores and min memory, then the minimum amount provisioned is billed.Aby bylo možné porovnat procesor s pamětí pro účely fakturace, je paměť normalizována na jednotky virtuální jádra tím, že převýší množství paměti v GB o 3 GB na vCore. In order to compare CPU with memory for billing purposes, memory is normalized into units of vCores by rescaling the amount of memory in GB by 3 GB per vCore.
vCore sekundvCore seconds
Balíček aplikaceApp package app_memory_percentapp_memory_percent Procentuální podíl paměti používané aplikací vzhledem k maximálnímu povolenému počtu paměti pro aplikaci.Percentage of memory used by the app relative to max memory allowed for the app. ProcentoPercentage
Fond uživatelůUser pool cpu_percentcpu_percent Procento virtuální jádra, které používá uživatelské zatížení vzhledem k maximálnímu virtuální jádra povolenému pro zatížení uživatele.Percentage of vCores used by user workload relative to max vCores allowed for user workload. ProcentoPercentage
Fond uživatelůUser pool data_IO_percentdata_IO_percent Procento datových IOPS používaných uživatelskými úlohami vzhledem k maximálnímu počtu datových IOPS povolených pro zatížení uživatele.Percentage of data IOPS used by user workload relative to max data IOPS allowed for user workload. ProcentoPercentage
Fond uživatelůUser pool log_IO_percentlog_IO_percent Procento protokolu MB/s používaného uživatelskými úlohami vzhledem k maximálnímu počtu MB/s povoleného pro zatížení uživatele.Percentage of log MB/s used by user workload relative to max log MB/s allowed for user workload. ProcentoPercentage
Fond uživatelůUser pool workers_percentworkers_percent Procentuální podíl pracovníků využívaných uživatelskými úlohami vzhledem k maximálnímu počtu pracovních procesů povolených pro zatížení uživatele.Percentage of workers used by user workload relative to max workers allowed for user workload. ProcentoPercentage
Fond uživatelůUser pool sessions_percentsessions_percent Procento relací používaných uživatelskými úlohami vzhledem k maximálnímu počtu relací povolených pro zatížení uživatele.Percentage of sessions used by user workload relative to max sessions allowed for user workload. ProcentoPercentage

Stav pozastavení a obnoveníPause and resume status

V Azure Portal se stav databáze zobrazí v podokně přehledu serveru, kde jsou uvedeny databáze, které obsahuje.In the Azure portal, the database status is displayed in the overview pane of the server that lists the databases it contains. Stav databáze je také zobrazen v podokně Přehled pro databázi.The database status is also displayed in the overview pane for the database.

Pomocí následujících příkazů můžete zadat dotaz na stav pozastavení a obnovení databáze:Using the following commands to query the pause and resume status of a database:

Použití prostředí PowerShellUse PowerShell

Get-AzSqlDatabase -ResourceGroupName $resourcegroupname -ServerName $servername -DatabaseName $databasename `
  | Select -ExpandProperty "Status"

Použití Azure CLIUse the Azure CLI

az sql db show --name $databasename --resource-group $resourcegroupname --server $servername --query 'status' -o json

Omezení prostředkůResource limits

Omezení prostředků najdete v tématu výpočetní vrstva bez serveru.For resource limits, see serverless compute tier.

FakturaceBilling

Cena za výpočetní náklady je maximální využití procesoru a využité paměti každou sekundu.The amount of compute billed is the maximum of CPU used and memory used each second. Pokud je množství využitého procesoru a využité paměti menší než minimální velikost zřízená za každou, účtuje se zřízené množství.If the amount of CPU used and memory used is less than the minimum amount provisioned for each, then the provisioned amount is billed. Aby bylo možné porovnat procesor s pamětí pro účely fakturace, je paměť normalizována na jednotky virtuální jádra tím, že převýší množství paměti v GB o 3 GB na vCore.In order to compare CPU with memory for billing purposes, memory is normalized into units of vCores by rescaling the amount of memory in GB by 3 GB per vCore.

  • Prostředek se účtuje : procesor a paměť.Resource billed : CPU and memory
  • Účtovaná částka : Vcore Unit Price * Max (min virtuální jádra, virtuální jádra použito, min. gb × 1/3, využité paměti gb × 1/3)Amount billed : vCore unit price * max (min vCores, vCores used, min memory GB * 1/3, memory GB used * 1/3)
  • Četnost fakturace : za sekunduBilling frequency : Per second

Jednotková cena vCore je cena za vCore za sekundu.The vCore unit price is the cost per vCore per second. Konkrétní jednotkové ceny v dané oblasti najdete na stránce s cenami Azure SQL Database .Refer to the Azure SQL Database pricing page for specific unit prices in a given region.

K dispozici je množství COMPUTE, které se účtuje pomocí následující metriky:The amount of compute billed is exposed by the following metric:

  • Metrika : App_cpu_billed (Vcore sekund)Metric : app_cpu_billed (vCore seconds)
  • Definice : max (minimum virtuální jádra, virtuální jádra použito, minimální paměť GB × 1/3, využité paměťové GB × 1/3)Definition : max (min vCores, vCores used, min memory GB * 1/3, memory GB used * 1/3)
  • Frekvence generování sestav : za minutuReporting frequency : Per minute

Toto množství se počítá každou sekundu a agreguje se za 1 minutu.This quantity is calculated each second and aggregated over 1 minute.

Minimální faktura za výpočetní prostředkyMinimum compute bill

Pokud je databáze bez serveru pozastavena, je vyúčtování vypočítáno jako nula.If a serverless database is paused, then the compute bill is zero. Pokud databáze bez serveru není pozastavená, minimální vyfakturovaná částka je nižší než množství virtuální jádra na základě Max (min virtuální jádra, min Memory GB × 1/3).If a serverless database is not paused, then the minimum compute bill is no less than the amount of vCores based on max (min vCores, min memory GB * 1/3).

Příklady:Examples:

  • Předpokládejme, že databáze bez serveru není pozastavená a nakonfigurovaná s 8 Max virtuální jádra a 1 min vCoreami odpovídajícími 3,0 GB min. paměti.Suppose a serverless database is not paused and configured with 8 max vCores and 1 min vCore corresponding to 3.0 GB min memory. Minimální vyúčtování vychází z maxima (1 vCore, 3,0 GB × 1 vCore/3 GB) = 1 vCore.Then the minimum compute bill is based on max (1 vCore, 3.0 GB * 1 vCore / 3 GB) = 1 vCore.
  • Předpokládejme, že databáze bez serveru není pozastavena a nakonfigurována s 4 max virtuální jádra a 0,5 min virtuální jádray odpovídající 2,1 GB min. paměti.Suppose a serverless database is not paused and configured with 4 max vCores and 0.5 min vCores corresponding to 2.1 GB min memory. Minimální vyúčtování vychází z maxima (0,5 virtuální jádra, 2,1 GB × 1 vCore/3 GB) = 0,7 virtuální jádra.Then the minimum compute bill is based on max (0.5 vCores, 2.1 GB * 1 vCore / 3 GB) = 0.7 vCores.

Cenové kalkulačky Azure SQL Database pro server bez serveru se dají použít k určení minimální konfigurovatelné paměti na základě počtu virtuální jádra nakonfigurovaných na maximum a min.The Azure SQL Database pricing calculator for serverless can be used to determine the min memory configurable based on the number of max and min vCores configured. V případě pravidla platí, že pokud je minimální virtuální jádra nakonfigurovaný větší než 0,5 virtuální jádra, pak je minimální vyúčtování nezávisle na minimální konfiguraci paměti a na základě počtu nakonfigurovaných minimálních virtuální jádra.As a rule, if the min vCores configured is greater than 0.5 vCores, then the minimum compute bill is independent of the min memory configured and based only on the number of min vCores configured.

Ukázkový scénářExample scenario

Vezměte v úvahu databázi bez serveru nakonfigurovanou s 1 min vCore a 4 max virtuální jádra.Consider a serverless database configured with 1 min vCore and 4 max vCores. Tato hodnota odpovídá přibližně 3 GB paměti a maximální velikosti paměti 12 GB.This corresponds to around 3 GB min memory and 12-GB max memory. Předpokládejme, že prodleva automatického pozastavení je nastavená na 6 hodin a úloha databáze je aktivní během prvních 2 hodin po dobu 24 hodin a jinak neaktivní.Suppose the auto-pause delay is set to 6 hours and the database workload is active during the first 2 hours of a 24-hour period and otherwise inactive.

V takovém případě se databáze fakturuje za výpočetní výkon a úložiště během prvních 8 hodin.In this case, the database is billed for compute and storage during the first 8 hours. I když je databáze neaktivní od druhé hodiny, bude se vám v následujících 6 hodinách účtovat za výpočetní výkon na základě minimálního výpočetního zřízeného, zatímco je databáze online.Even though the database is inactive starting after the second hour, it is still billed for compute in the subsequent 6 hours based on the minimum compute provisioned while the database is online. Během období 24 hodin se fakturuje jenom úložiště, zatímco databáze je pozastavená.Only storage is billed during the remainder of the 24-hour period while the database is paused.

Ve výše uvedeném příkladu je vypočítaná faktura za výpočetní výkon následující:More precisely, the compute bill in this example is calculated as follows:

Časový intervalTime Interval Virtuální jádra použité za sekunduvCores used each second Využité GB za sekunduGB used each second Dimenze COMPUTE se fakturuje.Compute dimension billed vCore sekund se účtují v časovém intervalu.vCore seconds billed over time interval
0:00-1:000:00-1:00 44 99 Virtuální jádra použitovCores used 4 virtuální jádra × 3600 sekund = 14400 vCore sekund4 vCores * 3600 seconds = 14400 vCore seconds
1:00-2:001:00-2:00 11 1212 Využití pamětiMemory used 12 GB × 1/3 × 3600 sekund = 14400 vCore sekund12 GB * 1/3 * 3600 seconds = 14400 vCore seconds
2:00-8:002:00-8:00 00 00 Minimální zřízená paměťMin memory provisioned 3 GB × 1/3 × 21600 sekund = 21600 vCore sekund3 GB * 1/3 * 21600 seconds = 21600 vCore seconds
8:00-24:008:00-24:00 00 00 Při pozastavení se neúčtují žádné výpočetní prostředky.No compute billed while paused 0 vCore sekund0 vCore seconds
Celkový počet vCore sekund fakturovaných za 24 hodinTotal vCore seconds billed over 24 hours 50400 vCore sekund50400 vCore seconds

Předpokládejme, že cena za výpočetní jednotku je $0.000145/vCore/sekunda.Suppose the compute unit price is $0.000145/vCore/second. Pak se za toto 24hodinové období účtuje produkt ceny za výpočetní jednotku a vCore sekundy: $0.000145/vCore/Second × 50400 vCore sekund ~ $7,31Then the compute billed for this 24-hour period is the product of the compute unit price and vCore seconds billed: $0.000145/vCore/second * 50400 vCore seconds ~ $7.31

Zvýhodněné hybridní využití Azure a Rezervovaná kapacitaAzure Hybrid Benefit and reserved capacity

Zvýhodněné hybridní využití Azure (AHB) a slevy za rezervované kapacity se nevztahují na výpočetní úroveň bez serveru.Azure Hybrid Benefit (AHB) and reserved capacity discounts do not apply to the serverless compute tier.

Dostupné oblastiAvailable regions

Výpočetní vrstva bez serveru je dostupná po celém světě s výjimkou následujících oblastí: Čína – východ, Čína – sever, Německo Central, Německo – severovýchod a US Gov Central (Iowa).The serverless compute tier is available worldwide except the following regions: China East, China North, Germany Central, Germany Northeast, and US Gov Central (Iowa).

Další krokyNext steps