Veelgestelde vragen over Azure SQL Database Hyperscale

Een Hyperscale-database is een database in SQL Database die wordt ondersteund door de uitschaaltechnologie van Hyperscale. Een Hyperscale-database ondersteunt maximaal 100 TB aan gegevens en biedt hoge doorvoer en prestaties, evenals snelle schaalaanpassing om aan te passen aan de workloadvereisten. Verbinding maken iviteit, queryverwerking, functies van database-engine, enzovoort, werken als elke andere database in Azure SQL Database.

De Hyperscale-servicelaag is alleen beschikbaar voor individuele databases met behulp van het aankoopmodel op basis van vCore in Azure SQL Database. Het is niet beschikbaar in het aankoopmodel op basis van DTU.

De servicelagen op basis van vCore zijn gedifferentieerd op basis van databasebeschikbaarheid en opslagtype, prestaties en maximale opslaggrootte, zoals beschreven in de vergelijking van resourcelimieten.

De Hyperscale-servicelaag is bedoeld voor alle klanten die hogere prestaties en beschikbaarheid nodig hebben, snelle back-up en herstel, en/of snelle opslag- en rekenschaalbaarheid. Dit omvat klanten die overstappen naar de cloud om hun toepassingen te moderniseren en klanten die al andere servicelagen gebruiken in Azure SQL Database. Met Hyperscale krijgt u het volgende:

• Databasegrootte tot 100 TB.
• Snelle databaseback-ups, ongeacht de grootte van de database (back-ups zijn gebaseerd op momentopnamen van opslag).
• Snelle databaseherstelbewerkingen, ongeacht de grootte van de database (herstelbewerkingen zijn afkomstig van momentopnamen van opslag).
• Hogere logboekdoorvoer, ongeacht de databasegrootte en het aantal vCores.
• Uitschalen lezen met behulp van een of meer alleen-lezen replica's, gebruikt voor lezen-offloading of als hot stand-bydatabases.
• Snel omhoog schalen van rekenkracht, in constante tijd, om krachtiger te zijn voor de zware werkbelasting en vervolgens in constante tijd omlaag te schalen. Het schalen van bewerkingen duurt enkele cijfers voor ingerichte rekenkracht en minder dan een seconde voor serverloze berekeningen, ongeacht de grootte van de database.

De Hyperscale-servicelaag is beschikbaar in alle regio's waar Azure SQL Database beschikbaar is.

Ja. Zie sql Database-resourcelimieten voor individuele en pooldatabases op een server voor meer informatie en limieten voor het aantal databases per server.

De Hyperscale-architectuur biedt hoge prestaties en doorvoer en ondersteunt grote databasegrootten.

Hyperscale biedt snelle schaalbaarheid op basis van uw workloadvraag.

• Omhoog/omlaag schalen

  Met Hyperscale kunt u de primaire rekenkracht omhoog schalen in termen van resources zoals CPU en geheugen, en vervolgens in constante tijd omlaag schalen. Omdat de opslag extern is, is omhoog schalen en omlaag schalen geen grootte van gegevensbewerkingen.

  Ondersteuning voor serverloze berekeningen biedt automatisch omhoog en omlaag schalen en rekenkracht wordt gefactureerd op basis van gebruik.

• In-/uitschalen

  Met Hyperscale kunt u drie soorten secundaire replica's gebruiken om te voldoen aan de vereisten voor uitschalen, hoge beschikbaarheid en geo-replicatie. Dit zijn onder andere de nieuwe mogelijkheden:

  • Maximaal vier replica's met hoge beschikbaarheid met dezelfde rekenkracht als primaire replica's . Deze fungeren als dynamische stand-byreplica's om snel een failover van de primaire replica uit te voeren. U kunt ze ook gebruiken om leesworkloads uit de primaire database te offloaden.
  • Maximaal 30 benoemde replica's met dezelfde of een andere rekenkracht dan de primaire replica, om te voldoen aan verschillende uitschaalscenario's voor lezen.
  • Een geo-replica in een andere Azure-regio om te beschermen tegen regionale storingen en om geografisch uitschalen van leesbewerkingen mogelijk te maken.

Ja, dat kan.

