Škálování prostředků jednoúčelové databáze ve službě Azure SQL Database

Tento článek popisuje, jak škálovat výpočetní prostředky a prostředky úložiště dostupné pro službu Azure SQL Database ve zřízené výpočetní vrstvě. Alternativně úroveň výpočetních prostředků bez serveru poskytuje automatické škálování výpočetních prostředků a účtuje se za sekundu za využité výpočetní prostředky.

Po počátečním výběru počtu virtuálních jader nebo jednotek DTU můžete vertikálně navýšit nebo snížit kapacitu izolované databáze dynamicky na základě skutečného využití:

• Transact-SQL
• Azure Portal
• PowerShell
• Azure CLI
• REST API

Důležité

Za určitých okolností možná budete muset zmenšit databázi, aby se uvolnilo nevyužité místo. Další informace najdete v tématu Správa prostoru souborů ve službě Azure SQL Database.

Poznámka:

ID Microsoft Entra se dříve označovalo jako Azure Active Directory (Azure AD).

Dopad

Změna úrovně služby nebo velikosti výpočetních prostředků zahrnuje hlavně službu, která provádí následující kroky:

1. Vytvořte pro databázi novou výpočetní instanci.

   Vytvoří se nová výpočetní instance s požadovanou úrovní služby a velikostí výpočetních prostředků. U některých kombinací změn úrovně služby a velikosti výpočetních prostředků se musí v nové výpočetní instanci vytvořit replika databáze, která zahrnuje kopírování dat a může výrazně ovlivnit celkovou latenci. Bez ohledu na to, že databáze zůstane během tohoto kroku online a připojení se budou dál směrovat do databáze v původní výpočetní instanci.

2. Přepněte směrování připojení k nové výpočetní instanci.

   Stávající připojení k databázi v původní výpočetní instanci se zahodí. Všechna nová připojení se navazují k databázi v nové výpočetní instanci. U některých kombinací změn úrovně služby a velikosti výpočetních prostředků se soubory databáze během přepínače odpojí a znovu připojují. Bez ohledu na to může přepnutí vést ke krátkému přerušení služby, když je databáze obecně nedostupná po dobu kratší než 30 sekund a často jen několik sekund. Pokud při vyřazení připojení běží dlouhotrvající transakce, může doba trvání tohoto kroku trvat delší dobu, než se obnoví přerušené transakce. Zrychlené obnovení databáze může snížit dopad přerušení dlouhotrvajících transakcí.

Důležité

Během jakéhokoli kroku pracovního postupu se neztratí žádná data. Ujistěte se, že jste implementovali určitou logiku opakování v aplikacích a součástech, které používají Azure SQL Database při změně úrovně služby.

Latence

Odhadovaná latence změny úrovně služby, škálování velikosti výpočetních prostředků izolované databáze nebo elastického fondu, přesunutí databáze do nebo z elastického fondu nebo přesunutí databáze mezi elastickými fondy je parametrizována následujícím způsobem:

