Azure SQL Database Hyperscale – nejčastější dotazy

Databáze Hyperscale je databáze ve službě SQL Database, která je podporována technologií úložiště s horizontálním navýšením kapacity hyperškálování. Databáze Hyperscale podporuje až 128 TB dat a poskytuje vysokou propustnost a výkon a rychlé škálování, které se přizpůsobí požadavkům úloh. Připojení, zpracování dotazů, funkce databázového stroje atd., fungují stejně jako všechny ostatní databáze ve službě Azure SQL Database.

Úroveň služby Hyperscale je k dispozici pouze pro jednoúčelové databáze využívající nákupní model založený na virtuálních jádrech ve službě Azure SQL Database. Není k dispozici v nákupním modelu založeném na DTU.

Úrovně služeb založené na virtuálních jádrech se liší podle dostupnosti databáze a typu úložiště, výkonu a maximální velikosti úložiště, jak je popsáno v porovnání limitů prostředků.

Úroveň služby Hyperscale je určená pro všechny zákazníky, kteří hledají vyšší výkon a dostupnost, rychlé zálohování a obnovení, rychlé úložiště a škálovatelnost výpočetních prostředků. To zahrnuje zákazníky, kteří začínají malé a rostoucí, kteří používají rozsáhlé důležité databáze, ty, kteří se přesouvají do cloudu, aby modernizovali své aplikace a zákazníky, kteří už používají jiné úrovně služeb ve službě Azure SQL Database. S Hyperscale získáte:

• Velikost databáze, která se může zvětšit z 10 GB až na 128 TB.
• Výpočetní prostředky virtuálních jader z 2 virtuálních jader až do 128 virtuálních jader
• Rychlé zálohování databází bez ohledu na velikost databáze (zálohy jsou založené na snímcích úložiště).
• Rychlé obnovení databáze bez ohledu na velikost databáze (obnovení pocházejí ze snímků úložiště).
• Vyšší propustnost protokolu bez ohledu na velikost databáze a počet virtuálních jader.
• Čtení škálování na více instancí pomocí jedné nebo více replik jen pro čtení, které se používají pro snižování zátěže úloh jen pro čtení nebo jako aktivní pohotovostní databáze.
• Rychlé vertikální navýšení kapacity výpočetních prostředků v konstantním čase pro zvýšení výkonu, který by vyhovoval náročné úloze, a následné vertikální snížení kapacity v konstantním čase. Operace škálování pro zřízené výpočetní prostředky zabírají jednociferné minuty a bez ohledu na velikost databáze za sekundu pro bezserverové výpočetní prostředky.
• Možnost platit za to, co používáte s bezserverovými výpočetními prostředky, kde se výpočetní prostředky účtují na základě využití.

Úroveň služby Hyperscale je dostupná ve všech oblastech, ve kterých je dostupná služba Azure SQL Database.

Ano. Další informace a omezení počtu databází na server najdete v tématu Omezení prostředků služby SQL Database pro izolované databáze a databáze ve fondu na serveru.

Architektura Hyperscale poskytuje vysoký výkon a propustnost a současně podporuje velké velikosti databází.

Hyperscale poskytuje rychlou škálovatelnost na základě vaší poptávky po úlohách.

• Vertikální navýšení/snížení kapacity

  Hyperscale umožňuje vertikálně navýšit kapacitu primárního výpočetního výkonu z hlediska prostředků, jako je procesor a paměť, a pak vertikálně snížit kapacitu v konstantním čase. Vzhledem k tomu, že je úložiště vzdálené, vertikální navýšení a snížení kapacity není velikost operace s daty.

  Podpora bezserverových výpočetních prostředků poskytuje automatické vertikální navýšení a snížení kapacity a výpočetní prostředky se účtují na základě využití.

• Horizontální navýšení/snížení kapacity

  S hyperškálováním můžete použít tři druhy sekundárních replik, které zajišťují škálování na více instancí čtení, vysokou dostupnost a požadavky na geografickou replikaci. Sem patří:

  • Až čtyři repliky s vysokou dostupností mají stejnou velikost výpočetních prostředků jako primární. Slouží jako aktivní pohotovostní repliky pro rychlé převzetí služeb při selhání z primárního serveru. Můžete je také použít k přesměrování zátěže čtení z primárního serveru.
  • Až 30 pojmenovaných replik, které mají stejnou nebo jinou velikost výpočetních prostředků než primární, aby vyhovovaly různým scénářům škálování na více instancí čtení.
  • Geografická replika v jiné oblasti Azure, která chrání před oblastmi výpadky a umožňuje škálování geografického čtení na více instancí.

