Elastische taken in Azure SQL Database (preview)

Van toepassing op: Azure SQL Database

In dit artikel bekijken we de mogelijkheden en details van elastische taken voor Azure SQL Database.

• Zie de zelfstudie voor elastische taken voor een zelfstudie over het configureren van elastische taken.
• Meer informatie over automatiseringsconcepten in Azure-databaseplatforms.

Notitie

Elastische taken zijn in preview. Functies die momenteel in de preview-versie beschikbaar zijn, zijn beschikbaar onder aanvullende gebruiksvoorwaarden. Bekijk de juridische voorwaarden die van toepassing zijn op Azure-functies die in preview zijn. Azure SQL Database biedt previews om u de kans te geven feedback te evalueren en te delen met de productgroep over functies voordat deze algemeen beschikbaar worden.

Overzicht van elastische taken

U kunt elastische taken maken en plannen die periodiek kunnen worden uitgevoerd op een of meer Azure SQL-databases om Transact-SQL-query's (T-SQL) uit te voeren en onderhoudstaken uit te voeren.

U kunt een doeldatabase of groepen databases definiëren waarin de taak wordt uitgevoerd, en ook schema's voor het uitvoeren van een taak definiëren. Alle datums en tijden in elastische taken bevinden zich in de UTC-tijdzone.

Een taak handelt het aanmelden bij de doeldatabase af. Ook definieert, onderhoudt en handhaaft u Transact-SQL-scripts die in een groep databases moeten worden uitgevoerd.

Door elke taak wordt de uitvoeringsstatus in een logboek vastgelegd en wordt ook geprobeerd de bewerkingen opnieuw uit te voeren als er een fout optreedt.

Wanneer u elastische taken gebruikt

Er zijn verschillende scenario's waarin u elastische taakautomatisering kunt gebruiken:

• Beheertaken automatiseren en plannen dat ze elke weekdag, na kantooruren, enzovoort worden uitgevoerd.
  • Schemawijzigingen implementeren, referentiebeheer.
  • Prestatiegegevensverzameling of tenanttelemetrieverzameling (klant).
  • Werk referentiegegevens (algemene informatie voor alle databases) bij.
  • Gegevens laden uit Azure Blob Storage.
• Configureer taken voor uitvoering in een verzameling databases op terugkerende basis, zoals tijdens daluren.
  • Verzamel op continue basis queryresultaten uit een reeks databases in een centrale tabel.
  • Query's kunnen voortdurend worden uitgevoerd en geconfigureerd om extra taken te activeren die moeten worden uitgevoerd.
• Gegevens verzamelen voor rapportage
  • Verzamel gegevens uit een verzameling databases in één doeltabel.
  • Voer langer durende gegevensverwerkingsquery's uit voor een groot aantal databases, zoals het verzamelen van klanttelemetrie. Resultaten worden in één doeltabel verzameld voor verdere analyse.
• Gegevensverplaatsing
  • Voor aangepaste ontwikkelde oplossingen, bedrijfsautomatisering of ander taakbeheer.
  • ETL-verwerking voor het extraheren/verwerken/invoegen van gegevens tussen tabellen in een database.

Overweeg elastische taken wanneer u:

• Een taak hebben die regelmatig moet worden uitgevoerd volgens een planning, gericht op een of meer databases.
• Een taak hebben die eenmaal moet worden uitgevoerd, maar voor meerdere databases.
• Taken moeten worden uitgevoerd op basis van elke combinatie van databases: een of meer afzonderlijke databases, alle databases op een server, alle databases in een elastische pool, met de extra flexibiliteit om een specifieke database op te nemen of uit te sluiten. Taken kunnen worden uitgevoerd op meerdere servers en meerdere pools, en kunnen zelfs worden uitgevoerd voor databases in verschillende abonnementen. Servers en pools worden dynamisch opgesomd tijdens runtime, zodat taken worden uitgevoerd voor alle databases die op het moment van de uitvoering in de doelgroep aanwezig zijn.
  • Dit is een aanzienlijke differentiatie van SQL Agent, die de doeldatabases niet dynamisch kan inventariseren, met name in SaaS-klantscenario's waarin databases dynamisch worden toegevoegd of verwijderd.

