Bewerken

Delen via


Veelgestelde vragen over Azure SQL Database Hyperscale

Van toepassing op: Azure SQL Database

In dit artikel vindt u antwoorden op veelgestelde vragen voor klanten die een database overwegen in de Azure SQL Database Hyperscale-servicelaag, ook wel Hyperscale genoemd in de rest van deze veelgestelde vragen. In dit artikel worden de scenario's beschreven die Door Hyperscale worden ondersteund en welke functies compatibel zijn met Hyperscale.

  • Deze veelgestelde vragen zijn bedoeld voor lezers die een kort begrip hebben van de Hyperscale-servicelaag en hun specifieke vragen en zorgen willen beantwoorden.
  • Deze veelgestelde vragen zijn niet bedoeld om een gids te zijn of vragen te beantwoorden over het gebruik van een Hyperscale-database. Raadpleeg de documentatie van Azure SQL Database Hyperscale voor een inleiding tot Hyperscale.

Algemene vragen

Wat is een Hyperscale-database?

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.

Welke resourcetypen en aankoopmodellen ondersteunen Hyperscale?

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.

Hoe verschilt de Hyperscale-servicelaag van de servicelaag Algemeen gebruik en Bedrijfskritiek servicelagen?

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.

Wie moet de Hyperscale-servicelaag gebruiken?

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.

Welke regio's ondersteunen momenteel Hyperscale?

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

Kan ik meerdere Hyperscale-databases per server maken?

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

Wat zijn de prestatiekenmerken van een Hyperscale-database?

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

Wat is de schaalbaarheid van een Hyperscale-database?

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.

Uitgebreide vragen

Kan ik Hyperscale en individuele databases combineren op één server?

Ja, dat kan.

Moet mijn toepassingsprogrammeermodel worden gewijzigd in Hyperscale?

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.

Welk niveau van transactieisolatie is de standaardinstelling in een Hyperscale-database?

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.

Kan ik mijn on-premises of IaaS SQL Server-licentie overbrengen naar Hyperscale?

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.

Voor welk soort workloads is Hyperscale ontworpen?

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

Hoe kan ik kiezen tussen Azure Synapse Analytics en Azure SQL Database Hyperscale?

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.

Vragen over Hyperscale-rekenproces

Kan ik mijn rekenproces op elk gewenst moment onderbreken?

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.

Kan ik een rekenreplica inrichten met extra RAM voor mijn geheugenintensieve workload?

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.

Kan ik meerdere rekenreplica's van verschillende grootten inrichten?

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

Hoeveel uitschaalreplica's voor lezen worden ondersteund?

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.

Voor hoge beschikbaarheid moet ik extra rekenreplica's inrichten?

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.

Vragen over de grootte en opslag van gegevens

Wat is de maximale databasegrootte die wordt ondersteund met Hyperscale?

100 TB.

Wat is de grootte van het transactielogboek met Hyperscale?

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.

Schaalt mijn tempdb naarmate mijn database groeit?

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.

Groeit de grootte van mijn database automatisch of moet ik de grootte van gegevensbestanden beheren?

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

Wat is de kleinste databasegrootte die Door Hyperscale wordt ondersteund?

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

In welke stappen neemt de grootte van mijn database toe?

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

Is de opslag in Hyperscale lokaal of extern?

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.

Kan ik bestanden of bestandsgroepen beheren of definiëren met Hyperscale?

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.

Kan ik een vaste limiet inrichten voor de groei van gegevens voor mijn database?

Nee

Wordt database verkleinen ondersteund?

Op dit moment niet.

Wordt gegevenscompressie ondersteund?

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

Als ik een enorme tabel heb, worden tabelgegevens verspreid over meerdere gegevensbestanden?

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.

Vragen over gegevensmigratie

Kan ik mijn bestaande databases in Azure SQL Database verplaatsen naar de Hyperscale-servicelaag?

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.

Kan ik mijn Hyperscale-databases verplaatsen naar andere servicelagen?

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.

Verlies ik functionaliteit of mogelijkheden na de migratie naar de Hyperscale-servicelaag?

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.

Kan ik mijn on-premises SQL Server-database of mijn SQL Server-database in een virtuele cloudmachine verplaatsen naar Hyperscale?

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.

Wat is mijn downtime tijdens de migratie van een on-premises of virtuele-machineomgeving naar Hyperscale en hoe kan ik deze minimaliseren?

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.

Hoeveel tijd kost het om X-hoeveelheid gegevens naar Hyperscale te brengen?

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.

Kan ik gegevens lezen uit blobopslag en snel laden (zoals Polybase in Azure Synapse Analytics)?

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.

Staat Hyperscale het inrichten van meerdere knooppunten toe voor parallelle opname van grote hoeveelheden gegevens?

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.

Biedt Hyperscale ondersteuning voor migratie vanuit andere gegevensbronnen, zoals Amazon Aurora, MySQL, PostgreSQL, Oracle, DB2 en andere databaseplatforms?

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