Ano, můžete.

Ne, programovací model aplikace zůstane stejný jako u jakékoli jiné databáze MSSQL. Používáte připojovací řetězec jako obvykle a další běžné způsoby interakce s databází Hyperscale. Jakmile vaše aplikace používá databázi Hyperscale, může vaše aplikace využívat funkce, jako jsou sekundární repliky.

Na primární replice je výchozí úroveň izolace transakcí RCSI (izolace snímků potvrzená čtením). Na sekundárních replikách se škálováním na více systémů čtení je výchozí úroveň izolace snímek. Je to stejné jako v jakékoli jiné databázi Azure SQL.

Díky nové zjednodušené ceně od 15. prosince 2023 se snížila cena výpočetních prostředků pro nově vytvořené databáze Hyperscale, všechny bezserverové databáze Hyperscale a všechny elastické fondy Hyperscale. Díky novým zjednodušeným cenám není nutné použít Zvýhodněné hybridní využití Azure (AHB) k získání ekvivalentních úspor. Zvýhodněné hybridní využití Azure (AHB) je možné použít pouze u starších (vytvořených před 15. prosincem 2023) jednoúčelových databází Hyperscale se zřízenými výpočetními prostředky. U těchto starších databází platí AHB pouze do prosince 2026, po kterém se budou tyto databáze účtovat také podle nových zjednodušených cen. Další informace najdete na blogu s cenami hyperškálování a azure SQL Database Hyperscale – nižší, zjednodušené ceny.!

Hyperscale funguje dobře pro všechny typy úloh, včetně úloh OLTP, Hybrid (HTAP) a Analytické (datové tržiště).

Pokud aktuálně spouštíte interaktivní analytické dotazy využívající SQL Server jako datový sklad, je hyperškálování skvělou volbou, protože můžete hostovat malé a střední datové sklady (například několik TB až 128 TB) za nižší cenu a můžete migrovat úlohy datového skladu SQL Serveru do Hyperscale s minimálními změnami kódu T-SQL.

Pokud spouštíte analýzu dat ve velkém měřítku se složitými dotazy a trvalými rychlostmi příjmu dat vyšší než 100 MB/s nebo používáte paralelní datový sklad (PDW), Teradata nebo jiné datové sklady mpP (Massively Parallel Processing), jako je Azure Synapse Analytics, může být nejlepší volbou Microsoft Fabric.

Rychlost příjmu dat nebo generování protokolů 150 MB/s je k dispozici jako funkce opt-in Preview. Další informace a vyjádření souhlasu s 150 MB/s najdete v blogu : Vylepšení hyperškálování z listopadu 2024.

V tuto chvíli to není možné. Můžete ale škálovat výpočetní prostředky a počet replik dolů, aby se snížily náklady během nepeakových časů, nebo použít bezserverové škálování výpočetních prostředků na základě využití.

Pro úlohy čtení můžete vytvořit pojmenovanou repliku s vyšší velikostí výpočetních prostředků (více jader a paměti) než primární. Další informace o dostupných velikostech výpočetních prostředků najdete v tématu Úložiště Hyperscale a velikosti výpočetních prostředků.

U úloh čtení je to možné dosáhnout pomocí pojmenovaných replik.

Počet sekundárních replik vysoké dostupnosti můžete škálovat mezi 0 a 4 pomocí webu Azure Portal nebo rozhraní REST API. Kromě toho můžete vytvořit až 30 pojmenovaných replik pro mnoho scénářů škálování na více instancí čtení.

V databázích Hyperscale se odolnost dat poskytuje na úrovni úložiště. K zajištění odolnosti potřebujete jenom jednu repliku (primární). Když dojde k výpadku výpočetní repliky, vytvoří se nová replika automaticky bez ztráty dat.

Pokud je ale jenom primární replika, může vytvoření nové repliky po převzetí služeb při selhání trvat minutu nebo dvě. V případě, že je k dispozici sekundární replika vysoké dostupnosti. Nová replika bude zpočátku obsahovat studené mezipaměti, což může vést k vyšší latenci úložiště a snížení výkonu dotazů ihned po převzetí služeb při selhání.

