Azure SQL Database kiszolgáló nélkül

ÉRVÉNYES: Azure SQL Database

A Kiszolgáló nélküli egy számítási szint a Azure SQL Database-ban található egyes adatbázisokhoz, amelyek automatikusan átméretezik a számítási adatokat a munkaterhelési igény és a másodpercenkénti számítási mennyiség számlái alapján. A kiszolgáló nélküli számítási szint inaktív időszakokban is automatikusan szünetelteti az adatbázisokat, amikor csak a tárterület kerül számlázásra, és a tevékenység visszatérésekor automatikusan folytatja az adatbázisokat.

Kiszolgáló nélküli számítási réteg

A kiszolgáló nélküli számítási réteg a teljes tartomány Azure SQL Database a számítási automatikus méretezési tartomány és az automatikus szüneteltetés késleltetése paraméteres. Ezeknek a paramétereknek a konfigurálása alakítja az adatbázis teljesítményét és a számítási költségeket.

serverless billing

Teljesítménykonfiguráció

  • A minimális vCore és a maximális vCore paraméter olyan konfigurálható paraméterek, amelyek meghatározzák az adatbázishoz rendelkezésre álló számítási kapacitás tartományát. A memória és az IO határértéke a megadott vCore tartományhoz van arányban. 
  • Az automatikus szüneteltetés késleltetése egy konfigurálható paraméter, amely megadja, hogy az adatbázisnak ennyi ideig kell inaktívnak lennie az automatikus szüneteltetés előtt. Az adatbázist a rendszer automatikusan folytatja, amikor legközelebb bejelentkezik vagy más tevékenységet folytat. Másik lehetőségként le is tilthatja az automatikus szüneteltetés funkcióját.

Költség

  • A kiszolgáló nélküli adatbázisok költsége a számítási költség és a tárterület költségének összegzése.
  • Ha a számítási használat a konfigurált minimális és maximális korlát között van, a számítási költség a vCore-on és a felhasznált memórián alapul.
  • Ha a számítási használat a konfigurált minimális korlát alatt van, a számítási költség a beállított minimális vCores és minimális memóriaszámon alapul.
  • Az adatbázis szüneteltetése után a számítási költség nulla, és csak a tárterületköltségek fel vannak számolva.
  • A tárterület költségét ugyanúgy határozzák meg, mint a kiépített számítási rétegben.

További költségadatokért lásd: Számlázás.

Esetek

A kiszolgáló nélküli kiszolgálók olyan, időnkénti, kiszámíthatatlan használati mintákkal összeszámítatlan adatbázisokra optimalizált ár-teljesítmény, amelyek az üresjárati használati időszakok után némi késéssel tudnak számításokat ki számítani. Ezzel szemben a kiépített számítási szint az ár-teljesítményt úgy optimalizáltuk, hogy csak egy adatbázist vagy több, magasabb átlagfelhasználású, rugalmassági készletekben található adatbázist optimalizáljon, amelyek nem tudnak késést fizetni a be melegedés kiszámításához.

Kiszolgáló nélküli számításhoz jól használható esetek

  • Az időnkénti, kiszámíthatatlan használati mintákkal és inaktivitási időszakokkal kiszámíthatatlan módon, hosszabb idő alatt kisebb átlagos számítási kapacitással számoló egyetlen adatbázis.
  • A kiépített számítási réteg egyetlen, gyakran átméretezésre használt adatbázisa, valamint azok az ügyfelek, akik delegálni szeretnék a számítási újraszámítást a szolgáltatásra.
  • Új, a használati előzmény nélküli adatbázisok, ahol a számítás méretezése bonyolult vagy nem lehetséges becslést számítani a projektben való SQL Database.

A kiépített számítási feladatokhoz jól használható esetek

  • Egységes adatbázisok, amelyek rendszeresebb, kiszámíthatóbb használati mintákkal és idővel magasabb átlagos számítási felhasználással vannak kihasználva.
  • Azokat az adatbázisokat, amelyek nem tudják lehozni a memória-metszés vagy a szüneteltetett állapotból való visszaesés gyakori késéseiből eredő teljesítménycseréket.
  • Több adatbázis időnként kiszámíthatatlan használati mintákkal, amelyek rugalmas készletekbe összevonhatóak a jobb ár-teljesítményoptimalizálás érdekében.

