Veelgestelde vragen over Azure SQL Database Hyperscale

Een Hyperscale-database is een database in Azure SQL Database die wordt ondersteund door de Hyperscale scale-out opslagtechnologie. Een Hyperscale-database ondersteunt maximaal 128 TB aan gegevens en biedt hoge doorvoer en prestaties, evenals snelle schaalaanpassing om aan te passen aan de workloadvereisten. Connectiviteit, queryverwerking, database-enginefuncties, enzovoort, werken zoals in elke andere database in Azure SQL Database.

De Hyperscale-servicelaag is beschikbaar voor individuele databases (zowel ingericht als serverloos) en voor elastische pools met behulp van het aankoopmodel op basis van vCore. 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 vergelijking van resourcelimieten.

De Hyperscale-servicelaag is bedoeld voor alle klanten die op zoek zijn naar hogere prestaties en beschikbaarheid, snelle back-ups en herstelbewerkingen, snelle opslag en schaalbaarheid van rekenkracht. Dit omvat klanten die beginnen met kleine en groeiende, grote bedrijfskritieke databases, degenen 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 die kan toenemen van 10 GB tot 128 TB, ongeacht de rekenkracht.
• Bereken vCore-resources van 2 vCores tot 128 vCores.
• 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 doorvoer van transactielogboeken, ongeacht de databasegrootte en het aantal vCores.
• Uitschalen lezen met behulp van een of meer alleen-lezen replica's, gebruikt voor het offloaden van alleen-lezen workloads of als dynamische 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 optie om te betalen voor wat u gebruikt met serverloze berekeningen, waarbij de berekening wordt gefactureerd op basis van gebruik.

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 servervoor 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 compute- biedt automatische omhoog en omlaag schalen en compute-facturering 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 omvat:

  • Maximaal vier replica's met hoge beschikbaarheid dezelfde rekenkracht hebben als de primaire replica. 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 dezelfde of een andere rekenkracht hebben dan de primaire, 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 geografische uitschaling 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 uw toepassing gebruikmaakt van de Hyperscale-database, kan uw toepassing profiteren van functies zoals secundaire replica's.

Op de primaire replica is het standaardniveau voor transactieisolatie READ COMMITTED met de READ_COMMITTED_SNAPSHOT databaseoptie (RCSI) ingeschakeld. Op de secundaire replica's is het isolatieniveau SNAPSHOT. Dit is hetzelfde als in elke andere Azure SQL-database.

Met de nieuwe, vereenvoudigde prijzen die van kracht zijn sinds 15 december 2023, is de prijs van rekenkracht verminderd voor nieuw gemaakte Hyperscale-databases, alle serverloze Hyperscale-databases en alle elastische Hyperscale-pools. Met de nieuwe, vereenvoudigde prijzen hoeft u Azure Hybrid Benefit (AHB) niet toe te passen om gelijkwaardige besparingen te verkrijgen. Azure Hybrid Benefit (AHB) kan alleen worden toegepast op oudere (gemaakt vóór 15 december 2023) Hyperscale-individuele databases met ingerichte rekenkracht. Voor deze oudere databases is AHB pas van toepassing tot december 2026, waarna deze databases ook worden gefactureerd volgens de nieuwe, vereenvoudigde prijzen.

Zie voor meer informatie Blog over prijzen van Hyperscale en Azure SQL Database Hyperscale : lagere, vereenvoudigde prijzen.

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 datawarehouse, is Hyperscale een uitstekende optie omdat u kleine en middelgrote datawarehouses (zoals een paar TB tot 128 TB) tegen lagere kosten kunt hosten en u uw SQL Server-datawarehouse-workloads kunt migreren naar Hyperscale met minimale T-SQL-codewijzigingen.

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

Opname- of logboekgeneratiesnelheid van 150 MiB/s is beschikbaar als een preview-functie voor opt-in voor premium-serie en premium-serie geoptimaliseerd geheugen. Zie Blog: verbeteringen van Hyperscale in november 2024voor meer informatie en om u aan te kiezen voor 150 MiB/s.

Niet op dit moment. U kunt uw rekenkracht en het aantal replica's echter omlaag schalen om kosten te verlagen tijdens niet-peaktijden, of serverloze gebruiken om de berekening automatisch 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 rekengroottenvoor 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 tussen 0 en 4 schalen met behulp van Azure Portal of REST API-. Daarnaast kunt u maximaal 30 benoemde replica's maken voor veel uitschaalscenario's met leesbewerkingen. Elke benoemde replica kan maximaal 4 HA secundaire replica's hebben.

In Hyperscale-databases wordt gegevenstolerantie geboden op opslagniveau. U hebt slechts één replica (de primaire) nodig om tolerantie te bieden. Als de rekenreplica mislukt of onder onderhoud valt, 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, 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 toepassingen 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 er een hot stand-byreplica beschikbaar is om te fungeren als failoverdoel.

