Dela via

Automatisera hanteringsuppgifter med hjälp av SQL Agent-jobb i Azure SQL Managed Instance

  • Artikel

Gäller för:Azure SQL Managed Instance

Med SQL Server Agent i SQL Server och SQL Managed Instance kan du skapa och schemalägga jobb som kan köras regelbundet mot en eller flera databaser för att köra Transact-SQL-frågor (T-SQL) och utföra underhållsuppgifter. Den här artikeln beskriver användningen av SQL Agent för SQL Managed Instance.

Kommentar

SQL Agent är inte tillgängligt i Azure SQL Database eller Azure Synapse Analytics. I stället rekommenderar vi jobbautomatisering med elastiska jobb.

När du ska använda SQL Agent-jobb

Det finns flera scenarier när du kan använda SQL Agent-jobb:

  • Automatisera hanteringsuppgifter och schemalägg dem så att de körs varje veckodag, efter timmar osv.
    • Distribuera schemaändringar, hantering av autentiseringsuppgifter, insamling av prestandadata eller insamling av telemetri för klientorganisation (kund).
    • Uppdatera referensdata (information som är gemensam över alla databaser), läsa in data från Azure Blob-lagring. Microsoft rekommenderar att du använder SIGNATURAUTENTISERING FÖR DELAD ÅTKOMST för att autentisera till Azure Blob Storage.
    • Vanliga underhållsaktiviteter, inklusive DBCC CHECKDB att säkerställa dataintegritet eller indexunderhåll för att förbättra frågeprestanda. Konfigurera jobb att köras över en samling databaser regelbundet, till exempel vid tidpunkter för låg belastning.
    • Samla in frågeresultat från en uppsättning databaser till en central tabell regelbundet. Prestandafrågor kan kontinuerligt köras och konfigureras för att utlösa ytterligare åtgärder som ska utföras.
  • Samla in data för rapportering
    • Aggregera data från en samling databaser till en enda måltabell.
    • Kör databearbetningsfrågor med längre körningstid över en stor uppsättning databaser, till exempel insamling av kundtelemetri. Resultaten samlas till en enskild måltabell för ytterligare analys.
  • Dataförflyttningar
    • Skapa jobb som replikerar ändringar som gjorts i dina databaser till andra databaser eller samla in uppdateringar som görs i fjärrdatabaser och tillämpa ändringar i databasen.
    • Skapa jobb som läser in data från eller till databaser med hjälp av SQL Server Integration Services (SSIS).

SQL Agent-jobb i SQL Managed Instance

SQL Agent-jobb körs av SQL Agent-tjänsten som fortsätter att användas för uppgiftsautomatisering i SQL Server och SQL Managed Instance.

SQL Agent-jobb är en angiven serie T-SQL-skript mot databasen. Använd jobb för att definiera en administrativ uppgift som kan köras en eller flera gånger och övervakas lyckad eller misslyckad status.

Ett jobb kan köras på en lokal server eller på flera fjärrservrar. SQL Agent-jobb är en intern databasmotorkomponent som körs i SQL Managed Instance-tjänsten.

Det finns flera viktiga begrepp vad gäller SQL Agent-jobb:

  • Jobbsteg är en uppsättning med ett eller flera steg som ska köras i jobbet. För varje jobbsteg kan du definiera strategi för återförsök och vilken åtgärd som ska vidtas om jobbsteget lyckas eller misslyckas.
  • Scheman definierar när jobbet ska köras.
  • Med meddelanden kan du definiera regler som ska användas för att meddela operatörer via e-post när jobbet är klart.

Jobbsteg

SQL Agent-jobbsteg är sekvenser med åtgärder som SQL Agent ska köra. Varje steg har följande steg som ska köras om steget lyckas eller misslyckas, antalet återförsök i fall av fel.

Med SQL Agent kan du skapa olika typer av jobbsteg, till exempel Transact-SQL-jobbsteg som kör en enda Transact-SQL-batch mot databasen eller OS-kommando/PowerShell-steg som kan köra anpassat OS-skript, SSIS-jobbsteg som gör att du kan läsa in data med SSIS-körning eller replikeringssteg som kan publicera ändringar från databasen till andra databaser.

Kommentar

Mer information om hur du använder Azure SSIS Integration Runtime med SSISDB som hanteras av SQL Managed Instance finns i Använda Azure SQL Managed Instance med SQL Server Integration Services (SSIS) i Azure Data Factory.