Összehasonlítása kiépített számítási rétegekkel

Az alábbi táblázat összefoglalja a kiszolgáló nélküli számítási szint és a kiépített számítási szint különbségét:

Kiszolgáló nélküli számítás Kiépített számítás
Adatbázis-használati minta Időnként, kiszámíthatatlan módon, kisebb átlagos számítási kihasználtság mellett. Rendszeresebb használati minták nagyobb átlagos számítási kihasználtság mellett idővel, illetve több, rugalmassági készletekből álló adatbázis használata esetén.
Teljesítménykezelési munka Alacsonyabb Magasabb
Méretezés kiszámítása Automatikus Kézi
Számítási válaszidő Lower after inactive periods Immediate
Számlázási részletesség Másodpercenként Óránként

Vásárlási modell és szolgáltatásréteg

SQL Database serverless jelenleg csak az Általános cél szint 5. generációs hardveren támogatott a vCore vásárlási modellben.

Automatikus méretezés

A skálázás válaszidejűsége

A kiszolgáló nélküli adatbázisok általában olyan gépen futnak, amely megfelelő kapacitással rendelkezik ahhoz, hogy az erőforrásigényt megszakítás nélkül kielégítse a max vCores érték által beállított korlátokon belül kért bármely számítási mennyiség esetén. Időnként automatikusan történik terheléselosztás, ha a gép néhány percen belül nem képes kielégíteni az erőforrásigényt. Ha például az erőforrásigény 4 vCore, de csak 2 vCore áll rendelkezésre, akkor akár néhány percig is eltarthat, amíg 4 vCores meg nem történik. Az adatbázis online állapotban marad a terheléselosztás során, kivéve a kapcsolat megszakadása esetén a művelet végén egy rövid ideig.

Memóriakezelés

A kiszolgáló nélküli adatbázisok memóriája gyakrabban visszaigénylhető, mint a kiépített számítási adatbázisokhoz. Ez a viselkedés fontos a kiszolgáló nélküli költségek szabályozásában, és hatással lehet a teljesítményre.

Gyorsítótár reklamációja

A kiépített számítási adatbázisokkal ellentétben a SQL gyorsítótár memóriája visszaigényel a kiszolgáló nélküli adatbázisból, ha a processzor vagy az aktív gyorsítótár kihasználtsága alacsony.

  • Az aktív gyorsítótár-használat alacsonynak minősül, ha egy adott időszakra a legutóbb használt gyorsítótárbejegyzések teljes mérete egy adott küszöbérték alá csökken.
  • A gyorsítótár visszakiáltójelének kiváltása esetén a célgyorsítótár mérete a korábbi méret töredékére csökken, és a reklamáció csak akkor folytatódik, ha a használat továbbra is alacsony.
  • Gyorsítótár-visszanyerés esetén az evict gyorsítótár-bejegyzéseinek kiválasztására vonatkozó házirend megegyezik a kiépített számítási adatbázisok kiválasztására vonatkozó házirendtel, amikor a memóriakommaláció magas.
  • A gyorsítótár mérete soha nem csökken a konfigurálható minimális memóriakorlát alatt.

Kiszolgáló nélküli és kiépített számítási adatbázisokban a gyorsítótár bejegyzései kieshetnek, ha az összes rendelkezésre álló memóriát használja.

Ha a processzor kihasználtsága alacsony, az aktív gyorsítótár-használat a használati szabálytól függően magas marad, és meggátolja a memória felkiáltójel-felhasználását. Az is lehet, hogy más késések is jelentkeznek, ha a felhasználói tevékenység leáll, mielőtt a memória felkiáltójele jelentkezik a korábbi felhasználói tevékenységre adott rendszeres háttérfolyamatok miatt. A törlési műveletek és a Query Store-beli adattörlési feladatok például törlésre megjelölt, de fizikailag nem törölt szellemrekordokat hoznak létre, amíg le nem fut a szellemtörlési folyamat. A szellem tisztítása további adatlapok gyorsítótárba olvasását is magában foglalhatja.

Gyorsítótár használata

A SQL gyorsítótár mérete nő, ahogy az adatok a lemezről ugyanúgy és ugyanolyan sebességűként vannak lehívva, mint a kiépített adatbázisok esetén. Ha az adatbázis foglalt, a gyorsítótár korlátlanul nőhet a maximális memóriakorlátig.

