Vanliga frågor och svar om Azure SQL Database Hyperscale

En Hyperskala-databas är en databas i Azure SQL Database som backas upp av Hyperskala skalbar lagringsteknik. En Hyperskala-databas stöder upp till 128 TB data och ger högt dataflöde och prestanda samt snabb skalning för att anpassa sig till arbetsbelastningskraven. Anslutningar, frågebearbetning, databasmotorfunktioner och så vidare fungerar som i alla andra databaser i Azure SQL Database.

Tjänstnivån Hyperskala är tillgänglig för enskilda databaser (både etablerade och serverlösa) och för elastiska pooler med hjälp av den vCore-baserade inköpsmodellen. Den är inte tillgänglig i den DTU-baserade inköpsmodellen.

De vCore-baserade tjänstnivåerna är differentierade baserat på databastillgänglighet och lagringstyp, prestanda och maximal lagringsstorlek enligt beskrivningen i resursgränsjämförelse.

Tjänstnivån Hyperskala är avsedd för alla kunder som vill ha högre prestanda och tillgänglighet, snabb säkerhetskopiering och återställning, snabb lagring och skalbarhet för beräkning. Detta inkluderar kunder som börjar små och växande, de som kör stora verksamhetskritiska databaser, de som flyttar till molnet för att modernisera sina program och kunder som redan använder andra tjänstnivåer i Azure SQL Database.

Med Hyperskala får du:

• Databasstorleken kan öka från 10 GB upp till 128 TB, oavsett beräkningsstorlek.
• Beräkna virtuella kärnor från 2 virtuella kärnor upp till 128 virtuella kärnor.
• Snabba säkerhetskopieringar av databaser oavsett databasstorlek (säkerhetskopior baseras på ögonblicksbilder av lagring).
• Snabb databasåterställning oavsett databasstorlek (återställningar kommer från ögonblicksbilder av lagring).
• Högre dataflöde för transaktionsloggar oavsett databasstorlek och antalet virtuella kärnor.
• Läs Skala ut med en eller flera skrivskyddade repliker, som används för att avlasta skrivskyddade arbetsbelastningar eller som frekventa väntelägesdatabaser.
• Snabb skalning av beräkning, i konstant tid, för att vara mer kraftfull för att hantera den tunga arbetsbelastningen och sedan skala ned, i konstant tid. Skalningsåtgärder tar ensiffriga minuter för etablerad beräkning och mindre än en sekund för serverlös beräkning, oavsett databasstorlek.
• Alternativet att betala för det du använder med serverlös beräkning, där beräkning faktureras baserat på användning.

Tjänstnivån Hyperskala är tillgänglig i alla regioner där Azure SQL Database är tillgängligt.

Ja. Mer information och begränsningar för antalet databaser per server finns i SQL Database-resursgränser för enskilda databaser och pooldatabaser på en server.

Hyperskala-arkitekturen ger höga prestanda och dataflöde samtidigt som den stöder stora databasstorlekar.

Hyperskala ger snabb skalbarhet baserat på din arbetsbelastningsefterfrågan.

• skala upp/ned

  Med Hyperskala kan du skala upp den primära beräkningsstorleken när det gäller resurser som CPU och minne och sedan skala ned i konstant tid. Eftersom lagringen är fjärransluten är det inte en storleksåtgärd att skala upp och skala ned.

  Stöd för serverlös beräkning ger automatisk uppskalning och nedskalning och beräkningsfakturering baserat på användning.

• att skala in/ut

  Med Hyperskala kan du använda tre typer av sekundära repliker för att uppfylla kraven på lässkalning, hög tillgänglighet och geo-replikering. Detta inkluderar:

  • Upp till fyra repliker med hög tillgänglighet har samma beräkningsstorlek som primär. Dessa fungerar som frekventa standby-repliker för att snabbt redundansväxla från den primära. Du kan också använda dem för att avlasta läsarbetsbelastningar från den primära.
  • Upp till 30 namngivna repliker har samma eller annan beräkningsstorlek än den primära, för att hantera olika scenarier med lässkalning.
  • En geo-replik i en annan Azure-region för att skydda mot regionala avbrott och för att aktivera geografisk utskalning av läsning.

Ja, det kan du.