Nee, uw toepassingsprogrammeermodel blijft hetzelfde als voor elke andere MSSQL-database. U gebruikt uw verbindingsreeks zoals gebruikelijk en de andere reguliere manieren om te communiceren met uw Hyperscale-database. Zodra u Hyperscale gebruikt, kan uw toepassing profiteren van functies zoals secundaire replica's.

Op de primaire replica is het standaardisolatieniveau voor transacties RCSI (Lees vastgelegde momentopname-isolatie). Op de secundaire replica's voor uitschalen voor lezen is het standaardisolatieniveau Momentopname. Dit is hetzelfde als in elke andere Azure SQL-database.

Ja, Azure Hybrid Benefit is alleen beschikbaar voor Hyperscale in de ingerichte rekenlaag. Elke SQL Server Standard-kern kan worden toegewezen aan één Hyperscale vCores. Elke SQL Server Enterprise-kern kan worden toegewezen aan vier Hyperscale vCores. U hebt geen SQL-licentie nodig voor secundaire replica's. De prijs van Azure Hybrid Benefit wordt automatisch toegepast op uitschalingsreplica's voor lezen (secundaire). Zie serverloze berekeningen voor een alternatieve factureringsoptie op basis van gebruik. Opmerking: Vereenvoudigde prijzen voor SQL Database Hyperscale binnenkort beschikbaar. Raadpleeg de blog over prijzen van Hyperscale voor meer informatie.

Hyperscale werkt goed voor alle workloadtypen, waaronder OLTP, Hybride (HTAP) en Analytische workloads (datamart).

Als u momenteel interactieve analysequery's uitvoert met BEHULP van SQL Server als een datawarehouse, is Hyperscale een uitstekende optie omdat u kleine en middelgrote datawarehouses (zoals een paar TB tot 100 TB) tegen lagere kosten kunt hosten en u uw SQL Server-datawarehouse-workloads kunt migreren naar Hyperscale met minimale wijzigingen in T-SQL-code.

Als u gegevensanalyse uitvoert op grote schaal met complexe query's en aanhoudende opnamesnelheden die hoger zijn dan 100 MB/s of parallel datawarehouse (PDW), Teradata of andere MPP-datawarehouses (Massively Parallel Processing), kan Azure Synapse Analytics de beste keuze zijn.

Op dit moment niet. U kunt uw rekenkracht en het aantal replica's echter omlaag schalen om kosten te verlagen tijdens niet-peaktijden, of serverloos gebruiken om automatisch rekenkracht te schalen op basis van gebruik.

Voor leesworkloads kunt u een benoemde replica maken met een hogere rekenkracht (meer kernen en geheugen) dan de primaire. Zie Hyperscale-opslag- en rekengrootten voor meer informatie over beschikbare rekengrootten.

Voor leesworkloads kan dit worden bereikt met behulp van benoemde replica's.

U kunt het aantal secundaire replica's met hoge beschikbaarheid schalen tussen 0 en 4 met behulp van Azure Portal of REST API. Daarnaast kunt u maximaal 30 benoemde replica's maken voor veel uitschaalscenario's voor leesbewerkingen.

In Hyperscale-databases wordt gegevenstolerantie geboden op opslagniveau. U hebt slechts één replica (de primaire) nodig om tolerantie te bieden. Wanneer de rekenreplica niet beschikbaar is, wordt er automatisch een nieuwe replica gemaakt zonder gegevensverlies.

Als er echter alleen de primaire replica is, kan het een paar minuten duren om een nieuwe replica te maken na een failover, in vergelijking met seconden in het geval dat er een secundaire replica met hoge beschikbaarheid beschikbaar is. De nieuwe replica heeft in eerste instantie koude caches, wat kan leiden tot een hogere opslaglatentie en lagere queryprestaties direct na een failover.

Voor bedrijfskritieke apps waarvoor hoge beschikbaarheid met minimale failover-impact is vereist, moet u ten minste één secundaire replica met hoge beschikbaarheid inrichten om ervoor te zorgen dat een hot stand-byreplica beschikbaar is om te fungeren als failoverdoel.

100 TB.

