Skapa, konfigurera och hantera elastiska jobb (förhandsversion)

  • Artikel
  • 3 minuter för att läsa

GÄLLER FÖR: Azure SQL Database

I den här artikeln får du lära dig hur du skapar, konfigurerar och hanterar elastiska jobb.

Om du inte har använt elastiska jobb kan du läsa mer om begreppen för jobbautomatisering i Azure SQL Database.

Skapa och konfigurera agenten

  1. Skapa eller identifiera en tom S0- eller högre databas. Den här databasen används som jobbdatabas när elastiska jobbagenter skapas.

  2. Skapa en elastisk jobbagent i portalen eller med PowerShell.

    Skapa elastisk jobbagent

Skapa, kör och hantera jobb

  1. Skapa autentiseringsuppgifter för jobbkörning i jobbdatabasen med PowerShell eller T-SQL.

  2. Definiera målgruppen (de databaser som du vill köra jobbet mot) med hjälp av PowerShell eller T-SQL.

  3. Skapa autentiseringsuppgifter för en jobbagent i varje databas som jobbet ska köras mot (lägg till användaren (eller rollen) till varje databas i gruppen). Exempel finns i PowerShell-självstudien.

  4. Skapa ett jobb med PowerShell eller T-SQL.

  5. Lägg till jobbsteg med PowerShell eller T-SQL.

  6. Kör ett jobb med PowerShell eller T-SQL.

  7. Övervaka jobbkörningsstatus med hjälp av portalen, PowerShell eller T-SQL.

    Portalen

Autentiseringsuppgifter för att köra jobb

Jobbet använder databasbegränsade autentiseringsuppgifter för att ansluta till de databaser som anges av målgruppen vid körning. Om en målgrupp innehåller servrar eller pooler används de här databasbegränsade autentiseringsuppgifterna för att ansluta till huvuddatabasen för att räkna upp de tillgängliga databaserna.

Att konfigurera rätt autentiseringsuppgifter för att köra ett jobb kan vara något förvirrande, så tänk på följande punkter:

  • Autentiseringsuppgifterna för databasen måste skapas i jobbdatabasen.
  • Alla måldatabaser måste ha en inloggning med tillräcklig behörighet för att jobbet ska slutföras ( i diagrammet jobuser nedan).
  • Autentiseringsuppgifter kan återanvändas mellan jobb och lösenorden för autentiseringsuppgifter krypteras och skyddas från användare som har skrivskyddad åtkomst till jobbobjekt.

Följande bild är utformad för att underlätta förståelse och konfiguration av rätt autentiseringsuppgifter för jobb. Kom ihåg att skapa användaren i varje databas (alla målanvändardatabaser) som jobbet behöver köras mot.

Autentiseringsuppgifter för elastiska jobb

Rekommenderade säkerhetsmetoder

Några metodtips för att arbeta med elastiska jobb:

  • Begränsa användningen av API:er till betrodda personer.
  • Autentiseringsuppgifter ska ha minsta möjliga behörigheter som krävs för att utföra jobbsteget. Mer information finns i Auktorisering och behörigheter.
  • När du använder en server och/eller poolmålgruppsmedlem rekommenderar vi starkt att du skapar separata autentiseringsuppgifter med behörighet för huvuddatabasen för att visa/lista databaser som används för att expandera databaslistorna över servrarna och/eller poolerna före jobbkörningen.

Agentprestanda, kapacitet och begränsningar

Elastiska jobb använder minimalt med beräkningsresurser medan de väntar på att jobb med lång körningstid blir klara.

Beroende på storleken på målgruppen med databaser och önskad körningstid för ett jobb (antalet samtidiga arbetare) kräver agenten olika mängder beräkningsresurser och prestanda från jobbdatabasen (ju fler mål och ju högre antal jobb, desto större beräkningsresurser krävs det).

För tillfället är förhandsgranskningen begränsad till 100 samtidiga jobb.

Förhindra jobb från att minska måldatabasens prestanda

För att resurser inte ska överbelastas vid körning av jobb mot databaser i en elastisk SQL-pool kan jobb konfigureras för att begränsa antalet databaser som ett jobb kan köras mot samtidigt.

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

Metodtips för att skapa jobb

Idempotent-skript

T-SQL-skripten för ett jobb måste vara idempotent. Idempotent innebär att om skriptet lyckas och körs igen, så erhålls samma resultat. Ett skript kan misslyckas på grund av tillfälliga nätverksproblem. I så fall försöker jobbet automatiskt köra skriptet på nytt ett förinställt antal gånger innan det ger upp. Ett idempotent-skript ger samma resultat även om det har lyckats köra två eller fler gånger.

En enkel metod är att testa om ett objekt finns innan det skapas. Ett hypotetiskt exempel visas nedan:

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å liknande sätt måste ett skript kunna lyckas köra genom att logiskt testa och motverka eventuella tillstånd som det hittar.

Nästa steg