Nej, programprogrammeringsmodellen förblir densamma som för andra MSSQL-databaser. Du använder anslutningssträngen som vanligt och de andra vanliga sätten att interagera med hyperskala-databasen. När programmet använder Hyperskala-databasen kan programmet dra nytta av funktioner som sekundära repliker.

På den primära repliken är standardnivån för transaktionsisolering READ COMMITTED med alternativet READ_COMMITTED_SNAPSHOT databas (RCSI) aktiverat. På de sekundära replikerna är isoleringsnivån SNAPSHOT. Detta är samma som i alla andra Azure SQL-databaser.

Med den nya, förenklade prissättningen i kraft sedan den 15 december 2023 har beräkningspriset sänkts för nyligen skapade Hyperskala-databaser, alla serverlösa Hyperskala-databaser och alla elastiska Hyperskala-pooler. Med den nya, förenklade prissättningen behöver du inte använda Azure Hybrid Benefit (AHB) för att få motsvarande besparingar. Azure Hybrid Benefit (AHB) kan endast tillämpas på äldre (skapade före den 15 december 2023) hyperskala med enkla databaser med etablerad beräkning. För dessa äldre databaser gäller AHB endast fram till december 2026, varefter dessa databaser också faktureras enligt den nya, förenklade prissättningen.

Mer information finns i hyperskalas prisblogg och Azure SQL Database Hyperscale – lägre, förenklad prissättning.

Hyperskala fungerar bra för alla arbetsbelastningstyper, inklusive arbetsbelastningar för OLTP, Hybrid (HTAP) och Analys (data mart).

Om du för närvarande kör interaktiva analysfrågor med SQL Server som ett informationslager är Hyperskala ett bra alternativ eftersom du kan vara värd för små och medelstora informationslager (till exempel några TB upp till 128 TB) till en lägre kostnad, och du kan migrera dina SQL Server-informationslagerarbetsbelastningar till Hyperskala med minimala T-SQL-kodändringar.

Om du kör dataanalys i stor skala med komplexa frågor och ihållande inmatningshastigheter som är högre än 100 MB/s eller använder Parallel Data Warehouse (PDW), Teradata eller andra MPP-informationslager (Massively Parallel Processing), till exempel Azure Synapse Analytics, kan Microsoft Fabric vara det bästa valet.

Inmatnings- eller logggenereringshastighet på 150 MiB/s är tillgänglig som en förhandsversionsfunktion för premiumserie- och premiumserieminne optimerat. Mer information och om du vill välja 150 MiB/s finns i Blogg: Förbättringar av Hyperskala i november 2024.

Inte just nu. Du kan dock skala ned din beräkning och antalet repliker för att minska kostnaderna under icke-svarstider, eller använda serverlösa för att automatiskt skala beräkning baserat på användning.

För läsarbetsbelastningar kan du skapa en med namnet replik med en högre beräkningsstorlek (fler kärnor och minne) än den primära. Mer information om tillgängliga beräkningsstorlekar finns i Hyperskala-lagrings- och beräkningsstorlekar.

För läsarbetsbelastningar kan detta uppnås med hjälp av namngivna repliker.

Du kan skala antalet sekundära HA-repliker mellan 0 och 4 med hjälp av Azure-portalen eller REST API-. Dessutom kan du skapa upp till 30 namngivna repliker för många lässkalningsscenarier. Varje namngiven replik kan ha upp till 4 sekundära HA-repliker.

I Hyperskala-databaser tillhandahålls dataåterhämtning på lagringsnivå. Du behöver bara en replik (den primära) för att ge återhämtning. Om beräkningsrepliken misslyckas eller under underhåll skapas en ny replik automatiskt utan dataförlust.

Men om det bara finns den primära repliken kan det ta en minut eller två att skapa en ny replik, jämfört med sekunder när en sekundär HA-replik är tillgänglig. Den nya repliken kommer att ha kalla cacheminnen från början, vilket kan leda till högre lagringssvarstid och lägre frågeprestanda omedelbart efter redundansväxling.

För verksamhetskritiska program som kräver hög tillgänglighet med minimal redundanspåverkan bör du etablera minst en sekundär ha-replik för att säkerställa att en replik med frekvent vänteläge är tillgänglig för att fungera som ett redundansmål.