Onderdelen van elastische taken

Onderdeel	Beschrijving
Elastische taakagent	De Azure-resource die u maakt om taken uit te voeren en te beheren.
Taakdatabase	Een database in Azure SQL die de taakagent gebruikt om taakgerelateerde gegevens, taakdefinities enzovoort op te slaan.
Functie	Een taak is een werkeenheid die uit een of meer taakstappen bestaat. Taakstappen bepalen welk T-SQL-script moet worden uitgevoerd en andere details die nodig zijn voor het uitvoeren van het script.
Doelgroep	De set servers, pools en databases waarop een taak moet worden uitgevoerd.

Elastische taakagent

Een elastische taakagent is de Azure-resource voor het maken, uitvoeren en beheren van taken. De elastische-taakagent is een Azure-resource die u in de portal maakt (PowerShell en REST API worden ook ondersteund).

Voor het maken van een elastische taakagent is een bestaande database in Azure SQL Database vereist. De agent configureert deze bestaande Azure SQL Database als taakdatabase.

U kunt een taak starten, uitschakelen of annuleren via Azure Portal. Met Azure Portal kunt u ook taakdefinities en uitvoeringsgeschiedenis weergeven.

Kosten van de elastische taakagent

De elastische taakagent is gratis voor de huidige preview. Factureringskaarten in Azure Portal tijdens de preview-versie tonen een schatting (in Amerikaanse dollars) van de kosten op basis van de geselecteerde capaciteitslaag voor gelijktijdigheid. Dit is momenteel alleen bedoeld voor geavanceerde kostenramingen.

De taakdatabase wordt tegen hetzelfde tarief gefactureerd als een database in Azure SQL Database.

Elastische taakdatabase

De taakdatabase wordt gebruikt voor het definiëren van taken en het bijhouden van de status en geschiedenis van taakuitvoeringen. Taken worden uitgevoerd in doeldatabases. De taakdatabase wordt ook gebruikt voor het opslaan van metagegevens van agents, logboeken, resultaten, taakdefinities en bevat ook veel nuttige opgeslagen procedures en andere databaseobjecten voor het maken, uitvoeren en beheren van taken met behulp van T-SQL.

Voor de huidige preview wordt een bestaande database in Azure SQL Database (S1 of hoger) aanbevolen om een elastische taakagent te maken.

De taakdatabase moet een schone, lege, S1 of hogere servicedoelstelling van Azure SQL Database zijn.

De aanbevolen servicedoelstelling van de taakdatabase is S1 of hoger, maar de optimale keuze is afhankelijk van de prestatiebehoeften van uw taak(en): het aantal taakstappen, het aantal taakdoelen en hoe vaak taken worden uitgevoerd.

Als bewerkingen voor de taakdatabase langzamer zijn dan verwacht, bewaak dan de databaseprestaties en het resourcegebruik in de taakdatabase tijdens trage periodes met behulp van Azure Portal of de DMV sys. dm_db_resource_stats. Als het gebruik van een resource, zoals CPU, gegevens-IO of logboekschrijfbewerkingen bijna 100% is en overeenkomt met trage perioden, kunt u overwegen om de database stapsgewijs te schalen naar hogere servicedoelstellingen (in het DTU-model of het vCore-model) totdat de prestaties van de taakdatabase voldoende zijn verbeterd.

Belangrijk

Wijzig de bestaande objecten niet of maak nieuwe objecten in de taakdatabase, maar u kunt deze lezen uit de tabellen voor rapportage en analyse.

Elastische taken en taakstappen

Een taak is een werkeenheid die wordt uitgevoerd volgens een schema of als een eenmalige taak. Een taak bestaat uit een of meer taakstappen.

Elke taakstap bevat een uit te voeren T-SQL-script, een of meer doelgroepen waarvoor het T-SQL-script moet worden uitgevoerd en de referenties die de agent nodig heeft om verbinding te maken met de doeldatabase. Elke taakstap heeft een instelbaar beleid voor time-out en nieuwe pogingen, en kan optioneel uitvoerparameters bevatten.