Pro důležité aplikace, které vyžadují vysokou dostupnost s minimálním dopadem na převzetí služeb při selhání, byste měli zřídit aspoň jednu sekundární repliku vysoké dostupnosti, abyste zajistili dostupnost aktivní pohotovostní repliky, která bude sloužit jako cíl převzetí služeb při selhání.

Maximální velikost jedné databáze Hyperscale je aktuálně 128 TB. Maximální velikost databáze v elastickém fondu Hyperscale je aktuálně 100 TB.

V Hyperscale je transakční protokol prakticky nekonečný s omezením, že aktivní část protokolu nesmí překročit 1 TB. Aktivní část protokolu se může zvětšovat kvůli dlouhotrvajícím transakcím nebo kvůli zpracování funkce Change Data Capture , která nezůsáhá tempo změny dat. Vyhněte se zbytečně dlouhým a velkým transakcím, abyste zůstali pod tímto limitem. Kromě tohoto omezení se nemusíte starat o nedostatek místa na protokolu v systému s vysokou propustností protokolu. Rychlost generování protokolů ale může být omezena pro průběžné agresivně zapisované úlohy. Rychlost generování protokolů ve špičce je 100 MB/s.

Rychlost generování protokolů 150 MB/s je dostupná jako funkce opt-in Preview. Další informace a vyjádření souhlasu s 150 MB/s najdete v blogu : Vylepšení hyperškálování z listopadu 2024.

Vaše tempdb databáze se nachází v místním úložišti SSD a je úměrná velikosti výpočetních prostředků (počtu jader), které zřídíte. Velikost tempdb není konfigurovatelná a spravuje se za vás. Pokud chcete určit maximální tempdb velikost databáze, přečtěte si téma Velikost úložiště a výpočetních prostředků Hyperscale.

Velikost databáze se automaticky zvětšuje při vkládání a ingestování dalších dat.

10 GB. Databáze Hyperscale se vytvoří s počáteční velikostí 10 GB a podle potřeby roste v 10GB blocích.

Každý datový soubor roste o 10 GB. Najednou se může zvětšit více datových souborů.

V Hyperscale se datové soubory ukládají ve službě Azure Standard Storage. Data jsou plně uložená v mezipaměti místního úložiště SSD na stránkových serverech, které jsou vzdálené pro výpočetní repliky. Kromě toho mají výpočetní repliky mezipaměť dat na místním disku SSD a v paměti, aby se snížila frekvence načítání dat ze vzdálených stránkových serverů.

Ne. Datové soubory se automaticky přidají do PRIMARY skupiny souborů. Běžné důvody pro vytváření dalších skupin souborů se nevztahují v architektuře úložiště Hyperscale ani v Azure SQL Database obecněji.

Ne.

Ano, operace zmenšení databáze a souborů jsou aktuálně ve verzi Preview. Další informace o verzi Preview najdete v tématu Zmenšení služby Azure SQL Database Hyperscale.

Ano, stejně jako v jakékoli jiné databázi Azure SQL DB. To zahrnuje kompresi row, page a columnstore.

Ano. Datové stránky přidružené k dané tabulce můžou skončit v několika datových souborech, které jsou všechny součástí stejné skupiny souborů. Databázový stroj MSSQL používá proporcionální strategii vyplnění k distribuci dat do datových souborů.

Ano. Existující databáze ve službě Azure SQL Database můžete přesunout do hyperškálování. Pro testování konceptu (POCS) doporučujeme vytvořit kopii databáze a migrovat ji do hyperškálování.

Doba potřebná k přesunutí existující databáze do Hyperscale se skládá z času kopírování dat a času pro přehrání změn provedených ve zdrojové databázi při kopírování dat. Doba kopírování dat je úměrná velikosti dat. Doba přehrání změn je kratší, pokud se přesun provádí během období nízké aktivity zápisu.

Získejte ukázkový kód pro migraci existujících databází Azure SQL do Hyperscale na webu Azure Portal, Azure CLI, PowerShellu a Transact-SQL při migraci existující databáze do Hyperscale.

Zpětná migrace na úroveň služby Pro obecné účely umožňuje zákazníkům, kteří nedávno migrovali existující databázi ve službě Azure SQL Database na úroveň služby Hyperscale, přesunout zpět, pokud Hyperscale nevyhovuje jejich potřebám. I když je změna úrovně služby inicializována zpětnou migrací, jedná se v podstatě o operaci velikosti dat mezi různými architekturami. Podobně jako při migraci na Hyperscale je v případě nízké aktivity zápisu rychlejší zpětná migrace. Přečtěte si o omezeních pro zpětnou migraci.