Den maximala storleken för en enskild Hyperskala-databas är för närvarande 128 TB, oavsett beräkningsstorlek. Den maximala storleken på en databas i en elastisk Hyperskala-pool är för närvarande 100 TB.

I Hyperskala är transaktionsloggen praktiskt taget oändlig, med en begränsning som den aktiva delen av loggen inte får överskrida 1 TB. Den aktiva delen av loggen kan växa på grund av långvariga transaktioner, eller på grund av Ändringsdatainsamling bearbetningen inte håller jämna steg med dataändringshastigheten. Undvik onödigt långa och stora transaktioner för att hålla dig under den här gränsen. Förutom den här begränsningen behöver du inte oroa dig för att loggutrymmet ska ta slut på ett system med högt loggdataflöde. Logggenereringsfrekvensen kan dock minskas för kontinuerlig aggressivt skrivning av arbetsbelastningar. Den högsta ihållande logggenereringshastigheten är 100 MB/s.

Logggenereringshastigheten på 150 MiB/s är tillgänglig som en förhandsversionsfunktion för premiumserie- och premiumserieminne optimerat. Mer information och om du vill välja 150 MiB/s finns i Blogg: Förbättringar av Hyperskala i november 2024.

Din tempdb-databas finns på lokal SSD-lagring och har proportionell storlek på beräkningsstorleken (antalet kärnor) som du etablerar. Storleken på tempdb kan inte konfigureras och hanteras åt dig. Information om hur du fastställer maximal tempdb storlek för databasen finns i Hyperskala-lagrings- och beräkningsstorlekar.

Databasstorleken växer automatiskt när du infogar/matar in mer data.

10 GB. En Hyperskala-databas skapas med en startstorlek på 10 GB och växer efter behov.

Varje datafil växer med 10 GB. Flera datafiler kan växa samtidigt.

I Hyperskala lagras datafiler i Azures standardlagring. Data cachelagras helt på lokal SSD-lagring på sidservrar som är fjärranslutna till beräkningsrepliker. Dessutom har beräkningsrepliker datacacheminnen på lokal SSD och i minnet, för att minska frekvensen för att hämta data från fjärrsideservrar.

Nej. Datafiler läggs till automatiskt i PRIMARY filgrupp. De vanligaste orsakerna till att skapa ytterligare filgrupper gäller inte i Hyperskala-lagringsarkitekturen eller i Azure SQL Database mer allmänt.

Nej.

Ja, databas- och filkrympningsåtgärder för närvarande är i förhandsversion. Mer information om förhandsversionen finns i Shrink for Azure SQL Database Hyperscale.

Ja, precis som i alla andra Azure SQL DB-databaser. Detta omfattar komprimeringrad, sida och kolumnarkiv.

Ja. De datasidor som är associerade med en viss tabell kan hamna i flera datafiler, som alla ingår i samma filgrupp. MSSQL-databasmotorn använder proportionell fyllningsstrategi för att distribuera data över datafiler.

Ja. För konceptbevis rekommenderar vi att du gör en kopia av databasen och migrerar kopian till Hyperskala.

Den tid som krävs för att flytta en befintlig databas till Hyperskala består av tiden för att kopiera data och tiden för att spela upp de ändringar som gjorts i källdatabasen när data kopieras. Datakopieringstiden är proportionell mot datastorleken. Tiden för att spela upp ändringar är kortare om flytten görs under en period med låg skrivaktivitet.

Hämta exempelkod för att migrera befintliga Azure SQL-databaser till Hyperskala i Azure-portalen, Azure CLI, PowerShell och Transact-SQL i Migrera en befintlig databas till Hyperskala.

Omvänd migrering till tjänstnivån Generell användning gör att kunder som nyligen har migrerat en befintlig databas i Azure SQL Database till tjänstnivån Hyperskala kan flytta tillbaka om Hyperskala inte uppfyller deras behov. Omvänd migrering initieras av en ändring på tjänstnivå, men det är i princip en datastorleksåtgärd mellan olika arkitekturer. På samma sätt som migrering till Hyperskala går omvänd migrering snabbare om den görs under en period med låg skrivaktivitet. Lär dig begränsningarna för omvänd migrering.