Doelen voor elastische taken

Elastische taken bieden de mogelijkheid om een of meer T-SQL-scripts parallel uit te voeren voor een groot aantal databases, volgens een planning of op aanvraag. Het doel kan elke laag van Azure SQL Database zijn.

U kunt geplande taken uitvoeren op elke combinatie van databases: een of meer afzonderlijke databases, alle databases op een server, alle databases in een elastische pool, met de extra flexibiliteit om een specifieke database op te nemen of uit te sluiten. Taken kunnen worden uitgevoerd op meerdere servers en meerdere pools, en kunnen zelfs worden uitgevoerd voor databases in verschillende abonnementen. Servers en pools worden dynamisch opgesomd tijdens runtime, zodat taken worden uitgevoerd voor alle databases die op het moment van de uitvoering in de doelgroep aanwezig zijn.

De volgende afbeelding toont hoe een taakagent taken uitvoert op verschillende soorten doelgroepen:

Doelgroep

Een doelgroep definieert de verzameling databases waarvoor een taakstap wordt uitgevoerd. Een doelgroep kan een willekeurig aantal en een willekeurige combinatie van de volgende elementen bevatten:

• Logische SQL-server: als een server is opgegeven, maken alle databases op de server op het moment waarop de taak wordt uitgevoerd, deel uit van de groep. De master databasereferentie moet worden opgegeven, zodat de groep kan worden geïnventariseerd en bijgewerkt voordat de taak wordt uitgevoerd. Zie Wat is een server in Azure SQL Database en Azure Synapse Analytics voor meer informatie over logische servers.
• Elastische pool: als een elastische pool is opgegeven, maken alle databases die zich in de elastische pool bevinden op het moment dat de taak wordt uitgevoerd, deel uit van de groep. Net als bij een server moet de master databasereferentie worden opgegeven, zodat de groep kan worden bijgewerkt voordat de taak wordt uitgevoerd.
• Individuele database: geef een of meer afzonderlijke databases op als onderdeel van de groep.

Tip

Op het moment dat de taak wordt uitgevoerd, wordt de reeks databases in de doelgroepen die servers of pools bevatten, opnieuw geëvalueerd met behulp van dynamische opsomming. Dynamische opsomming zorgt ervoor dat taken worden uitgevoerd voor alle databases die in de server of de pool bestaan op het moment dat de taak wordt uitgevoerd. Een herevaluatie van de lijst met databases tijdens runtime is met name nuttig als het lidmaatschap van de pool of server regelmatig verandert.

Pools en individuele databases kunnen worden opgegeven als ingesloten in of uitgesloten van de groep. Zo kunt u een doelgroep maken met een willekeurige combinatie van databases. Zo kunt u bijvoorbeeld een server toevoegen aan een doelgroep, maar specifieke databases in een elastische pool (of een hele pool) uitsluiten.

Een doelgroep kan databases in meerdere abonnementen en uit meerdere regio's bevatten. Uitvoeringen tussen regio's hebben een hogere latentie dan uitvoeringen binnen dezelfde regio.

In de volgende voorbeelden ziet u hoe verschillende doelgroepdefinities tijdens de uitvoering van de taak dynamisch worden geïnventariseerd om te bepalen in welke databases de taak wordt uitgevoerd:

• In Voorbeeld 1 ziet u een doelgroep dat bestaat uit een lijst met afzonderlijke databases. Wanneer een taakstap wordt uitgevoerd met behulp van deze doelgroep, wordt de actie van de taakstap uitgevoerd in elk van deze databases.
• In Voorbeeld 2 ziet u een doelgroep die een server als doel heeft. Wanneer een taakstap wordt uitgevoerd met behulp van deze doelgroep, wordt de server dynamisch geïnventariseerd om de actuele lijst met databases op de server te bepalen. De actie van de taakstap wordt uitgevoerd in elk van deze databases.
• In Voorbeeld 3 ziet u een vergelijkbare doelgroep als in Voorbeeld 2, maar een afzonderlijke database wordt uitdrukkelijk uitgesloten. De actie van de taakstap wordt niet uitgevoerd in de uitgesloten database.
• In Voorbeeld 4 ziet u een doelgroep die een elastische pool als doel heeft. De pool wordt, vergelijkbaar met in Voorbeeld 2, dynamisch geïnventariseerd tijdens het uitvoeren van de taak om de lijst met databases in de pool te bepalen.