Auto-pausing and auto-resuming

Automatikus szüneteltetés

Az automatikus szüneteltetés akkor aktiválódik, ha az automatikus szüneteltetés késleltetésének időtartamára az összes alábbi feltétel teljesül:

  • Munkamenetek száma = 0
  • Cpu = 0 a felhasználói erőforráskészletben futó felhasználói terhelés esetén

Az automatikus szüneteltetés szükség esetén letiltható.

Az alábbi funkciók nem támogatják az automatikus szüneteltetés funkciót, de támogatják az automatikus méretezést. Ha az alábbi szolgáltatások bármelyikét használja, akkor az automatikus szüneteltetésnek le kell tiltva lennie, és az adatbázis online állapotban marad, függetlenül az adatbázis inaktivitási időtartamától:

Az automatikus szüneteltetés átmenetileg le van tiltva egyes olyan szolgáltatásfrissítések telepítése során, amelyekhez az adatbázisnak online állapotban kell lennie. Ilyen esetben az automatikus szüneteltetés a szolgáltatásfrissítés befejezése után ismét engedélyezetté válik.

Hibaelhárítási hibák automatikus szüneteltetése

Ha az automatikus szüneteltetés engedélyezve van, de egy adatbázis nem szünetelteti automatikusan a késleltetési idő után, és a fent felsorolt funkciók nem használatosak, az alkalmazás vagy a felhasználói munkamenetek megakadályozhatják az automatikus szüneteltetést. Ha meg szeretne tudni, hogy vannak-e éppen alkalmazás- vagy felhasználói munkamenetek az adatbázishoz csatlakoztatva, csatlakozzon az adatbázishoz bármely ügyféleszköz használatával, és hajtsa végre az alábbi lekérdezést:

SELECT session_id,
       host_name,
       program_name,
       client_interface_name,
       login_name,
       status,
       login_time,
       last_request_start_time,
       last_request_end_time
FROM sys.dm_exec_sessions AS s
INNER JOIN sys.dm_resource_governor_workload_groups AS wg
ON s.group_id = wg.group_id
WHERE s.session_id <> @@SPID
      AND
      (
      (
      wg.name like 'UserPrimaryGroup.DB%'
      AND
      TRY_CAST(RIGHT(wg.name, LEN(wg.name) - LEN('UserPrimaryGroup.DB') - 2) AS int) = DB_ID()
      )
      OR
      wg.name = 'DACGroup'
      );

Tipp

A lekérdezés futtatása után mindenképpen válassza le az adatbázist. Ellenkező esetben a lekérdezés által használt nyitott munkamenet meggátolja az automatikus szüneteltetést.

Ha az eredményhalmaz nem üres, az azt jelenti, hogy vannak olyan munkamenetek, amelyek meggátolják az automatikus szüneteltetést.

Ha az eredményhalmaz üres, akkor is lehetséges, hogy a munkamenetek – akár csak rövid ideig – meg voltak nyitva az automatikus szüneteltetés késleltetési időszakának egy korábbi pontján. Ha meg kell vizsgálnia, hogy történt-e ilyen tevékenység a késési időszakban, használja az Azure SQL auditálást, és vizsgálja meg a vonatkozó időszakra vonatkozó naplóadatokat.

A nyitott munkamenetek jelenléte – a felhasználói erőforráskészletben egyidejű processzor-használatmal vagy anélkül – a leggyakoribb oka annak, ha a kiszolgáló nélküli adatbázisok nem szüneteltetik automatikusan a szüneteltetésüket a várt módon.

Automatikus visszaúszás

Az automatikus visszaúszás akkor aktiválódik, ha a következő feltételek bármelyike teljesül:

Funkció Automatikus önéletrajz-eseményindító
Hitelesítés és hitelesítés Bejelentkezés
Veszélyforrás-észlelés A veszélyforrások észlelésére vonatkozó beállítások engedélyezése/letiltása az adatbázis vagy a kiszolgáló szintjén.
A veszélyforrások észlelési beállításainak módosítása az adatbázis vagy a kiszolgáló szintjén.
Adatfeltárás és -besorolás Bizalmasság-címkék hozzáadása, módosítása, törlése és megtekintése
Naplózás Naplórekordok megtekintése.
A naplózási házirend frissítése vagy megtekintése.
Adatmaszkolás Adatmaszkolási szabályok hozzáadása, módosítása, törlése és megtekintése
Áttetsző adattitkosítás Átlátszó adattitkosítás állapotának vagy állapotának megtekintése
Biztonsági rés felmérése Eseti és rendszeres vizsgálat (ha engedélyezve van)
Query (performance) data store A lekérdezéstár beállításainak módosítása és megtekintése
Teljesítménybeli javaslatok Teljesítménybeli javaslatok megtekintése vagy alkalmazása
Automatikus beállítás Az automatikus beállítási javaslatok alkalmazása és ellenőrzése, például az automatikus indexelés
Adatbázis-másolás Hozza létre az adatbázist másolatként.
Exportálás BACPAC-fájlba.
SQL szinkronizálása Konfigurálható ütemezés szerint vagy manuálisan futtatott központi és tagadatbázisok közötti szinkronizálás
Bizonyos adatbázis-metaadatok módosítása Új adatbáziscímkék hozzáadása
A max vCore, a min vCores vagy az automatikus szüneteltetés késleltetésének módosítása
SQL Server Management Studio (SSMS) A 18.1-esnél korábbi SSMS-verziók használata és a kiszolgáló bármelyik adatbázisának új lekérdezésablakának megnyitása a kiszolgálón folytatja az automatikus szüneteltetésű adatbázist. Ez a viselkedés nem jelentkezik az SSMS 18.1-es vagy újabb verziójának használata esetén.

A fent felsorolt műveletek bármelyikének figyelése, kezelése vagy más megoldások automatikus visszavezetést vált ki.

Az automatikus visszaúszás bizonyos szolgáltatásfrissítések telepítésekor is aktiválódik, amelyekhez az adatbázisnak online állapotban kell lennie.

Kapcsolat

Ha egy kiszolgáló nélküli adatbázis fel van függesztve, akkor az első bejelentkezés folytatja az adatbázist, és egy hibaüzenetet ad vissza, amely arról közli, hogy az adatbázis nem érhető el a 40613-as hibakóddal. Az adatbázis újraindítását követően újra be kell jelentkeznie a kapcsolat létesítéséhez. A kapcsolati újrapróbálkozási logikával is rendelkezik adatbázis-ügyfeleket nem kell módosítani. Az SqlClient-illesztő beépített csatlakozási újrapróbálkozási beállításairól a konfigurálható újrapróbálkozási logika az SqlClient-ben címűban tájékozódik.

Késés

A kiszolgáló nélküli adatbázisok automatikus újraindításának és automatikus szüneteltetésének késése általában 1 perc, az automatikus szüneteltetés pedig 1–10 perc.

Ügyfél által kezelt átlátszó adattitkosítás (BYOK)

Ha ügyfél által kezelt átlátszó adattitkosítást (BYOK) használ, és a kiszolgáló nélküli adatbázis automatikusan szünetelteti a billentyűt a kulcs törlésekor vagy visszavonásakor, akkor az adatbázis automatikusan szüneteltetett állapotban marad. Ebben az esetben az adatbázis legközelebbi folytatása után az adatbázis nagyjából 10 percen belül elérhetetlenné válik. Amikor az adatbázis elérhetetlenné válik, a helyreállítási folyamat ugyanaz, mint a kiépített számítási adatbázisoké. Ha a kiszolgáló nélküli adatbázis online állapotban van kulcs törlésekor vagy visszavonásakor, akkor az adatbázis körülbelül 10 percen belül elérhetetlenné válik, ugyanúgy, mint a kiépített számítási adatbázisok esetén.

Beúszás kiszolgáló nélküli számítási rétegbe

Új adatbázis létrehozása vagy meglévő adatbázis kiszolgáló nélküli számítási rétegbe való áthelyezése ugyanazt a mintát követi, mint amikor egy új adatbázist hoz létre a kiépített számítási rétegben, és az alábbi két lépést kell követnie.

  1. Adja meg a szolgáltatási cél célt. A szolgáltatás célkitűzése átirasztja a szolgáltatásszintet, a hardverek generálása és a maximális vCore-értékeket. A szolgáltatás céljának beállítási lehetőségeiről a kiszolgáló nélküli erőforráskorlátok

  2. Szükség esetén megadhatja a minimális vCore-értékeket és az automatikus szüneteltetés késleltetését az alapértelmezett értékek módosítása érdekében. Az alábbi táblázat ezeknek a paramétereknek az értékeit tartalmazza.

    Paraméter Érték választási lehetőségei Alapértelmezett érték
    Minimális vCores A beállított max vCores típustól függ – lásd az erőforráskorlátokat. 0,5 vCores
    Késleltetés automatikus kitöltése Minimum: 60 perc (1 óra)
    Maximum: 10080 perc (7 nap)
    Lépések: 10 perc
    Automatikus javítás letiltása: -1
    60 perc