De maximale grootte van één Hyperscale-database is momenteel 128 TB, ongeacht de rekenkracht. De maximale grootte van een database in een elastische Hyperscale-pool is momenteel 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 Change Data Capture verwerking niet bijhoudt met de snelheid van gegevenswijziging. Vermijd onnodig lange en grote transacties om onder deze limiet te blijven. Behalve 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 verminderd voor doorlopende schrijfworkloads. Het piekpercentage voor het genereren van logboeken is 100 MiB/s.

De snelheid van het genereren van logboeken van 150 MiB/s is beschikbaar als een opt-in preview-functie voor geoptimaliseerd geheugen uit de Premium-serie en premium-serie. Zie Blog: verbeteringen van Hyperscale in november 2024voor meer informatie en om u aan te kiezen voor 150 MiB/s.

Uw tempdb-database bevindt zich op de lokale SSD-opslag en heeft een proportionele grootte ten opzichte van de rekenkracht (het aantal kernen) dat u inricht. De grootte van tempdb kan niet worden geconfigureerd en wordt voor u beheerd. Zie tempdbom de maximale 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.

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.

Ja, database- en bestandskrimpbewerkingen worden ondersteund in Azure SQL Database Hyperscale.

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 strategie voor proportionele opvulling om gegevens over gegevensbestanden te distribueren.

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

U kunt een bestaande Azure SQL Database converteren naar Hyperscale in Azure Portal, Azure CLI, PowerShell en Transact-SQL. Zie Een bestaande database converteren naar Hyperscalevoor meer informatie.

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 van lage schrijfactiviteit. Zie Omgekeerde migratie van Hyperscalevoor meer informatie.

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 omgekeerd migreren naar de servicelaag Algemeen gebruik en vervolgens de servicelaag wijzigen. Omgekeerde migratie is een grootte van gegevensbewerkingen.

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

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

Ja. Sommige Azure SQL Database-functies worden niet ondersteund in Hyperscale. Als sommige van deze functies zijn ingeschakeld voor uw database, kan de migratie naar Hyperscale worden geblokkeerd of werken deze functies niet meer na de migratie. Zie Bekende beperkingenvoor 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 de 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 MiB/s van 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 leessnelheid van de bron, het type belasting (bulk versus rij-per-rij) en de doelstelling van het doeldatabaseserviceniveau. De snelheid van het genereren van logboeken van 150 MiB/s is beschikbaar als een opt-in preview-functie voor geoptimaliseerd geheugen uit de Premium-serie en premium-serie. Zie Blog: verbeteringen van Hyperscale in november 2024voor meer informatie en om u aan te kiezen voor 150 MiB/s.

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 gebruiken in Azure Databricks- met de Spark-connector voor SQL. De Spark-connector voor SQL ondersteunt bulksgewijs invoegen.

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

Eenvoudige of bulksgewijs vastgelegde herstelmodellen worden 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 meerdere replica's maken om alleen-lezenworkloads uit te schalen.

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

Facturering van Hyperscale na een conversie begint pas nadat de cutover is voltooid.

Ja. Op dit moment hebt u de mogelijkheid om de cutover handmatig te starten wanneer u een database converteert naar Hyperscale via Azure Portal, PowerShell, Azure CLI of T-SQL. Tijdens de laatste cutover naar Hyperscale ervaart u slechts een korte periode van downtime, meestal minder dan een minuut.

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.

Ja. Zie voor meer informatie elastische Hyperscale-pools en Blog: Elastische Hyperscale-pools zijn nu algemeen beschikbaar.

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 as-is voor de geconfigureerde bewaarperiode. Tijdens het herstellen worden relevante transactielogboekrecords toegepast op herstelde opslagmomentopnamen. Ongeacht de frequentie van momentopnamen, resulteert dit in een transactioneel consistente database vanaf het opgegeven tijdstip binnen de retentieperiode, zonder gegevensverlies. 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. Het uitgeven van een herstel na een recente wijziging van opslagredundantie kan leiden tot langere hersteltijden omdat de herstelbewerking in dat geval een gegevensgrootte kan zijn en de hersteltijd mogelijk 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 of geografisch zone-redundante opslag wordt gebruikt. Geografisch redundante opslag 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 geo-hersteltijd is aanzienlijk korter als de database wordt hersteld in de Azure-regio die is gekoppeld met de regio van de brondatabase. Zie Geo-herstel voor Azure SQL Databasevoor meer informatie.

Ja. geo-replicatie en failover groepen kunnen 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 pagina met prijzen 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 opslagredundantievoor meer informatie.

Zie Geautomatiseerde back-upsvoor meer informatie over het meten van de grootte van back-upopslag.

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. Gebruik Azure Monitor REST API-om via programmacode query's uit te voeren op relevante metrische gegevens van Azure Monitor voor meerdere intervallen per uur. Back-upfacturering in de serverloze rekenlaag hetzelfde is 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.

Zie Geautomatiseerde back-upsvoor meer informatie over het minimaliseren van de kosten voor back-upopslag.

