Anteckning
Åtkomst till den här sidan kräver auktorisering. Du kan prova att logga in eller ändra kataloger.
Åtkomst till den här sidan kräver auktorisering. Du kan prova att ändra kataloger.
gäller för:Azure SQL Managed Instance
Med SQL Server Agent i AzureSQL Managed Instance kan du skapa och schemalägga jobb som kan köras regelbundet mot en eller flera databaser. Dessa SQL Agent-jobb kör Transact-SQL frågor (T-SQL) och utför underhållsaktiviteter. Den här artikeln beskriver användningen av SQL Agent för SQL Managed Instance.
Not
SQL Agent är inte tillgängligt i Azure SQL Database eller Azure Synapse Analytics. I stället rekommenderar vi Jobbautomatisering med Elastic Jobs.
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 klienttelemetriinsamling (kund).
- Uppdatera referensdata (information som är gemensam för alla databaser) och läs in data från Azure Blob Storage. Se BULK_INSERT för argumenten som används för att autentisera till Azure Blob Storage.
- Vanliga underhållsaktiviteter, inklusive
DBCC CHECKDBför 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 på en återkommande basis, till exempel under lågtrafikperioder. - Samla in frågeresultat från en uppsättning databaser till en central tabell kontinuerligt. Prestandafrågor kan köras kontinuerligt och konfigureras för att utlösa fler uppgifter som ska köras.
- Samla in data för rapportering
- Aggregera data från en samling databaser till en enda måltabell.
- Kör långvariga databearbetningsfrågor över en stor uppsättning databaser, till exempel insamling av kunddata. Resultaten samlas in i en enda 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 dina databaser med hjälp av SQL Server Integration Services (SSIS).
SQL Agent-jobb i SQL Managed Instance
SQL Server Agent kör SQL Agent-jobb som används för uppgiftsautomatisering i SQL Managed Instance.
SQL Agent-jobb är en angiven serie T-SQL-skript mot din databas. Använd jobb för att definiera en administrativ uppgift som kan köras en eller flera gånger och övervakas för att lyckas eller misslyckas.
Ett jobb kan köras på en lokal instans eller på flera fjärrinstanser. Ett SQL Agent-jobb är en intern databasmotorkomponent som körs i SQL Managed Instance-tjänsten.
Det finns flera viktiga begrepp i 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 en återförsöksstrategi och den åtgärd som ska utföras om jobbsteget lyckas eller misslyckas.
- Scheman definierar när jobbet ska köras.
- Med meddelanden kan du definiera de regler som används för att meddela operatörer via e-post när jobbet har slutförts.
Jobbsteg
SQL Agent-jobbsteg är sekvenser av åtgärder som SQL Agent ska köra. Varje steg har följande steg som ska köras om steget lyckas eller misslyckas och ett visst antal återförsök om det misslyckas.
Med SQL Agent kan du skapa olika typer av jobbsteg.
- Transact-SQL jobbsteg som kör en enda Transact-SQL batch mot databasen.
- OS-kommando/PowerShell-steg som kan köra anpassat OS-skript.
- SSIS-jobbsteg som tillåter dig att ladda upp data med SSIS-runtime.
- Replikeringssteg som kan publicera ändringar från databasen till andra databaser.
Not
Mer information 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, såsom Merge-replikering och köläsare.
Jobbscheman
Ett körschema anger när ett jobb körs. Fler än ett jobb kan köras enligt samma schema och mer än ett schema kan gälla för samma jobb.
Ett schema kan definiera följande villkor för den tid då ett jobb körs:
- Starta när SQL Server-agenten startar. Jobbet aktiveras efter varje redundansväxling.
- Börja en gång, vid ett specifikt datum och en specifik tid, vilket är användbart för senare körning av ett jobb.
- Starta enligt ett återkommande schema.
Mer information om hur du schemalägger ett SQL Agent-jobb finns i Schemalägga ett jobb.
Not
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 ett e-postkonto 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 ska det finnas en profil som ska kallas AzureManagedInstance_dbmail_profile. Annars kan SQL Managed Instance inte skicka e-postmeddelanden via SQL Agent.
Not
För e-postservern rekommenderar vi att du använder autentiserade SMTP-relätjänster (Simple Mail Transfer Protocol) för att skicka e-post. Dessa relätjänster ansluter vanligtvis via portarna 25 eller 587 för TLS-anslutningar (Transport Layer Security) 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_dbmail lagrade systemproceduren.
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 miljöer med flera SQL-hanterade instanser eller SQL Server-instanser kan många personer dela operatörsansvar. En operatör innehåller inte 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 hjälp av SQL Server Management Studio (SSMS) eller det Transact-SQL skript 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 Database Mail Log i SSMS.
Du kan ändra alla SQL Agent-jobb och tilldela operatorer som meddelas via e-post om jobbet slutförs, misslyckas eller lyckas. Ändra jobbet 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 alternativen för att justera Agentens kvarhållningsprincip för poster i jobbhistoriken är fastställda vid standardvärdet av 1 000 antalet poster totalt och högst 100 poster per jobb i historiken.
Mer information finns i Visa SQL Agent-jobbhistorik.
Fast databasrollmedlemskap
Om användare som är länkade till nonsysadmin-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, kör följande T-SQL-skript för varje användarinloggning som lagts till dessa roller, för att uttryckligen bevilja EXECUTE behörigheter till de systemlagrade procedurerna som listas. 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-.
Vissa SQL Agent-funktioner som är tillgängliga i SQL Server stöds inte i SQL Managed Instance:
- SQL Agent-inställningarna är skrivskyddade.
- Den system lagrade proceduren
sp_set_agent_propertiesstöds inte.
- Den system lagrade proceduren
- 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:
- Pager stöds inte.
- NetSend stöds inte.
- Aviseringar stöds inte.
- Proxyservrar stöds inte.
- Händelseloggar stöds inte.
- Jobbschemautlösare som baseras på en inaktiv CPU stöds inte.
- Steg för sammanslagning av replikeringsjobb 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.
Relaterat innehåll
- Vad är Azure SQL Managed Instance?
- Vad är nytt i Azure SQL Managed Instance?
- T-SQL-skillnader i Azure SQL Managed Instance jämfört med SQL Server
- jämförelse av funktioner: Azure SQL Database och Azure SQL Managed Instance
- Konfigurera Database Mail
- Felsöka problem med utgående SMTP-anslutning i Azure