Transaktionsreplikering kan replikera ändringarna från dina tabeller till andra databaser i SQL Managed Instance, Azure SQL Database eller SQL Server. Mer information finns i Konfigurera replikering i Azure SQL Managed Instance.

Andra typer av jobbsteg stöds för närvarande inte i SQL Managed Instance, till exempel Sammanslagningsreplikering och Köläsare.

Jobbscheman

Ett schema anger när ett jobb körs. Fler än ett jobb kan köras på samma schema, och fler än ett schema kan tillämpas på samma jobb.

Ett schema kan definiera följande villkor för den tid då ett jobb körs:

  • När SQL Server-agenten startar. Jobbet aktiveras efter varje redundans.
  • En gång vid ett specifikt datum och en specifik tid, vilket är användbart för fördröjd körning av ett jobb.
  • Enligt ett återkommande schema.

Mer information om hur du schemalägger ett SQL Agent-jobb finns i Schemalägga ett jobb.

Kommentar

Med Azure SQL Managed Instance kan du för närvarande inte starta ett jobb när processorn är inaktiv.

Jobbmeddelanden

Med SQL Agent-jobb kan du få meddelanden när jobbet har slutförts eller misslyckas. Du kan ta emot meddelanden via e-post.

Om den inte redan är aktiverad måste du först konfigurera funktionen Database Mail på SQL Managed Instance:

GO
EXEC sp_configure 'show advanced options', 1;
GO
RECONFIGURE;
GO
EXEC sp_configure 'Database Mail XPs', 1;
GO
RECONFIGURE

Som en exempelövning konfigurerar du det e-postkonto som ska användas för att skicka e-postaviseringar. Tilldela kontot till e-postprofilen med namnet AzureManagedInstance_dbmail_profile. Om du vill skicka e-post med SQL Agent-jobb i SQL Managed Instance bör det finnas en profil som måste anropas AzureManagedInstance_dbmail_profile. Annars kan SQL Managed Instance inte skicka e-postmeddelanden via SQL Agent.

Kommentar

För e-postservern rekommenderar vi att du använder autentiserade SMTP-relätjänster för att skicka e-post. Dessa relätjänster ansluter vanligtvis via TCP-portarna 25 eller 587 för anslutningar via TLS eller port 465 för SSL-anslutningar, men Database Mail kan konfigureras för att använda valfri port. Dessa portar kräver en ny regel för utgående trafik i den hanterade instansens nätverkssäkerhetsgrupp. Dessa tjänster används för att upprätthålla IP- och domänrykte för att minimera risken för att externa domäner avvisar dina meddelanden eller placerar dem i mappen SPAM. Överväg att använda en autentiserad SMTP-relätjänst som redan finns på dina lokala servrar. I Azure är SendGrid en sådan SMTP-relätjänst, men det finns andra.

Använd följande exempelskript för att skapa ett Database Mail-konto och en profil och associera dem sedan med varandra:

-- Create a Database Mail account
EXECUTE msdb.dbo.sysmail_add_account_sp
    @account_name = 'SQL Agent Account',
    @description = 'Mail account for Azure SQL Managed Instance SQL Agent system.',
    @email_address = '$(loginEmail)',
    @display_name = 'SQL Agent Account',
    @mailserver_name = '$(mailserver)' ,
    @username = '$(loginEmail)' ,
    @password = '$(password)';

-- Create a Database Mail profile
EXECUTE msdb.dbo.sysmail_add_profile_sp
    @profile_name = 'AzureManagedInstance_dbmail_profile',
    @description = 'E-mail profile used for messages sent by Managed Instance SQL Agent.';

-- Add the account to the profile
EXECUTE msdb.dbo.sysmail_add_profileaccount_sp
    @profile_name = 'AzureManagedInstance_dbmail_profile',
    @account_name = 'SQL Agent Account',
    @sequence_number = 1;

Testa Database Mail-konfigurationen via T-SQL med hjälp av den sp_send_db_mail system lagrade proceduren:

DECLARE @body VARCHAR(4000) = 'The email is sent from ' + @@SERVERNAME;
EXEC msdb.dbo.sp_send_dbmail  
    @profile_name = 'AzureManagedInstance_dbmail_profile',  
    @recipients = 'ADD YOUR EMAIL HERE',  
    @body = 'Add some text',  
    @subject = 'Azure SQL Instance - test email';

Du kan meddela operatorn att något hände med dina SQL Agent-jobb. En operatör definierar kontaktinformation för en person som ansvarar för underhåll av en eller flera instanser i SQL Managed Instance. Ibland tilldelas operatörsansvar till en enskild person.