• In Voorbeeld 5 en Voorbeeld 6 ziet u geavanceerde scenario's waarin servers, elastische pools en databases kunnen worden gecombineerd met behulp van regels voor opnemen en uitsluiten.

Notitie

De taakdatabase zelf kan het doel van een taak zijn. In dit scenario wordt de taakdatabase net als elke andere doeldatabase behandeld. De taakgebruiker moet worden gemaakt en voldoende machtigingen krijgen in de taakdatabase, en de databasereferentie voor de taakgebruiker moet ook aanwezig zijn in de taakdatabase, net zoals voor elke andere doeldatabase.

Verificatie

Kies één methode voor alle doelen voor een elastische taakagent. Voor één elastische-taakagent kunt u bijvoorbeeld niet één doelserver configureren voor het gebruik van referenties binnen het databasebereik en een andere voor het gebruik van Microsoft Entra ID-verificatie.

De elastische taakagent kan verbinding maken met de server(s)/database(s) die zijn opgegeven door de doelgroep via twee verificatieopties:

• Gebruik Microsoft Entra-verificatie (voorheen Azure Active Directory) met een door de gebruiker toegewezen beheerde identiteit (UMI).
• Gebruik databasereferenties. (Voorheen was dit de enige verificatiemethode.)

De naam van Azure Active Directory is gewijzigd in Microsoft Entra ID, vanaf 2023.

Verificatie via door de gebruiker toegewezen beheerde identiteit (UMI)

Microsoft Entra-verificatie (voorheen Azure Active Directory) via door de gebruiker toegewezen beheerde identiteit (UMI) is de aanbevolen optie voor het verbinden van elastische taken met Azure SQL Database. Met ondersteuning voor Microsoft Entra ID kan de taakagent verbinding maken met doeldatabases (databases, servers, elastische pools) en uitvoerdatabase(s) met behulp van de UMI.

Optioneel kan Microsoft Entra ID-verificatie ook worden ingeschakeld op de logische server die de elastische taakdatabase bevat, voor het openen/opvragen van die database via Microsoft Entra ID-verbindingen. De taakagent zelf maakt echter gebruik van interne verificatie op basis van certificaten om verbinding te maken met de taakdatabase.

U kunt één UMI maken of een bestaande UMI gebruiken en dezelfde UMI toewijzen aan meerdere jobagents. Er wordt slechts één UMI per taakagent ondersteund. Zodra een UMI is toegewezen aan een jobagent, gebruikt jobagent deze identiteit alleen om verbinding te maken en t-SQL-taken uit te voeren op de doeldatabases. SQL-verificatie wordt niet gebruikt voor de doelserver/databases van die taakagent.

De UMI-naam moet beginnen met een letter of cijfer en met een lengte tussen 3 en 128. Het kan de - en _ tekens bevatten.

Zie Beheerde identiteiten voor Azure SQL voor meer informatie over UMI in Azure SQL, inclusief de vereiste stappen en voordelen van het gebruik van een UMI als de logische serveridentiteit van Azure SQL Database. Zie Microsoft Entra (voorheen Azure Active Directory) gebruiken om te verifiëren bij Azure SQL-platforms voor meer informatie.

Belangrijk

Wanneer u Microsoft Entra ID-verificatie gebruikt, maakt u uw jobuser gebruiker op basis van die Microsoft Entra-id in elke doeldatabase. Geef die gebruiker de machtigingen die nodig zijn om uw taken uit te voeren in elke doeldatabase.

Het gebruik van een door het systeem toegewezen beheerde identiteit (SMI) wordt niet ondersteund.

