Sqlserver
 sql >> Base de données >  >> RDS >> Sqlserver

4 façons d'obtenir l'historique des tâches SQL Server

Dans cet article, je présente quatre options pour renvoyer les données d'historique des travaux de l'Agent SQL Server.

Les options

J'ai inclus deux options GUI et deux options T-SQL :

  • Option 1 :Utilisez l'interface graphique SSMS.
  • Option 2 :Utilisez l'interface graphique Azure Data Studio (via l'extension SQL Server Agent)
  • Option 3 :Exécute le sp_help_jobhistory procédure stockée.
  • Option 4  :Interroger le sysjobhistory table (et joignez-la à la sysjobs_view afficher ou les sysjobs table).

Les objets de l'Agent SQL Server résident dans le msdb base de données, et donc les options T-SQL doivent être exécutées dans cette base de données. Vous pouvez le faire en basculant vers le msdb base de données d'abord, ou en qualifiant l'objet de manière appropriée (par exemple, msdb.dbo.sysjobhistory ).

Option 1 :Utiliser l'interface graphique SSMS

Vous pouvez utiliser l'interface graphique de SQL Server Management Studio (SSMS) pour afficher l'historique des tâches.

Vous pouvez le faire en développant le nœud SQL Server Agent dans l'Explorateur d'objets, puis en cliquant avec le bouton droit sur Tâches et en sélectionnant Afficher l'historique depuis le menu contextuel :

Cela ouvre une nouvelle fenêtre avec l'historique des travaux de tous les travaux dans la visionneuse de fichiers journaux :

Vous pouvez afficher l'historique d'un seul travail en désélectionnant les autres travaux dans cet écran. Vous pouvez également localiser cette tâche dans l'Explorateur d'objets et cliquer dessus avec le bouton droit de la souris.

Voir Afficher l'historique des travaux de l'Agent SQL Server avec SSMS pour plus de détails et des captures d'écran.

Option 2 :Utiliser l'interface graphique Azure Data Studio

Si vous utilisez Azure Data Studio, vous ne le savez peut-être pas, mais vous avez également la possibilité d'afficher l'historique des travaux de l'Agent SQL Server.

Pour ce faire, utilisez l'extension SQL Server Agent.

Voici à quoi cela ressemble :

Dans cet écran, nous examinons l'historique d'une tâche appelée BackupKrankyKranesDB .

L'historique des travaux est répertorié dans le volet de gauche. Vous pouvez cliquer sur chaque élément dans le volet d'historique de gauche pour afficher les détails de cet élément dans le volet de droite.

Au moment d'écrire ces lignes, il semble que vous ne puissiez afficher l'historique que d'un seul travail à la fois.

Consultez Afficher l'historique des travaux de l'Agent SQL Server avec Azure Data Studio pour plus de détails et des captures d'écran.

Option 3 :Le sp_help_jobhistory Procédure stockée

Si vous préférez (ou devez) effectuer vos tâches avec T-SQL, alors le sp_help_jobhistory procédure stockée est une option simple et rapide pour vous.

Lorsque vous appelez sp_help_jobhistory sans aucun argument, il renvoie l'historique de tous les travaux. Mais lorsque vous transmettez le nom ou l'identifiant d'une tâche, seul l'historique de cette tâche est répertorié.

Voici un exemple :

EXEC msdb.dbo.sp_help_jobhistory;

Résultat :

Notez que sp_help_jobhistory est situé dans le msdb base de données, vous devez donc vous assurer que vous l'exécutez à partir de là. Vous pouvez le faire soit en basculant vers cette base de données (par exemple avec USE msdb ), ou en qualifiant la procédure stockée avec la base de données et le schéma (c'est-à-dire msdn.dbo.sp_help_jobhistory ).

Vous pouvez obtenir l'historique d'une seule tâche en transmettant l'ID ou le nom de cette tâche en tant qu'argument.

Exemple :

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

Vous pouvez également utiliser le @mode parameter pour spécifier s'il faut ou non renvoyer toutes les colonnes du jeu de résultats (FULL ), ou juste un résumé (SUMMARY ). 

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

La valeur par défaut est SUMMARY .

Option 4 :Le sysjobhistory Tableau

Le sysjobhistory table est la table qui stocke les données de l'historique des travaux.

Comme pour n'importe quel tableau, vous pouvez simplement faire quelque chose comme ceci :

SELECT * FROM msdb.dbo.sysjobhistory;

Cela renverra toutes les colonnes de la table.

Cependant, cette table ne stocke pas le nom du travail (ou la description du travail, etc.). Pour obtenir ces données, vous devrez joindre cette table à d'autres tables/vues, telles que sysjobs_view afficher ou les sysjobs table. Cela fournira un ensemble de résultats plus complet.

Vous trouverez ci-dessous une requête que vous pouvez utiliser pour renvoyer des données plus complètes. 

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;

Résultat :

Vous pouvez ajouter plus de colonnes au SELECT liste au besoin.

Si vous vous demandez pourquoi cette requête utilise tout un tas de choses supplémentaires, comme le AGENT_DATETIME() fonction, la STUFF() fonction, RIGHT() , CAST() , et REPLICATE() , c'est à cause de la façon dont sysjobhistory stocke ses valeurs datetime.

Si je n'avais pas utilisé ces fonctions, les valeurs datetime auraient été moins lisibles.

En particulier, la run_date , run_time et run_duration les colonnes stockent leurs données en tant que int valeurs. Par défaut, les données de ces colonnes ressemblent à ceci :

Cela peut rendre la lecture difficile pour certains d'entre nous, humains. Surtout le run_duration colonne. Par conséquent, nous avons utilisé les différentes fonctions de la requête ci-dessus pour présenter ces colonnes dans un format plus lisible par l'homme.

Vous remarquerez peut-être que le sp_help_jobhistory procédure stockée souffre du même problème.

Aussi, je dois mentionner que AGENT_DATE() semble être une fonction non documentée.