Om du tidigare har migrerat en befintlig Azure SQL Database till tjänstnivån Hyperskala kan du ångra migreringen till tjänstnivån Generell användning inom 45 dagar efter den ursprungliga migreringen till Hyperskala. Om du vill migrera databasen till en annan tjänstnivå, till exempel Affärskritisk, först omvänd migrering till tjänstnivån Generell användning, ändrar du sedan tjänstnivån. Omvänd migrering är en datastorleksåtgärd.

Databaser som skapats på tjänstnivån Hyperskala kan inte flyttas till andra tjänstnivåer.

Lär dig hur du omvänt migrerar från Hyperskala, inklusive begränsningar för omvänd migrering och påverkade säkerhetskopieringsprinciper.

Ja. Vissa Azure SQL Database-funktioner stöds inte i Hyperskala. Om vissa av dessa funktioner är aktiverade för databasen kan migreringen till Hyperskala blockeras eller så slutar dessa funktioner att fungera efter migreringen. Mer information finns i Kända begränsningar.

Ja. Du kan använda många befintliga migreringstekniker för att migrera till Hyperskala, inklusive transaktionsreplikering och andra dataförflyttningstekniker (Masskopiering, Azure Data Factory, Azure Databricks, SSIS). Se även Azure Database Migration Service, som stöder många migreringsscenarier.

Stilleståndstiden för migrering till Hyperskala är samma som stilleståndstiden när du migrerar dina databaser till andra Azure SQL Database-tjänstnivåer. Du kan använda transaktionsreplikering för att minimera stilleståndstiden för databaser upp till några TB i storlek. För mycket stora databaser (10+ TB) kan du överväga att implementera migreringsprocessen med hjälp av ADF, Spark eller andra massdataförflyttningstekniker.

Hyperskala kan förbruka 100 MB/s nya/ändrade data, men den tid som krävs för att flytta data till databaser i Azure SQL Database påverkas också av tillgängligt nätverksdataflöde, källläsningshastighet, typ av belastning (bulk jämfört med rad för rad) och målet för måldatabasens tjänstnivå. Logggenereringshastigheten på 150 MiB/s är tillgänglig som en förhandsversionsfunktion för premiumserie- och premiumserieminne optimerat. Mer information och om du vill välja 150 MiB/s finns i Blogg: Förbättringar av Hyperskala i november 2024.

Du kan låta ett klientprogram läsa data från Azure Storage och läsa in datainläsning till en Hyperskala-databas (precis som med andra databaser i Azure SQL Database). Polybase stöds för närvarande inte i Azure SQL Database. Du kan också använda Azure Data Factoryeller använda ett Spark-jobb i Azure Databricks med Spark-anslutningsappen för SQL. Spark-anslutningsappen till SQL stöder massinfogning.

Det går också att massläsa data från Azure Blob Store med HJÄLP av BULK INSERT eller OPENROWSET: Exempel på massåtkomst till data i Azure Blob Storage.

Enkla eller massloggade återställningsmodeller stöds inte i Hyperskala. Fullständig återställningsmodell krävs för att tillhandahålla hög tillgänglighet och återställning till tidpunkt. Hyperskala-loggarkitektur ger dock bättre datainmatningshastighet jämfört med andra Azure SQL Database-tjänstnivåer.

Nej. Hyperskala är en symmetrisk SMP-arkitektur (multi-processing) och är inte en massivt parallell bearbetning (MPP) eller en arkitektur med flera original. Du kan skapa flera repliker för att skala ut skrivskyddade arbetsbelastningar.

Ja. Azure Database Migration Service stöder många migreringsscenarier.

Se serviceavtal för Azure SQL Database. Vi rekommenderar att du lägger till sekundära HA-repliker för kritiska arbetsbelastningar. Detta ger snabbare redundans och minskar den potentiella prestandapåverkan direkt efter redundansväxlingen.

Ja.

Ja, Hyperskala stöder zonredundant konfiguration. Minst en sekundär ha-replik och användning av zonredundant eller geo-zonredundant lagring krävs för att aktivera zonredundant konfiguration för Hyperskala.

Ja. Mer information finns i elastiska hyperskalapooler och Blogg: Elastiska hyperskalapooler är nu allmänt tillgängliga.

