Temps d'exécution d'un job

Version imprimable

20/10/2020, 12h29
alfabo

Temps d'exécution d'un job

Bonjour,

Je voulais savoir s'il vous plais s'il y a une fonction ou une possibilité de récupérer le temps d'exécution d'un job par requête

Merci d'avance
20/10/2020, 15h19
SQLpro
Tous les jobs sont stockées avec leur historique d'exécution dans la bases msdb, dans les tables intitulées sys.sysjob....

En particulier intéressez vous à
Code:

1 2 SELECT * FROM [msdb].[dbo].[sysjobhistory]
A +
20/10/2020, 15h44
Invité

La fameuse table système avec les heures stockées dans des INT au format HHMMSS... :roll:
20/10/2020, 16h32
SQLpro

Citation:

Envoyé par 7gyY9w1ZY6ySRgPeaefZ

La fameuse table système avec les heures stockées dans des INT au format HHMMSS... :roll:

Merci Sybase !!!!!!

A +
20/10/2020, 16h55
vanagreg

Un chouïa mieux que Générix qui stocke les heures minutes secondes en number(6, 2), les 2 décimales étant les secondes. Je suis toujours à la recherche d'une explication rationnelle à ce mystère, tout comme stocker les dates en varchar2(8).

J'ai cette vielle fonction qui peut t'être utile pour manipuler cette table.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
-- =============================================
-- Description:	Permet de transformer deux données date et heure en INT en un type datetime
--			Pourquoi créer cette bidouille improbable et contre-performante ?
--			Parce les données de certaines tables systèmes sont stocké dans des INT
--			au lieu de faire ça comme du monde en mettant ça dans un type datetime
--			exemple : msdb.dbo.sysjobactivity
-- =============================================
CREATE FUNCTION [dbo].[f_scal_Convert_int_int_to_datetime] ( @param_date int, @param_time int )
RETURNS datetime
AS
BEGIN
	RETURN convert( datetime, convert( varchar(25) , @param_date ), 112 ) 
		+ convert( datetime, stuff( stuff( 
				replicate ('0', 6 - len (convert(varchar(25), @param_time )) ) 
				+ convert(varchar(25), @param_time )
			 , 3, 0 , ':') , 6, 0 , ':' ) , 108) 
END
GO

20/10/2020, 17h48
mikedavem

Moi personnellement j'aime bien utiliser la fonction dbo.agent_datetime comme ceci: ^^

Code:

dbo.agent_datetime(run_date,run_time)

++
20/10/2020, 17h54
Invité

Citation:

Envoyé par mikedavem

Moi personnellement j'aime bien utiliser la fonction dbo.agent_datetime comme ceci: ^^

Je ne la connaissais pas encore celle-là !
L'expression « réinventer la roue » prend toute sa signification ici. :mouarf:
21/10/2020, 08h46
SQLpro

Citation:

Envoyé par vanagreg

Un chouïa mieux que Générix qui stocke les heures minutes secondes en number(6, 2), les 2 décimales étant les secondes. Je suis toujours à la recherche d'une explication rationnelle à ce mystère, tout comme stocker les dates en varchar2(8).

Il y a bien pire !
Extrait d'un de mes audits...
"
HARDIS (logiciel "Reflex") a eu l’idée parfaitement imbécile de séparer la date entre 5 parties :
• siècle, type NUMERIC(2,0);
• année, type NUMERIC(2,0);
• mois, type NUMERIC(2,0);
• jour du mois, type NUMERIC(2,0);
• heure + minute, type NUMERIC(4,0);
ou bien
• heure + minute + seconde, type NUMERIC(6,0).
Ce qui fait qu'une date/heure du logiciel de reflex HARDIS nécessite 25 octets (5 colonnes numérique de taille inférieur ou égale à 9 donc de taille interne 5 octets) alors que le type DATETIME2(0) de SQL Server utilise 6 octets. Soit 4 fois moins. La solution HARDIS, s’avère donc 4 fois plus volumineuse que le type propre !...
De plus, aucun index ne peut être utilisé pour rechercher ou comparer une date qui doit être décortiquée avant d'être manipulée. Il en résulte des temps de réponse catastrophiques...
De plus, certaines dates stockées sont incohérentes rendant les transtypages extrêmement difficiles...

Toutes nos tentatives pour reconstruire des dates cohérentes et donc bien typées se sont heurtées à une problématique de non déterminisme du code. Ce qui implique l’impossibilité d’utiliser des techniques de pointe telles que la colonne calculée indexée ou la vue indexée.
"

Alors vos date en string.... c'est du pipi de chat à côté !

A +
21/10/2020, 09h13
vanagreg

Pas mal en effet. J'ai connu Hardis à l'époque par leur logiciel Adelia 400 sur AS/400. Mais as-tu au moins pu obtenir une réponse à ce choix de stockage? Pourquoi? Quel intérêt? Un pari perdu? Une vengeance?
21/10/2020, 12h25
SQLpro

Citation:

Envoyé par vanagreg

Pas mal en effet. J'ai connu Hardis à l'époque par leur logiciel Adelia 400 sur AS/400. Mais as-tu au moins pu obtenir une réponse à ce choix de stockage? Pourquoi? Quel intérêt? Un pari perdu? Une vengeance?

C'est effectivement lié à leur atelier de crétinisme logiciel" ADELIA et transposé de AS 400 en table pseudo relationnelles (nombreuses sont celles sans clé) avec des centaines de colonnes et 80% de redondance !!!!

A +