Elastische jobs in Azure SQL Database

Van toepassing op:Azure SQL Database

In dit artikel worden de mogelijkheden en details van elastische taken voor Azure SQL Database besproken.

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

Overzicht van elastische taken

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

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

Een job voert de taak van authenticatie naar de doeldatabase uit. U definieert, onderhoudt en slaat Transact-SQL-scripts op om uit te voeren in een groep databases.

Elke taak registreert de status van de uitvoering en probeert de bewerkingen automatisch opnieuw als er een fout optreedt.

Wanneer u elastische taken gebruikt

Gebruik automatisering van elastische taken in de volgende scenario's:

• Automatiseer beheertaken en plan ze elke weekdag of na kantooruren uit te voeren, bijvoorbeeld.
  • Schemawijzigingen implementeren en referenties beheren.
  • Prestatiegegevens of tenantlogboeken (klantlogboeken) verzamelen.
  • Referentiegegevens bijwerken (informatie die gebruikelijk is voor alle databases).
  • Gegevens laden uit Azure Blob Storage.
• Configureer taken voor uitvoering in een verzameling databases op terugkerende basis, zoals tijdens daluren.
  • Verzamel doorlopend queryresultaten van een set databases in een centrale tabel.
  • Query's kunnen voortdurend worden uitgevoerd en geconfigureerd om extra taken te activeren.
• Gegevens verzamelen voor rapportage
  • Gegevens uit een verzameling databases aggregeren in één doeltabel.
  • Voer gegevensverwerkingsquery's uit in een grote set databases, bijvoorbeeld de verzameling klantlogboeken. Resultaten worden verzameld in een enkele doeltabel voor verdere analyse.
• Gegevensverplaatsing
  • Voor aangepaste ontwikkelde oplossingen, bedrijfsautomatisering of ander taakbeheer.
  • ETL-verwerking voor het extraheren, transformeren en laden 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 één keer 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, meerdere pools en kunnen zelfs worden uitgevoerd op databases in verschillende abonnementen. Servers en pools worden dynamisch geïnventariseerd tijdens runtime, zodat taken worden uitgevoerd op alle databases die aanwezig zijn in de doelgroep op het moment van uitvoering.

  • Deze mogelijkheid is een aanzienlijke differentiatie van SQL Agent, die de doeldatabases niet dynamisch kan inventariseren, met name in SaaS-klantscenario's waarbij databases dynamisch worden toegevoegd of verwijderd.

Onderdelen van elastische taken

Onderdeel	Description
Elastic job-agent	De Azure-resource die u maakt om taken uit te voeren en te beheren.
Vacaturedatabase	Een database in Azure SQL Database die door de taakagent wordt gebruikt om taakgerelateerde gegevens, taakdefinities en meer op te slaan.
Taak	Een taak is een werkeenheid die bestaat uit een of meer taakstappen. Taakstappen geven het T-SQL-script op dat moet worden uitgevoerd en andere vereiste details.
Doelgroep	De verzameling van servers, pools en databases waarop een taak kan worden uitgevoerd.

Elastische taakagent

