Elastiska jobb i Azure SQL Database

gäller för:Azure SQL Database

Den här artikeln går igenom funktionerna och informationen om elastiska jobb för Azure SQL Database.

• En självstudiekurs om hur du konfigurerar elastiska jobb finns i självstudien om elastiska jobb.
• Läs mer om automatiseringsbegrepp på Azure-databasplattformar.

Översikt över elastiska jobb

Du kan skapa och schemalägga elastiska jobb som regelbundet körs mot en eller flera Azure SQL-databaser. Jobben kör Transact-SQL frågor (T-SQL) och utför underhållsaktiviteter.

Du kan definiera måldatabaser eller grupper av databaser där jobbet körs. Du kan också definiera scheman för att köra ett jobb. Alla datum och tider i elastiska jobb finns i UTC-tidszonen.

Ett jobb hanterar uppgiften att autentisera till måldatabasen. Du definierar, underhåller och bevarar även Transact-SQL skript som ska köras över en grupp databaser.

Varje jobb loggar körningens status och försöker automatiskt utföra åtgärderna igen om något fel inträffar.

När du ska använda elastiska jobb

Använd elastisk jobbautomatisering i följande scenarier:

• Automatisera hanteringsuppgifter och schemalägg dem så att de körs varje veckodag eller efter timmar, till exempel.
  • Distribuera schemaändringar och hantera autentiseringsuppgifter.
  • Samla in prestandadata eller klientloggar (kund).
  • Uppdatera referensdata (information som är gemensam för alla databaser).
  • Läs in data från Azure Blob Storage.
• Konfigurera jobb för att köras över en samling databaser regelbundet, till exempel utanför högtrafik.
  • Samla in frågeresultat från en uppsättning databaser till en central tabell kontinuerligt.
  • Frågor kan köras kontinuerligt och konfigureras för att utlösa ytterligare uppgifter.
• Samla in data för rapportering
  • Aggregera data från en samling databaser till en enda måltabell.
  • Kör databearbetningsfrågor i en stor uppsättning databaser, till exempel insamling av kundloggar. Resultaten samlas in i en enda måltabell för ytterligare analys.
• Dataförflyttning
  • För anpassade utvecklade lösningar, affärsautomatisering eller annan uppgiftshantering.
  • ETL-bearbetning för att extrahera, transformera och läsa in data mellan tabeller i en databas.

Överväg elastiska jobb när du:

• Ha en uppgift som måste köras regelbundet enligt ett schema som riktar sig till en eller flera databaser.

• Ha en uppgift som måste köras en gång, men över flera databaser.

• Behöver köra jobb mot valfri kombination av databaser: en eller flera enskilda databaser, alla databaser på en server, alla databaser i en elastisk pool, med den extra flexibiliteten att inkludera eller exkludera en specifik databas. Jobb kan köras över flera servrar, flera pooler och kan till och med köras mot databaser i olika prenumerationer. Servrar och pooler räknas upp dynamiskt under körning, så uppgifter körs mot alla databaser som finns i målsystemet vid exekveringstidpunkten.

  • Den här funktionen är en betydande skillnad från SQL Agent, som inte dynamiskt kan räkna upp måldatabaserna, särskilt i SaaS-kundscenarier där databaser läggs till eller tas bort dynamiskt.

Elastiska jobbkomponenter

Komponent	Description
Elastisk jobbagent	Den Azure-resurs som du skapar för att köra och hantera jobb.
Jobbdatabas	En databas i Azure SQL Database som jobbagenten använder för att lagra jobbrelaterade data, jobbdefinitioner med mera.
Jobb	Ett jobb är en arbetsenhet som består av ett eller flera jobbsteg. Jobbsteg anger T-SQL-skriptet som ska köras och annan nödvändig information.
Målgrupp	Den uppsättning servrar, pooler och databaser ett uppdrag ska köras mot.

Elastisk jobbagent

En elastisk jobbagent är Azure-resursen för att skapa, köra och hantera jobb. Du skapar den elastiska jobbagenten som en Azure-resurs i portalen (Skapa och hantera elastiska jobb med hjälp av PowerShell och REST API stöds också).

För att skapa en elastisk jobbagent krävs en befintlig databas i Azure SQL Database. Agenten konfigurerar den befintliga Azure SQL Database som jobbdatabas.