Det finns inga traditionella fullständiga säkerhetskopieringar, differentiella och transaktionsloggar för Hyperskala-databaser. I stället finns det regelbundna ögonblicksbilder av datafiler med en separat ögonblicksbildstakt för varje fil. Den genererade transaktionsloggen behålls as-is för den konfigurerade kvarhållningsperioden. Vid återställningstillfället tillämpas relevanta transaktionsloggposter på återställd lagringsögonblicksbild. Oavsett ögonblicksbildstakt resulterar detta i en transaktionsmässigt konsekvent databas från och med den angivna tidpunkten inom kvarhållningsperioden, utan dataförlust. Databassäkerhetskopiering i Hyperskala är i själva verket kontinuerlig.

Ja.

RPO för återställning till tidpunkt är 0 min. De flesta återställningsåtgärder för tidpunkt slutförs inom 60 minuter oavsett databasstorlek. Återställningstiden kan vara längre för större databaser och om databasen har haft betydande skrivaktivitet före och fram till återställningspunkten. Om du utfärdar en återställning efter en nyligen ändrad lagringsredundans kan resultera i längre återställningstider eftersom återställningen kan vara en datastorleksåtgärd i det fallet och återställningstiden kan vara proportionell mot databasens storlek.

Nej. Säkerhetskopior hanteras av lagringsundersystemet och använder ögonblicksbilder av lagring. De påverkar inte användararbetsbelastningar.

Ja. Geo-återställning stöds fullt ut om geo-redundant eller geo-zonredundant lagring används. Geo-redundant lagring är standard för nya databaser. Till skillnad från återställning till tidpunkt kräver geo-återställning en datastorleksåtgärd. Datafiler kopieras parallellt, så varaktigheten för den här åtgärden beror främst på storleken på den största filen i databasen i stället för på den totala databasstorleken. Geo-återställningstiden blir betydligt kortare om databasen återställs i Azure-regionen som är parat med källdatabasens region.

Ja. Geo-replikering och redundansgrupper kan konfigureras för Hyperskala-databaser.

Nej. Lagringsformatet för Hyperskala-databaser skiljer sig från alla versioner av SQL Server och du styr inte säkerhetskopior eller har åtkomst till dem. Om du vill ta bort dina data från en Hyperskala-databas kan du extrahera data med hjälp av dataförflyttningstekniker som Azure Data Factory, Azure Databricks, SSIS osv.

Ja. Från och med den 4 maj 2022 debiteras säkerhetskopieringar för alla nya databaser baserat på den förbrukade lagringen för säkerhetskopiering och vald lagringsredundans till priser som samlas in i azure SQL Database-prissidan. För Hyperskala-databaser som skapats före den 4 maj 2022 debiteras säkerhetskopieringar endast om kvarhållning av säkerhetskopior är inställt på mer än sju dagar. Mer information finns i Hyperskala-säkerhetskopior och lagringsredundans.

Mer information om hur du mäter lagringsstorleken för säkerhetskopiering finns i Automatiserade säkerhetskopieringar.

För att fastställa fakturan för lagring av säkerhetskopior beräknas lagringsstorleken för säkerhetskopiering regelbundet och multipliceras med lagringshastigheten för säkerhetskopiering och antalet timmar sedan den senaste beräkningen. Om du vill beräkna din säkerhetskopieringsfaktura för en tidsperiod multiplicerar du lagringsstorleken för fakturerbar säkerhetskopiering för varje timme av perioden med lagringshastigheten för säkerhetskopiering och lägger till alla timbelopp. Om du vill köra frågor mot relevanta Azure Monitor-mått för flera timintervall programmatiskt använder du Azure Monitor REST API-. Säkerhetskopieringsfakturering på serverlös beräkningsnivå är samma som på den etablerade beräkningsnivån.

Kostnaderna för säkerhetskopiering blir högre för arbetsbelastningar som lägger till, ändrar eller tar bort stora mängder data i databasen. Arbetsbelastningar som oftast är skrivskyddade kan däremot ha mindre säkerhetskopieringskostnader.

Mer information om hur du minimerar kostnaderna för lagring av säkerhetskopior finns i Automatiserade säkerhetskopieringar.