Vragen over bedrijfscontinuïteit en herstel na noodgevallen

Welke SLA's zijn beschikbaar voor een Hyperscale-database?

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.

Worden de databaseback-ups beheerd voor mij door Azure SQL Database?

Ja.

Ondersteunt Hyperscale Beschikbaarheidszones?

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.

Hoe vaak worden back-ups van databases gemaakt?

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.

Biedt Hyperscale ondersteuning voor herstel naar een bepaald tijdstip?

Ja.

Wat is de RPO (Recovery Point Objective)/Recovery Time Objective (RTO) voor databaseherstel in Hyperscale?

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.

Heeft databaseback-up invloed op de rekenprestaties op mijn primaire of secundaire replica's?

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

Kan ik geo-herstel uitvoeren met een Hyperscale-database?

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.

Kan ik geo-replicatie instellen met een Hyperscale-database?

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

Kan ik een back-up van een Hyperscale-database maken en deze herstellen naar mijn on-premises server of op SQL Server in een VIRTUELE machine?

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.

Worden er kosten in rekening gebracht voor back-upopslagkosten in Hyperscale?

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.

Hoe kan ik de grootte van back-upopslag in mijn Hyperscale-database meten?

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

Hoe kan ik weten wat mijn back-upfactuur is?

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.

Hoe beïnvloedt mijn workload de kosten voor mijn back-upopslag?

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.

Hoe kan ik de kosten voor back-upopslag minimaliseren?

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

Prestatievragen

Hoeveel schrijfdoorvoer kan ik pushen in een Hyperscale-database?

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.

Hoeveel IOPS krijg ik op de grootste rekenkracht?

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.

Wordt mijn doorvoer beïnvloed door back-ups?

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

Wordt mijn doorvoer beïnvloed wanneer ik extra rekenreplica's inricht?

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.

Is Hyperscale geschikt voor resource-intensieve, langlopende query's en transacties?

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.

Hoe kan ik prestatieproblemen in een Hyperscale-database vaststellen en oplossen?

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.

Hoe wordt de maximale geheugenlimiet in serverloos vergeleken met ingerichte berekeningen?

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.

Vragen over schaalbaarheid

Hoe lang duurt het om een rekenreplica omhoog en omlaag te schalen?

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.

Is mijn database offline terwijl de bewerking omhoog/omlaag schalen wordt uitgevoerd?

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

Zou ik een afname van de verbinding verwachten wanneer de schaalbewerkingen worden uitgevoerd?

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.

Wordt het automatisch of door de eindgebruiker geactiveerde bewerking voor het omhoog en omlaag schalen van rekenreplica's uitgevoerd?

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

Groeit de grootte van mijn tempdb-database en RBPEX-cache ook naarmate de rekenkracht omhoog wordt geschaald?

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.

Kan ik meerdere primaire rekenreplica's inrichten, zoals een systeem met meerdere masters, waarbij meerdere primaire rekenkoppen een hoger gelijktijdigheidsniveau kunnen stimuleren?

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

Vragen over uitschalen lezen

Welke soorten secundaire replica's (uitschalen lezen) zijn beschikbaar in Hyperscale?

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

Hoeveel secundaire replica's met hoge beschikbaarheid kan ik inrichten?

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

Hoe kan ik verbinding maken met een secundaire replica met hoge beschikbaarheid?

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.

Hoe kan ik controleren of ik verbinding heb gemaakt met een secundaire rekenreplica met behulp van SQL Server Management Studio (SSMS) of andere clienthulpprogramma's?

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.

Kan ik een toegewezen eindpunt maken voor een secundaire replica met hoge beschikbaarheid?

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.

Doet het systeem intelligente taakverdeling van de leesworkload op secundaire replica's met hoge beschikbaarheid?

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

Kan ik secundaire replica's omhoog/omlaag schalen, onafhankelijk van de primaire replica?

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.

Krijg ik verschillende tempdb-grootten voor mijn primaire rekenkracht en mijn secundaire replica's met hoge beschikbaarheid?

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.

Kan ik indexen en weergaven toevoegen aan mijn secundaire rekenreplica's?

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.

Hoeveel vertraging is er tussen de primaire en secundaire rekenreplica's?

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.

Kan een benoemde replica worden gebruikt als failoverdoel?

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

Hoe kan ik een alleen-lezen workload distribueren over mijn benoemde replica's?

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.

Kan een benoemde replica zich in een andere regio bevinden dan de regio van de primaire replica?

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

Kan een benoemde replica van invloed zijn op de beschikbaarheid of prestaties van de primaire 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 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.

Wat gebeurt er met benoemde replica's als de primaire replica bijvoorbeeld niet beschikbaar is vanwege gepland onderhoud?

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

Hoe kan ik de beschikbaarheid van benoemde replica's verbeteren?

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.

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