Latence škálování databáze	Do jednoúčelové databáze Basic, jednoúčelová databáze Standard (S0-S1)	Do jednoúčelové databáze úrovně Standard (S2-S12), jednoúčelová databáze pro obecné účely, databáze s elastickým fondem Basic, databáze s elastickým fondem Standard, databáze ve fondu pro obecné účely	Na jednoúčelovou databázi nebo databázi ve fondu úrovně Premium Pro důležité obchodní informace jednoúčelovou databázi nebo databázi ve fondu	Do izolované databáze nebo databáze ve fondu hyperškálování
Z jednoúčelové databáze Basic, jednoúčelové databáze Standard (S0-S1)	• Konstantní časová latence nezávislá na použitém prostoru. • Obvykle méně než 5 minut.	• Latence úměrná prostoru databáze použitému kvůli kopírování dat. • Obvykle je využito méně než 1 minuta za GB místa.	• Latence úměrná prostoru databáze použitému kvůli kopírování dat. • Obvykle je využito méně než 1 minuta za GB místa.	• Latence úměrná prostoru databáze použitému kvůli kopírování dat. • Obvykle je využito méně než 1 minuta za GB místa.
Z databáze ve fondu Basic, jednoúčelové databáze standardu (S2–S12), databáze ve fondu úrovně Standard, jednoúčelová databáze pro obecné účely nebo databáze ve fondu	• Latence úměrná prostoru databáze použitému kvůli kopírování dat. • Obvykle je využito méně než 1 minuta za GB místa.	• U jednoúčelových databází je konstantní časová latence nezávislá na využitých prostorech. • U jednoúčelových databází obvykle méně než 5 minut. • Pro elastické fondy úměrné počtu databází.	• Latence úměrná prostoru databáze použitému kvůli kopírování dat. • Obvykle je využito méně než 1 minuta za GB místa.	• Latence úměrná prostoru databáze použitému kvůli kopírování dat. • Obvykle je využito méně než 1 minuta za GB místa.
Z jednoúčelové databáze premium nebo databáze ve fondu Pro důležité obchodní informace jednoúčelové databáze nebo databáze ve fondu	• Latence úměrná prostoru databáze použitému kvůli kopírování dat. • Obvykle je využito méně než 1 minuta za GB místa.	• Latence úměrná prostoru databáze použitému kvůli kopírování dat. • Obvykle je využito méně než 1 minuta za GB místa.	• Latence úměrná prostoru databáze použitému kvůli kopírování dat. • Obvykle je využito méně než 1 minuta za GB místa.	• Latence úměrná prostoru databáze použitému kvůli kopírování dat. • Obvykle je využito méně než 1 minuta za GB místa.
Z izolované databáze hyperškálování nebo databáze ve fondu	–	Informace o podporovaných scénářích a omezeních najdete v tématu Zpětná migrace z Hyperscale .	–	• Konstantní časová latence nezávislá na použitém prostoru. • Obvykle méně než 2 minuty.

Poznámka:

• Kromě toho u databází Úrovně Standard (S2-S12) a Pro obecné účely bude latence pro přesun databáze do nebo z elastického fondu nebo mezi elastickými fondy úměrná velikosti databáze, pokud databáze používá úložiště sdílené složky ÚROVNĚ Premium (PFS).
• V případě přesunu databáze do nebo z elastického fondu ovlivňuje latenci jenom prostor používaný databází, nikoli prostor používaný elastickým fondem.
• Pokud chcete zjistit, jestli databáze používá úložiště PFS, spusťte v kontextu databáze následující dotaz. Pokud je PremiumFileStorage hodnota ve sloupci AccountType nebo PremiumFileStorage-ZRS, databáze používá úložiště PFS.

SELECT s.file_id,
       s.type_desc,
       s.name,
       FILEPROPERTYEX(s.name, 'AccountType') AS AccountType
FROM sys.database_files AS s
WHERE s.type_desc IN ('ROWS', 'LOG');

Poznámka:

• Zónově redundantní vlastnost zůstane ve výchozím nastavení stejná při škálování izolované databáze z Pro důležité obchodní informace na úroveň Pro obecné účely.
• Latence operace škálování při změně redundance zóny pro jednoúčelovou databázi pro obecné účely je úměrná velikosti databáze.

Tip

Pokud chcete monitorovat probíhající operace, přečtěte si téma: Správa operací pomocí rozhraní SQL REST API, správa operací pomocí rozhraní příkazového řádku, monitorování operací pomocí T-SQL a těchto dvou příkazů PowerShellu: Get-AzSqlDatabaseActivity a Stop-AzSqlDatabaseActivity.

Monitorování nebo zrušení změn škálování

Operaci změny úrovně služby nebo škálování výpočetních prostředků je možné monitorovat a rušit.

Azure Portal

Na stránce Přehled databáze SQL vyhledejte banner označující probíhající operaci škálování a vyberte odkaz Zobrazit další informace o probíhajícím nasazení.

Na výsledné stránce probíhajících operací vyberte Zrušit tuto operaci.

PowerShell