Een elastische taakagent is de Azure-resource voor het maken, uitvoeren en beheren van taken. U maakt de elastische-taakagent als een Azure-resource in de portal (Elastische taken maken en beheren met behulp van 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 taakdatabase wordt gefactureerd tegen hetzelfde tarief als elke database in Azure SQL Database. De kosten van de elastische taakagent zijn gebaseerd op de vaste prijsstelling van de servicelaag die u selecteert voor de taakagent. Zie de pagina met prijzen voor Azure SQL Database voor meer informatie.

Elastische taakdatabase

Gebruik de taakdatabase om taken te definiëren en de status en geschiedenis van taakuitvoeringen bij te houden. Taken worden uitgevoerd in doeldatabases. De taakdatabase slaat ook metagegevens van agents, logboeken, resultaten en taakdefinities op. Het bevat veel nuttige opgeslagen procedures en andere databaseobjecten voor het maken, uitvoeren en beheren van taken met behulp van T-SQL.

U hebt een Azure SQL Database nodig om een elastische taakagent te maken. De taakagent slaat alle taakgerelateerde metagegevens op in de taakdatabase. Dit moet een nieuwe, lege Azure SQL Database zijn.

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

Als bewerkingen voor de taakdatabase langzamer zijn dan verwacht, controleert u de databaseprestaties en het resourcegebruik in de taakdatabase tijdens perioden van traagheid met behulp van Azure Portal of de sys.dm_db_resource_stats DMV. Als het gebruik van een resource, zoals CPU, Gegevens-I/O of Logboekschrijven 100% nadert en correleert met perioden van traagheid, kunt u overwegen de database stapsgewijs te schalen naar hogere servicedoelstellingen (hetzij in het aankoopmodel op basis van DTU of in het aankoopmodel van vCore) totdat de prestaties van de taakdatabase voldoende zijn verbeterd.

De taakdatabase zelf kan het doel zijn van een elastische taak. In dit scenario behandelt u de taakdatabase net als elke andere doeldatabase. U moet de taakgebruiker maken en voldoende machtigingen verlenen in de taakdatabase. De databasereferenties voor de taakgebruiker moeten ook aanwezig zijn in de taakdatabase, net als voor andere doeldatabases.

Wanneer de taakdatabase een doel van een taak is, moet u ervoor zorgen dat uw taken geen specifieke metagegevens van de taakagent wijzigen of verwijderen die zijn opgeslagen in die database. Gebruik alleen opgeslagen procedures of taakweergaven voor het wijzigen of opvragen van taakgerelateerde informatie.

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 volgens een planning of als een eenmalige taak wordt uitgevoerd. Een taak bestaat uit een of meer taakstappen.

Elke taakstap geeft een T-SQL-script op dat moet worden uitgevoerd, een of meer doelgroepen waarop het T-SQL-script moet worden uitgevoerd en de referenties waarmee de taakagent verbinding moet maken met de doeldatabase. Elke taakstap heeft aanpasbare time-out en beleid voor opnieuw proberen en kan eventueel uitvoerparameters opgeven.

Doelen voor elastische taken

Elastische taken kunnen een of meer T-SQL-scripts parallel uitvoeren, in 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 of 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 op databases in verschillende abonnementen. Servers en pools worden dynamisch geïnventariseerd tijdens runtime, zodat taken worden uitgevoerd op alle databases die aanwezig zijn in de doelgroep op het moment van uitvoering.

In de volgende afbeelding ziet u een taakagent die taken uitvoert voor de verschillende typen doelgroepen:

Doelgroep

Een doelgroep definieert de set databases waarin een taakstap wordt uitgevoerd. Een doelgroep kan een willekeurig aantal en een combinatie van de volgende typen bevatten:

• Logische SQL-server: als u een server opgeeft, maken alle databases op het moment van de taakuitvoering deel uit van de groep. U moet de master databasereferentie opgeven, zodat de groep kan worden geïnventariseerd en bijgewerkt voordat de taak wordt uitgevoerd. Zie Wat is een logische server in Azure SQL Database en Azure Synapse voor meer informatie over logische servers?

• Elastische pool: als u een elastische pool opgeeft, maken alle databases die zich op het moment van de taakuitvoering bevinden deel uit van de groep. Net als bij een server moet u de master databasereferentie opgeven, zodat de groep kan worden bijgewerkt voordat de taak wordt uitgevoerd.

• Individuele database: geef een of meer afzonderlijke databases op die deel uitmaken van de groep.

Aanbeveling

Op het moment van taakuitvoering herwaardeert dynamische inventarisatie de set databases in doelgroepen die servers of pools bevatten. Dynamische inventarisatie zorgt ervoor dat taken worden uitgevoerd op alle databases die aanwezig zijn op de server of pool op het moment van taakuitvoering. Het opnieuw evalueren van de lijst met databases tijdens runtime is handig voor scenario's waarbij groep- of serverlidmaatschap regelmatig wordt gewijzigd.

Pools en individuele databases kunnen worden opgenomen of uitgesloten van de groep. U kunt een doelgroep maken met elke combinatie van databases. U kunt bijvoorbeeld een server toevoegen aan een doelgroep, maar specifieke databases uitsluiten in een elastische pool (of een hele pool uitsluiten).

Een doelgroep kan databases in meerdere abonnementen en in 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 definities van doelgroepen dynamisch worden geïnventariseerd op het moment van taakuitvoering om te bepalen welke databases moeten worden beïnvloed:

• In voorbeeld 1 ziet u een doelgroep die bestaat uit een lijst met afzonderlijke databases. Wanneer een taakstap deze doelgroep gebruikt, wordt de actie van de taakstap uitgevoerd in elk van deze databases.

• Voorbeeld 2 toont een doelgroep die een server als doel bevat. Wanneer een taakstap deze doelgroep gebruikt, wordt de server dynamisch geïnventariseerd om de lijst met databases te bepalen die zich momenteel op de server bevinden. De taakstap wordt uitgevoerd in elk van deze databases.

• Voorbeeld 3 toont een vergelijkbare doelgroep als voorbeeld 2, maar een afzonderlijke database is specifiek uitgesloten. De actie van de taakstap wordt niet uitgevoerd in de uitgesloten database.

• Voorbeeld 4 toont een doelgroep die een elastische pool als doel bevat. Net als bij voorbeeld 2 wordt de pool dynamisch geïnventariseerd tijdens de runtime 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.

Planningen voor elastische taken

Elastische taken zijn cloud-first producten. Ze zijn ontworpen om te beginnen, zelfs als er een tijdelijk netwerk- of service-beschikbaarheidsprobleem optreedt wanneer ze worden gepland. Schema's voor elastische taken houden rekening met de begintijd van de planning en de aangevraagde intervallen. Wanneer u een elastische taakplanning maakt, wordt de taak uitgevoerd zo snel mogelijk na elke geplande interval.

Belangrijk

Maak als best practice taakplanningen die in de toekomst beginnen.

Taakplanningen detecteren gemiste gebeurtenissen. Als u een nieuw taakschema maakt dat in het verleden begint, wordt de taak onmiddellijk uitgevoerd wanneer deze is ingeschakeld. Als deze optie is uitgeschakeld of anderszins niet beschikbaar is, wordt de taak direct uitgevoerd nadat deze is ingeschakeld of beschikbaar is.

Het is bijvoorbeeld momenteel 2 januari 9:00 UUR UTC. U hebt een nieuwe taak ingesteld met als geplande starttijd vanavond, 2 januari om 10:30 uur (UTC), die dagelijks wordt uitgevoerd. De taak wordt uitgevoerd om 10:30 uur (UTC).

Als u wilt voorkomen dat een taak per ongeluk wordt gestart, maakt u planningen die in de toekomst beginnen. In een voorbeeld dat kan leiden tot een onbedoelde start van een taak, stelt u een nieuwe taak in om dagelijks om 10:30 UUR UTC uit te voeren. U schakelt de taak voor een week uit. Als u de taak vervolgens om 8:30 uur UTC inschakelt, wordt de taak onmiddellijk uitgevoerd om het gemiste interval van gisteravond in te halen. Nadat de taak is uitgevoerd, wordt de taakagent niet opnieuw uitgevoerd tot de volgende geplande uitvoering om 10:30 uur UTC. Als u wilt voorkomen dat de taak wordt uitgevoerd om 8:30 UUR UTC in dit scenario, werkt u het begin van de taakplanning bij tot 8 januari om 10:30 UTC en schakelt u de taak vervolgens in. Of u kunt de taak inschakelen wanneer deze direct kan worden uitgevoerd.

Authenticatie

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 in het databasebereik en een andere voor het gebruik van Microsoft Entra ID-verificatie.

De elastische taakagent kan verbinding maken met de servers en databases die zijn opgegeven door de doelgroep met behulp van twee verificatieopties:

• Gebruik Microsoft Entra-verificatie (voorheen Azure Active Directory) met een door de gebruiker toegewezen beheerde identiteit (UMI).
• Gebruik database-gecentreerde referenties.

Verificatie via door de gebruiker toegewezen beheerde identiteit (UMI)

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

U kunt eventueel Microsoft Entra ID-verificatie inschakelen op de logische server die de elastische taakdatabase bevat, voor toegang tot en query's op die database via Microsoft Entra ID-verbindingen. De taakagent 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. Elke taakagent ondersteunt slechts één UMI. Nadat u een UMI aan een taakagent hebt toegewezen, gebruikt de taakagent deze identiteit om T-SQL-taken te verbinden en uit te voeren op de doeldatabases. De taakagent gebruikt geen SQL-verificatie voor de doelserver of databases.

De UMI-naam moet beginnen met een letter of een getal en een lengte hebben tussen 3 en 128 tekens. Het kan afbreekstreepjes () en onderstrepingstekens (-_) bevatten.

Zie Beheerde identiteiten voor Azure SQL voor meer informatie over UMI in Azure SQL Database, inclusief de vereiste stappen en voordelen van het gebruik van een UMI als de logische serveridentiteit van Azure SQL Database. Zie Microsoft Entra-verificatie voor Azure SQL 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, kunt u taken configureren voor het gebruik van referenties binnen het databasebereik om verbinding te maken met de databases die door de doelgroep zijn opgegeven na uitvoering. Vóór oktober 2023 waren database-gespecificeerde referenties de enige authenticatieoptie.

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

• Maak de database-inloggegevens aan in de job-database.

• Alle doeldatabases moeten een login hebben met voldoende machtigingen voor het succesvol voltooien van de taak (in het volgende diagram).

• De referenties die u maakt in doeldatabases (LOGIN en PASSWORD voor masteruser en jobuser, in het volgende diagram) moeten overeenkomen met de IDENTITY referenties SECRET die u in de taakdatabase maakt.

• U kunt referenties voor alle taken opnieuw gebruiken. Referentieswachtwoorden worden versleuteld en beveiligd tegen gebruikers die alleen-lezentoegang hebben tot taakobjecten.

De volgende afbeelding helpt u te begrijpen hoe u de juiste taakreferenties instelt en hoe de elastische taakagent verbinding maakt met behulp van databasereferenties als verificatie voor aanmeldingen en gebruikers in doelservers en databases.

Opmerking

Wanneer u database-specifieke referenties gebruikt, moet u een jobuser gebruiker aanmaken 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- en uitvoerservers, zodat de taakagent deze kan bereiken, zelfs wanneer de optie Openbare toegang weigeren is ingeschakeld. Het gebruik van privé-eindpunten is ook een mogelijke oplossing als u wilt uitschakelen dat Azure-services en -resources toegang hebben tot die serveroptie .

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- en 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- en uitvoerservers van uw taakagent, maakt Azure een door de service beheerd privé-eindpunt. 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- en uitvoerdatabases.

U kunt privé-eindpunten voor elastische taken maken en toestaan 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 of databases worden gehost in Azure (dezelfde of verschillende regio's) en in hetzelfde cloudtype (bijvoorbeeld zowel in de openbare cloud als in beide in de overheidscloud).

• De Microsoft.Network resourceprovider moet worden geregistreerd voor de hostabonnementen van zowel de taakagent als de doel- en uitvoerservers.

• Azure maakt privé-eindpunten voor elastische taken per doel- en uitvoerserver. U moet ze goedkeuren voordat de elastische taakagent ze kan gebruiken. U kunt ze goedkeuren via het deelvenster Netwerken van die logische server of uw voorkeursclient. Vervolgens kan de elastische taakagent alle databases onder die server bereiken met behulp van een privéverbinding.

• De verbinding van de elastische-taakagent met de taakdatabase 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.

  • Als u de taakdatabank toevoegt als lid van de doeldatabasegroep, gedraagt deze zich als een regulier doel. U moet configureren met een privé-eindpunt indien nodig.

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. Beheerders kunnen gebruikers de mogelijkheid bieden om taakuitvoering te bewaken door ze toe te voegen aan de jobs_reader rol in de taakdatabase.

Rolnaam	jobs schemamachtigingen	jobs_internal schemamachtigingen
jobs_reader	SELECT	Geen

Waarschuwing

Werk interne catalogusweergaven niet bij in de taakdatabase, zoals jobs.target_group_members. Als u deze catalogusweergaven handmatig wijzigt, kan de taakdatabase beschadigd raken en falen. Deze weergaven zijn alleen bedoeld voor alleen-lezen query's. U kunt de opgeslagen procedures in uw taakdatabase gebruiken om doelgroepen en leden toe te voegen of te verwijderen, zoals jobs.sp_add_target_group_member.

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 een opgeslagen referentie gebruikt om verbinding te maken met een database onder het beheer van de kwaadwillende gebruiker. Met dit beveiligingsprobleem kan de kwaadwillende gebruiker het wachtwoord van de referentie bepalen of schadelijke opdrachten uitvoeren.

Elastische taken bewaken

De elastische taakagent kan worden geïntegreerd met Azure-waarschuwingen voor taakstatusmeldingen, waardoor de oplossing voor het bewaken van de status en geschiedenis van de taakuitvoering wordt vereenvoudigd.

Azure Portal bevat extra functies voor het ondersteunen van elastische taken en taakbewaking. Op de overzichtspagina van de elastische taakagent worden de meest recente taakuitvoeringen weergegeven, zoals wordt weergegeven in de volgende schermopname.

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 voor een voorbeeld.

Taakuitvoer

Het resultaat van de stappen van een taak op elke doeldatabase wordt gedetailleerd vastgelegd en scriptuitvoer kan worden vastgelegd in een opgegeven tabel. U kunt een database opgeven om gegevens op te slaan die worden geretourneerd door een taak.

Taakgeschiedenis

U kunt de uitvoeringsgeschiedenis van elastische taken in de taakdatabase weergeven door een query uit te voeren op de tabel jobs.job_executions. Met een systeemopruimingstaak wordt de uitvoeringsgeschiedenis verwijderd die ouder is dan 45 dagen. Als u de geschiedenis wilt verwijderen die minder dan 45 dagen oud is, 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.

Beste praktijken

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

Aanbevolen procedures voor beveiliging

• Beperk het gebruik van de API's aan vertrouwde personen.

• Verleen referenties de minimaal vereiste bevoegdheden om een taakstap uit te voeren. Zie Autorisatie en machtigingen voor meer informatie.

• Wanneer u een lid van een server- of pooldoelgroep gebruikt, maakt u afzonderlijke referentiegegevens met rechten voor de master database om databases te bekijken en op te sommen. Met deze referentie worden de databaselijsten van de servers en pools uitgebreid voordat de taak wordt uitgevoerd.

Prestaties van elastische taakuitvoering

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 capaciteitsniveaus

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. Als u meer gelijktijdige doelverbindingen wilt ophalen voor taakuitvoering, moet u de laag van een taakagent bijwerken 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.

Elastische taakagent-laag	Maximum aantal gelijktijdige taken
JA100	100
JA200	200
JA400	400
JA800	800

Het overschrijden van de gelijktijdigheidslimiet van de taakagent met taakdoelstellingen veroorzaakt wachttijdvertragingen bij bepaalde doeldatabases en -servers. Als u bijvoorbeeld een taak met 110 doelen in de JA100-laag start, wachten 10 doelen totdat anderen klaar zijn.

U kunt de laag of servicedoelstelling van een elastische-taakagent wijzigen via Azure Portal, PowerShell of de REST API van Job Agents. Zie De taakagent schalen voor een voorbeeld.

Beperk de taakbelasting voor elastische pools

Als u ervoor wilt zorgen dat resources niet overbelast zijn bij het uitvoeren van taken op databases in een elastische pool van Azure SQL Database, configureert u taken om het aantal databases te beperken waarop een taak tegelijkertijd wordt uitgevoerd.

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

Idempotente scripts

De T-SQL-scripts van een elastische taak moeten idempotent zijn. Als het script slaagt en opnieuw wordt uitgevoerd, treedt hetzelfde resultaat op. Een script kan mislukken vanwege tijdelijke netwerkproblemen. In dat geval probeert de taak het script automatisch een vooraf ingesteld aantal keren uit te voeren voordat het stopt. Een idempotent script heeft hetzelfde resultaat, zelfs als het twee keer (of meer) is uitgevoerd.

Een eenvoudige tactiek is om te testen op het bestaan van een object voordat u het maakt. Het volgende voorbeeld is hypothetisch:

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 in staat zijn succesvol te worden uitgevoerd door logisch te testen op en elke toestand die het tegenkomt tegen te gaan.

Beperkingen

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

Probleem	Description
De elastische taakagent moet na een failover of het overstappen naar een nieuwe Azure-regio opnieuw worden gemaakt en gestart in de nieuwe 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 taakdatabase, taakagent en taakmetagegevens naar de nieuwe Azure-regio. De elastische taakagent is echter een alleen rekenresource die expliciet opnieuw gemaakt en gestart moet worden in het nieuwe gebied voordat taken opnieuw worden uitgevoerd. Zodra de elastische taakagent is gestart, worden de taken in de nieuwe regio hervat volgens het eerder gedefinieerde taakrooster.
Overmatige SQL-auditlogboeken uit de jobdatabase	De elastische taakagent werkt door voortdurend de taakdatabase te controleren op de aanwezigheid van nieuwe taken en andere CRUD-bewerkingen. Als controle is ingeschakeld op de server die een takendatabase bevat, kan de database met taken een groot aantal auditlogboeken genereren. U kunt dit probleem oplossen 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 "application_name <> 'Microsoft Azure SQL Database elastic jobs'" Met deze opdracht worden alleen de taakagent-auditlogboeken van de takendatabase gefilterd, niet die van de taakagent naar de doeldatabase-auditlogboeken.
Gebruik van een Hyperscale-database als taakdatabase	Het gebruik van een Hyperscale-database als een taakdatabase wordt niet ondersteund. Elastische taken kunnen echter hyperscale databases op dezelfde manier aanpakken 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 die voor elastische taken zijn bedoeld, ondersteunen automatisch pauzeren, en taakverbindingen hervatten de databases.
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 u de taakdatabase eerst verwijderen voordat u de server exporteert.

Volgende stap

Zelfstudie: Elastische taken maken, configureren en beheren

Verwante inhoud

• Beheertaken automatiseren in Azure SQL
• Elastische taken maken en beheren met behulp van PowerShell
• Elastische taken maken en beheren met behulp van T-SQL