Pokud jste už dříve migrovali existující službu Azure SQL Database na úroveň služby Hyperscale, můžete ji do 45 dnů od původní migrace na Hyperscale vrátit zpět na úroveň služby Pro obecné účely. Pokud chcete migrovat databázi na jinou úroveň služby, jako je například Pro důležité obchodní informace, nejprve převést migraci na úroveň služby Pro obecné účely a pak upravit úroveň služby. Zpětná migrace je velikost operace dat.

Databáze vytvořené na úrovni služby Hyperscale nejde přesunout do jiných úrovní služby.

Zjistěte , jak provést zpětnou migraci z Hyperscale, včetně omezení pro zpětnou migraci a ovlivněných zásad zálohování.

Ano. Některé funkce Azure SQL Database se zatím v Hyperscale nepodporují. Pokud jsou některé z těchto funkcí pro vaši databázi povolené, může být migrace do Hyperscale zablokovaná nebo tyto funkce po migraci přestanou fungovat. Očekáváme, že tato omezení budou dočasná. Podrobnosti najdete v tématu Známá omezení.

Ano. K migraci na Hyperscale můžete použít mnoho existujících technologií migrace, včetně transakční replikace a dalších technologií přesunu dat (Bulk Copy, Azure Data Factory, Azure Databricks, SSIS). Podívejte se také na službu Azure Database Migration Service, která podporuje mnoho scénářů migrace.

Výpadek migrace na Hyperscale je stejný jako výpadek při migraci databází do jiných úrovní služby Azure SQL Database. Transakční replikaci můžete použít k minimalizaci migrace výpadků databází až do velikosti několika TB. U velmi velkých databází (10+ TB) můžete zvážit implementaci procesu migrace pomocí ADF, Sparku nebo jiných technologií hromadného přesunu dat.

Hyperscale dokáže využívat 100 MB/s nových nebo změněných dat, ale doba potřebná k přesunu dat do databází ve službě Azure SQL Database má vliv také na dostupnou propustnost sítě, rychlost čtení zdroje a cíl na úroveň cílové služby databáze. Rychlost generování protokolů 150 MB/s je dostupná jako funkce opt-in Preview. Další informace a vyjádření souhlasu s 150 MB/s najdete v blogu : Vylepšení hyperškálování z listopadu 2024.

Klientská aplikace může číst data ze služby Azure Storage a načítat data do databáze Hyperscale (stejně jako u jakékoli jiné databáze v Azure SQL Database). PolyBase se v současné době nepodporuje ve službě Azure SQL Database. Jako alternativu k rychlému načítání můžete použít Azure Data Factory nebo použít úlohu Sparku v Azure Databricks s konektorem Spark pro SQL. Konektor Sparku pro SQL podporuje hromadné vkládání.

Pomocí funkce BULK INSERT nebo OPENROWSET je také možné hromadně číst data z úložiště objektů blob v Azure: Příklady hromadného přístupu k datům ve službě Azure Blob Storage.

Hyperscale nepodporuje jednoduché obnovení nebo model hromadného protokolování. K zajištění vysoké dostupnosti a obnovení k určitému bodu v čase se vyžaduje úplný model obnovení. Architektura protokolů Hyperscale ale poskytuje lepší rychlost příjmu dat v porovnání s jinými úrovněmi služby Azure SQL Database.

Ne. Hyperscale je symetrická architektura SMP (Multi-Processing) a nejedná se o architekturu MPP (Massively Parallel Processing) ani multi-master architekturu. Pro horizontální navýšení kapacity úloh jen pro čtení můžete vytvořit více replik.

Ano. Azure Database Migration Service podporuje mnoho scénářů migrace.

Viz smlouva SLA pro Azure SQL Database. Pro důležité úlohy doporučujeme přidat sekundární repliky vysoké dostupnosti. To zajišťuje rychlejší převzetí služeb při selhání a snižuje potenciální dopad na výkon okamžitě po převzetí služeb při selhání.

Ano.

Ano, Hyperscale podporuje zónově redundantní konfiguraci. K povolení zónově redundantní konfigurace pro Hyperscale se vyžaduje alespoň jedna sekundární replika vysoké dostupnosti a použití zónově redundantního úložiště nebo geograficky zónově redundantního úložiště.