In Hyperscale is het transactielogboek vrijwel oneindig, met een beperking dat het actieve gedeelte van het logboek niet groter mag zijn dan 1 TB. Het actieve gedeelte van het logboek kan toenemen vanwege langlopende transacties of vanwege de verwerking van Change Data Capture die niet aan de snelheid van gegevenswijziging voldoet. Vermijd onnodig lange en grote transacties om onder deze limiet te blijven. Anders dan deze beperking hoeft u zich geen zorgen te maken over onvoldoende logboekruimte op een systeem met een hoge logboekdoorvoer. Het aantal logboekgeneraties kan echter worden beperkt voor doorlopende schrijfworkloads. De piek voor het genereren van logboeken is 100 MB/s.

Uw tempdb database bevindt zich op lokale SSD-opslag en is proportioneel aangepast aan de rekenkracht (het aantal kernen) dat u inricht. De grootte is tempdb niet configureerbaar en wordt voor u beheerd. Zie Hyperscale-opslag- en rekengrootten om de maximale tempdb grootte voor uw database te bepalen.

De grootte van uw database groeit automatisch naarmate u meer gegevens invoegt/opneemt.

10 GB. Een Hyperscale-database wordt gemaakt met een begingrootte van 10 GB en groeit naar behoefte in segmenten van 10 GB.

Elk gegevensbestand groeit met 10 GB. Meerdere gegevensbestanden kunnen tegelijkertijd groeien.

In Hyperscale worden gegevensbestanden opgeslagen in Azure Standard Storage. Gegevens worden volledig in de cache opgeslagen in lokale SSD-opslag, op paginaservers die extern zijn om replica's te berekenen. Bovendien hebben rekenreplica's gegevenscaches op lokale SSD en in het geheugen, om de frequentie van het ophalen van gegevens van externe paginaservers te verminderen.

Nee Gegevensbestanden worden automatisch toegevoegd aan de PRIMARY bestandsgroep. De veelvoorkomende redenen voor het maken van extra bestandsgroepen zijn niet van toepassing in de Hyperscale-opslagarchitectuur of in Azure SQL Database.

Nee

Op dit moment niet.

Ja, net als in elke andere Azure SQL DB-database. Dit omvat rij-, pagina- en columnstore-compressie.

Ja. De gegevenspagina's die aan een bepaalde tabel zijn gekoppeld, kunnen uiteindelijk in meerdere gegevensbestanden terechtkomen, die allemaal deel uitmaken van dezelfde bestandsgroep. De MSSQL-database-engine maakt gebruik van een proportionele opvulstrategie om gegevens over gegevensbestanden te distribueren.