Du kan starta, inaktivera eller avbryta ett jobb via Azure-portalen. Med Azure-portalen kan du också visa jobbdefinitioner och körningshistorik.

Kostnaden för den elastiska jobbagenten

Jobbdatabasen faktureras med samma hastighet som alla databaser i Azure SQL Database. Kostnaden för den elastiska jobbagenten baseras på fast prissättning för den tjänstnivå som du väljer för jobbagenten. Mer information finns på sidan med priser för Azure SQL Database.

Elastisk jobbdatabas

Använd jobbdatabasen för att definiera jobb och spåra status och historik för jobbkörningar. Jobb körs i måldatabaser. Jobbdatabasen lagrar även agentmetadata, loggar, resultat och jobbdefinitioner. Den innehåller många användbara lagrade procedurer och andra databasobjekt för att skapa, köra och hantera jobb med hjälp av T-SQL.

Du behöver en Azure SQL Database för att skapa en elastisk jobbagent. Jobbagenten lagrar alla sina jobbrelaterade metadata i jobbdatabasen, som ska vara en ny, tom Azure SQL Database.

Det rekommenderade tjänstmålet för jobbdatabasen är DTU S1 eller högre, men det optimala valet beror på dina jobbs prestandabehov: antalet jobbsteg, antalet jobbmål och hur ofta jobb körs.

Om åtgärderna mot jobbdatabasen är långsammare än förväntat övervakar du databasprestanda och resursanvändningen i jobbdatabasen under perioder med långsamhet med hjälp av Azure-portalen eller sys.dm_db_resource_stats DMV. Om användningen av en resurs, till exempel CPU, data-I/O eller loggskrivning närmar sig 100% och korrelerar med perioder av långsamhet, bör du överväga att stegvis skala databasen till högre tjänstmål (antingen i den DTU-baserade inköpsmodellen eller i köpmodellen för virtuella kärnor) tills jobbdatabasens prestanda har förbättrats tillräckligt.

Själva jobbdatabasen kan vara målet för ett elastiskt jobb. I det här scenariot behandlar du jobbdatabasen precis som andra måldatabaser. Du måste skapa jobbanvändaren och bevilja tillräcklig behörighet i jobbdatabasen. Jobbanvändarens databasomfattande autentiseringsuppgifter måste också finnas i jobbdatabasen, precis som för andra måldatabaser.

När jobbdatabasen är ett mål för ett jobb kontrollerar du att dina jobb inte ändrar eller tar bort jobbagentspecifika metadata som lagras i databasen. Använd endast jobb lagrade procedurer eller jobbvyer för att ändra eller fråga jobbrelaterad information.

Viktigt!

Ändra inte befintliga objekt eller skapa nya objekt i jobbdatabasen, även om du kan läsa från tabellerna för rapportering och analys.

Elastiska jobb och jobbsteg

Ett jobb är en arbetsenhet som körs enligt ett schema eller som ett engångsjobb. Ett jobb består av ett eller flera jobbsteg.

Varje jobbsteg anger ett T-SQL-skript som ska köras, en eller flera målgrupper som T-SQL-skriptet ska köras mot och de autentiseringsuppgifter som jobbagenten måste ansluta till måldatabasen. Varje jobbsteg har anpassningsbara tidsgränser och återförsöksprinciper och kan också ange utdataparametrar.

Elastiska jobbmål

Elastiska jobb kan köra ett eller flera T-SQL-skript parallellt, över ett stort antal databaser, enligt ett schema eller på begäran. Målet kan vara vilken nivå som helst av Azure SQL Database.

Du kan köra schemalagda jobb mot valfri kombination av databaser: en eller flera enskilda databaser, alla databaser på en server eller alla databaser i en elastisk pool, med den extra flexibiliteten att inkludera eller exkludera en specifik databas. Jobb kan köras över flera servrar och flera pooler och kan till och med köras mot databaser i olika prenumerationer. Servrar och pooler räknas upp dynamiskt under körning, så uppgifter körs mot alla databaser som finns i målsystemet vid exekveringstidpunkten.

Följande bild visar en jobbagent som kör jobb i olika typer av målgrupper:

Målgrupp

En målgrupp definierar den uppsättning databaser där ett jobbsteg körs. En målgrupp kan innehålla valfritt tal och en kombination av följande typer:

• Logisk SQL-server: Om du anger en server är alla databaser som finns på servern vid tidpunkten för jobbkörningen en del av gruppen. Du måste ange master databasens autentiseringsuppgifter så att gruppen kan listas och uppdateras före jobbet. Mer information om logiska servrar finns i Vad är en logisk server i Azure SQL Database och Azure Synapse?

• Elastisk pool: Om du specificerar en elastisk pool så ingår alla databaser som finns i den elastiska poolen vid den tidpunkt då jobbet körs i gruppen. Precis som med en server måste du ange master databasens autentiserings-behörigheter så att gruppen kan uppdateras innan jobbet körs.

• Enskild databas: Ange en eller flera enskilda databaser som ska ingå i gruppen.

Tips/Råd

När jobbet körs omvärderar dynamisk uppräkning uppsättningen databaser i målgrupper som innehåller servrar eller pooler. Dynamisk uppräkning säkerställer att jobb körs över alla databaser som finns i servern eller poolen vid tidpunkten för jobbkörningen. Att omvärdera listan över databaser vid körning är användbart för scenarier där pool- eller servermedlemskap ändras ofta.

Pooler och enskilda databaser kan inkluderas eller exkluderas från gruppen. Du kan skapa en målgrupp med valfri kombination av databaser. Du kan till exempel lägga till en server i en målgrupp, men exkludera specifika databaser i en elastisk pool (eller exkludera en hel pool).

En målgrupp kan inkludera databaser i flera prenumerationer och i flera regioner. Exekveringar mellan regioner har högre svarstid än exekveringar inom samma region.

Följande exempel visar hur olika målgruppsdefinitioner listas dynamiskt när jobbet körs för att avgöra vilka databaser som ska påverkas.

• Exempel 1 visar en målgrupp som består av en lista över enskilda databaser. När ett jobbsteg använder den här målgruppen körs jobbstegets åtgärd i var och en av dessa databaser.

• Exempel 2 visar en målgrupp som innehåller en server som mål. När ett jobbsteg använder den här målgruppen räknas servern upp dynamiskt för att fastställa listan över databaser som för närvarande finns på servern. Jobbstegets åtgärd körs i var och en av dessa databaser.

• Exempel 3 visar en liknande målgrupp som Exempel 2, men en enskild databas är specifikt exkluderad. Jobbstegets åtgärd körs inte i den exkluderade databasen.

• Exempel 4 visar en målgrupp som innehåller en elastisk pool som mål. I likhet med exempel 2 räknas poolen upp dynamiskt vid jobbkörning för att fastställa listan över databaser i poolen.

• Exempel 5 och Exempel 6 visar avancerade scenarier där servrar, elastiska pooler och databaser kan kombineras med hjälp av inkludera och exkludera regler.

Elastiska jobbscheman

Elastiska jobb är molnbaserade produkter. De är utformade för att starta även om ett tillfälligt problem med nätverks- eller tjänsttillgänglighet uppstår när de schemaläggs. Elastiska jobbscheman tar hänsyn till schemats starttid och begärda intervall. När du skapar ett elastiskt jobbschema körs jobbet så snart som möjligt efter varje schemalagd intervallhändelse.

Viktigt!

Vi rekommenderar att du skapar jobbscheman som startar i framtiden.

Jobbscheman identifierar missade händelser. Om du skapar ett nytt jobbschema som börjar tidigare körs jobbet omedelbart när det är aktiverat. Om jobbet är inaktiverat eller inte är tillgängligt körs det omedelbart efter att det har aktiverats eller blivit tillgängligt.

Till exempel är det för närvarande 2 januari, 09:00 UTC. Du har konfigurerat ett nytt jobb så att det har schemalagd starttid ikväll, den 2 januari kl. 22:30 (UTC), och ska köras dagligen. Arbetet körs kl. 22:30 (UTC).