Ano. Další informace najdete v tématu Hyperscale elastické fondy a blog: Elastické fondy Hyperscale jsou nyní obecně dostupné.

V případě databází úrovně Hyperscale se neprovádí tradiční úplné ani rozdílové zálohování ani zálohování transakčních protokolů. Místo toho existují běžné snímky úložiště datových souborů s samostatnou četností snímků pro každý soubor. Vygenerovaný transakční protokol se uchovává v nezměněné podobě po nakonfigurovanou dobu uchovávání. V době obnovení se na obnovené snímky úložiště použijí relevantní záznamy transakčního protokolu. Bez ohledu na četnost snímků to vede k transakční konzistentní databázi bez ztráty dat v zadaném bodu v čase během doby uchovávání. Zálohování databáze v Hyperscale je tedy průběžné.

Ano.

RPO pro obnovení k určitému bodu v čase je 0 min. Většina operací obnovení k určitému bodu v čase se dokončí během 60 minut bez ohledu na velikost databáze. U větších databází může být doba obnovení delší a pokud u databáze došlo k významné aktivitě zápisu před a až do bodu obnovení v čase. Změna redundance úložiště při vydávání obnovení může způsobit delší dobu obnovení, protože obnovení je velikost dat, a proto bude doba úměrná velikosti databáze.

Ne. Zálohy spravuje subsystém úložiště a používají snímky úložiště. Nemají vliv na uživatelské úlohy.

Ano. Geografické obnovení se plně podporuje, pokud se používá geograficky redundantní úložiště. Toto je výchozí hodnota pro nové databáze. Na rozdíl od obnovení k určitému bodu v čase vyžaduje geografické obnovení operaci velikosti dat. Datové soubory se kopírují paralelně, takže doba trvání této operace závisí především na velikosti největšího souboru v databázi, nikoli na celkové velikosti databáze. Doba geografického obnovení bude výrazně kratší, pokud se databáze obnoví v oblasti Azure spárované s oblastí zdrojové databáze.

Ano. Geografickou replikaci je možné nastavit pro databáze Hyperscale.

Ne. Formát úložiště pro databáze Hyperscale se liší od jakékoli vydané verze SQL Serveru a neřídíte zálohování ani k nim nemáte přístup. Pokud chcete data vytáhnout z databáze Hyperscale, můžete extrahovat data pomocí libovolných technologií přesunu dat, tj. Azure Data Factory, Azure Databricks, SSIS atd.

Ano. Od 4. května 2022 se zálohy pro všechny nové databáze účtují na základě spotřebovaného a vybraného úložiště redundance úložiště s mírami zachycenými na stránce s cenami služby Azure SQL Database. U databází Hyperscale vytvořených před 4. květnem 2022 se zálohy budou účtovat pouze v případě, že je uchovávání záloh nastavené na více než sedm dnů. Další informace najdete v tématu Zálohování hyperškálování a redundance úložiště.

Podrobnosti o měření velikosti úložiště zálohování se zaznamenávají v automatizovaných zálohách.

Pokud chcete zjistit fakturu za úložiště zálohování, velikost úložiště zálohování se počítá pravidelně a vynásobí se rychlostí úložiště zálohování a počtem hodin od posledního výpočtu. Pokud chcete odhadnout fakturu za zálohování na časové období, vynásobte fakturovatelnou velikost úložiště záloh každou hodinu v období sazbou úložiště zálohování a sečtěte všechny hodinové částky. Pokud chcete dotazovat relevantní metriky služby Azure Monitor pro více hodinových intervalů prostřednictvím kódu programu, použijte rozhraní REST API služby Azure Monitor. Fakturace zálohování na úrovni výpočetních prostředků bez serveru je stejná jako ve zřízené výpočetní vrstvě.

Náklady na zálohování budou vyšší pro úlohy, které přidávají, upravují nebo odstraňují velké objemy dat v databázi. Naopak úlohy, které jsou většinou jen pro čtení, můžou mít menší náklady na zálohování.

Podrobnosti o tom, jak minimalizovat náklady na úložiště zálohování, se zaznamenávají v automatizovaných zálohách.