Ja. U kunt uw bestaande databases in Azure SQL Database verplaatsen naar Hyperscale. Voor proof-of-concept (POC's) raden we u aan een kopie van uw database te maken en de kopie naar Hyperscale te migreren.

De tijd die nodig is om een bestaande database naar Hyperscale te verplaatsen, bestaat uit de tijd die nodig is om gegevens te kopiëren en de tijd om de wijzigingen die in de brondatabase zijn aangebracht, opnieuw af te spelen tijdens het kopiëren van gegevens. De tijd voor het kopiëren van gegevens is evenredig aan de grootte van de gegevens. De tijd voor het opnieuw afspelen van wijzigingen is korter als de verplaatsing wordt uitgevoerd tijdens een periode met een lage schrijfactiviteit.

Haal voorbeeldcode op om bestaande Azure SQL-databases te migreren naar Hyperscale in Azure Portal, Azure CLI, PowerShell en Transact-SQL in Migrate an existing database to Hyperscale.

Met omgekeerde migratie naar de servicelaag Algemeen gebruik kunnen klanten die onlangs een bestaande database in Azure SQL Database hebben gemigreerd naar de Hyperscale-servicelaag teruggaan, mocht Hyperscale niet aan hun behoeften voldoen. Hoewel omgekeerde migratie wordt geïnitieerd door een wijziging in de servicelaag, is het in wezen een grootte van gegevensbewerking tussen verschillende architecturen. Net als bij de migratie naar Hyperscale is omgekeerde migratie sneller als deze wordt uitgevoerd tijdens een periode met een lage schrijfactiviteit. Meer informatie over de beperkingen voor omgekeerde migratie.

Als u eerder een bestaande Azure SQL Database naar de Hyperscale-servicelaag hebt gemigreerd, kunt u deze binnen 45 dagen na de oorspronkelijke migratie naar Hyperscale omkeren naar de servicelaag Algemeen gebruik. Als u de database wilt migreren naar een andere servicelaag, zoals Bedrijfskritiek, moet u eerst omkeren naar de servicelaag Algemeen gebruik en vervolgens de servicelaag wijzigen. Omgekeerde migratie is een grootte van gegevensbewerkingen.

Databases die in de Hyperscale-servicelaag zijn gemaakt, kunnen niet worden verplaatst naar andere servicelagen.

Leer hoe u de migratie van Hyperscale kunt omkeren, inclusief de beperkingen voor omgekeerde migratie en beïnvloede back-upbeleidsregels.

Ja. Sommige Azure SQL Database-functies worden nog niet ondersteund in Hyperscale. Als sommige van deze functies zijn ingeschakeld voor uw database, kan migratie naar Hyperscale worden geblokkeerd of werken deze functies niet meer na de migratie. We verwachten dat deze beperkingen tijdelijk zijn. Zie Bekende beperkingen voor meer informatie.

Ja. U kunt veel bestaande migratietechnologieën gebruiken om te migreren naar Hyperscale, inclusief transactionele replicatie en andere technologieën voor gegevensverplaatsing (bulksgewijs kopiëren, Azure Data Factory, Azure Databricks, SSIS). Zie ook de Azure Database Migration Service, die ondersteuning biedt voor veel migratiescenario's.

Downtime voor migratie naar Hyperscale is hetzelfde als de downtime wanneer u uw databases migreert naar andere Azure SQL Database-servicelagen. U kunt transactionele replicatie gebruiken om downtimemigratie voor databases tot een paar TB te minimaliseren. Voor zeer grote databases (10+ TB) kunt u overwegen het migratieproces te implementeren met behulp van ADF-, Spark- of andere technologieën voor bulkgegevensverplaatsing.

Hyperscale kan 100 MB/s nieuwe/gewijzigde gegevens verbruiken, maar de tijd die nodig is om gegevens naar databases in Azure SQL Database te verplaatsen, wordt ook beïnvloed door de beschikbare netwerkdoorvoer, de bronleessnelheid en de doeldoelstelling van de databaseserviceniveau.

U kunt een clienttoepassing gegevens laten lezen uit Azure Storage en gegevens laden in een Hyperscale-database (net als bij elke andere database in Azure SQL Database). Polybase wordt momenteel niet ondersteund in Azure SQL Database. Als alternatief voor snelle belasting kunt u Azure Data Factory gebruiken of een Spark-taak in Azure Databricks gebruiken met de Spark-connector voor SQL. De Spark-connector voor SQL ondersteunt bulksgewijs invoegen.

Het is ook mogelijk om gegevens bulksgewijs te lezen uit het Azure Blob-archief met BULK INSERT of OPENROWSET: voorbeelden van bulktoegang tot gegevens in Azure Blob Storage.

Eenvoudig herstel- of bulklogboekregistratiemodel wordt niet ondersteund in Hyperscale. Het model voor volledig herstel is vereist om hoge beschikbaarheid en herstel naar een bepaald tijdstip te bieden. Hyperscale-logboekarchitectuur biedt echter een betere gegevensopnamesnelheid in vergelijking met andere Azure SQL Database-servicelagen.

Nee Hyperscale is een SMP-architectuur (symmetrische multiverwerking) en is geen MPP (Massively Parallel Processing) of een architectuur met meerdere masters. U kunt alleen meerdere replica's maken om alleen-lezenworkloads uit te schalen.

Ja. Azure Database Migration Service ondersteunt veel migratiescenario's.

Zie SLA voor Azure SQL Database. We raden u aan secundaire HA-replica's toe te voegen voor kritieke workloads. Dit biedt een snellere failover en vermindert de mogelijke invloed op de prestaties direct na de failover.

Ja.

Ja, Hyperscale ondersteunt zone-redundante configuratie. Ten minste één secundaire replica met hoge beschikbaarheid en het gebruik van zone-redundante of geografisch zone-redundante opslag is vereist voor het inschakelen van de zone-redundante configuratie voor Hyperscale.

Er zijn geen traditionele back-ups van volledige, differentiële en transactielogboeken voor Hyperscale-databases. In plaats daarvan zijn er reguliere opslagmomentopnamen van gegevensbestanden, met een afzonderlijke momentopnamefrequentie voor elk bestand. Het gegenereerde transactielogboek wordt bewaard zoals deze is voor de geconfigureerde retentieperiode. Tijdens het herstellen worden relevante transactielogboekrecords toegepast op herstelde opslagmomentopnamen. Ongeacht de frequentie van momentopnamen, resulteert dit in een transactioneel consistente database zonder gegevensverlies vanaf het opgegeven tijdstip binnen de retentieperiode. Databaseback-up in Hyperscale is in feite doorlopend.

Ja.

De RPO voor herstel naar een bepaald tijdstip is 0 min. De meeste herstelbewerkingen naar een bepaald tijdstip zijn binnen 60 minuten voltooid, ongeacht de grootte van de database. Hersteltijd kan langer zijn voor grotere databases en als de database een aanzienlijke schrijfactiviteit heeft gehad voordat en tot aan het herstelpunt in de tijd. Als u de opslagredundantie wijzigt bij het uitvoeren van een herstelbewerking, kan dit leiden tot langere hersteltijden omdat het herstellen de grootte van gegevens is en de tijd dus evenredig is met de grootte van de database.

Nee Back-ups worden beheerd door het opslagsubsysteem en maken gebruik van momentopnamen van opslag. Ze hebben geen invloed op gebruikersworkloads.

Ja. Geo-herstel wordt volledig ondersteund als geografisch redundante opslag wordt gebruikt. Dit is de standaardinstelling voor nieuwe databases. In tegenstelling tot herstel naar een bepaald tijdstip is geo-herstel een grootte van de gegevensbewerking vereist. Gegevensbestanden worden parallel gekopieerd, dus de duur van deze bewerking is voornamelijk afhankelijk van de grootte van het grootste bestand in de database, in plaats van de totale databasegrootte. De tijd voor geo-herstel is aanzienlijk korter als de database wordt hersteld in de Azure-regio die is gekoppeld aan de regio van de brondatabase.

Ja. Geo-replicatie kan worden ingesteld voor Hyperscale-databases.

Nee De opslagindeling voor Hyperscale-databases verschilt van elke uitgebrachte versie van SQL Server en u beheert geen back-ups of hebt er toegang toe. Als u uw gegevens uit een Hyperscale-database wilt halen, kunt u gegevens extraheren met behulp van technologieën voor gegevensverplaatsing, zoals Azure Data Factory, Azure Databricks, SSIS, enzovoort.

Ja. Vanaf 4 mei 2022 worden back-ups voor alle nieuwe databases in rekening gebracht op basis van de verbruikte back-upopslag en geselecteerde opslagredundantie tegen tarieven die zijn vastgelegd op de prijspagina van Azure SQL Database. Voor Hyperscale-databases die vóór 4 mei 2022 zijn gemaakt, worden alleen back-ups in rekening gebracht als back-upretentie is ingesteld op meer dan zeven dagen. Zie Hyperscale-back-ups en opslagredundantie voor meer informatie.

Details over het meten van de grootte van back-upopslag worden vastgelegd in geautomatiseerde back-ups.

Om de factuur voor back-upopslag te bepalen, wordt de grootte van de back-upopslag periodiek berekend en vermenigvuldigd met de opslagsnelheid van de back-up en het aantal uren sinds de laatste berekening. Als u een schatting wilt maken van uw back-upfactuur voor een bepaalde periode, vermenigvuldigt u de factureerbare back-upopslaggrootte voor elk uur met de back-upopslagsnelheid en voegt u alle uurbedragen samen. Als u via een programma een query wilt uitvoeren op relevante metrische gegevens van Azure Monitor voor meerdere intervallen per uur, gebruikt u de AZURE Monitor REST API. Back-upfacturering in de serverloze rekenlaag is hetzelfde als in de ingerichte rekenlaag.

Back-upkosten zijn hoger voor workloads die grote hoeveelheden gegevens in de database toevoegen, wijzigen of verwijderen. Omgekeerd kunnen workloads die voornamelijk alleen-lezen zijn, lagere back-upkosten hebben.

Meer informatie over het minimaliseren van de kosten voor back-upopslag worden vastgelegd in geautomatiseerde back-ups.

De doorvoerlimiet voor transactielogboeken is ingesteld op 100 MB/s voor elke Rekenkracht van Hyperscale. De mogelijkheid om dit tarief te bereiken, is afhankelijk van meerdere factoren, waaronder maar niet beperkt tot workloadtype, clientconfiguratie en prestaties, en voldoende rekencapaciteit hebben op de primaire rekenreplica om logboekrecords met deze snelheid te produceren.

De IOPS- en IO-latentie variëren, afhankelijk van de workloadpatronen. Als de gegevens die worden geopend, in de cache worden opgeslagen in RBPEX op de rekenreplica, ziet u vergelijkbare IO-prestaties als in Bedrijfskritiek- of Premium-servicelagen.

Nee Compute is losgekoppeld van de opslaglaag. Dit elimineert de invloed van de prestaties van back-ups.

Omdat de opslag wordt gedeeld en er geen directe fysieke replicatie plaatsvindt tussen primaire en secundaire rekenreplica's, wordt de doorvoer op de primaire replica niet rechtstreeks beïnvloed door secundaire replica's toe te voegen. Continue en agressieve schrijfworkloads kunnen echter worden beperkt op de primaire werkbelasting, zodat logboeken kunnen worden toegepast op secundaire replica's en paginaservers om in te halen. Dit voorkomt slechte leesprestaties voor secundaire replica's en lang herstel na een failover naar een secundaire replica met hoge beschikbaarheid.

Ja. Net als in andere Azure SQL DB-databases kunnen verbindingen echter worden beëindigd door zeer onregelmatige tijdelijke fouten, waardoor langlopende query's kunnen worden afgebroken en transacties kunnen worden teruggedraaid. Een van de oorzaken van tijdelijke fouten is wanneer het systeem de database snel naar een ander rekenknooppunt verplaatst om de beschikbaarheid van reken- en opslagresources te waarborgen of om gepland onderhoud uit te voeren. De meeste van deze herconfiguratie-gebeurtenissen worden in minder dan 10 seconden voltooid. Toepassingen die verbinding maken met uw database, moeten worden gebouwd om deze onregelmatige tijdelijke fouten te verwachten en te verdragen door logica voor opnieuw proberen te implementeren. U kunt ook een onderhoudsvenster configureren dat overeenkomt met uw workloadplanning om tijdelijke fouten te voorkomen vanwege gepland onderhoud.

Voor de meeste prestatieproblemen, met name de problemen die niet zijn geroot in de opslagprestaties, zijn veelvoorkomende stappen voor diagnostische SQL-gegevens en probleemoplossing van toepassing. Zie de diagnostische gegevens van SQL Hyperscale-prestaties voor het oplossen van problemen met de prestaties van Hyperscale voor specifieke opslagdiagnose.

De maximale hoeveelheid geheugen die een serverloze database omhoog kan schalen, is 3 GB/vCore keer het maximum aantal vCores dat is geconfigureerd in vergelijking met meer dan 5 GB/vCores keer hetzelfde aantal vCores in ingerichte rekenkracht. Controleer de limieten voor serverloze Hyperscale-resources voor meer informatie.

Omhoog of omlaag schalen in de ingerichte rekenlaag duurt doorgaans maximaal 2 minuten, ongeacht de gegevensgrootte. In de serverloze rekenlaag, waarbij de rekenkracht automatisch wordt geschaald op basis van de vraag naar werkbelasting, is de schaaltijd doorgaans subseconden, maar kan het af en toe duren zolang het schalen van de ingerichte rekenkracht.

Nee Een database blijft online tijdens het omhoog of omlaag schalen van bewerkingen.

Het omhoog of omlaag schalen van ingerichte rekenkracht resulteert in verbindingen die worden verwijderd wanneer er een failover plaatsvindt aan het einde van de schaalbewerking. Bij serverloze berekeningen leidt automatisch schalen meestal niet tot het verwijderen van een verbinding, maar dit kan af en toe gebeuren. Als u secundaire replica's toevoegt of verwijdert, leidt dit niet tot een daling van de verbinding op de primaire replica.

Schalen in ingerichte rekenkracht wordt uitgevoerd door de eindgebruiker. Automatisch schalen in serverloze berekeningen wordt uitgevoerd door de service.

Ja. De tempdb database- en RBPEX-cachegrootte op rekenknooppunten worden automatisch omhoog geschaald naarmate het aantal kernen wordt verhoogd. Zie Hyperscale-opslag- en rekengrootten voor meer informatie.

Nee Alleen de primaire rekenreplica accepteert lees-/schrijfaanvragen. Secundaire rekenreplica's accepteren alleen-lezenaanvragen.

Hyperscale ondersteunt hoge beschikbaarheidsreplica's, benoemde replica's en geo-replica's. Zie secundaire Hyperscale-replica's voor meer informatie.

Tussen 0 en 4. Als u het aantal replica's wilt aanpassen, kunt u dit doen met behulp van Azure Portal of REST API.

U kunt verbinding maken met deze extra alleen-lezen rekenreplica's door de eigenschap in uw ApplicationIntent verbindingsreeks in te stellen op ReadOnly. Verbindingen die zijn gemarkeerd met ReadOnly , worden automatisch doorgestuurd naar een van de secundaire replica's met hoge beschikbaarheid, indien aanwezig. Zie Alleen-lezen replica's gebruiken om alleen-lezen queryworkloads te offloaden voor meer informatie.

U kunt de volgende T-SQL-query uitvoeren: SELECT DATABASEPROPERTYEX ('<database_name>', 'Updateability'). Het resultaat is READ_ONLY als u bent verbonden met een secundaire replica met het kenmerk Alleen-lezen en READ_WRITE als u bent verbonden met de primaire replica. De databasecontext moet worden ingesteld op de naam van uw database, niet op de master database.

Nee U kunt alleen verbinding maken met secundaire replica's met hoge beschikbaarheid door op te ApplicationIntent=ReadOnlygeven. U kunt echter toegewezen eindpunten gebruiken voor benoemde replica's.

Nee Een nieuwe verbinding met de intentie Alleen-lezen wordt omgeleid naar een willekeurige secundaire replica met hoge beschikbaarheid.

Niet in de ingerichte rekenlaag. Secundaire hoge beschikbaarheidsreplica's worden gebruikt als failoverdoelen voor hoge beschikbaarheid, dus ze moeten dezelfde configuratie hebben als de primaire replica om verwachte prestaties te bieden na een failover. In serverloze modus wordt de berekening automatisch geschaald voor elke HA-replica op basis van de afzonderlijke workloadvraag. Elke secundaire ha kan nog steeds automatisch schalen naar de geconfigureerde maximumkernen om plaats te bieden aan de rol na de failover. Benoemde replica's bieden de mogelijkheid om elke replica onafhankelijk te schalen.

Nee Uw database is geconfigureerd op basis van de ingerichte rekenkracht. Uw tempdb secundaire replica's met hoge beschikbaarheid hebben dezelfde grootte, waaronder tempdb, als de primaire rekenkracht. Bij benoemde replica's is de tempdb grootte afhankelijk van de rekenkracht van de replica, zodat deze kleiner of groter kan zijn dan tempdb op de primaire replica.

Nee Hyperscale-databases hebben gedeelde opslag, wat betekent dat alle rekenreplica's dezelfde tabellen, indexen en andere databaseobjecten zien. Als u aanvullende indexen wilt optimaliseren voor leesbewerkingen op secundaire, moet u deze toevoegen aan de primaire index. U kunt nog steeds tijdelijke tabellen maken (tabelnamen voorafgegaan door # of ##) op elke secundaire replica om tijdelijke gegevens op te slaan. Tijdelijke tabellen zijn lezen/schrijven.

Gegevenslatentie vanaf het moment dat een transactie wordt doorgevoerd op het primaire tijdstip dat deze kan worden gelezen op een secundaire, is afhankelijk van de huidige snelheid van het genereren van logboeken, transactiegrootte, belasting van de replica en andere factoren. Typische gegevenslatentie voor kleine transacties is in tientallen milliseconden, maar er is geen bovengrens voor gegevenslatentie. Gegevens op een bepaalde secundaire replica zijn altijd transactioneel consistent, waardoor grotere transacties langer duren om door te geven. Op een bepaald tijdstip kunnen gegevenslatentie en databasestatus echter verschillen voor verschillende secundaire replica's. Workloads die vastgelegde gegevens onmiddellijk moeten lezen, moeten worden uitgevoerd op de primaire replica.

Nee, benoemde replica's kunnen niet worden gebruikt als failoverdoelen voor de primaire replica. Voeg ha-replica's toe voor dat doel.

Omdat elke benoemde replica een andere serviceniveaudoelstelling kan hebben en dus kan worden gebruikt voor verschillende gebruiksvoorbeelden, is er geen ingebouwde manier om alleen-lezenverkeer dat naar de primaire replica wordt verzonden, naar een set benoemde replica's te leiden. U kunt bijvoorbeeld acht benoemde replica's hebben en u wilt de OLTP-workload mogelijk alleen doorsturen naar benoemde replica's 1 tot en met 4, terwijl analytische Workloads van Power BI benoemde replica's 5 en 6 gebruiken en de data science-workload replica's 7 en 8 gebruikt. Afhankelijk van welk hulpprogramma of welke programmeertaal u gebruikt, kunnen strategieën voor het distribueren van dergelijke werkbelasting variëren. Bekijk het OLTP-voorbeeld voor uitschalen voor een voorbeeld van het maken van een oplossing voor workloadroutering om een REST-back-end uit te schalen.

Nee, omdat benoemde replica's dezelfde paginaservers van de primaire replica gebruiken, moeten ze zich in dezelfde regio bevinden.

Een benoemde replica kan geen invloed hebben op de beschikbaarheid van de primaire replica. Benoemde replica's zijn onder normale omstandigheden waarschijnlijk niet van invloed op de prestaties van de primaire replica, maar dit kan gebeuren als er intensieve workloads worden uitgevoerd. Net als bij een ha-replica wordt een benoemde replica gesynchroniseerd met de primaire replica via de transactielogboekservice. Als een benoemde replica om welke reden dan ook niet snel genoeg het transactielogboek kan gebruiken, wordt de primaire replica gevraagd om het genereren van logboeken te vertragen (beperken), zodat het logboek kan worden ingehaald. Hoewel dit gedrag geen invloed heeft op de beschikbaarheid van de primaire, kan dit invloed hebben op de prestaties van schrijfworkloads op de primaire. Om deze situatie te voorkomen, moet u ervoor zorgen dat uw benoemde replica's voldoende ruimte hebben voor resources, voornamelijk CPU, om transactielogboeken zonder vertraging te verwerken. Als de primaire bijvoorbeeld talloze gegevenswijzigingen verwerkt, wordt aanbevolen om benoemde replica's met ten minste dezelfde serviceniveaudoelstelling als de primaire replica te gebruiken, om verzadiging van de CPU op de replica's te voorkomen en de primaire replica te vertragen.

Benoemde replica's zijn nog steeds beschikbaar voor alleen-lezentoegang, zoals gebruikelijk.

Benoemde replica's hebben standaard geen eigen HA-replica's. Voor een failover van een benoemde replica moet eerst een nieuwe replica worden gemaakt. Dit duurt doorgaans ongeveer 1-2 minuten. Benoemde replica's kunnen echter ook profiteren van hogere beschikbaarheid en kortere failovers die worden geleverd door HA-replica's. Als u HA-replica's wilt toevoegen voor een benoemde replica, kunt u de parameter gebruiken met AZ CLI of de parameter HighAvailabilityReplicaCount met PowerShell of de highAvailabilityReplicaCount eigenschap met REST API.ha-replicas Het aantal HA-replica's kan worden ingesteld tijdens het maken van een benoemde replica en kan worden gewijzigd, alleen via AZ CLI, PowerShell of REST API, wanneer de benoemde replica is gemaakt. Prijzen van HA-replica's voor benoemde replica's zijn hetzelfde als hoge beschikbaarheidsreplica's voor reguliere Hyperscale-databases.

Gerelateerde inhoud

Zie de Hyperscale-servicelaag voor meer informatie over de Hyperscale-servicelaag.