Aby bylo možné vyvolat příkazy PowerShellu v počítači, musí být místně nainstalován balíček Az verze 9.7.0 nebo novější verze. Nebo zvažte použití Azure Cloud Shellu ke spuštění Azure PowerShellu na shell.azure.com.

Nejprve se přihlaste k Azure a nastavte správný kontext pro vaše předplatné:

Login-AzAccount
$SubscriptionID = "<YourSubscriptionIdHere>"
Select-AzSubscription -SubscriptionName $SubscriptionID

K monitorování operací v databázi, včetně operací škálování, použijte Rutinu Get-AzSqlDatabaseActivity. Následující ukázka vrátí pro každou aktuálně spuštěnou OperationId operaci.

Get-AzSqlDatabaseActivity -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "Database01"

Pokud chcete zrušit asynchronní operaci, jako je škálování databáze, identifikujte operaci a pak pomocí příkazu Stop-AzSqlDatabaseActivity s konkrétní OperationIdukázkou, jak je znázorněno v následující ukázce.

Stop-AzSqlDatabaseActivity -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -DatabaseName "Database01" -OperationId af97005d-9243-4f8a-844e-402d1cc855f5

Azure CLI

Z terminálu Cloud Shell použijte následující ukázkový příkaz k identifikaci aktuálně spuštěných operací. V terminálu Cloud Shellu $resourceGroupNamenastavte , $serverNamea $databaseName proměnné a pak spusťte následující příkaz:

$resourceGroupName = "<resource group name>"
$serverName = "<server name>"
$databaseName = "<sql database name>"
az sql db op list --resource-group $resourceGroupName --server $serverName --database $databaseName --query "[?state=='InProgress'].name" --out tsv

Pokud chcete zastavit asynchronní operaci, jako je škálování databáze, v terminálu Cloud Shellu $resourceGroupName$serverName$databaseName nastavte a proměnné a spusťte následující příkaz:

$resourceGroupName = "<resource group name>"
$serverName = "<server name>"
$databaseName = "<sql database name>"
$operationName = (az sql db op list --resource-group $resourceGroupName --server $serverName --database $databaseName --query "[?state=='InProgress'].name" --out tsv)
if (-not [string]::IsNullOrEmpty($operationName)) {
    (az sql db op cancel --resource-group $resourceGroupName --server $serverName --database $databaseName --name $operationName)
        "Operation " + $operationName + " has been canceled"
}
else {
    "No service tier change or compute rescaling operation found"
}

Oprávnění

K škálování databází prostřednictvím jazyka Transact-SQL ALTER DATABASE se používá. Pokud chcete škálovat databázi, musí být přihlašovací jméno správce serveru (vytvořené při zřízení logického serveru Azure SQL Database), správce Microsoft Entra serveru, člen databázové role dbmanager v master, člen role databáze db_owner databáze v aktuální databázi nebo dbo databáze. Další informace naleznete v tématu ALTER DATABASE.

Ke škálování databází prostřednictvím webu Azure Portal, PowerShellu, Azure CLI nebo rozhraní REST API se vyžadují oprávnění Azure RBAC, konkrétně role Přispěvatel, Přispěvatel databáze SQL nebo Role Azure RBAC přispěvatele SQL Serveru. Další informace najdete v předdefinovaných rolích Azure RBAC.

Další důležité informace