Új adatbázis létrehozása a kiszolgáló nélküli számítási rétegben

Az alábbi példák egy új adatbázist hoznak létre a kiszolgáló nélküli számítási rétegben.

Az Azure Portal használata

Lásd: Gyorsútmutató:Egyetlen adatbázis Azure SQL Database az Azure Portal használatával.

A PowerShell használata

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

Az Azure CLI használata

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

A Transact-SQL (T-SQL) használata

T-SQL a minimális vcore-értékek és az automatikus alkalmazás késleltetése. Ezeket később módosítani lehet a portálról vagy más kezelési API-kon keresztül (PowerShell, Azure CLI, REST API).

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

Részletes információkért lásd: ADATBÁZIS LÉTREHOZÁSA.

Adatbázis áthelyezése a kiépített számítási rétegből a kiszolgáló nélküli számítási rétegbe

Az alábbi példák egy adatbázist áthelyeznek a kiépített számítási rétegből a kiszolgáló nélküli számítási rétegbe.

A PowerShell használata

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

Az Azure CLI használata

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

A Transact-SQL (T-SQL) használata

A T-SQL minimális aláhúzásjelek és az automatikus szüneteltetés késleltetésére alapértelmezett értékeket alkalmaz a program. Ezeket később módosítani lehet a portálról vagy más kezelési API-kon keresztül (PowerShell, Azure CLI, REST API).

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

Részletes információkért lásd: ALTER DATABASE.

Adatbázis áthelyezése a kiszolgáló nélküli számítási rétegből a kiépített számítási rétegbe

A kiszolgáló nélküli adatbázis ugyanúgy áthelyezheti egy kiépített számítási rétegbe, mint a kiépített számítási adatbázist egy kiszolgáló nélküli számítási rétegbe.

Kiszolgáló nélküli konfiguráció módosítása

A PowerShell használata

A maximális vagy minimális vCore- és automatikus kitöltési késleltetést a PowerShell Set-AzSqlDatabase parancsával, a , valamint az argumentumokkal MinVcoreAutoPauseDelayInMinutes hajthatja végre.

Az Azure CLI használata

A maximális vagy minimális vCore-értékeket, valamint az automatikus javítás késleltetését az Sql db update parancs használatával hajtjuk végre az Azure CLI-ben a , és az min-capacityauto-pause-delay argumentumok használatával.

Figyelés

Felhasznált és kiszámlázható erőforrások

A kiszolgáló nélküli adatbázisok erőforrásait appcsomag, példány SQL és felhasználói erőforráskészlet entitások tikkosodják.

Appcsomag

Az appcsomag az adatbázis külső legtöbb erőforrás-kezelési határa, függetlenül attól, hogy az adatbázis kiszolgáló nélküli vagy kiépített számítási rétegben található-e. Az appcsomag tartalmazza a SQL és külső szolgáltatásokat, például a Teljes szöveges keresés szolgáltatást, amely együtt hatókört biztosít az adott adatbázisban használt összes felhasználói és rendszererőforrás SQL Database. A SQL példány általában teljes erőforrás-kihasználtságot jellemzően az appcsomagban jellemzően tartalmaz.

Felhasználói erőforráskészlet

A felhasználói erőforráskészlet egy adatbázis belső erőforrás-kezelési határa, függetlenül attól, hogy az adatbázis kiszolgáló nélküli vagy kiépített számítási rétegben található-e. A felhasználói erőforráskészlet hatóköre a DDL-lekérdezésekkel (például CREATE és ALTER, DML) létrehozott felhasználói munkaterhelés esetén (például INSERT, UPDATE, DELETE és MERGE, SELECT) a felhasználói erőforráskészlet hatókörét adja meg. Ezek a lekérdezések általában az appcsomagon belüli használat legnagyobb részét képviselik.