Om du vill förhindra att ett jobb startas av misstag skapar du scheman som startar i framtiden. I ett exempel som kan leda till en oavsiktlig jobbstart konfigurerar du ett nytt jobb som ska köras dagligen kl. 22:30 UTC. Du inaktiverar jobbet i en vecka. Om du sedan aktiverar jobbet kl. 08:30 UTC körs jobbet omedelbart och kommer ikapp den missade intervallhändelsen som skulle ha körts i går kväll. När den har körts körs inte jobbagenten igen förrän nästa schemalagda körning kl. 22:30 UTC. Om du vill förhindra att det körs kl. 08:30 UTC i det här scenariot, uppdatera schemats starttid till den 8 januari kl. 22:30 UTC och aktivera sedan jobbet. Eller sätt igång jobbet vid en tidpunkt då det kan köras omedelbart.

Authentication

Välj en metod för alla mål för en elastisk jobbagent. För en enda elastisk jobbagent kan du till exempel inte konfigurera en målserver för att använda databasomfattande autentiseringsuppgifter och en annan för att använda Microsoft Entra-ID-autentisering.

Den elastiska jobbagenten kan ansluta till de servrar och databaser som anges av målgruppen med två autentiseringsalternativ:

• Använd Microsoft Entra-autentisering (tidigare Azure Active Directory) med en användartilldelad hanterad identitet (UMI).
• Använd databasomfångsbegränsade autentiseringsuppgifter.

Autentisering via användartilldelad hanterad identitet (UMI)

Microsoft Entra-autentisering via användartilldelad hanterad identitet (UMI) är det rekommenderade alternativet för att ansluta elastiska jobb till Azure SQL Database. Med stöd för Microsoft Entra-ID ansluter jobbagenten till måldatabaser (databaser, servrar, elastiska pooler) och utdatadatabas med hjälp av UMI.

Du kan också aktivera Microsoft Entra-ID-autentisering på den logiska server som innehåller den elastiska jobbdatabasen för att få åtkomst till och köra frågor mot databasen via Microsoft Entra ID-anslutningar. Jobbagenten använder dock intern certifikatbaserad autentisering för att ansluta till sin jobbdatabas.

Du kan skapa en UMI eller använda en befintlig UMI och tilldela samma UMI till flera jobbagenter. Varje jobbagent stöder endast en UMI. När du har tilldelat en UMI till en jobbagent använder jobbagenten den här identiteten för att ansluta och köra T-SQL-jobb i måldatabaserna. Jobbagenten använder inte SQL-autentisering mot målservern eller databaserna.

UMI-namnet måste börja med en bokstav eller ett tal och ha en längd mellan 3 och 128 tecken. Den kan innehålla bindestreck (-) och understreck (_) tecken.

Mer information om UMI i Azure SQL Database finns i Hanterade identiteter för Azure SQL, inklusive de steg som krävs och fördelarna med att använda en UMI som den logiska Azure SQL Database-serveridentiteten. Mer information finns i Microsoft Entra-autentisering för Azure SQL.

Viktigt!

När du använder Microsoft Entra-ID-autentisering skapar du din jobuser användare från det Microsoft Entra-ID:t i varje måldatabas. Ge användaren de behörigheter som krävs för att köra dina jobb i varje måldatabas.

Det går inte att använda en systemtilldelad hanterad identitet (SMI).

Autentisering via databasomfattande autentiseringsuppgifter

Microsoft Entra-autentisering (tidigare Azure Active Directory) är det rekommenderade alternativet, men du kan konfigurera jobb att använda databasspecifika autentiseringsuppgifter för att ansluta till de databaser som specificerats av målgruppen vid körning. Före oktober 2023 var databasomfattande autentiseringsuppgifter det enda autentiseringsalternativet.

Om en målgrupp innehåller servrar eller pooler ansluter dessa databasomfångade autentiseringsuppgifter till master databasen för att räkna upp tillgängliga databaser.

• Skapa databasomfattande autentiseringsuppgifter i jobbdatabasen.

• Alla måldatabaser måste ha en inloggning med tillräcklig behörighet för att jobbet ska slutföras (jobuser i följande diagram).

• Den autentisering du skapar i måldatabaserna (LOGIN och PASSWORD för masteruser och jobuser, i följande diagram) ska stämma överens med IDENTITY och SECRET i autentiseringen du skapar i jobbdatabasen.

• Du kan återanvända autentiseringsuppgifter mellan jobb. Lösenord för autentiseringsuppgifter krypteras och skyddas från användare som har skrivskyddad åtkomst till jobbobjekt.