• Pokud upgradujete na vyšší úroveň služby nebo výpočetní velikost, nezvýší se maximální velikost databáze, pokud explicitně neurčíte větší velikost (maxsize).
• Pokud chcete databázi downgradovat, musí být využitý prostor databáze menší než maximální povolená velikost cílové úrovně služby a velikosti výpočetních prostředků.
• Při downgradu z úrovně Premium na úroveň Standard platí dodatečné náklady na úložiště, pokud se v cílové velikosti výpočetních prostředků podporuje maximální velikost databáze (1) a (2) maximální velikost překračuje zahrnutou velikost úložiště cílové velikosti výpočetních prostředků. Pokud je například databáze P1 s maximální velikostí 500 GB nižší než S3, platí dodatečné náklady na úložiště, protože S3 podporuje maximální velikost 1 TB a jeho zahrnutá velikost úložiště je pouze 250 GB. Velikost úložiště navíc je 500 GB – 250 GB = 250 GB. Ceny dodatečného úložiště najdete na stránce s cenami služby Azure SQL Database. Pokud je skutečné množství využitého místa menší než zahrnuté množství úložiště, můžete se těmto dodatečným nákladům vyhnout snížením maximální velikosti databáze na zahrnutou částku.
• Při upgradu databáze s povolenou geografickou replikací upgradujte sekundární databáze na požadovanou úroveň služby a velikost výpočetních prostředků před upgradem primární databáze (obecné pokyny pro dosažení nejlepšího výkonu). Při upgradu na jinou edici je potřeba nejprve upgradovat sekundární databázi.
• Při downgradu databáze s povolenou geografickou replikací downgradujte primární databáze na požadovanou úroveň služby a velikost výpočetních prostředků před downgradem sekundární databáze (obecné pokyny pro dosažení nejlepšího výkonu). Při downgradu na jinou edici je potřeba nejprve downgradovat primární databázi.
• Nabídky služeb pro obnovení se u různých úrovní služby liší. Pokud downgradujete na úroveň Basic , je k dispozici nižší doba uchovávání záloh. Viz Zálohování služby Azure SQL Database.
• Nové vlastnosti databáze se použijí, dokud se změny nedokončí.
• Pokud se při změně úrovně služby vyžaduje kopírování dat pro škálování databáze (viz Latence), může vysoké využití prostředků souběžné s operací škálování způsobit delší dobu škálování. Díky zrychlenému obnovení databáze (ADR) není vrácení dlouhotrvajících transakcí významným zdrojem zpoždění, ale vysoké využití prostředků může ponechat méně výpočetních prostředků, úložiště a šířky pásma sítě pro škálování, zejména u menších velikostí výpočetních prostředků.

Fakturace

Za každou hodinu se účtuje, že databáze existuje s použitím nejvyšší úrovně služby a velikosti výpočetních prostředků, která se použila během této hodiny, bez ohledu na využití nebo na to, jestli byla databáze aktivní za méně než hodinu. Pokud například vytvoříte jednu databázi a odstraníte ji pět minut později, faktura bude odrážet poplatek za jednu hodinu databáze.

Změna velikosti úložiště

Nákupní model založený na virtuálních jádrech

• Úložiště je možné zřídit až do maximální velikosti úložiště dat pomocí 1 GB přírůstků. Minimální konfigurovatelné úložiště dat je 1 GB. Maximální limity velikosti úložiště dat v jednotlivých cílech služby najdete na stránkách dokumentace k limitu prostředků pro omezení prostředků pro izolované databáze pomocí nákupního modelu virtuálních jader a omezení prostředků pro izolované databáze pomocí nákupního modelu DTU.

• Úložiště dat pro jednoúčelovou databázi je možné zřídit zvýšením nebo snížením její maximální velikosti pomocí webu Azure Portal, Transact-SQL, PowerShellu, Azure CLInebo REST API. Pokud je hodnota maximální velikosti zadána v bajtech, musí být násobkem 1 GB (1073741824 bajtů).

• Velikost dat, která lze uložit do datových souborů databáze, je omezená maximální velikostí nakonfigurovaného úložiště dat. Kromě úložiště azure SQL Database automaticky přidá 30% více úložiště, které se použije pro transakční protokol. Cena úložiště pro jednu databázi nebo elastický fond je součet objemů úložiště dat a úložiště transakčních protokolů vynásobené jednotkovou cenou za jednotku úložiště úrovně služby. Pokud je například datové úložiště nastavené na 10 GB, je dodatečné úložiště transakčních protokolů 10 GB × 30 % = 3 GB a celkové množství fakturovatelného úložiště je 10 GB + 3 GB = 13 GB.

  Poznámka:

  Maximální velikost souboru transakčního protokolu se spravuje automaticky a v některých případech může být větší než 30 % maximální velikosti úložiště dat. Tím se nezvyšuje cena úložiště pro databázi.

