Azure SQL Database Vanliga frågor och svar om hyperskala

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

Tjänstnivån Hyperskala är endast tillgänglig för enskilda databaser med hjälp av den vCore-baserade inköpsmodellen i Azure SQL Database. Den är inte tillgänglig i den DTU-baserade inköpsmodellen.

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

Tjänstnivån Hyperskala är avsedd för alla kunder som behöver högre prestanda och tillgänglighet, snabb säkerhetskopiering och återställning och/eller snabb skalbarhet för lagring och beräkning. Detta inkluderar kunder 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:

• Databasens storlek är upp till 100 TB.
• 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 loggdataflöde oavsett databasstorlek och antalet virtuella kärnor.
• Läs Skala ut med en eller flera skrivskyddade repliker, som används för läs-avlastning eller som frekventa väntelägesdatabaser.
• Snabb uppskalning av beräkning, i konstant tid, för att kunna hantera den tunga arbetsbelastningen följt av nedskalning 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.

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 enkla 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 skalning och nedskalning inte en storlek på dataåtgärden.

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

• 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 omfattar:

  • 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 som 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 din anslutningssträng som vanligt och de andra vanliga sätten att interagera med hyperskala-databasen. När du använder Hyperskala kan programmet dra nytta av funktioner som sekundära repliker.

På den primära repliken är standardnivån för transaktionsisolering RCSI (Read Committed Snapshot Isolation). På skrivskyddade sekundära repliker är standardisoleringsnivån Ögonblicksbild. Detta är samma som i alla andra Azure SQL-databaser.

Ja, Azure Hybrid-förmån är endast tillgängligt för Hyperskala på den etablerade beräkningsnivån. Varje SQL Server Standard-kärna kan mappas till en virtuell Hyperskala-kärna. Varje SQL Server Enterprise-kärna kan mappas till fyra virtuella Hyperskala-kärnor. Du behöver ingen SQL-licens för sekundära repliker. Priset Azure Hybrid-förmån tillämpas automatiskt på skrivskyddade (sekundära) repliker. Se Serverlös beräkning för ett alternativt faktureringsalternativ baserat på användning. Obs! Förenklad prissättning för SQL Database Hyperscale kommer snart. Mer information finns i prissättningsbloggen för Hyperskala.

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 100 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 PDW (Parallel Data Warehouse), Teradata eller andra MPP-informationslager (Massively Parallel Processing) kan Azure Synapse Analytics vara det bästa valet.

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

För läsarbetsbelastningar kan du skapa en namngiven 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-lagring 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:et. Dessutom kan du skapa upp till 30 namngivna repliker för många lässkalningsscenarier.

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. När beräkningsrepliken är nere 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 efter redundansväxlingen, 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 appar 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.

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 att bearbetningen av ändringsdatainsamling 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. Logggenereringshastigheten kan dock begränsas för kontinuerlig aggressiv skrivning av arbetsbelastningar. Den högsta ihållande logggenereringshastigheten är 100 MB/s.

Databasen tempdb finns på lokal SSD-lagring och har proportionell storlek på beräkningsstorleken (antalet kärnor) som du etablerar. Storleken på tempdb är inte konfigurerbar och hanteras åt dig. Information om hur du fastställer maximal tempdb storlek för databasen finns i Hyperskala-lagring 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 i 10 GB segment.

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 filgruppen. De vanligaste orsakerna till att skapa ytterligare filgrupper gäller inte i Hyperskala-lagringsarkitekturen eller i Azure SQL Database mer allmänt.

Nej.

Nej, inte just nu.

Ja, precis som i alla andra Azure SQL DB-databaser. Detta inkluderar komprimering av rad, 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. Du kan flytta dina befintliga databaser i Azure SQL Database till Hyperskala. 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 blir 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 utförs under en period med låg skrivaktivitet. Mer information om 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, kan du först ångra migreringen till tjänstnivån Generell användning och sedan ändra tjänstnivån. Omvänd migrering är en storlek på dataåtgärden.

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änsningarna för omvänd migrering och påverkade säkerhetskopieringsprinciper.