Verificatie via referenties in databasebereik

Hoewel Microsoft Entra-verificatie (voorheen Azure Active Directory) de aanbevolen optie is, kunnen taken worden geconfigureerd voor het gebruik van referenties binnen het databasebereik om verbinding te maken met de databases die zijn opgegeven door de doelgroep na uitvoering. Vóór oktober 2023 waren referenties met databasebereik de enige verificatieoptie.

Als een doelgroep servers of pools bevat, worden deze databasereferenties gebruikt om verbinding te maken met de master database om de beschikbare databases op te sommen.

• De referenties voor het databasebereik moeten worden gemaakt in de taakdatabase.
• Alle doeldatabases moeten over voldoende machtigingen beschikken om de taak te kunnen voltooien (jobuserin het volgende diagram).
• Referenties die zijn gemaakt in doeldatabases (LOGIN en PASSWORD voor masteruser en jobuser, in het volgende diagram) moeten overeenkomen met de IDENTITY referenties SECRET die zijn gemaakt in de taakdatabase.
• Referenties kunnen opnieuw worden gebruikt in verschillende taken en de referentieswachtwoorden worden versleuteld en beveiligd tegen gebruikers die alleen-lezentoegang hebben tot taakobjecten.

De volgende afbeelding is ontworpen om inzicht te verkrijgen in het instellen van de juiste taakreferenties en hoe de elastische taakagent verbinding maakt met behulp van databasereferenties als verificatie voor aanmeldingen/gebruikers in doelservers/databases.

Notitie

Wanneer u referenties voor databasebereik gebruikt, moet u uw jobuser gebruiker maken in elke doeldatabase.

Privé-eindpunten voor elastische taken

De elastische taakagent ondersteunt privé-eindpunten voor elastische taken. Als u een privé-eindpunt voor elastische taken maakt, wordt er een privékoppeling gemaakt tussen de elastische taak en de doelserver. De functie voor privé-eindpunten voor elastische taken verschilt van de Azure Private Link.

De functie privé-eindpunten voor elastische taken ondersteunt privéverbindingen met doel-/uitvoerservers, zodat de taakagent deze nog steeds kan bereiken, zelfs wanneer de optie Openbare toegang weigeren is ingeschakeld. Het gebruik van privé-eindpunten is ook een mogelijke oplossing als u de optie Toestaan dat Azure-services en -resources toegang hebben tot die server uitschakelen.

Privé-eindpunten voor elastische taken ondersteunen alle opties voor verificatie van elastische taakagenten.

Met de functie privé-eindpunt voor elastische taken kunt u een door de service beheerd privé-eindpunt kiezen om een beveiligde verbinding tot stand te brengen tussen de taakagent en de doel-/uitvoerservers. Een door de service beheerd privé-eindpunt is een privé-IP-adres binnen een specifiek virtueel netwerk en subnet. Wanneer u ervoor kiest om privé-eindpunten te gebruiken op een van de doel-/uitvoerservers van uw taakagent, wordt er een door de service beheerd privé-eindpunt gemaakt door Microsoft. Dit privé-eindpunt wordt vervolgens uitsluitend gebruikt door de taakagent voor het verbinden en uitvoeren van taken, of voor het schrijven van de taakuitvoer op die doel-/uitvoerdatabases.

Privé-eindpunten voor elastische taken kunnen worden gemaakt en toegestaan via Azure Portal. Doelservers die zijn verbonden via de private link, kunnen zich overal in Azure bevinden, zelfs in verschillende geografische gebieden en abonnementen. U moet een privé-eindpunt maken voor elke gewenste doelserver en de taakuitvoerserver om deze communicatie in te schakelen.

Zie Privé-eindpunt voor elastische Azure SQL-taken configureren voor een zelfstudie voor het configureren van een nieuw, door de service beheerd privé-eindpunt voor elastische taken.

Vereisten voor privé-eindpunten voor elastische taken