Följande bild hjälper dig att förstå hur du konfigurerar rätt jobbautentiseringsuppgifter och hur den elastiska jobbagenten ansluter med databasautentiseringsuppgifter som autentisering till inloggningar och användare i målservrar och databaser.

Anmärkning

När du använder databasomfångsbegränsade autentiseringsuppgifter bör du komma ihåg att skapa användaren jobuser i varje måldatabas.

Privata slutpunkter för elastiskt jobb

Den elastiska jobbagenten stöder privata slutpunkter för elastiska jobb. När du skapar en privat slutpunkt för elastiska jobb upprättas en privat länk mellan det elastiska jobbet och målservern. Funktionen för privata slutpunkter för elastiska jobb skiljer sig från Azure Private Link.

Funktionen privata slutpunkter för elastiska jobb stöder privata anslutningar till mål- och utdataservrar, så att jobbagenten kan nå dem även när alternativet Neka offentlig åtkomst är aktiverat. Att använda privata slutpunkter är också en möjlig lösning om du vill inaktivera alternativet Tillåt Azure-tjänster och resurser att komma åt den servern .

Privata slutpunkter för elastiska jobb stöder alla alternativ för autentisering med elastisk jobbagent.

Med den privata slutpunktsfunktionen för elastiska jobb kan du välja en tjänsthanterad privat slutpunkt för att upprätta en säker anslutning mellan jobbagenten och dess mål- och utdataservrar. En tjänsthanterad privat slutpunkt är en privat IP-adress i ett specifikt virtuellt nätverk och undernät. När du väljer att använda privata slutpunkter på en av jobbagentens mål- och utdataservrar skapar Azure en tjänsthanterad privat slutpunkt. Den här privata slutpunkten används sedan uteslutande av jobbagenten för att ansluta, köra jobb och skriva jobbutdata till mål- och utdatadatabaserna.

Du kan skapa och tillåta privata slutpunkter för elastiska jobb via Azure-portalen. Målservrar som är anslutna via den privata länken kan finnas var som helst i Azure, även i olika geografiska områden och prenumerationer. Du måste skapa en privat slutpunkt för varje önskad målserver och jobbutdataservern för att aktivera den här kommunikationen.

En självstudiekurs om hur du konfigurerar en ny tjänsthanterad privat slutpunkt för elastiska jobb finns i Konfigurera privata slutpunkter för elastiska Azure SQL-jobb.

Krav för privata slutpunkter för elastiska jobb

• Om du vill använda en privat slutpunkt för elastiska jobb måste både jobbagenten och målservrarna eller databaserna finnas i Azure (samma eller olika regioner) och i samma molntyp (till exempel både i det offentliga molnet eller i båda i myndighetsmolnet).

• Resursprovidern Microsoft.Network måste vara registrerad för värdprenumerationer för både jobbagenten och mål- och utdataservrarna.

• Azure skapar privata slutpunkter för elastiska jobb per mål- och utdataserver. Du måste godkänna dem innan den elastiska jobbagenten kan använda dem. Du kan godkänna dem via fönstret Nätverk på den logiska servern eller önskad klient. Sedan kan den elastiska jobbagenten nå alla databaser under den servern med hjälp av privat anslutning.

• Anslutningen från den elastiska jobbagenten till jobbdatabasen använder inte privat slutpunkt. Själva jobbagenten använder intern certifikatbaserad autentisering för att ansluta till jobbdatabasen.

  • Om du lägger till jobbdatabasen som en målgruppsmedlem fungerar den som ett vanligt mål. Du måste konfigurera med privat slutpunkt efter behov.

Behörigheter för elastisk jobbdatabas

När jobbagenten skapas skapas ett schema, tabeller och en roll som kallas jobs_reader i jobbdatabasen. Rollen skapas med följande behörighet och är utformad för att ge administratörer bättre åtkomstkontroll för jobbövervakning. Administratörer kan ge användare möjlighet att övervaka jobbkörning genom att lägga till dem i jobs_reader-rollen för jobbdatabasen.

Rollnamn	jobs schemabehörigheter	jobs_internal schemabehörigheter
jobs_reader	SELECT	None

Försiktighet