Ja. Vissa Azure SQL Database-funktioner stöds inte i Hyperskala ännu. Om vissa av dessa funktioner är aktiverade för databasen kan migreringen till Hyperskala blockeras, eller så slutar dessa funktioner att fungera efter migreringen. Vi förväntar oss att dessa begränsningar är tillfälliga. 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 och målmålet på databastjänstnivå.

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. Som ett alternativ för att ge snabb belastning kan du använda Azure Data Factory eller 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 BULK INSERT eller OPENROWSET: Exempel på massåtkomst till data i Azure Blob Storage.

Enkel återställnings- eller massloggningsmodell 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 bara 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.

Det finns ingen traditionell, fullständig säkerhetskopiering, differentiell säkerhetskopiering eller säkerhetskopiering för 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 som den är 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 utan dataförlust från och med den angivna tidpunkten inom kvarhållningsperioden. 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 ändrar lagringsredundansen när du utfärdar en återställning kan det leda till längre återställningstider eftersom återställningen är storleken på data och därför är tiden 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 lagring används. Det här är standardvärdet 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 Den Azure-region som är kopplad till källdatabasens region.

Ja. Geo-replikering 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 alla dataförflyttningstekniker, dvs. 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 på prissidan för Azure SQL Database. 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.

Information om hur du mäter lagringsstorleken för säkerhetskopiering samlas in 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. Faktureringen för säkerhetskopiering på den serverlösa beräkningsnivån är densamma 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.

Information om hur du minimerar kostnaderna för lagring av säkerhetskopior samlas in i automatiserade säkerhetskopieringar.

Transaktionsloggens dataflödesgräns är inställd på 100 MB/s för alla beräkningsstorlekar för 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.

IOPS- och I/O-svarstiden varierar beroende på arbetsbelastningsmönstren. Om data som används cachelagras i RBPEX på beräkningsrepliken ser du liknande I/O-prestanda som i Affärskritisk- eller Premium-tjänstnivåer.

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. 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 DB-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 ett 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 SQL-diagnostik- och felsökningssteg. Mer information om hyperskalaspecifik lagringsdiagnostik finns i Felsökning av prestandafelsökning i 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 Resursbegränsningar för serverlös 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. Databasen tempdb och RBPEX-cachestorleken 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:et.

Du kan ansluta till dessa ytterligare skrivskyddade beräkningsrepliker genom att ange ApplicationIntent egenskapen i din anslutningssträng 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 anges till namnet på databasen, inte till master databasen.

Nej. Du kan bara ansluta till sekundära HA-repliker genom att ApplicationIntent=ReadOnlyange . 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 ger möjlighet att skala varje replik oberoende av varandra.

Nej. Databasen tempdb ä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 repliker tempdbär storleken enligt replikens beräkningsstorlek, så den kan vara mindre eller större än tempdb den primära.

Nej. Hyperskala-databaser har delad 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. 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 dock 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 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-utskalningsexemplet.

Nej, eftersom namngivna repliker använder samma sidservrar för den primära repliken måste de finnas i samma region.

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 sakta ned logggenereringen (begränsa) logggenereringen 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. Undvik den här situationen genom att se till 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 servicenivåmål som det primära, för att undvika att processorn mättas på replikerna och därför tvingar den primära att sakta ner.

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

Namngivna repliker har som standard 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. Om du vill lägga till HA-repliker för en namngiven replik kan du använda parametern med AZ CLI, parametern HighAvailabilityReplicaCount med PowerShell eller highAvailabilityReplicaCount egenskapen med REST API.ha-replicas Antalet HA-repliker kan anges när en namngiven replik skapas och kan ändras – endast via AZ CLI, PowerShell eller REST API – 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 vanliga Hyperskala-databaser.

Relaterat innehåll

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