I system med flera instanser i SQL Managed Instance eller SQL Server kan många personer dela operatörsansvar. En operatör innehåller ingen säkerhetsinformation och definierar inte ett säkerhetsobjekt. Helst är en operatör inte en person vars ansvar kan ändras, utan en e-postdistributionsgrupp.

Du kan skapa operatorer med SQL Server Management Studio (SSMS) eller Transact-SQL-skriptet som visas i följande exempel:

EXEC msdb.dbo.sp_add_operator
    @name=N'AzureSQLTeam',
    @enabled=1,
    @email_address=N'AzureSQLTeamn@contoso.com';

Bekräfta att e-postmeddelandet lyckades eller misslyckades via databasens e-postlogg i SSMS.

Du kan sedan ändra alla SQL Agent-jobb och tilldela operatorer som meddelas via e-post om jobbet slutförs, misslyckas eller lyckas med hjälp av SSMS eller följande T-SQL-skript:

EXEC msdb.dbo.sp_update_job @job_name=N'Load data using SSIS',
    @notify_level_email=3, -- Options are: 1 on succeed, 2 on failure, 3 on complete
    @notify_email_operator_name=N'AzureSQLTeam';

Jobbhistorik

SQL Managed Instance tillåter för närvarande inte att ändra några SQL Agent-egenskaper eftersom de lagras i de underliggande registervärdena. Det innebär att alternativ för att justera kvarhållningsprincipen för agenten för jobbhistorikposter är fasta som standard på 1 000 totala poster och högst 100 historikposter per jobb.

Mer information finns i Visa SQL Agent-jobbhistorik.

Fast databasrollmedlemskap

Om användare som är länkade till icke-sysadmin-inloggningar läggs till i någon av de tre fasta databasrollerna för SQL Agent i systemdatabasen msdb , finns det ett problem där explicita EXECUTE-behörigheter måste beviljas till tre system lagrade procedurer i master databasen. Om det här problemet uppstår visas felmeddelandet The EXECUTE permission was denied on the object <object_name> (Microsoft SQL Server, Error: 229) .

När du lägger till användare i en fast SQL Agent-databasroll (SQLAgentUserRole, SQLAgentReaderRole eller SQLAgentOperatorRole) i msdb, för var och en av användarens inloggningar som lagts till i dessa roller, kör du T-SQL-skriptet nedan för att uttryckligen bevilja EXECUTE-behörigheter till de system lagrade procedurerna i listan. I det här exemplet förutsätts att användarnamnet och inloggningsnamnet är samma:

USE [master]
GO
CREATE USER [login_name] FOR LOGIN [login_name];
GO
GRANT EXECUTE ON master.dbo.xp_sqlagent_enum_jobs TO [login_name];
GRANT EXECUTE ON master.dbo.xp_sqlagent_is_starting TO [login_name];
GRANT EXECUTE ON master.dbo.xp_sqlagent_notify TO [login_name];

Begränsningar för SQL Agent-jobb i SQL Managed Instance

Det är värt att notera skillnaderna mellan SQL Agent som är tillgängligt i SQL Server och som en del av SQL Managed Instance. Mer information om de funktionsskillnader som stöds mellan SQL Server och SQL Managed Instance finns i Azure SQL Managed Instance T-SQL-skillnader från SQL Server.

Några av de SQL Agent-funktioner som är tillgängliga i SQL Server stöds inte i SQL Managed Instance:

  • Inställningar för SQL Agent är skrivskyddade.
    • Den system lagrade proceduren sp_set_agent_properties stöds inte.
  • Aktivering/inaktivering av SQL Agent stöds för närvarande inte. SQL Agent körs alltid.
  • Meddelanden stöds delvis, men följande stöds inte:
    • Personsökare stöds inte.
    • NetSend stöds inte.
    • Aviseringar stöds inte.
  • Proxyservrar stöds inte.
  • EventLog stöds inte.
  • Jobbschemautlösare som baseras på en inaktiv CPU stöds inte.
  • Steg för sammanslagningsreplikeringsjobb stöds inte.
  • Köläsare stöds inte.
  • Analysis Services stöds inte.
  • Det går inte att köra ett skript som lagras som en fil på disken.
  • Import av externa moduler, till exempel dbatools och dbachecks, stöds inte.
  • PowerShell Core stöds inte.

Mer information

Nästa steg