• Azure SQL Database pro databázi automaticky přidělí 32 GB na virtuální jádro tempdb . tempdb se nachází v místním úložišti SSD ve všech úrovních služby. Náklady tempdb jsou zahrnuté v ceně izolované databáze nebo elastického fondu.

• Podrobnosti o ceně úložiště najdete v tématu Ceny služby Azure SQL Database.

Důležité

Za určitých okolností možná budete muset zmenšit databázi, aby se uvolnilo nevyužité místo. Další informace najdete v tématu Správa prostoru souborů ve službě Azure SQL Database.

Nákupní model založený na DTU

• Cena DTU pro jednu databázi zahrnuje určitou velikost úložiště bez dalších nákladů. Dodatečné úložiště nad rámec zahrnutého objemu se dá zřídit za další poplatek až do limitu maximální velikosti v přírůstcích po 250 GB a do 1 TB potom v přírůstcích po 256 GB nad 1 TB. Zahrnuté částky úložiště a maximální limity velikosti najdete v tématu Jednoúčelová databáze: Velikosti úložiště a velikosti výpočetních prostředků.
• Větší úložiště dat pro jednoúčelovou databázi je možné zřídit zvýšením její maximální velikosti pomocí webu Azure Portal, Transact-SQL, PowerShellu, Azure CLI nebo REST API.
• Cena dodatečného úložiště pro jednoúčelovou databázi je dodatečné množství úložiště vynásobené cenou za jednotku úložiště úrovně služby. Podrobnosti o ceně dodatečného úložiště najdete v tématu Ceny služby Azure SQL Database.

Důležité

Za určitých okolností možná budete muset zmenšit databázi, aby se uvolnilo nevyužité místo. Další informace najdete v tématu Správa prostoru souborů ve službě Azure SQL Database.

Geograficky replikovaná databáze

Pokud chcete změnit velikost replikované sekundární databáze, změňte velikost primární databáze. Tato změna se pak replikuje a implementuje i v sekundární databázi.

Omezení P11 a P15, pokud maximální velikost větší než 1 TB

Ve všech oblastech s výjimkou Číny – východ, Čína – sever, Německo – střed a Německo – severovýchod je aktuálně k dispozici více než 1 TB úložiště na úrovni Premium. V těchto oblastech je úložiště na úrovni Premium omezeno na 1 TB. Následující aspekty a omezení platí pro databáze P11 a P15 s maximální velikostí větší než 1 TB:

• Pokud byla maximální velikost databáze P11 nebo P15 nastavená na hodnotu větší než 1 TB, můžete ji obnovit nebo zkopírovat pouze do databáze P11 nebo P15. Následně je možné databázi škálovat na jinou velikost výpočetních prostředků za předpokladu, že množství místa přiděleného v době operace opětovného škálování nepřekračuje maximální limity velikosti nové velikosti výpočetních prostředků.
• Pro aktivní scénáře geografické replikace:
  • Nastavení vztahu geografické replikace: Pokud je primární databáze P11 nebo P15, musí být sekundární (ies) také P11 nebo P15. Nižší velikosti výpočetních prostředků jsou odmítnuty jako sekundární, protože nejsou schopné podporovat více než 1 TB.
  • Upgrade primární databáze v relaci geografické replikace: Změna maximální velikosti na více než 1 TB v primární databázi aktivuje stejnou změnu v sekundární databázi. Oba upgrady musí být úspěšné, aby se změna primárního serveru projevila. Platí omezení oblasti pro možnost větší než 1 TB. Pokud je sekundární oblast v oblasti, která nepodporuje více než 1 TB, primární se neupgraduje.
• Použití služby Import/Export pro načítání databází P11/P15 s více než 1 TB se nepodporuje. K importu a exportu dat použijte SqlPackage.

Související obsah

Celkové limity prostředků najdete v tématu Omezení prostředků založených na virtuálních jádrech služby Azure SQL Database – izolované databáze a limity prostředků na základě DTU služby Azure SQL Database – izolované databáze.