Elastische jobs in Azure SQL Database

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.

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 (T-SQL)-query's uit te voeren en onderhoudstaken uit te voeren.

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

Een job handelt het inloggen bij de doeldatabase af. U definieert, onderhoudt en behoudt ook Transact-SQL scripts die moeten worden uitgevoerd 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

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.
  • Het verzamelen van prestatiegegevens, of tenanttelemetrieverzameling (klant).
  • 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 die moeten worden uitgevoerd.
• Gegevens verzamelen voor rapportage
  • Gegevens uit een verzameling databases aggregeren in één doeltabel.
  • Voer langer lopende query's voor gegevensverwerking uit in een grote set databases, bijvoorbeeld de verzameling telemetrie van klanten. Resultaten worden verzameld in een enkele doeltabel 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, 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.
  • 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	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 voor het opslaan van taakgerelateerde gegevens, taakdefinities, enzovoort.
Taak	Een taak is een werkeenheid die bestaat uit een of meer taakstappen. Taakstappen geven het T-SQL-script op dat moet worden uitgevoerd, evenals andere details die nodig zijn om het script uit te voeren.
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. De elastische-taakagent is een Azure-resource die u in de portal maakt (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. Voor de kosten van de Elastic Job Agent zijn deze gebaseerd op de vaste prijzen van de servicelaag die is geselecteerd voor de taakagent. Zie de pagina met prijzen voor 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.

Een Azure SQL Database is vereist om een elastische taakagent te maken. JobAgent 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 taak(en): 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 wordt de taakdatabase net als elke andere doeldatabase behandeld. De taakgebruiker moet worden aangemaakt en voldoende machtigingen krijgen in de taakdatabase, en de database-specifieke referenties voor de taakgebruiker moeten ook aanwezig zijn in de taakdatabase, zoals dat ook geldt voor elke andere doeldatabase.

Wanneer taakdatabase zelf een doel van een taak is, moet u ervoor zorgen dat uw taken geen specifieke metagegevens van de taakagent wijzigen/verwijderen die zijn opgeslagen in die database. Alleen taakprocedures of taakweergaven moeten worden gebruikt voor het wijzigen/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 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, 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 waarop een taakstap wordt uitgevoerd. Een doelgroep kan een willekeurig aantal en een combinatie van het volgende bevatten:

• Logische SQL-server : als er een server is opgegeven, maken alle databases op het moment van de taakuitvoering 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 logische server in Azure SQL Database en Azure Synapse voor meer informatie over logische servers?
• Elastische pool : als er een elastische pool is opgegeven, maken alle databases in de elastische pool op het moment van de taakuitvoering 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 die deel uitmaken van de groep.

Aanbeveling

Op het moment van de taakuitvoering evalueert 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 opgegeven als opgenomen of uitgesloten van de groep. Hiermee kunt u 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 wordt uitgevoerd met behulp van deze doelgroep, 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 wordt uitgevoerd met deze doelgroep, wordt de server dynamisch geïnventariseerd om de lijst met databases te bepalen die zich momenteel op de server bevinden. De actie van 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 uitvoering 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 cloudproducten en zijn ontworpen om te beginnen, zelfs als er een tijdelijk netwerk- of servicebeschikbaarheidsprobleem 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 planning voor elastische taken maakt, wordt de taak zo snel mogelijk uitgevoerd na elke geplande interval-gebeurtenis.

Belangrijk

Maak als best practice taakplanningen die in de toekomst beginnen.

Taakplanningen hebben gemiste gebeurtenissen gedetecteerd. 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 9uUTC. U hebt een nieuwe taak ingesteld met een geplande starttijd van vanavond, 2 januari om 10:30 u UTC, die dagelijks wordt uitgevoerd. De taak wordt uitgevoerd om 10:30 pmUTC.

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:30uUTC uit te voeren. U schakelt de taak voor een week uit. Als u vervolgens de taak inschakelt op 8:30 uurUTC, wordt de taak onmiddellijk uitgevoerd, waarbij de gebeurtenis van het gemiste interval die gisteravond moet worden uitgevoerd, wordt ingehaald. Nadat deze is uitgevoerd, zal de taak-agent pas opnieuw worden uitgevoerd wanneer de volgende geplande uitvoering om 10:30 pm UTC plaatsvindt. Als u wilt voorkomen dat de taak wordt uitgevoerd om 8:30 uurUTC in dit scenario, werkt u het begin van de taakplanning bij tot 8 januari om 10:30UTC 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 om database-georiënteerde referenties te gebruiken en een andere om Microsoft Entra ID-verificatie te gebruiken.

De elastische taakagent kan verbinding maken met de servers/databases 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 database-gecentreerde referenties.

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 microsoft Entra ID-ondersteuning maakt de taakagent verbinding met doeldatabases (databases, servers, elastische pools) en uitvoerdatabase 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-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, 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 database-gespecificeerde referenties de enige authenticatieoptie.

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 een login hebben met voldoende machtigingen voor het succesvol voltooien van de taak (in het volgende diagram).
• Referenties die in doeldatabases (LOGIN en PASSWORD voor masteruser en jobuser, in het volgende diagram) zijn aangemaakt, moeten overeenkomen met de IDENTITY en SECRET in de referenties die in de taakdatabase zijn aangemaakt.
• 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.

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-/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. Eén voorbehoud is dat als u de banen-database als doelgroeplid toevoegt. 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. Beheerders kunnen gebruikers de mogelijkheid bieden om taakuitvoering te controleren door ze toe te voegen aan de jobs_reader rol in de taakdatabase.

Rolnaam	jobs schemamachtigingen	jobs_internal schemamachtigingen
jobs_reader	SELECT	Geen

Waarschuwing

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 falen. Deze weergaven zijn alleen bedoeld voor alleen-lezen query'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

De elastische taakagent heeft 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. Op de overzichtspagina van de elastische taakagent worden de meest recente taakuitvoeringen weergegeven, zoals 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

Bekijk de uitvoeringsgeschiedenis van elastische taken in de taakdatabase 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 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.

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.
• Referenties moeten de minste bevoegdheden hebben die nodig zijn om de taakstap uit te voeren. Zie Autorisatie en machtigingen voor meer informatie.
• Wanneer u een server en/of pooldoelgroeplid gebruikt, wordt u ten zeerste aangeraden een aparte referentie aan te maken met rechten voor de master database om databases weer te geven die worden gebruikt om de databaselijsten van de servers en/of pools uit te breiden voor de uitvoering van de taak.

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

Elastische taakagentlaag	Maximum aantal gelijktijdige taken
JA100	100
JA200	200
JA400	400
JA800	800

Als u de capaciteitslaag voor gelijktijdigheid van de taakagent overschrijdt met taakdoelen, zal dit wachtrijvertragingen veroorzaken voor sommige doeldatabases/-servers. Als u bijvoorbeeld een taak met 110 doelen in de JA100-laag start, wachten 10 doelen 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.

Beperk de invloed van een taak op elastische pools

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 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. 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 zal de taak automatisch een vastgesteld aantal keren proberen het script opnieuw 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. 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 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. We werken er actief aan om zoveel mogelijk van deze beperkingen te verwijderen.

Probleem	Description
De Elastic Job Agent moet opnieuw worden gemaakt en gestart in de nieuwe regio na een failover of 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 jobagent is gestart, zal hij de taken in de nieuwe regio hervatten volgens het eerder gedefinieerde jobrooster.
Overmatige auditlogboeken uit de taakdatabase	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 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 "application_name <> 'Microsoft Azure SQL Database elastic jobs'" Met deze opdracht worden alleen taakagentactiviteiten naar auditlogboeken van takendatabases gefilterd, niet naar 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 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 waarop elastische taken betrekking hebben, ondersteunen automatisch pauzeren 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.

Verwante inhoud

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

Volgende stap

Zelfstudie: Elastische taken maken, configureren en beheren