Neste artigo, apresento quatro opções para retornar dados do histórico de trabalho do SQL Server Agent.
As opções
Incluí duas opções de GUI e duas opções de T-SQL:
- Opção 1 :Use a GUI do SSMS.
- Opção 2 :use a GUI do Azure Data Studio (por meio da extensão do SQL Server Agent)
- Opção 3 :Execute o
sp_help_jobhistoryprocedimento armazenado. - Opção 4 :Consulte o
sysjobhistorytabela (e junte-a com osysjobs_viewview ousysjobstabela).
Os objetos do SQL Server Agent residem no msdb banco de dados e, portanto, as opções do T-SQL precisam ser executadas nesse banco de dados. Você pode fazer isso alternando para o msdb banco de dados primeiro, ou qualificando o objeto apropriadamente (por exemplo,
msdb.dbo.sysjobhistory ). Opção 1:use a GUI do SSMS
Você pode usar a GUI do SQL Server Management Studio (SSMS) para exibir o histórico de trabalhos.
Você pode fazer isso expandindo o nó do SQL Server Agent no Pesquisador de Objetos e clicando com o botão direito do mouse em Trabalhos e selecionando Visualizar histórico no menu contextual:
Isso abre uma nova janela com o histórico de todos os trabalhos dentro do Log File Viewer:
Você pode visualizar o histórico de um único trabalho desmarcando os outros trabalhos nesta tela. Como alternativa, você pode localizar esse trabalho no Pesquisador de objetos e clicar com o botão direito nele.
Consulte Exibir histórico de trabalho do SQL Server Agent com SSMS para obter mais detalhes e capturas de tela.
Opção 2:usar a GUI do Azure Data Studio
Se você usa o Azure Data Studio, talvez não saiba, mas também tem a opção de exibir o histórico de trabalhos do SQL Server Agent.
A maneira de fazer isso é por meio da extensão do SQL Server Agent.
Aqui está o que parece:
Nesta tela, estamos vendo o histórico de um trabalho chamado BackupKrankyKranesDB .
O histórico do trabalho é listado no painel esquerdo. Você pode clicar em cada item no painel esquerdo do histórico para exibir os detalhes desse item no painel direito.
No momento da redação deste artigo, parece que você só pode visualizar o histórico de um único trabalho por vez.
Consulte Exibir histórico de trabalho do SQL Server Agent com o Azure Data Studio para obter mais detalhes e capturas de tela.
Opção 3:a sp_help_jobhistory Procedimento armazenado
Se você preferir (ou precisar) fazer suas tarefas com T-SQL, então o
sp_help_jobhistory procedimento armazenado é uma opção rápida e fácil para você. Quando você chama
sp_help_jobhistory sem nenhum argumento, ele retorna o histórico de todos os trabalhos. Mas quando você passa o nome ou ID de um trabalho, ele lista apenas o histórico desse trabalho. Aqui está um exemplo:
EXEC msdb.dbo.sp_help_jobhistory;Resultado:
Observe que
sp_help_jobhistory está localizado no msdb banco de dados, então você precisa garantir que você o execute a partir daí. Você pode fazer isso alternando para esse banco de dados (por exemplo, com USE msdb ), ou qualificando o procedimento armazenado com o banco de dados e o esquema (ou seja, msdn.dbo.sp_help_jobhistory ). Você pode obter o histórico de um único trabalho passando o ID ou nome desse trabalho como um argumento.
Exemplo:
EXEC msdb.dbo.sp_help_jobhistory
@job_name = 'BackupKrankyKranesDB';Você também pode usar o
@mode parameter para especificar se deve ou não retornar todas as colunas no conjunto de resultados (FULL ), ou apenas um resumo (SUMMARY ). EXEC msdb.dbo.sp_help_jobhistory
@job_name = 'BackupKrankyKranesDB',
@mode = 'FULL';O padrão é
SUMMARY . Opção 4:o sysjobhistory Tabela
O
sysjobhistory table é a tabela que armazena os dados do histórico de trabalho. Como em qualquer tabela, você pode simplesmente fazer algo assim:
SELECT * FROM msdb.dbo.sysjobhistory;Isso retornará todas as colunas da tabela.
No entanto, esta tabela não armazena o nome do trabalho (ou a descrição do trabalho, etc.). Para obter esses dados, você precisará unir esta tabela com outras tabelas/visualizações, como a
sysjobs_view view ou sysjobs tabela. Isso fornecerá um conjunto de resultados mais completo. Abaixo está uma consulta que você pode usar para retornar dados mais completos.
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;Resultado:
Você pode adicionar mais colunas ao
SELECT lista conforme necessário. Se você está se perguntando por que essa consulta usa um monte de coisas extras, como o
AGENT_DATETIME() função, o STUFF() função, RIGHT() , CAST() e REPLICATE() , é por causa da maneira como sysjobhistory armazena seus valores de data e hora. Se eu não tivesse usado essas funções, os valores de data e hora seriam menos legíveis.
Em particular, o
run_date , run_time e run_duration colunas armazenam seus dados como int valores. Por padrão, os dados nessas colunas são assim:
Isso pode tornar difícil para alguns de nós, humanos, ler. Especialmente o
run_duration coluna. Portanto, usamos as várias funções na consulta acima para apresentar essas colunas em um formato mais legível. Você pode notar que o
sp_help_jobhistory procedimento armazenado sofre o mesmo problema. Além disso, devo mencionar que
AGENT_DATE() parece ser uma função não documentada. 
