Škálování prostředků jednoúčelové databáze ve službě Azure SQL Database
Platí pro:
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 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í:
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ů pro databáze 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:
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.
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. akcelerované obnovení databáze může snížit dopad na 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, Standardní jednoúčelová databáze (S0-S1) |
Na standardní jednoúčelovou databázi (S2-S12), Jednoúčelová databáze pro obecné účely, Základní elastická databáze ve fondu, Standardní elastická databáze ve fondu, Databáze sdružená pro obecné účely |
Do izolované databáze premium nebo databáze ve fondu, Kritická databáze pro podnikání nebo sdílená databáze |
Do izolované databáze nebo databáze ve fondu hyperškálování |
|---|---|---|---|---|
|
z jednoduché databáze Basic Standardní jednoúčelová databáze (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. |
|
Ze základní sdílené databáze, Standardní jednoúčelová databáze (S2-S12), Standardní sdružená databáze Všeobecná databáze nebo sdílená databáze |
– 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 použitém prostoru. – U jednoúčelových databází obvykle méně než 5 minut. - Pro elastické fondy platí, že počet databází je úměrný. |
– 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 prémiové samostatné databáze nebo sdružené databáze, Kriticky důležitá obchodní databáze nebo sdílená databáze |
– 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
PremiumFileStoragehodnota ve sloupci AccountType neboPremiumFileStorage-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.
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.
Oprávnění
K škálování databází prostřednictvím jazyka Transact-SQL se ALTER DATABASE 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.
Škálování databází prostřednictvím webu Azure Portal, PowerShellu, Azure CLI nebo rozhraní REST API: Jsou potřeba 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 tématu Předdefinované role 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 automatizované zálohy ve službě 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 k š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í. Se akcelerovaným obnovením databázenení vrácení dlouhotrvajících transakcí významným zdrojem zpoždění, ale vysoké souběžné využití prostředků může ponechat méně výpočetních, úložných a síťových prostředků pro škálování, zejména u menších výpočetních kapacit.
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 zadaná v bajtech, musí být násobkem 1 GB (1 073 741 824 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.tempdbse nachází v místním úložišti SSD ve všech úrovních služby. Nákladytempdbjsou 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ů pro databáze 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ů pro databáze 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. Později 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.