Momenteel kunnen niet-Hyperscale-servicelagen (Basic/Standard/Premium/Algemeen gebruik/Bedrijfskritiek) geen geo-herstelbewerkingen uitvoeren in een Hyperscale-servicelaag en omgekeerd. Als u een niet-Hyperscale-database wilt converteren naar een Hyperscale-database, wijzigt u de servicelaag na een herstelbewerking.

De doorvoerlimiet voor transactielogboeken is 100 MiB/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 snelheid van het genereren van logboeken van 150 MiB/s is beschikbaar als een opt-in preview-functie voor geoptimaliseerd geheugen uit de Premium-serie en premium-serie. Zie Blog: verbeteringen van Hyperscale in november 2024voor meer informatie en om u aan te kiezen voor 150 MiB/s.

De IOPS- en IO-latentie variëren, afhankelijk van de workloadpatronen. Als de gegevens die worden geopend in de cache worden opgeslagen in de lokale SSD-opslag op de rekenreplica, ziet u vergelijkbare I/O-prestaties als in bedrijfskritieke 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. De logboeksnelheid voor doorlopende en agressieve schrijfworkloads kan echter worden beperkt op de primaire, 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-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 diagnostische msSQL- en probleemoplossingsstappen van toepassing. Zie sql Hyperscale-prestatieproblemen oplossenvoor diagnostische gegevens over hyperscale-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. Bekijk serverloze Hyperscale-resourcelimieten 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 compute SSD-cache grootte op rekenknooppunten automatisch omhoog schalen naarmate het aantal kernen wordt verhoogd. Zie Hyperscale-opslag- en rekengroottenvoor 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 replica's van Hyperscale 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 ApplicationIntent in uw 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.

U kunt de volgende T-SQL-query uitvoeren: SELECT DATABASEPROPERTYEX ('<database_name>', 'Updateability'). Het resultaat is READ_ONLY als u bent verbonden met een alleen-lezen secundaire replica 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 ApplicationIntent=ReadOnlyop te geven. 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 de mogelijkheid bieden om elke benoemde replica onafhankelijk te schalen.

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

Nee. Hyperscale-databasereplica's delen 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 in de tempdb-database. 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 moment kunnen gegevenslatentie en databasestatus 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 de primaire replica 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. Voor een voorbeeld van het maken van een oplossing voor workloadroutering zodat een REST-back-end kan worden uitgeschaald, raadpleegt u het OLTP-voorbeeld van uitschalen.

Nee, omdat benoemde replica's dezelfde paginaservers van de primaire replica gebruiken, moeten ze zich in dezelfde regio bevinden. Als u echter een geo-replica hebt gemaakt voor de primaire replica in een andere regio, kunt u benoemde replica's maken voor de geo-replica.

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 transactielogboek kan gebruiken, wordt de primaire replica gevraagd om de snelheid van het genereren van logboeken te verminderen, zodat het kan inhalen. 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, is het raadzaam om benoemde replica's met ten minste dezelfde rekenkracht als de primaire replica te gebruiken om verzadiging van de CPU op de replica's te voorkomen en de primaire replica af te dwingen om 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. U kunt HA-replica's toevoegen voor een benoemde replica in Azure Portal of de parameter ha-replicas met AZ CLIof de parameter HighAvailabilityReplicaCount met PowerShell-of de eigenschap highAvailabilityReplicaCount met REST API-. Het aantal HA-replica's kan worden ingesteld tijdens het maken van een benoemde replica en kan op elk gewenst moment worden gewijzigd nadat de benoemde replica is gemaakt. Prijzen van HA-replica's voor benoemde replica's zijn hetzelfde als ha-replica's voor primaire replica's.

Ja. De kolomhoofdsleutel wordt opgeslagen in de gebruikersdatabase en kan worden gevalideerd door de query uit te voeren SELECT * FROM sys.column_master_keys. Benoemde replica's en secundaire replica's met hoge beschikbaarheid lezen gegevens van dezelfde paginaservers/opslaglaag als de primaire Hyperscale-database. Beide typen replica's worden gesynchroniseerd met de primaire Hyperscale-database via de logboekservice. Een sleutelwijziging wordt beschouwd als een transactie en wordt automatisch gerepliceerd naar alle secundaire replica's.

Niet wanneer u een query uitvoert op sys.dm_database_replica_states op de primaire replica. U kunt echter verbinding maken met een benoemde replica om de replica-id en andere details te bepalen met behulp van de volgende voorbeeldquery:

  SELECT replica_id,
         DB_NAME() AS named_replica_database_name,
         synchronization_state_desc,
         log_send_queue_size / 1024.0 / 1024.0 AS log_send_queue_size_gb,
         last_sent_time,
         last_received_time,
         last_commit_time,
         redo_queue_size / 1024.0 / 1024.0 AS redo_queue_size_gb,
         redo_rate,
         secondary_lag_seconds
  FROM sys.dm_database_replica_states
  WHERE is_local = 1
        AND
        replica_id = DATABASEPROPERTYEX(DB_NAME(), 'ReplicaID');

Verwante inhoud

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