Uppdatera inte interna katalogvyer i jobbdatabasen, till exempel jobs.target_group_members. Om du ändrar katalogvyerna manuellt kan jobbdatabasen skadas och orsaka fel. Dessa vyer är endast för skrivskyddade sökningar. Du kan använda de lagrade procedurerna i jobbdatabasen för att lägga till eller ta bort målgrupper och medlemmar, till exempel jobs.sp_add_target_group_member.

Överväg säkerhetskonsekvenserna innan du beviljar förhöjd åtkomst till jobbdatabasen. En obehörig användare med behörighet att skapa eller redigera jobb kan skapa eller redigera ett jobb som använder en lagrad autentiseringsuppgift för att ansluta till en databas under den skadliga användarens kontroll. Den här säkerhetsrisken kan göra det möjligt för den skadliga användaren att fastställa lösenordet för autentiseringsuppgifterna eller köra skadliga kommandon.

Övervaka elastiska jobb

Den elastiska jobbagenten integreras med Azure-aviseringar för meddelanden om jobbstatus, vilket förenklar lösningen för att övervaka status och körningshistorik för jobb.

Azure-portalen innehåller extra funktioner för att stödja elastiska jobb och jobbövervakning. På sidan Översikt för Elastic Job Agent visas de senaste jobbkörningarna, enligt följande skärmbild.

Du kan skapa Azure Monitor-aviseringsregler med Azure-portalen, Azure CLI, PowerShell och REST API. Måttet Misslyckade elastiska jobb är en bra utgångspunkt för att övervaka och ta emot aviseringar om elastisk jobbkörning. Dessutom kan du välja att få aviseringar via en konfigurerbar åtgärd som SMS eller e-post av Azure Alert-anläggningen. Mer information finns i Skapa aviseringar för Azure SQL Database i Azure-portalen.

Ett exempel finns i Skapa, konfigurera och hantera elastiska jobb.

Jobbutdata

Resultatet av ett jobbs steg på varje måldatabas registreras i detalj och skriptutdata kan samlas in i en angiven tabell. Du kan ange en databas för att spara data som returneras från ett jobb.

Jobbhistorik

Du kan visa historik för elastisk jobbkörning i jobbdatabasen genom att fråga tabellen jobs.job_executions. Ett systemrensningsjobb rensar bort körningshistorik som är äldre än 45 dagar. Om du vill ta bort historik som är mindre än 45 dagar gammal manuellt kör du den sp_purge_jobhistory lagrade proceduren i jobbdatabasen.

Jobbstatus

Du kan övervaka elastiska jobbkörningar i jobbdatabasen genom att fråga tabellen jobs.job_executions.

Metodtips

Tänk på följande metodtips när du arbetar med elastiska databasjobb.

Metodtips för säkerhet

• Begränsa användningen av API:erna till betrodda personer.

• Bevilja autentiseringsuppgifter de minsta behörigheter som krävs för att utföra ett jobbsteg. Mer information finns i Auktorisering och behörigheter.

• När du använder en server- eller poolmålgruppmedlem skapar du separata kontouppgifter med behörighet för master-databasen för att visa och lista databaser. Den här autentiseringsuppgiften expanderar databaslistorna över servrarna och poolerna före jobbkörningen.

Prestanda för elastiskt jobb

Elastiska jobb använder minimala beräkningsresurser i väntan på att långvariga jobb ska slutföras.

Beroende på storleken på målgruppen för databaser och önskad körningstid för ett jobb (antal samtidiga arbetare) kräver agenten olika mängder beräkning och prestanda för jobbdatabasen (ju fler mål och ju högre antal jobb, desto högre beräkningsmängd krävs).

Samtidiga kapacitetsnivåer

Från och med oktober 2023 har den elastiska jobbagenten flera prestandanivåer för att öka kapaciteten.

Kapacitetsökningar anger det totala antalet samtidiga måldatabaser som jobbagenten kan ansluta till och starta ett jobb. Om du vill få fler samtidiga målanslutningar för jobbexekvering ska du uppgradera jobbagentens nivå från standardnivån JA100, som har en gräns på 100 samtidiga målanslutningar.

De flesta miljöer kräver färre än 100 samtidiga jobb när som helst, så JA100 är standard.

Elastisk nivå för jobbagent	Maximalt antal samtidiga jobb
JA100	100
JA200	200
JA400	400
JA800	800