Maximální propustnost transakčního protokolu je nastavená na 100 MB/s pro libovolnou velikost výpočetních prostředků Hyperscale. Schopnost dosáhnout této rychlosti závisí na několika faktorech, včetně typů úloh, konfigurace klienta a výkonu a dostatečné výpočetní kapacity na primární výpočetní replice, aby se v této míře vytvořily záznamy protokolů. Rychlost generování protokolů 150 MB/s je dostupná jako funkce opt-in Preview. Další informace a vyjádření souhlasu s 150 MB/s najdete v blogu : Vylepšení hyperškálování z listopadu 2024.

Latence vstupně-výstupních operací za sekundu a vstupně-výstupních operací se bude lišit v závislosti na vzorech úloh. Pokud jsou data, ke které přistupujete, uložená v mezipaměti v RBPEXu na výpočetní replice, uvidíte podobný výkon vstupně-výstupních operací jako v Pro důležité obchodní informace nebo úrovních služby Premium.

Ne. Výpočetní prostředky se oddělí od vrstvy úložiště. Tím se eliminuje dopad zálohování na výkon.

Vzhledem k tomu, že se úložiště sdílí a mezi primárními a sekundárními výpočetními replikami neprobíhá přímá fyzická replikace, nebude propustnost primární repliky přímo ovlivněna přidáním sekundárních replik. Úlohy průběžného a agresivního zápisu se ale můžou omezovat na primárním serveru, aby se protokol mohl použít na sekundárních replikách a stránkových serverech. Tím se zabrání nízkému výkonu čtení na sekundárních replikách a dlouhému obnovení po převzetí služeb při selhání sekundární replikou s vysokou dostupností.

Ano. Stejně jako v jiných databázích Azure SQL DB se připojení můžou ukončit velmi zřídkakdy přechodnými chybami, které můžou přerušit dlouhotrvající dotazy a vrátit transakce zpět. Jednou z příčin přechodných chyb je, že systém rychle přesune databázi do jiného výpočetního uzlu, aby se zajistila nepřetržitá dostupnost výpočetních prostředků a prostředků úložiště nebo plánovaná údržba. Většina těchto událostí rekonfigurace se dokončí za méně než 10 sekund. Aplikace, které se připojují k databázi, by měly být sestaveny tak, aby očekávaly a tolerovat tyto občasné přechodné chyby implementací logiky opakování. Zvažte také konfiguraci časového období údržby, které odpovídá vašemu plánu úloh, aby nedocházelo k přechodným chybám kvůli plánované údržbě.

U většiny problémů s výkonem, zejména těch, které nejsou rootované v výkonu úložiště, platí běžné kroky diagnostiky SQL a řešení potíží. Informace o diagnostice úložiště specifické pro Hyperscale najdete v tématu Diagnostika řešení potíží s výkonem SQL Hyperscale.

Maximální velikost paměti, kterou může bezserverová databáze vertikálně navýšit, je 3 GB/vCore krát maximální počet virtuálních jader nakonfigurovaných ve srovnání s více než 5 GB/virtuálními jádry krát stejný počet virtuálních jader ve zřízených výpočetních prostředcích. Podrobnosti najdete v limitech prostředků hyperškálování bez serveru.

Vertikální navýšení nebo snížení kapacity ve zřízené výpočetní vrstvě obvykle trvá až 2 minuty bez ohledu na velikost dat. V bezserverové úrovni výpočetních prostředků, kde se výpočetní prostředky automaticky škálují na základě poptávky po úlohách, je čas škálování obvykle podsekundový, ale může někdy trvat i v případě škálování zřízeného výpočetního výkonu.

Ne. Databáze zůstává online během operací vertikálního navýšení nebo snížení kapacity.

Škálování zřízeného výpočetního výkonu nahoru nebo dolů vede k vyřazení připojení, když dojde k převzetí služeb při selhání na konci operace škálování. V bezserverových výpočetních prostředcích automatické škálování obvykle nevyvolá připojení, ale může k němu občas dojít. Přidání nebo odebrání sekundárních replik nemá za následek výpadky připojení na primárním serveru.

Škálování zřízeného výpočetního prostředí provádí koncový uživatel. Služba provádí automatické škálování výpočetních prostředků bez serveru.

Ano. Velikost tempdb mezipaměti databáze a RBPEX na výpočetních uzlech se automaticky vertikálně navyšují při zvýšení počtu jader. Podrobnosti najdete v tématu Hyperscale Storage a velikosti výpočetních prostředků.

Ne. Pouze primární výpočetní replika přijímá požadavky na čtení a zápis. Sekundární výpočetní repliky přijímají pouze požadavky jen pro čtení.

