4 sätt att få SQL Server-jobbhistorik

I den här artikeln presenterar jag fyra alternativ för att returnera SQL Server Agent-jobbhistorikdata.

Alternativen

Jag har inkluderat två GUI-alternativ och två T-SQL-alternativ:

Alternativ 1 :Använd SSMS GUI.
Alternativ 2 :Använd Azure Data Studio GUI (via SQL Server Agent-tillägget)
Alternativ 3 :Kör sp_help_jobhistory lagrad procedur.
Alternativ 4 :Fråga sysjobhistory tabellen (och anslut den med sysjobs_view vyn eller sysjobs tabell).

SQL Server Agent-objekten finns i msdb databas, och därför måste T-SQL-alternativen köras i den databasen. Du kan göra det genom att byta till msdb databas först, eller genom att kvalificera objektet på lämpligt sätt (t.ex. msdb.dbo.sysjobhistory ).

Alternativ 1:Använd SSMS GUI

Du kan använda SQL Server Management Studio (SSMS) GUI för att se jobbhistorik.

Du kan göra detta genom att expandera SQL Server Agent-noden i Objektutforskaren och sedan högerklicka på Jobb och välj Visa historik från den sammanhangsberoende menyn:

Detta öppnar ett nytt fönster med jobbhistoriken för alla jobb i Log File Viewer:

Du kan se historiken för ett enskilt jobb genom att avmarkera de andra jobben på den här skärmen. Alternativt kan du hitta jobbet i Objektutforskaren och högerklicka på det därifrån.

Se Visa SQL Server Agent Jobbhistorik med SSMS för mer information och skärmdumpar.

Alternativ 2:Använd Azure Data Studio GUI

Om du använder Azure Data Studio kanske du inte känner till det, men du har också möjlighet att visa SQL Server Agent jobbhistorik.

Sättet att göra detta är via tillägget SQL Server Agent.

Så här ser det ut:

På den här skärmen tittar vi på historiken för ett jobb som heter BackupKrankyKranesDB .

Jobbhistoriken listas i den vänstra rutan. Du kan klicka på varje objekt i den vänstra historikrutan för att visa objektets detaljer i den högra rutan.

När detta skrivs verkar det som att du bara kan se historiken för ett enda jobb åt gången.

Se Visa SQL Server Agent Jobbhistorik med Azure Data Studio för mer information och skärmdumpar.

Alternativ 3:`sp_help_jobhistory` Lagrad procedur

Om du föredrar (eller behöver) göra dina uppgifter med T-SQL, då sp_help_jobhistory lagrad procedur är ett snabbt och enkelt alternativ för dig.

När du ringer sp_help_jobhistory utan några argument returnerar den historiken för alla jobb. Men när du skickar ett jobbs namn eller ID listar det bara historiken för det ena jobbet.

Här är ett exempel:

EXEC msdb.dbo.sp_help_jobhistory;

Resultat:

Observera att sp_help_jobhistory finns i msdb databas, så du måste se till att du kör den därifrån. Du kan göra detta antingen genom att byta till den databasen (t.ex. med USE msdb ), eller genom att kvalificera den lagrade proceduren med databasen och schemat (dvs. msdn.dbo.sp_help_jobhistory ).

Du kan få historiken för ett enskilt jobb genom att skicka det jobbets ID eller namn som ett argument.

Exempel:

EXEC msdb.dbo.sp_help_jobhistory
	@job_name = 'BackupKrankyKranesDB';

Du kan också använda parametern @mode parameter för att ange om alla kolumner i resultatuppsättningen ska returneras eller inte (FULL ), eller bara en sammanfattning (SUMMARY ).

EXEC msdb.dbo.sp_help_jobhistory
	@job_name = 'BackupKrankyKranesDB',
	@mode = 'FULL';

Standard är SUMMARY .

Alternativ 4:`sysjobhistory` Tabell

sysjobhistory tabellen är tabellen som lagrar jobbhistorikdata.

Som med alla bord kan du helt enkelt göra något så här:

SELECT * FROM msdb.dbo.sysjobhistory;

Det kommer att returnera alla kolumner i tabellen.

Den här tabellen lagrar dock inte jobbnamnet (eller jobbets beskrivning etc). För att få den informationen måste du ansluta den här tabellen med andra tabeller/vyer, till exempel sysjobs_view vyn eller sysjobs tabell. Det ger en mer komplett resultatuppsättning.

Nedan finns en fråga som du kan använda för att returnera mer fullständig data.

SELECT jv.name AS Job,
		jh.step_name AS Step,
		msdb.dbo.AGENT_DATETIME(jh.run_date, jh.run_time) AS RunDateTime,
		STUFF(STUFF(STUFF(RIGHT(REPLICATE('0', 8) + CAST(jh.run_duration as varchar(8)), 8), 3, 0, ':'), 6, 0, ':'), 9, 0, ':') AS RunDuration
FROM msdb.dbo.sysjobs_view jv
INNER JOIN msdb.dbo.sysjobhistory jh
ON jv.job_id = jh.job_id
ORDER BY Job, RunDateTime;

Resultat:

Du kan lägga till fler kolumner i SELECT lista efter behov.

Om du undrar varför den här frågan använder en hel massa extra grejer, som AGENT_DATETIME() funktionen, STUFF() funktion, RIGHT() , CAST() , och REPLICATE() , det är på grund av sättet sysjobhistory lagrar dess datetime-värden.

Om jag inte hade använt dessa funktioner, skulle datetime-värdena ha varit mindre läsbara.

I synnerhet run_date , run_time och run_duration kolumner lagrar sina data som int värden. Som standard ser data i dessa kolumner ut så här:

Det kan göra det svårt för vissa av oss människor att läsa. Speciellt run_duration kolumn. Därför använde vi de olika funktionerna i ovanstående fråga för att presentera dessa kolumner i ett mer mänskligt läsbart format.

Du kanske märker att sp_help_jobhistory lagrad procedur lider av samma problem.

Jag bör också nämna att AGENT_DATE() verkar vara en odokumenterad funktion.