Om du överskrider jobbagentens samtidighetskapacitetsnivå med jobbmål skapas köfördröjningar för vissa måldatabaser och servrar. Till exempel, om du startar ett jobb med 110 mål på JA100-nivån, väntar 10 mål på att starta tills andra är klara.

Du kan ändra nivå- eller tjänstmålet för en elastisk jobbagent via Azure-portalen, PowerShell eller REST-API:et för jobbagenter. Ett exempel finns i Skala jobbagenten.

Begränsa jobbeffekten för elastiska pooler

För att säkerställa att resurser inte överbelastas när jobb körs mot databaser i en elastisk Azure SQL Database-pool konfigurerar du jobb för att begränsa antalet databaser som ett jobb körs mot samtidigt.

Ange antalet samtidiga databaser som ett jobb körs på genom att ange parametern för den sp_add_jobstep lagrade proceduren @max_parallelism i T-SQL.

Idempotent skript

Ett elastiskt jobbs T-SQL-skript måste vara idempotent, dvs. om skriptet lyckas och det körs igen uppstår samma resultat. Ett skript kan misslyckas på grund av tillfälliga nätverksproblem. I så fall försöker jobbet automatiskt köra skriptet ett förinställt antal gånger innan det avbryts. Ett idempotent-skript har samma resultat även om det har körts två gånger (eller mer).

En enkel taktik är att testa om det finns ett objekt innan det skapas. Följande exempel är hypotetiskt:

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.

På samma sätt måste ett skript kunna exekveras framgångsrikt genom att logiskt testa och motverka eventuella förutsättningar som uppstår.

Begränsningar

Det här är de aktuella begränsningarna för elastic jobs-tjänsten. Produktteamet arbetar aktivt med att ta bort så många av dessa begränsningar som möjligt.

Problematik	Description
Den elastiska jobbagenten måste återskapas och startas i den nya regionen efter en failover eller flytta till en ny Azure-region.	Tjänsten för elastiska jobb lagrar all sin jobbagentdata och jobbmetadata i jobbdatabasen. Vid redundansväxling eller flytt av Azure-resurser till en ny Azure-region flyttas även jobbdatabasen, jobbagenten och jobbmetadata till den nya Azure-regionen. Den elastiska jobbagenten är dock en beräkningsbaserad resurs som uttryckligen måste återskapas och startas i den nya regionen innan jobben börjar köras igen. När den elastiska jobbagenten har startats återupptas körningen av jobb i den nya regionen enligt det tidigare definierade jobbschemat.
Överdrivna SQL-granskningsloggar från jobbdatabasen	Den elastiska jobbagenten arbetar genom att ständigt söka efter nya jobb och andra CRUD-åtgärder i jobbdatabasen. Om granskning är aktiverat på servern som rymmer en jobbdatabas kan jobbdatabasen generera ett stort antal granskningsloggar. Du kan åtgärda det här problemet genom att filtrera bort dessa granskningsloggar med hjälp Set-AzSqlServerAudit av kommandot med ett predikatuttryck. Till exempel: 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'" Det här kommandot filtrerar bara ut jobbagenten till jobbdatabasens granskningsloggar, inte jobbagenten till måldatabasens granskningsloggar.
Användning av en Hyperskala-databas som jobbdatabas	Det går inte att använda en Hyperskala-databas som en jobbdatabas . Elastiska jobb kan dock rikta in sig på Hyperskala-databaser på samma sätt som andra databaser i Azure SQL Database.
Serverfria databaser och automatisk pausering med elastiska uppgifter.	Automatisk pausning av aktiverad serverlös databas stöds inte som en jobbdatabas. Serverlösa databaser som är inriktade på elastiska jobb stöder automatisk paus, och jobbanslutningar återupptar dessa.
Exportera en jobbdatabas till en BACPAC-fil	Export av en jobbdatabas till en BACPAC-fil stöds inte. Om SQL Server som innehåller en jobbdatabas måste exporteras släpper du jobbdatabasen först innan du exporterar servern.

Nästa steg

Självstudie: Skapa, konfigurera och hantera elastiska jobb

Relaterat innehåll

• Automatisera hanteringsuppgifter i Azure SQL
• Skapa och hantera elastiska jobb med hjälp av PowerShell
• Skapa och hantera elastiska jobb med hjälp av T-SQL