För närvarande går det inte att geo-återställa tjänstnivåer (Basic/Standard/Premium/Generell användning/Affärskritisk) till en hyperskala-tjänstnivå och vice versa. Om du vill konvertera en icke-Hyperskala-databas till en Hyperskala-databas ändrar du tjänstnivån efter en återställning.

Dataflödesgränsen för transaktionsloggar är 100 MB/s för alla beräkningsstorlekar i hyperskala. Möjligheten att uppnå den här frekvensen beror på flera faktorer, inklusive men inte begränsat till arbetsbelastningstyp, klientkonfiguration och prestanda, och att ha tillräckligt med beräkningskapacitet på den primära beräkningsrepliken för att skapa loggposter med den här takten. Logggenereringshastigheten på 150 MiB/s är tillgänglig som en förhandsversionsfunktion för premiumserie- och premiumserieminne optimerat. Mer information och om du vill välja 150 MiB/s finns i Blogg: Förbättringar av Hyperskala i november 2024.

IOPS- och I/O-svarstiden varierar beroende på arbetsbelastningsmönstren. Om de data som används cachelagras i lokal SSD-lagring på beräkningsrepliken ser du liknande I/O-prestanda som på tjänstnivåer för affärskritisk eller Premium.

Nej. Beräkningen är frikopplad från lagringslagret. Detta eliminerar prestandapåverkan av säkerhetskopiering.

Eftersom lagringen delas och det inte sker någon direkt fysisk replikering mellan primära och sekundära beräkningsrepliker påverkas inte dataflödet på den primära repliken direkt genom att lägga till sekundära repliker. Loggfrekvensen för kontinuerliga och aggressiva skrivarbetsbelastningar kan dock begränsas på den primära så att loggen kan tillämpas på sekundära repliker och sidservrar för att komma ikapp. Detta undviker dåliga läsprestanda på sekundära repliker och lång återställning efter redundansväxling till en sekundär HA-replik.

Ja. Men precis som i andra Azure SQL-databaser kan anslutningar avslutas av mycket ovanliga tillfälliga fel, vilket kan avbryta långvariga frågor och återställa transaktioner. En orsak till tillfälliga fel är när systemet snabbt flyttar databasen till en annan beräkningsnod för att säkerställa fortsatt tillgänglighet för beräknings- och lagringsresurser eller för att utföra planerat underhåll. De flesta av dessa omkonfigurationshändelser avslutas på mindre än 10 sekunder. Program som ansluter till databasen bör skapas för att förvänta sig och tolerera dessa ovanliga tillfälliga fel genom att implementera logik för återförsök. Överväg också att konfigurera en underhållsperiod som matchar ditt arbetsbelastningsschema för att undvika tillfälliga fel på grund av planerat underhåll.

För de flesta prestandaproblem, särskilt de som inte är rotade i lagringsprestanda, gäller vanliga MSSQL-diagnostik- och felsökningssteg. Information om Hyperskala-specifik lagringsdiagnostik finns i felsökning av prestanda för SQL Hyperskala.

Den maximala mängden minne som en serverlös databas kan skala upp är 3 GB/vCore gånger det maximala antalet virtuella kärnor som konfigurerats jämfört med mer än 5 GB/vCore gånger samma antal virtuella kärnor i etablerad beräkning. Mer information finns i serverlösa resursbegränsningar för hyperskala.

Det tar vanligtvis upp till 2 minuter att skala upp eller ned på den etablerade beräkningsnivån, oavsett datastorlek. På den serverlösa beräkningsnivån, där beräkning skalas automatiskt baserat på efterfrågan på arbetsbelastningar, är skalningstiden vanligtvis undersekunder, men kan ibland ta så lång tid som vid skalning av etablerad beräkning.

Nej. En databas förblir online under uppskalnings- eller nedskalningsåtgärder.

Upp- eller nedskalning av etablerad beräkning resulterar i att anslutningar tas bort när en redundansväxling sker i slutet av skalningsåtgärden. Vid serverlös beräkning resulterar automatisk skalning vanligtvis inte i att en anslutning släpps, men det kan inträffa ibland. Att lägga till eller ta bort sekundära repliker resulterar inte i att anslutningen avbryts på den primära repliken.

