Redigera

Dela via


Azure SQL Database Vanliga frågor och svar om hyperskala

Gäller för:Azure SQL Database

Den här artikeln innehåller svar på vanliga frågor och svar för kunder som överväger en databas på Azure SQL Database Hyperscale-tjänstnivån, som bara kallas Hyperskala i resten av dessa vanliga frågor och svar. Den här artikeln beskriver de scenarier som Hyperskala stöder och de funktioner som är kompatibla med Hyperskala.

  • Dessa vanliga frågor och svar är avsedda för läsare som har en kort förståelse för tjänstnivån Hyperskala och som vill få sina specifika frågor och problem besvarade.
  • Vanliga frågor och svar är inte avsedda att vara en guidebok eller besvara frågor om hur du använder en Hyperskala-databas. En introduktion till Hyperskala finns i dokumentationen om Hyperskala i Azure SQL Database.

Allmänna frågor

Vad är en Hyperskala-databas?

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.

Vilka resurstyper och inköpsmodeller stöder Hyperskala?

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.

Hur skiljer sig tjänstnivån Hyperskala från tjänstnivåerna Generell användning och Affärskritisk?

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.

Vem ska använda tjänstnivån Hyperskala?

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.

Vilka regioner stöder för närvarande Hyperskala?

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

Kan jag skapa flera Hyperskala-databaser per server?

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.

Vilka är prestandaegenskaperna för en Hyperskala-databas?

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

Vad är skalbarheten för en Hyperskala-databas?

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:

Djupdykningsfrågor

Kan jag blanda Hyperskala och enkla databaser på en enda server?

Ja, det kan du.

Kräver Hyperskala att min programprogrammeringsmodell ändras?

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.

Vilken transaktionsisoleringsnivå är standard i en Hyperskala-databas?

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.

Kan jag ta med min lokala eller IaaS SQL Server-licens till Hyperskala?

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.

Vilken typ av arbetsbelastningar är Hyperskala utformad för?

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

Hur kan jag välja mellan Azure Synapse Analytics och Azure SQL Database Hyperscale?

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.

Frågor om hyperskalningsberäkning

Kan jag pausa min beräkning när som helst?

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.

Kan jag etablera en beräkningsreplik med extra RAM-minne för min minnesintensiva arbetsbelastning?

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.

Kan jag etablera flera beräkningsrepliker av olika storlekar?

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

Hur många utskalningsrepliker stöds?

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.

Behöver jag etablera ytterligare beräkningsrepliker för hög tillgänglighet?

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.

Frågor om datastorlek och lagring

Vilken är den maximala databasstorleken som stöds med Hyperskala?

100 TB.

Hur stor är transaktionsloggen med Hyperskala?

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.

Skalas min tempdb när databasen växer?

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.

Växer databasstorleken automatiskt, eller måste jag hantera storleken på datafiler?

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

Vilken är den minsta databasstorleken som Hyperskala stöder?

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

I vilka steg växer min databasstorlek?

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

Är lagringen i Hyperskala lokal eller fjärransluten?

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.

Kan jag hantera eller definiera filer eller filgrupper med Hyperskala?

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.

Kan jag etablera ett hårt tak för datatillväxten för min databas?

Nej.

Stöds databaskrympning?

Nej, inte just nu.

Stöds datakomprimering?

Ja, precis som i alla andra Azure SQL DB-databaser. Detta inkluderar komprimering av rad, sida och kolumnarkiv.

Om jag har en enorm tabell, är tabelldata utspridda över flera datafiler?

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.

Frågor om datamigrering

Kan jag flytta mina befintliga databaser i Azure SQL Database till tjänstnivån Hyperskala?

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.

Kan jag flytta mina Hyperskala-databaser till andra tjänstnivåer?

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.

Förlorar jag några funktioner efter migreringen till tjänstnivån Hyperskala?

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.

Kan jag flytta min lokala SQL Server-databas, eller min SQL Server-databas på en virtuell molndator, till Hyperskala?

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.

Vad är min stilleståndstid under migreringen från en lokal eller virtuell datormiljö till Hyperskala, och hur kan jag minimera den?

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.

Hur lång tid skulle det ta att ta in X mängd data till Hyperskala?

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å.

Kan jag läsa data från bloblagring och göra en snabb inläsning (till exempel Polybase i Azure Synapse Analytics)?

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.

Tillåter Hyperskala etablering av flera noder för parallell inmatning av stora mängder data?

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.

Stöder Hyperskala migrering från andra datakällor som Amazon Aurora, MySQL, PostgreSQL, Oracle, DB2 och andra databasplattformar?

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