Hyperscale podporuje repliky s vysokou dostupností (HA), pojmenované repliky a geografické repliky. Podrobnosti najdete v tématu Sekundární repliky hyperškálování.

Mezi 0 a 4. Pokud chcete upravit počet replik, můžete to udělat pomocí webu Azure Portal nebo rozhraní REST API.

K těmto dalším výpočetním replikám jen pro čtení se můžete připojit nastavením ApplicationIntent vlastnosti v připojovací řetězec na ReadOnly. Všechna připojení označená ReadOnly pomocí se automaticky směrují na jednu ze sekundárních replik vysoké dostupnosti(pokud existují). Podrobnosti najdete v tématu Použití replik jen pro čtení k přesměrování zpracování úloh dotazů jen pro čtení.

Můžete spustit následující dotaz T-SQL: SELECT DATABASEPROPERTYEX ('<database_name>', 'Updateability'). Výsledkem je READ_ONLY , že jste připojení k sekundární replice jen pro čtení a READ_WRITE pokud jste připojení k primární replice. Kontext databáze musí být nastaven na název databáze, nikoli na master databázi.

Ne. Můžete se připojit pouze k sekundárním replikám vysoké dostupnosti zadáním ApplicationIntent=ReadOnly. Pro pojmenované repliky ale můžete použít vyhrazené koncové body.

Ne. Nové připojení se záměrem jen pro čtení se přesměruje na libovolnou sekundární repliku vysoké dostupnosti.

Není ve zřízené výpočetní vrstvě. Sekundární repliky vysoké dostupnosti se používají jako cíle převzetí služeb při selhání s vysokou dostupností, takže musí mít stejnou konfiguraci jako primární replika, aby po převzetí služeb při selhání poskytovaly očekávaný výkon. V bezserverové úrovni se výpočetní prostředky škálují automaticky pro každou repliku vysoké dostupnosti na základě individuální poptávky po úlohách. Každá sekundární vysoká dostupnost může stále automaticky škálovat na nakonfigurovaná maximální počet jader tak, aby vyhovovala své roli po převzetí služeb při selhání. Pojmenované repliky umožňují nezávisle škálovat každou repliku.

Ne. Vaše tempdb databáze se konfiguruje na základě zřízené velikosti výpočetních prostředků. Sekundární repliky vysoké dostupnosti mají stejnou velikost, včetně , jako tempdbprimární výpočetní prostředky. U pojmenovaných replik je velikost podle velikosti výpočetních prostředků replikytempdb, takže může být menší nebo větší než tempdb na primárním serveru.