Skalning i etablerad beräkning utförs av slutanvändaren. Automatisk skalning i serverlös beräkning utförs av tjänsten.

Ja. Den tempdb databasen och beräknings-SSD-cachen storlek på beräkningsnoder skalas upp automatiskt när antalet kärnor ökar. Mer information finns i Hyperskala-lagrings- och beräkningsstorlekar.

Nej. Endast den primära beräkningsrepliken accepterar läs-/skrivbegäranden. Sekundära beräkningsrepliker accepterar endast skrivskyddade begäranden.

Hyperskala stöder hög tillgänglighetsrepliker (HA), namngivna repliker och geo-repliker. Mer information finns i sekundära hyperskalarepliker.

Mellan 0 och 4. Om du vill justera antalet repliker kan du göra det med hjälp av Azure-portalen eller REST API-.

Du kan ansluta till dessa ytterligare skrivskyddade beräkningsrepliker genom att ange egenskapen ApplicationIntent i anslutningssträngen till ReadOnly. Eventuella anslutningar som har markerats med ReadOnly dirigeras automatiskt till en av de sekundära ha-replikerna, om de finns. Mer information finns i Använda skrivskyddade repliker för att avlasta skrivskyddade frågearbetsbelastningar.

Du kan köra följande T-SQL-fråga: SELECT DATABASEPROPERTYEX ('<database_name>', 'Updateability'). Resultatet är READ_ONLY om du är ansluten till en skrivskyddad sekundär replik och READ_WRITE om du är ansluten till den primära repliken. Databaskontexten måste vara inställd på namnet på databasen, inte till den master databasen.

Nej. Du kan bara ansluta till sekundära HA-repliker genom att ange ApplicationIntent=ReadOnly. Du kan dock använda dedikerade slutpunkter för namngivna repliker.

Nej. En ny anslutning med skrivskyddad avsikt omdirigeras till en godtycklig sekundär HA-replik.

Inte på den etablerade beräkningsnivån. Sekundära HA-repliker används som redundansmål med hög tillgänglighet, så de måste ha samma konfiguration som den primära för att ge förväntad prestanda efter redundansväxling. I serverlös skalas beräkningen automatiskt för varje HA-replik baserat på dess individuella arbetsbelastningsbehov. Varje ha-sekundär kan fortfarande autoskala till de konfigurerade maxskärnorna så att de passar dess roll efter redundansväxlingen. Namngivna repliker ge möjlighet att skala varje namngiven replik oberoende av varandra.

Nej. Din tempdb-databas är konfigurerad baserat på den etablerade beräkningsstorleken. dina sekundära HA-repliker har samma storlek, inklusive tempdb, som den primära beräkningen. På namngivna replikerstorleksanpassas tempdb enligt replikens beräkningsstorlek, vilket innebär att den kan vara mindre eller större än tempdb på den primära.