Frågor om affärskontinuitet och haveriberedskap

Vilka serviceavtal tillhandahålls för en Hyperskala-databas?

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.

Hanteras databassäkerhetskopiorna åt mig av Azure SQL Database?

Ja.

Stöder Hyperskala Tillgänglighetszoner?

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.

Hur ofta görs databassäkerhetskopior?

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.

Stöder Hyperskala återställning till tidpunkt?

Ja.

Vad är mål för återställningspunkt (RPO)/Mål för återställningstid (RTO) för databasåterställning i Hyperskala?

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.

Påverkar databassäkerhetskopiering beräkningsprestanda på mina primära eller sekundära repliker?

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

Kan jag utföra geo-återställning med en Hyperskala-databas?

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.

Kan jag konfigurera geo-replikering med en Hyperskala-databas?

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

Kan jag göra en hyperskala-databassäkerhetskopia och återställa den till min lokala server eller på SQL Server på en virtuell dator?

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.

Kommer jag att debiteras för lagringskostnader för säkerhetskopiering i Hyperskala?

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.

Hur mäter jag lagringsstorleken för säkerhetskopiering i min Hyperskala-databas?

Information om hur du mäter lagringsstorleken för säkerhetskopiering samlas in i Automatiserade säkerhetskopieringar.

Hur gör jag för att vet du vad min faktura för säkerhetskopiering kommer att bli?

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.

Hur påverkar min arbetsbelastning mina lagringskostnader för säkerhetskopiering?

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.

Hur kan jag minimera kostnaderna för lagring av säkerhetskopior?

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

Prestandafrågor

Hur mycket skrivdataflöde kan jag skicka i en Hyperskala-databas?

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.

Hur många IOPS får jag på den största beräkningen?

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.

Påverkas mitt dataflöde av säkerhetskopior?

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

Påverkas mitt dataflöde när jag etablerar ytterligare beräkningsrepliker?

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.

Passar Hyperskala bra för resursintensiva, långvariga frågor och transaktioner?

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.

Hur gör jag för att diagnostisera och felsöka prestandaproblem i en Hyperskala-databas?

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.

Hur ser den maximala minnesgränsen i serverlös ut jämfört med etablerad beräkning?

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.

Frågor om skalbarhet

Hur lång tid tar det att skala upp och ned en beräkningsreplik?

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.

Är min databas offline medan upp- och nedskalningsåtgärden pågår?

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

Bör jag förvänta mig en anslutningsminskning när skalningsåtgärderna pågår?

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.

Är upp- och nedskalningen av beräkningsrepliker automatisk eller slutanvändarens utlösta åtgärd?

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

Växer även storleken på min tempdb-databas och RBPEX-cache när beräkningen skalas upp?

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.

Kan jag etablera flera primära beräkningsrepliker, till exempel ett system med flera huvudservrar, där flera primära beräkningshuvuden kan driva en högre samtidighetsnivå?

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

Läsa utskalningsfrågor

Vilka typer av sekundära repliker (utskalning av läsning) är tillgängliga i Hyperskala?

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

Hur många sekundära HA-repliker kan jag etablera?

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.

Hur gör jag för att ansluta till en sekundär HA-replik?

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.

Hur gör jag för att verifiera om jag har anslutit till en sekundär beräkningsreplik med hjälp av SQL Server Management Studio (SSMS) eller andra klientverktyg?

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.

Kan jag skapa en dedikerad slutpunkt för en sekundär HA-replik?

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.

Gör systemet intelligent belastningsutjämning av läsarbetsbelastningen på sekundära HA-repliker?

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

Kan jag skala upp/ned ha sekundära repliker oberoende av den primära repliken?

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.

Får jag en annan "tempdb"-storlek för min primära beräkning och mina sekundära HA-repliker?

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.

Kan jag lägga till index och vyer på mina sekundära beräkningsrepliker?

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.

Hur lång fördröjning kommer det att uppstå mellan de primära och sekundära beräkningsreplikerna?

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.

Kan en namngiven replik användas som ett redundansmål?

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.

Hur distribuerar jag en skrivskyddad arbetsbelastning över mina namngivna repliker?

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.

Kan en namngiven replik finnas i en annan region än den primära replikens region?

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

Kan en namngiven replik påverka tillgängligheten eller prestandan för den primära 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 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.

Vad händer med namngivna repliker om den primära repliken till exempel inte är tillgänglig på grund av planerat underhåll?

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

Hur kan jag förbättra tillgängligheten för namngivna repliker?

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.

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