Ne. Výpočetní repliky databáze Hyperscale sdílejí úložiště, což znamená, že všechny výpočetní repliky vidí stejné tabulky, indexy a další databázové objekty. Pokud chcete, aby byly další indexy optimalizované pro čtení v sekundární oblasti, musíte je přidat na primární server. Dočasné tabulky (názvy tabulek s předponou # nebo ##) můžete pořád vytvářet na každé sekundární replice, aby se ukládaly dočasná data. Dočasné tabulky jsou pro čtení i zápis.

Latence dat od okamžiku, kdy je transakce potvrzena na primární do doby, kdy je čitelná na sekundárním serveru, závisí na aktuální rychlosti generování protokolů, velikosti transakce, zatížení repliky a dalších faktorech. Typická latence dat u malých transakcí je v desítkách milisekund, ale latence dat není nijak velká. Data na dané sekundární replice jsou vždy konzistentně konzistentní, takže šíření větších transakcí trvá déle. V daném časovém okamžiku se ale latence dat a stav databáze můžou lišit pro různé sekundární repliky. Úlohy, které potřebují číst potvrzená data, by se měly okamžitě spouštět na primární replice.

Ne, pojmenované repliky nelze použít jako cíle převzetí služeb při selhání primární repliky. Přidejte pro tento účel repliky vysoké dostupnosti.

Vzhledem k tomu, že každá pojmenovaná replika může mít jiný cíl na úrovni služby, a proto se používá pro různé případy použití, neexistuje žádný integrovaný způsob, jak směrovat provoz jen pro čtení odesílaný do primární sady pojmenovaných replik. Můžete mít například osm pojmenovaných replik a můžete chtít směrovat úlohy OLTP jenom na pojmenované repliky 1 až 4, zatímco analytické úlohy Power BI používají pojmenované repliky 5 a 6 a úloha datových věd používá repliky 7 a 8. V závislosti na tom, který nástroj nebo programovací jazyk používáte, se strategie distribuce takových úloh můžou lišit. Příklad vytvoření řešení směrování úloh, které umožňuje horizontální navýšení kapacity back-endu REST, najdete v ukázce horizontálního navýšení kapacity OLTP.

Ne, protože pojmenované repliky používají stejné stránkové servery primární repliky, musí být ve stejné oblasti.

Pojmenovaná replika nemůže ovlivnit dostupnost primární repliky. Pojmenované repliky za normálních okolností pravděpodobně nemají vliv na výkon primárního serveru, ale může k tomu dojít v případě, že jsou spuštěné náročné úlohy. Stejně jako replika vysoké dostupnosti se pojmenovaná replika synchronizuje s primární službou transakčního protokolu. Pokud pojmenovaná replika z nějakého důvodu nedokáže protokoly transakcí dostatečně rychle spotřebovat, začne se ptát primární repliky, aby zpomalila (omezovala) generování protokolu, aby mohla zachytávat. I když toto chování nebude mít vliv na dostupnost primárního serveru, může to mít vliv na výkon úloh zápisu na primárním serveru. Abyste se této situaci vyhnuli, ujistěte se, že vaše pojmenované repliky mají dostatek hlavní místnosti prostředků – hlavně procesoru – pro zpracování transakčního protokolu bez zpoždění. Pokud například primární zpracovává řadu změn dat, doporučuje se mít pojmenované repliky s alespoň stejným cílem úrovně služby jako primární, aby se zabránilo nasycení procesoru na replikách, a proto je nutné, aby se primární repliky zpomalovaly.

Pojmenované repliky budou nadále k dispozici pro přístup jen pro čtení, jako obvykle.

Pojmenované repliky ve výchozím nastavení nemají vlastní repliky vysoké dostupnosti. Převzetí služeb při selhání pojmenované repliky vyžaduje nejprve vytvoření nové repliky, která obvykle trvá přibližně 1 až 2 minuty. Pojmenované repliky ale můžou také těžit z vyšší dostupnosti a kratších převzetí služeb při selhání poskytovaných replikami vysoké dostupnosti. Pokud chcete přidat repliky vysoké dostupnosti pro pojmenovanou repliku, můžete použít parametr s AZ CLI nebo parametr HighAvailabilityReplicaCount s PowerShellem nebo highAvailabilityReplicaCount vlastnost s rozhraním REST API.ha-replicas Počet replik vysoké dostupnosti se dá nastavit při vytváření pojmenované repliky a dá se změnit – jenom pomocí AZ CLI, PowerShellu nebo rozhraní REST API – kdykoli po vytvoření pojmenované repliky. Ceny replik vysoké dostupnosti pro pojmenované repliky jsou stejné jako repliky vysoké dostupnosti pro běžné databáze Hyperscale.

Ano. Hlavní klíč sloupce je uložen v uživatelské databázi a lze jej ověřit spuštěním dotazu SELECT * FROM sys.column_master_keys. Pojmenované repliky a sekundární repliky s vysokou dostupností čtou data ze stejné stránkové servery nebo vrstvy úložiště jako primární databáze Hyperscale. Oba typy replik se synchronizují s primární databází Hyperscale prostřednictvím služby protokolů. Změna klíče se považuje za transakci a automaticky se replikuje do pojmenované repliky a sekundární repliky s vysokou dostupností.

Funkce DATABASEPROPERTYEX() při spuštění v kontextu pojmenované repliky může mapovat na odpovídající pojmenovanou repliku replica_id . V současné době ale není možné propojit replica_id s příslušnou pojmenovanou replikou pro každý záznam v sys.dm_database_replica_states zobrazení dynamické správy při dotazování z primární repliky. Následující ukázkový dotaz lze spustit v kontextu pojmenované repliky a identifikovat název repliky, ID repliky a podrobnosti synchronizace.

  SELECT replica_id, DB_NAME() AS 'Database/Replica name', 
  synchronization_state_desc, log_send_queue_size/1024.0/1024.0 AS log_send_queue_size_gb,
  last_sent_time, last_received_time, last_commit_time, secondary_lag_seconds
  FROM sys.dm_database_replica_states
  WHERE replica_id = DATABASEPROPERTYEX(DB_NAME(),'REPLICAID');

Související obsah

Další informace o úrovni služby Hyperscale najdete v tématu Úroveň služby Hyperscale.