Metrikák

A kiszolgáló nélküli adatbázisok appcsomagjának és felhasználói erőforráskészletének erőforrás-használatát figyelő metrikák az alábbi táblázatban szerepelnek:

Entitás Metrikus Leírás Mennyiség
Appcsomag app_cpu_percent Az app által használt vCore-érték százalékos értéke az app számára engedélyezett maximális vCore-értékhez viszonyítva. Százalék
Appcsomag app_cpu_billed Az alkalmazáshoz a jelentéskészítési időszak során kiszámított számítási összeg. Az ebben az időszakban kifizetett összeg e mutató és a vCore egységárának a terméke.

E mutató értékeit az adott időszakban felhasznált processzor és memória másodpercenkénti maximumának összesítése határozza meg. Ha a felhasznált mennyiség kisebb, mint a minimális vCores és a minimális memória által meghatározott, kiépített összeg, akkor a rendszer kiszámlázja a minimálisan kiépített mennyiséget. A processzor és a memória számlázási célokból való összehasonlítása érdekében a memória a vCore-értékek egy egységében normalizálódik a memória gb-os, vCore-onkénti 3 GB-os átszámításával.
vCore másodperc
Appcsomag app_memory_percent Az app által használt memória százalékos értéke az app számára engedélyezett maximális memóriához képest. Százalék
Felhasználói erőforráskészlet cpu_percent A felhasználói munkaterhelés által használt vCore-adatok százalékos aránya a felhasználói munkaterhelésben engedélyezett maximális vCore-értékhez viszonyítva. Százalék
Felhasználói erőforráskészlet data_IO_percent A felhasználói terhelés által használt adat-IOPS százalékos értéke a felhasználói terhelés esetén engedélyezett maximális adat IOPS-értékhez viszonyítva. Százalék
Felhasználói erőforráskészlet log_IO_percent A felhasználói munkaterhelés által használt log MB/m százalékos értéke ahhoz képest, hogy a felhasználó maximálisan hány log MB/s engedélyezett a felhasználói terheléshez. Százalék
Felhasználói erőforráskészlet workers_percent A felhasználó munkaterhelése által használt dolgozók százalékos aránya a felhasználó munkaterheléséhez engedélyezett maximális dolgozókhoz viszonyítva. Százalék
Felhasználói erőforráskészlet sessions_percent A felhasználói terhelés által használt munkamenetek százalékos aránya a felhasználói terheléshez engedélyezett maximális munkamenetekhez viszonyítva. Százalék

Szünet és folytatás állapota

Az Azure Portalon az adatbázis állapota a kiszolgáló áttekintő ablaktáblájában látható, amely felsorolja a benne található adatbázisokat. Az adatbázis állapota az adatbázis áttekintő ablaktáblájában is megjelenik.

Az alábbi parancsokkal lekérdezheti egy adatbázis szüneteltetési és újraindítási állapotát:

A PowerShell használata

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

Az Azure CLI használata

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

Erőforráskorlátok

Az erőforráskorlátokat a Kiszolgáló nélküli számítási szint .

Számlázás

A kiszámított számítási mennyiség a felhasznált processzor és a másodpercekben felhasznált memória maximális száma. Ha a felhasznált processzor és a felhasznált memória mennyisége kisebb az egyes erőforrásokhoz kiépített minimális mennyiségnél, akkor kiszámlázjuk a kiépített mennyiséget. A processzor és a memória számlázási célokból való összehasonlítása érdekében a memória a vCore-értékek egy egységében normalizálódik a memória gb-os, vCore-onkénti 3 GB-os átszámításával.

  • Erőforrás számlázása:processzor és memória
  • Kiszámlázva:vCore egységár * max (min vCores, felhasznált vCores, minimális memória GB * 1/3, felhasznált memória GB * 1/3)
  • Számlázási gyakoriság:Másodpercenként

A vCore egységára a vCore per másodperc díja. Az adott régió Azure SQL Database egységáraiért tekintse meg az árszabás lapját.

A kiszámított számítási összeg a következő mutató szerint van felfedve:

  • Mutató:app_cpu_billed (vCore másodperc)
  • Definíció:max (min vCores, használt vCores, min memória GB * 1/3, használt memória GB * 1/3)
  • Jelentés gyakorisága:percenként