Nej. Hyperskala-databasberäkningsrepliker delar lagring, vilket innebär att alla beräkningsrepliker ser samma tabeller, index och andra databasobjekt. Om du vill att ytterligare index ska optimeras för läsningar på sekundärt måste du lägga till dem i den primära. Du kan fortfarande skapa temporära tabeller (tabellnamn med prefixet # eller ##) på varje sekundär replik för att lagra temporära data i tempdb-databasen. Temporära tabeller är skrivskyddade.

Datafördröjningen från den tidpunkt då en transaktion checkas in på den primära till den tidpunkt då den kan läsas på en sekundär beror på den aktuella logggenereringshastigheten, transaktionsstorleken, belastningen på repliken och andra faktorer. Typisk datafördröjning för små transaktioner är i tiotals millisekunder, men det finns ingen övre gräns för datafördröjning. Data på en viss sekundär replik är alltid transaktionsmässigt konsekventa, vilket innebär att större transaktioner tar längre tid att sprida. Vid en viss tidpunkt kan datasvarstid och databastillstånd vara olika för olika sekundära repliker. Arbetsbelastningar som behöver läsa incheckade data omedelbart ska köras på den primära repliken.

Nej, namngivna repliker kan inte användas som redundansmål för den primära repliken. Lägg till HA-repliker för den ursprungliga repliken för det ändamålet.

Eftersom varje namngiven replik kan ha ett annat servicenivåmål och därför användas för olika användningsfall finns det inget inbyggt sätt att dirigera skrivskyddad trafik som skickas till den primära till en uppsättning namngivna repliker. Du kan till exempel ha åtta namngivna repliker och du kanske bara vill dirigera OLTP-arbetsbelastningen till namngivna repliker 1 till 4, medan Power BI-analysarbetsbelastningar använder namngivna repliker 5 och 6, och data science-arbetsbelastningen använder replikerna 7 och 8. Beroende på vilket verktyg eller programmeringsspråk du använder kan strategier för att distribuera en sådan arbetsbelastning variera. Ett exempel på hur du skapar en lösning för arbetsbelastningsroutning så att en REST-serverdel kan skalas ut finns i OLTP-utskalningsexempel.

Nej, eftersom namngivna repliker använder samma sidservrar för den primära repliken måste de finnas i samma region. Men om du har skapat en geo-replik för den primära repliken i en annan region kan du skapa namngivna repliker för geo-repliken.

En namngiven replik kan inte påverka tillgängligheten för den primära repliken. Namngivna repliker kommer under normala omständigheter sannolikt inte att påverka den primäras prestanda, men det kan inträffa om det finns intensiva arbetsbelastningar som körs. Precis som en HA-replik hålls en namngiven replik synkroniserad med den primära via transaktionsloggtjänsten. Om en namngiven replik av någon anledning inte kan använda transaktionsloggen tillräckligt snabbt börjar den be den primära repliken att minska logggenereringshastigheten så att den kan komma ikapp. Även om det här beteendet inte påverkar den primära tillgängligheten kan det påverka prestanda för skrivarbetsbelastningar på den primära. För att undvika den här situationen kontrollerar du att dina namngivna repliker har tillräckligt med resursutrymme – främst CPU – för att bearbeta transaktionsloggen utan fördröjning. Om den primära till exempel bearbetar många dataändringar rekommenderar vi att du har namngivna repliker med minst samma beräkningsstorlek som den primära för att undvika att mätta PROCESSORn på replikerna och tvinga den primära att sakta ner.

Namngivna repliker är fortfarande tillgängliga för skrivskyddad åtkomst, som vanligt.

Som standard har namngivna repliker inga egna HA-repliker. En redundansväxling av en namngiven replik kräver att du skapar en ny replik först, vilket vanligtvis tar cirka 1–2 minuter. Namngivna repliker kan dock också dra nytta av högre tillgänglighet och kortare redundans som tillhandahålls av HA-repliker. Du kan lägga till HA-repliker för en namngiven replik i Azure-portalen, eller använda parametern ha-replicas med AZ CLIeller parametern HighAvailabilityReplicaCount med PowerShelleller egenskapen highAvailabilityReplicaCount med REST API. Antalet HA-repliker kan anges när en namngiven replik skapas och kan ändras när som helst efter att den namngivna repliken har skapats. Prissättningen för HA-repliker för namngivna repliker är samma för HA-repliker för primära repliker.

Ja. Huvudnyckeln kolumn lagras i användardatabasen och kan verifieras genom att köra frågan SELECT * FROM sys.column_master_keys. Namngivna repliker och sekundära repliker med hög tillgänglighet läser data från samma sidservrar/lagringslager som den primära Hyperskala-databasen. Båda typerna av repliker synkroniseras med den primära Hyperskala-databasen via loggtjänsten. En nyckeländring betraktas som en transaktion och replikeras automatiskt till alla sekundära repliker.

Inte när du frågar sys.dm_database_replica_states på den primära repliken. Du kan dock ansluta till en namngiven replik för att fastställa dess replik-ID och annan information med hjälp av följande exempelfråga:

  SELECT replica_id,
         DB_NAME() AS named_replica_database_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,
         redo_queue_size / 1024.0 / 1024.0 AS redo_queue_size_gb,
         redo_rate,
         secondary_lag_seconds
  FROM sys.dm_database_replica_states
  WHERE is_local = 1
        AND
        replica_id = DATABASEPROPERTYEX(DB_NAME(), 'ReplicaID');

Relaterat innehåll

Mer information om tjänstnivån Hyperskala finns i Hyperskala-tjänstnivå.