• Als u een privé-eindpunt voor elastische taken wilt gebruiken, moeten zowel de taakagent als de doelservers/databases worden gehost in Azure (dezelfde of verschillende regio's) en in hetzelfde cloudtype (bijvoorbeeld in de openbare cloud of beide in de overheidscloud).
• Microsoft.Network resourceprovider moet zijn geregistreerd voor de hostabonnementen van zowel de taakagent als de doel-/uitvoerservers.
• Privé-eindpunten voor elastische taken worden gemaakt per doel-/uitvoerserver. Ze moeten worden goedgekeurd voordat de elastische taakagent ze kan gebruiken. Dit kan worden gedaan via het deelvenster Netwerken van die logische server of uw voorkeursclient. De elastische taakagent kan vervolgens alle databases onder die server bereiken met behulp van een privéverbinding.
• De verbinding van de elastische-taakagent naar de takendatabase maakt geen gebruik van een privé-eindpunt. De taakagent zelf maakt gebruik van interne verificatie op basis van certificaten om verbinding te maken met de taakdatabase. Een nadeel is dat u de takendatabase toevoegt als doelgroeplid. Vervolgens gedraagt het zich als een normaal doel dat u indien nodig moet instellen met een privé-eindpunt.

Databasemachtigingen voor elastische taken

Tijdens het maken van de taakagent worden een schema, tabellen en een rol met de naam jobs_reader gemaakt in de taakdatabase. De rol wordt gemaakt met de volgende machtiging en is ontworpen om beheerders een nauwkeuriger toegangsbeheer te geven voor taakbewaking. Beheer istrators kunnen gebruikers de mogelijkheid bieden om taakuitvoering te controleren door ze toe te voegen aan de jobs_reader rol in de taakdatabase.

Rolnaam	Machtigingen voor schema 'jobs'	Machtigingen voor schema 'jobs_internal'
jobs_reader	SELECTEREN	Geen

Let op

U moet geen interne catalogusweergaven in de taakdatabase bijwerken, zoals jobs.target_group_members. Als u deze catalogusweergaven handmatig wijzigt, kan de taakdatabase beschadigd raken en mislukt. Deze weergaven zijn alleen-lezenquery's. U kunt de opgeslagen procedures in uw taakdatabase gebruiken om doelgroepen/leden toe te voegen/te verwijderen, zoals jobs.sp_add_target_group_member.

Belangrijk

Houd rekening met de gevolgen voor de beveiliging voordat u verhoogde toegang verleent tot de taakdatabase. Een kwaadwillende gebruiker met machtigingen voor het maken of bewerken van taken kan een taak maken of bewerken die gebruikmaakt van een opgeslagen referentie om verbinding te maken met een database onder het beheer van de kwaadwillende gebruiker, waardoor de kwaadwillende gebruiker het wachtwoord van de referenties kan bepalen of schadelijke opdrachten kan uitvoeren.

Elastische taken bewaken

Vanaf oktober 2023 heeft de elastische taakagent integratie met Azure-waarschuwingen voor taakstatusmeldingen, waardoor de oplossing voor het bewaken van de status en geschiedenis van de taakuitvoering wordt vereenvoudigd.

Azure Portal bevat ook nieuwe, aanvullende functies voor het ondersteunen van elastische taken en taakbewaking. U kunt Azure Monitor-waarschuwingsregels maken met Azure Portal, Azure CLI, PowerShell en REST API. De metrische gegevens voor mislukte elastische taken zijn een goed startpunt voor het bewaken en ontvangen van waarschuwingen over de uitvoering van elastische taken. Daarnaast kunt u ervoor kiezen om te worden gewaarschuwd via een configureerbare actie, zoals sms of e-mail door de Azure Alert-faciliteit. Zie Waarschuwingen maken voor Azure SQL Database in Azure Portal voor meer informatie.

Zie Elastische taken maken, configureren en beheren (preview) voor een voorbeeld.

Taakuitvoer

Het resultaat van de stappen van een taak op elke doeldatabase wordt gedetailleerd geregistreerd en scriptuitvoer kan worden vastgelegd in een opgegeven tabel. U kunt een database opgeven om de resultaatgegevens van een taak vast te leggen.

Jobgeschiedenis

Bekijk de uitvoeringsgeschiedenis van elastische taken in de taakdatabase door een query uit te voeren op de tabel jobs.job_executions. Met een systeemopschoontaak wordt uitvoergeschiedenis verwijderd die ouder is dan 45 dagen. Als u de geschiedenis minder dan 45 dagen oud handmatig wilt verwijderen, voert u de sp_purge_jobhistory opgeslagen procedure uit in de taakdatabase.

Taakstatus

U kunt de uitvoeringen van elastische taken in de taakdatabase bewaken door een query uit te voeren op de tabel jobs.job_executions.

Aanbevolen procedures

Houd rekening met de volgende aanbevolen procedures bij het werken met elastische databasetaken.

Aanbevolen procedures voor beveiliging

• Beperk het gebruik van de API's tot vertrouwde personen.
• Referenties moeten slechts de minimale bevoegdheden hebben die nodig zijn om de taakstap uit te voeren. Zie Autorisatie en machtigingen voor meer informatie.
• Wanneer u een lid van een server en/of pooldoelgroep gebruikt, wordt u ten zeerste aangeraden om een afzonderlijke referentie te maken met rechten voor de master database om databases weer te geven of weer te geven die worden gebruikt om de databaselijsten van de server(s) en/of pool(s) uit te vouwen voordat de taak wordt uitgevoerd.

Prestaties van elastische taken

Elastische taken maken gebruik van minimale rekenresources terwijl wordt gewacht tot langlopende taken zijn voltooid.

Afhankelijk van de grootte van de doelgroep van databases en de gewenste uitvoeringstijd voor een taak (aantal gelijktijdige werknemers), vereist de agent verschillende hoeveelheden rekenkracht en prestaties van de taakdatabase (hoe meer doelen en hoe hoger het aantal taken, hoe hoger de benodigde hoeveelheid rekenkracht).

Gelijktijdige capaciteitslagen

Vanaf oktober 2023 heeft de elastische taakagent meerdere prestatielagen om de capaciteit te vergroten.

Capaciteitsverhogingen geven het totale aantal gelijktijdige doeldatabases aan waarmee de taakagent verbinding kan maken en een taak kan starten. Voor meer gelijktijdige doelverbindingen voor taakuitvoering voert u een upgrade uit van de laag van een taakagent vanuit de standaard JA100-laag, met een limiet van 100 gelijktijdige doelverbindingen.

De meeste omgevingen vereisen op elk gewenst moment minder dan 100 gelijktijdige taken, dus JA100 is de standaardinstelling.

Laag voor elastische taakagent	Maximum aantal gelijktijdige taken
JA100	100
JA200	200
JA400	400
JA800	800

Als u de capaciteitslaag voor gelijktijdigheid van de taakagent overschrijdt met taakdoelen, worden wachtrijvertragingen voor sommige doeldatabases/-servers gemaakt. Als u bijvoorbeeld een taak met 110 doelen in de JA100-laag start, wachten 10 taken totdat anderen klaar zijn.

De laag of servicedoelstelling van een elastische-taakagent kan worden gewijzigd via Azure Portal, PowerShell of de REST API voor taakagents. Zie De taakagent schalen voor een voorbeeld.

Invloed van taken op elastische pools beperken

Om ervoor te zorgen dat resources niet overbelast raken bij het uitvoeren van taken op databases in een elastische Pool van Azure SQL Database, kunnen taken worden geconfigureerd om het aantal databases te beperken waarop een taak tegelijkertijd kan worden uitgevoerd.

Stel het aantal gelijktijdige databases in waarop een taak wordt uitgevoerd door de parameter van @max_parallelism de sp_add_jobstep opgeslagen procedure in te stellen in T-SQL.

Idempotente scripts

De T-SQL-scripts van een elastische taak moeten idempotent zijn. Idempotent betekent dat als het script slaagt en het opnieuw wordt uitgevoerd, hetzelfde resultaat optreedt. Een script kan mislukken vanwege tijdelijke netwerkproblemen. In dat geval wordt automatisch een vooraf ingesteld aantal keer opnieuw geprobeerd om de taak uit te voeren alvorens het wordt afgebroken. Een idempotent script heeft hetzelfde resultaat, zelfs als het twee keer (of meer) is uitgevoerd.

Een eenvoudige tactiek is te testen of een object bestaat voordat u het maakt. Hier volgt een hypothetisch voorbeeld:

IF NOT EXISTS (SELECT * FROM sys.objects WHERE [name] = N'some_object')
    print 'Object does not exist'
    -- Create the object
ELSE
    print 'Object exists'
    -- If it exists, drop the object before recreating it.

Op dezelfde manier moet een script met succes kunnen worden uitgevoerd door logisch te testen op problemen en hierop te reageren.

Beperkingen

Dit zijn de huidige beperkingen voor de service voor elastische taken. We werken er actief aan om zoveel mogelijk van deze beperkingen te verwijderen.

Probleem	Beschrijving
De elastische-taakagent moet opnieuw worden gemaakt en gestart in de nieuwe regio na een failover/verplaatsing naar een nieuwe Azure-regio.	De service voor elastische taken slaat alle bijbehorende taakagents en taakmetagegevens op in de takendatabase. Elke failover of verplaatsing van Azure-resources naar een nieuwe Azure-regio verplaatst ook de takendatabase, taakagent en taakmetagegevens naar de nieuwe Azure-regio. De elastische-taakagent is echter een alleen rekenresource en moet expliciet opnieuw worden gemaakt en gestart in de nieuwe regio voordat taken opnieuw worden uitgevoerd in de nieuwe regio. Zodra de elastische-taakagent is gestart, worden de taken in de nieuwe regio hervat volgens de eerder gedefinieerde taakplanning.
Overmatige auditlogboeken uit de database met taken	De elastische-taakagent werkt door voortdurend de taakdatabase te peilen om te controleren op de komst van nieuwe taken en andere CRUD-bewerkingen. Als controle is ingeschakeld op de server die een takendatabase bevat, kan een groot aantal auditlogboeken worden gegenereerd door de takendatabase. Dit kan worden verzacht door deze auditlogboeken te filteren met behulp van de Set-AzSqlServerAudit opdracht met een predicaatexpressie. Voorbeeld: Set-AzSqlServerAudit -ResourceGroupName "ResourceGroup01" -ServerName "Server01" -BlobStorageTargetState Enabled -StorageAccountResourceId "/subscriptions/7fe3301d-31d3-4668-af5e-211a890ba6e3/resourceGroups/resourcegroup01/providers/Microsoft.Storage/storageAccounts/mystorage" -PredicateExpression "database_principal_name <> '##MS_JobAccount##'" Met deze opdracht wordt taakagent alleen gefilterd op auditlogboeken van takendatabases, niet op taakagents in auditlogboeken van doeldatabases.
Gebruik van een Hyperscale-database als taakdatabase	Het gebruik van een Hyperscale-database als een taakdatabase wordt niet ondersteund. Elastische taken kunnen hyperscale-databases echter op dezelfde manier richten als elke andere database in Azure SQL Database.
Serverloze databases en automatisch onderbreken met elastische taken.	Serverloze database met automatisch onderbreken wordt niet ondersteund als een taakdatabase. Serverloze databases waarop elastische taken betrekking hebben, ondersteunen automatisch onderbreken en worden hervat door taakverbindingen.
Een taakdatabase exporteren naar een BACPAC-bestand	Het exporteren van een taakdatabase naar een BACPAC-bestand wordt niet ondersteund. Als de SQL Server met een taakdatabase moet worden geëxporteerd, moet de taakdatabase eerst worden verwijderd voordat u de server exporteert.

Gerelateerde inhoud

• Elastische taken maken, configureren en beheren (preview)
• Beheertaken automatiseren in Azure SQL
• Elastische taken maken en beheren met behulp van PowerShell (preview)
• Elastische taken maken en beheren met behulp van T-SQL (preview)

Volgende stap

Zelfstudie: Elastische taken maken, configureren en beheren (preview)