Ezt a mennyiséget a program minden másodpercben kiszámítja, és 1 percen keresztül összesíti.

Minimális számítási számla

Ha egy kiszolgáló nélküli adatbázis szüneteltetve van, akkor a számítási számla nulla. Ha a kiszolgáló nélküli adatbázis nincs szüneteltetve, akkor a minimális számítási számla nem kisebb, mint a max (min vCores, min memory GB* 1/3) alapuló vCore-adatok mennyisége.

Példák:

  • Tegyük fel, hogy egy kiszolgáló nélküli adatbázis nincs felfüggesztve, és nincs beállítva 8 max vCore és 1 perc vCore érték, amely 3,0 GB-os memóriaként van beállítva. Ezután a minimális számítási számla alapja a max (1 vCore, 3,0 GB * 1 vCore / 3 GB) = 1 vCore.
  • Tegyük fel, hogy egy kiszolgáló nélküli adatbázis nincs felfüggesztve és konfigurálva 4 max vCore és 0,5 perc vCore értékekkel, amelyek a 2,1 GB-os memória 2,1 GB-nak nek fel vannak állítva. Ezután a minimális számítási számla alapja a max (0,5 vCore, 2,1 GB * 1 vCore / 3 GB) = 0,7 vCore.

A Azure SQL Database nélküli windowsos árazási kalkulátor segítségével megállapíthatja, hogy hány memória van beállítva a beállított max és min vCore érték alapján. Általános szabály, hogy ha a konfigurált minimális vCores érték nagyobb, mint 0,5 vCore, akkor a minimális számítási számla független a konfigurált minimális memóriaszámtól, és csak a konfigurált minimális vCore-adatok száma alapján történik.

Példa:

Fontolja meg az 1 perc vCore és 4 max vCore értékekkel konfigurált kiszolgáló nélküli adatbázist. Ez a konfiguráció körülbelül 3 GB perc memória, illetve 12 GB maximális memória felel meg. Tegyük fel, hogy az automatikus szüneteltetés késleltetése 6 óra, az adatbázis terhelése pedig aktív a 24 órás időszak első 2 órájában, és egyébként inaktív.

Ebben az esetben az adatbázist kiszámlázjuk a számításhoz és a tárterülethez az első 8 órában. Még ha az adatbázis inaktív a második óra után is, a számlázás a következő 6 órában továbbra is számítható ki a minimálisan kiépített számítási érték alapján, miközben az adatbázis online állapotban van. Az adatbázis szüneteltetése közben a 24 órás időtartam fennmaradó része alatt csak a tárterület számlázása fog kiszámlázva.

Pontosabban, a példában a számítási számla kiszámítása az alábbi képlet alapján történik:

Időintervallum vCores used each second MÁSODPERCenként használt GB Kiszámlázva a számítási dimenzió vCore seconds billed over time interval
0:00-1:00 4 9 használt vCores 4 vCores * 3600 seconds = 14400 vCore seconds
1:00-2:00 1 12 Felhasznált memória 12 GB * 1/3 * 3600 másodperc = 14400 vCore másodperc
2:00-8:00 0 0 A memóriával létesített minimális memória 3 GB * 1/3 * 21600 másodperc = 21600 vCore másodperc
8:00-24:00 0 0 Nincs számítási számlázás szüneteltetve 0 vCore másodperc
24 óránál több mint 24 óra alatt kiszámlázott vCore-másodpercek összesen 50400 vCore másodperc

Tegyük fel, hogy a számítási egység ára 0,000145 Ft/vCore/másodperc. Ezután a 24 órás időszakhoz kiszámított számítási számla a kiszámított egységár és a kiszámlázott vCore másodperc díja: 0,000145 Ft/vCore/másodperc * 50400 vCore másodperc ~ 7,31 USD.

Azure Hibrid előny és fenntartott kapacitás

Az Azure Hibrid előny (AHB) és a fenntartott kapacitási kedvezmények nem vonatkoznak a kiszolgáló nélküli számítási rétegre.

Elérhető régiók

A kiszolgáló nélküli számítási szint világszerte elérhető, kivéve a következő régiókat: Kína kelet, Észak-Kína, Németország Central, Germany Northeast és US Gov Central (Iowa).

További lépések