Le Blog SQL Server d'ElSüket » Agent SQL Server

Pourquoi je ne peux pas être supporter de l’utilisation des plans de maintenance en production

elsuket — Wed, 18 Jul 2012 17:27:08 +0000

Voici une énumération des raisons qui font que jusque ici, je n’ai jamais donné mon aval à la création de plans de maintenance sur des instance SQL Server de production :

=> Les plans de maintenance ne sont pas portables : il est impossible de déployer simplement sur plusieurs instances de SQL Server un même plan de maintenance en une seule fois. D’autre part, une fois la copie réalisée, il est nécessaire de mettre à jour la chaîne de connexion qui est dans celui-ci, et qui correspond a l’instance sur laquelle celui-ci a été créé. Enfin, on peut se heurter à des problèmes d’intégrité des données référentielle dans la base de données système msdb, ce que le DBA (trop) prudent que je suis se refuse catégoriquement à réaliser.

=> Lorsqu’on supprime un plan de maintenance, le package SSIS est supprimé, mais pas le travail de l’Agent SQL Server qui lui est attaché

=> A chaque fois que quelqu’un crée ou modifie un plan de maintenance, il est nécessaire de changer de nouveau le propriétaire de celui-ci et/ou du travail de l’Agent SQL Server qui est attaché à ce plan, car celui-ci est écrasé automatiquement par le nom de connexion de l’utilisateur qui réalise l’édition du plan de maintenance

=> Dans les éditions Enterprise de SQL Server 2005, il est impossible d’obtenir l’option CHECKSUM lorsqu’on souhaite réaliser une sauvegarde de base de données. Sous SQL Server 2008, ce n’est pas possible non plus, mais le CHECKSUM est calculé lorsqu’on active la compression des sauvegardes de base de données.

=> En ce qui concerne la maintenance des statistiques, il est impossible d’indiquer le niveau d’échantillonnage par défaut. D’autre part, l’échantillonnage est soit annulé (FULL), soit il est identique pour toutes les tables, ce qui n’est pas optimal

=> Quand on connaît les dégâts que peuvent causer un rétrécissement de base de données, on comprend qu’une telle tâche ne devrait tout simplement pas exister

=> Les tâches de défragmentation et de reconstruction des index ne permettent pas de spécifier des valeurs seuil pour lesquelles il est préférable de défragmenter plutôt que de reconstruire un index, et inversement.

=> La vérification de l’intégrité des bases de données ne permet malheureusement pas de spécifier le niveau de vérification avec lequel on souhaite l’effectuer.

En revanche les tâches de nettoyage des fichiers, d’envoi de notification à un opérateur, d’exécution d’un travail de l’Agent SQL Server, d’exécution de script T-SQL ou de l’historique sont plutôt bien conçues, même si pour la dernière j’aurai préféré pouvoir spécifier une durée de rétention par type d’historique.

Pour toutes ces raisons, je proscris pour le moment l’utilisation des plans de maintenance sur les serveurs de production, pour lesquels j’ai développé un ensemble de procédures stockées qui me permet de réaliser juste le minimum.

Je pense que les plans de maintenance sont un très bon moyen d’assurer un niveau minimal de qualité d’une base de données avec un minimum d’effort, et sont appropriés pour des serveurs de développement ou des test peu importants, mais pas (encore ?) pour des instances de SQL Server qui supportent la production.

Attention donc à ne pas utiliser les plans de maintenance à tors et à travers

ElSüket.

Connaître la longueur maximale des lignes des tables, et calculs relatifs

elsuket — Tue, 06 Oct 2009 17:10:14 +0000

Il est intéressant de connaître la longueur maximale qui peut être stockée par une table pour tenter de prévoir la taille d’une base de données lorsque le système sera arrivé à maturité.
Voici une petite requête pour nous y aider sous SQL Server 2005 et 2008…

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

-------------------------------
-- Nicolas SOUQUET - 06/10/2009
-------------------------------
SELECT nomTable,
longueurLigne,
8060 / longueurLigne AS nbLignesParPage,
longueurLigne * (8060 / longueurLigne) AS nbMaxOctetsParPage,
8060 - (longueurLigne * (8060 / longueurLigne)) nbOctetsPerdusParPage,
(longueurLigne + longueurLigne % 8060) / 8060 AS nbPagesStockeLigne
FROM
(
SELECT T.name AS nomTable,
SUM(C.max_length) AS longueurLigne
FROM sys.tables AS T
JOIN sys.columns AS C
ON T.object_id = C.object_id
JOIN sys.types AS TY
ON C.user_type_id = TY.user_type_id
GROUP BY T.name
) AS TMP (nomTable, longueurLigne)

ElSuket

Une requête pour lister tous les travaux de l’Agent SQL Server avec leur caractéristiques d’exécution

elsuket — Mon, 30 Jul 2012 14:20:45 +0000

Voici une requête qui permet de lister tous les jobs existant sur une instance SQL Server :

– toutes leurs étapes
– la définition de ces étapes (appel à une procédure stockée, exécution d’un package SSIS, …)
– la date et l’heure de la prochaine fois que le job sera exécuté
– la fréquence à laquelle l’exécution du job est planifiée, si le job a une planification
– la date à laquelle le job job a été créé, et à laquelle il a été modifié pour la dernière fois

-------------------------------
-- Nicolas Souquet - 30/07/2012
-------------------------------
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED
GO

SELECT J.name AS job_name
, JS.step_name
, JS.command
, JS.database_name AS database_context
, NR.next_run_date_time
, CASE J.enabled WHEN 1 THEN 'YES' ELSE 'NO' END AS job_is_enabled
, CASE S.enabled WHEN 1 THEN 'YES' ELSE 'NO' END AS job_is_scheduled
, SP.name AS owner_login_name
, CASE S.freq_type
WHEN 1 THEN 'Once'
WHEN 4 THEN 'Daily'
WHEN 8 THEN 'Weekly'
WHEN 16 THEN 'Monthly'
WHEN 32 THEN 'Monthly relative'
WHEN 64 THEN 'When SQL Server Agent starts'
WHEN 128 THEN 'Start whenever the CPU(s) become idle'
END AS frenquency
, CASE S.freq_type
WHEN 1 THEN 'One time only'
WHEN 4 THEN 'Every ' + CASE CONVERT(varchar, S.freq_interval) WHEN '1' THEN 'day' ELSE 'days' END
WHEN 8 THEN 'Every ' + CASE CONVERT(varchar, S.freq_recurrence_factor) WHEN '1' THEN 'week' ELSE 'weeks' END + ' on ' + D.freq_day_concat
WHEN 16 THEN 'Day ' + CONVERT(varchar, S.freq_interval) + ' of every '
+ CASE CONVERT(varchar, S.freq_recurrence_factor) WHEN '1' THEN ' month' ELSE ' months' END
WHEN 32 THEN 'The ' + CASE S.freq_relative_interval
WHEN 1 THEN 'first'
WHEN 2 THEN 'second'
WHEN 4 THEN 'third'
WHEN 8 THEN 'fourth'
WHEN 16 THEN 'last'
END
+ ' '
+ CASE S.freq_interval
WHEN 1 THEN 'Sunday'
WHEN 2 THEN 'Monday'
WHEN 3 THEN 'Tuesday'
WHEN 4 THEN 'Wednesday'
WHEN 5 THEN 'Thursday'
WHEN 6 THEN 'Friday'
WHEN 7 THEN 'Saturday'
WHEN 8 THEN 'Day'
WHEN 9 THEN 'Weekday'
WHEN 10 THEN 'Weekend Day'
END
+ ' of every '
+ CASE CONVERT(varchar, S.freq_recurrence_factor) WHEN '1' THEN ' month' ELSE ' months' END
END + CASE S.freq_subday_type
WHEN 1 THEN ', once, at ' + AT.start_time
WHEN 2 THEN ', every ' + CONVERT(varchar(10), S.freq_subday_interval)
+ ' seconds, starting at ' + AT.start_time
+ ' ending at ' + AT.end_time
WHEN 4 THEN ', every ' + CONVERT(varchar(10), S.freq_subday_interval) + ' minutes, from '
+ AT.start_time + ', to ' + AT.end_time
WHEN 8 THEN ', every ' + CONVERT(varchar(10), S.freq_subday_interval) + ' hours, starting at '
+ AT.start_time + ', ending at ' + AT.end_time
END AS frequency_detail
, CASE
WHEN S.freq_type = 1 THEN 'On date: ' + AD.active_start_date + ' At time: '
+ AT.start_time
WHEN S.freq_type < 64 THEN 'Start date: ' + AD.active_start_date +
+ CASE AD.active_end_date
WHEN '31/12/9999' THEN ' - No end date'
ELSE ' - End date: ' + AD.active_end_date
END
END AS date_range
, CASE C.name WHEN '[Uncategorized (Local)]' THEN 'Uncategorized' ELSE C.name END AS job_category_name
, J.description AS job_description
, J.date_created
, J.date_modified
FROM msdb.dbo.sysjobs AS J
INNER JOIN msdb.dbo.sysjobsteps AS JS
ON J.job_id = JS.job_id
INNER JOIN msdb.dbo.sysjobschedules AS JSCH
ON J.job_id = JSCH.job_id
INNER JOIN msdb.dbo.sysschedules AS S
ON JSCH.schedule_id = S.schedule_id
INNER JOIN msdb.dbo.syscategories AS C
ON J.category_id = C.category_id
LEFT JOIN sys.server_principals AS SP
ON SP.sid = J.owner_sid
OUTER APPLY (
SELECT freq_day + ', '
FROM (
SELECT CASE WHEN S.freq_interval & 1 = 1 THEN 'Sunday' ELSE '' END AS freq_day
UNION ALL SELECT CASE WHEN S.freq_interval & 2 = 2 THEN 'Monday' ELSE '' END
UNION ALL SELECT CASE WHEN S.freq_interval & 4 = 4 THEN 'Tuesday' ELSE '' END
UNION ALL SELECT CASE WHEN S.freq_interval & 8 = 8 THEN 'Wednesday' ELSE '' END
UNION ALL SELECT CASE WHEN S.freq_interval & 16 = 16 THEN 'Thursday' ELSE '' END
UNION ALL SELECT CASE WHEN S.freq_interval & 32 = 32 THEN 'Friday' ELSE '' END
UNION ALL SELECT CASE WHEN S.freq_interval & 64 = 64 THEN 'Saturday' ELSE '' END
) AS S
WHERE LEN(freq_day) > 0
FOR XML PATH ('')
) AS D (freq_day_concat)
OUTER APPLY (
SELECT STUFF(STUFF(REPLICATE('0', 6 - LEN(S.active_start_time))
+ CAST(S.active_start_time AS varchar(6)), 3, 0, ':'), 6, 0, ':') AS start_time
, STUFF(STUFF(REPLICATE('0', 6 - LEN(S.active_end_time))
+ CAST(S.active_end_time AS varchar(6)), 3, 0, ':'), 6, 0, ':') AS end_time
) AS AT
OUTER APPLY (
SELECT CONVERT(char(10), CAST(CAST(S.active_start_date AS char(8)) AS date), 103) AS active_start_date
, CONVERT(char(10), CAST(CAST(S.active_end_date AS char(8)) AS date), 103) AS active_end_date
) AS AD
OUTER APPLY (
SELECT CAST(NULLIF(JSCH.next_run_date, 0) AS char(8)) + ' '
+ STUFF(STUFF(REPLICATE('0', 6 - LEN(JSCH.next_run_time)) + CAST(JSCH.next_run_time AS char(6)), 3, 0, ':'), 6, 0, ':') AS next_run_date_time
) AS NR
WHERE 1 = 1
--AND J.name LIKE '%unMot%'
--AND JS.database_name = 'uneBD'
--AND J.enabled = 1
ORDER BY J.name, JS.step_id

Bonne planification de job à tous !

ElSüket

Le petit lien qui fait du bien dans l’historique des jobs de l’Agent SQL Server 2012

elsuket — Thu, 19 Apr 2012 17:52:22 +0000

Un petit lien bien agréable a été ajouté dans la visionneuse de l’historique des jobs de SQL Server dans la version 2012 de SQL Server Management Studio

On peut consulter l’historique d’un job simplement en effectuant un clic-droit sur le job en question :

La fenêtre du journal s’ouvre alors :

Et ce nouveau lien nous permet d’accéder directement à la définition du job, ce qui n’était pas la cas jusqu’à SQL Server Management Studio 2008 :

Bonne gestion des jobs !

@++

Gestion et lecture des journaux d’événements de SQL Server

elsuket — Mon, 19 Sep 2011 17:00:00 +0000

Voici quelques procédures stockées systèmes et quelques suites de clics dans SQL Server Management Studio pour gérer un peu plus finement les fichiers d’information et d’erreur du moteur de bases de données de SQL Server, et de l’Agent SQL Server.

Commençons d’abord par l’emplacement de ces fichiers, qui sont en fait de simples fichiers texte : par défaut il s’agit de :
C:\Program Files\Microsoft SQL Server\MSSQL.n\MSSQL\LOG\

Le .n indique le numéro de l’instance s’il s’agit d’une instance nommée : dans le cas contraire, le .n est absent.
On trouve dans ce dossier :

=> Des fichiers ERRORLOG et ERRORLOG.[n], où [n] est un entier qui est d’autant plus grand qu’il est ancien.
Ce sont les fichiers de journaux d’erreurs de moteur de base de données.
Si la configuration des journaux d’événements n’a jamais été modifiée, on a ERRORLOG.6, car comme nous allons le voir, SQL Server ne conserve que 6 journaux d’erreur.

=> Des fichiers SQLAGENT et SQLAGENT.[n], où [n] est utilisé de la même façon que précédemment.
On l’aura compris, ces fichiers sont les journaux d’événements de l’Agent SQL Server.

=> Des fichiers FDLAUNCHERRORLOG et FDLAUNCHERRORLOG.[n], qui sont les journaux d’événements du moteur de recherche en texte intégral de SQL Server.

=> Des fichiers log_xx.trc, qui sont les fichiers de trace SQL Profiler par défaut de SQL Server.
En effet une trace SQL Profiler est démarrée par défaut à chaque démarrage d’un instance SQL Server.
En interrogeant la vue système sys.traces, vous verrez que cette trace est toujours démarrée et porte l’id de valeur 1.

Tous les fichiers présents dans ce répertoire sont interprétables par n’importe quel éditeur texte, à l’exception des fichiers de trace par défaut.
On peut ouvrir ces derniers directement par un double-clic qui exécutera SQL Profiler.

Dans ce billet nous nous limiterons à la gestion des fichiers d’événements :
– du moteur de bases de données SQL Server
– de l’Agent SQL Server

On peut tout à fait changer le nombre de journaux d’erreur à converser, et on peut aussi automatiser leur renouvellement, par exemple avec un fichier par jour.
Cela permet, lorsqu’on audite ces fichiers ou qu’on conduit des investigations à la suite d’un problème, d’avoir un fichier de journal assez petit, en ne se focalisant que sur un seul jour.

Voyons d’abord comment lire ces fichiers journaux à l’aide de SQL Server Management Studio.
Après avoir ouvert l’Explorateur d’Objets (F8), le nœud Gestion une fois développé, nous affiche un nœud Journaux SQL Server:

Un double-clic sur l’un d’entre eux affiche leur contenu, et on peut accéder aux autres journaux à partir du même dialogue :

A partir de cette fenêtre, on voit que l’on peut visualiser plusieurs types de journaux :

– Ceux de l’Agent SQL Server
– Ceux du moteur de bases de donnée relationnelles
– Ceux de Windows
– Ceux de la messagerie de bases de données

On peut bien sûr mélanger le contenu de plusieurs journaux de types différents, ce qui peut aider à corréler les tenants et aboutissants d’un événement touchant à SQL Server.

Enfin, à l’aide des boutons de la barre d’outils, il est possible de restreindre les dates entre lesquelles on souhaite afficher les messages, et aussi de rechercher dans le contenu de ceux-ci.
Ces deux fonctions sont assez rapides si la machine et SQL Server fonctionnent correctement, mais il en va parfois tout autrement lorsque des problèmes surviennent.
En effet, il m’est arrivé de devoir lire des fichiers de journaux faisant plusieurs centaines de Mo, et il est impossible d’arrêter la Visionneuse de Journaux, à moins de décocher tous les journaux, ce qui n’affiche plus rien. C’est là l’intérêt de gérer ces fichiers.

Voyons donc comment augmenter (ou diminuer) le nombre de journaux d’erreurs.
Dans l’Explorateur d’Objets (F8), après avoir développé le nœud Gestion, il suffit de faire un clic-droit sur Journaux SQL Server puis de choisir l’option Configurer :

On remarque que l’étiquette portée par les fichiers journaux comporte la date de dernière écriture dans le fichier.
Par défaut la case Limiter le nombre de fichiers de journaux d’erreurs avant qu’ils ne soient recyclés n’est pas cochée.
Dès lors qu’on la coche, on est libre de spécifier le nombre de journaux que l’on souhaite conserver :

Je le mets toujours au maximum, 99, parce que je l’assortis d’un job de l’Agent SQL Server pour recycler les journaux (ce que nous allons voir par la suite).
En scriptant le changement, on obtient le script suivant :

1
2
3
4

USE [master]

GO

EXEC xp_instance_regwrite N'HKEY_LOCAL_MACHINE', N'Software\Microsoft\MSSQLServer\MSSQLServer', N'NumErrorLogs', REG_DWORD, 99

GO

C’est à dire que le nombre de journaux de l’instance SQL Server n’est pas stocké dans une des bases de données système (on aurait pu le stocker dans la base de données master ou msdb).

La procédure stockée sp_cycle_errorlog permet de forcer la création d’un nouveau fichier de journal.
Le cas échéant, elle supprime également le fichier de journal le plus ancien si son numéro incrémenté dépasse le nombre de journaux que l’on a spécifié vouloir conserver.
On peut donc créer un job de l’Agent SQL Server qui s’exécute tous les jours à minuit pour forcer la création d’un nouveau journal d’erreur.
Créons donc ce job, ce que l’on peut faire très simplement par un clic-droit sur le nœud Agent SQL Server de l’Explorateur d’Objets :

On spécifie le nom du job, et un petit commentaire sur le rôle du job ne fait jamais de mal :

Puis on peut passer à la page Étapes :

EDIT 09/02/2012: il faut mettre le contexte de base de données à msdb, et non pas le laisser sur master

On peut ensuite basculer dans la page Planifications.
Après avoir cliqué sur le bouton Nouvelle, on obtient la fenêtre suivante :

En cliquant sur OK dans ce dialogue et dans le dialogue parent (Propriétés du travail), on valide la création du travail.
On le trouve dès lors dans l’Explorateur d’Objets dans la liste des travaux :

On remarque au passage le nœud Journaux d’erreurs, enfant du nœud Agent SQL server : c’est à partir de celui-ci que l’on peut lire les journaux de l’Agent SQL Server :

De la même façon, il est possible de configurer la rétention d’informations :

Comme on le voit, à la différence des options pour les journaux du moteur de bases de données relationnelles, il est ici possible de recycler les journaux de l’Agent SQL Server.

Cette fois, c’est la procédure stockée sp_cycle_agent_errorlog qui permet de forcer le recyclage des journaux de l’Agent SQL Server.
On peut donc tout à fait l’ajouter en seconde étape de notre travail DBA – Cycle Event Logs :

Après avoir cliqué sur Nouveau …, on peut modifier le travail pour la régénération des journaux de l’Agent SQL Server :

Une fois que l’on a cliqué sur OK, puis de la même façon dans le dialogue parent (Propriétés du travail), le travail est maintenant modifié pour renouveler les journaux du moteur de bases de données et de l’Agent SQL Server, tous les jours à minuit.

Il est enfin possible de lire les fichiers journaux de ces deux types (SGBDR et Agent) à l’aide de la procédure stockée étendue système xp_readerrorlog, qui n’est pas documentée.
Comprenez par là que l’utilisation à vos risques et périls, et que rien ne garantit que Microsoft mettra toujours à disposition cette fonctionnalité dans une future version de SQL Server.
Ici on peut se permettre de l’utiliser car cela n’a aucun impact sur le moteur de bases de données : on ne fait que de la lecture de fichiers texte qui sont stockés en dehors des structures de stockage gérées par SQL Server.

Voici donc la document officieuse de cette procédure stockée étendue.
Elle peut prendre quatre paramètres en entrée, qui sont les suivants :

=> le premier indique est un int, et indique l’indice du journal à lire : passez zéro si vous souhaitez lire le journal courant, 1 si vous souhaitez l’archive la plus récente. On peut également de rien passer, et on obtient alors le contenu du fichier de journal du SGBDR courant.
=> le deuxième est un int, et précise le type de journal à lire : passez 1 pour les journaux du SGBDR, et 2 pour l’Agent SQL Server
=> le 3e et le 4e sont des varchar(255), et sont tous deux des chaînes à rechercher dans le contenu des messages.

Vous l’aurez compris, aucun des paramètres n’est obligatoire.
Comme il s’agit d’une procédure stockée étendue, il est impossible d’en obtenir le nom des paramètres, ce qui fait que tout appel se fait par une suite de valeurs.

Si l’on souhaite donc chercher les échecs d’authentification dans le journal courant du SGBDR, on exécutera :

EXEC xp_readerrorlog 0, 1, 'Failed', 'login'

Bonnes investigations des journaux SQL Server !

ElSüket

Trouver et changer le propriétaire d’un job de l’Agent SQL Server

elsuket — Sun, 27 Nov 2011 06:44:21 +0000

Fonctionnalité pratique pour ne pas dire nécessaire, l’Agent SQL Server est le planificateur de tâches de SQL Server.
Il permet d’effectuer des tâches très variées, qui vont de l’exécution d’une procédure stockée à celle d’un script PowerShell en passant par celle d’un package SQL Server Integration Services et bien d’autres, et ce, à intervalles de temps réguliers et planifiés.

Côté sécurité, cette fonctionnalité n’est pas en reste, puisque tout job a un propriétaire.
Il est donc requis de vérifier que le propriétaire d’un job à les droits nécessaires à l’exécution de celui-ci.

Cela peut se faire de deux façons : par l’interface graphique de SQL Server Management Studio, ou bien en requêtes.
Voyons cela plus en détails :

=> Par des requêtes

Voici la requête qui permet de trouver le propriétaire de tous les jobs :

1
2
3
4
5
6
7
8
9

-------------------------------
-- Nicolas Souquet - 27/11/2011
-------------------------------
SELECT J.name AS job_name
, SP.name AS job_owner_name
FROM msdb.dbo.sysjobs AS J
INNER JOIN sys.server_principals AS SP
ON SP.sid = J.owner_sid
WHERE J.name = 'monJob'

En dé-commentant la dernière ligne, on peut trouver le propriétaire d’un job en particulier.

Si l’on souhaite le changer, il suffit d’exécuter :

1
2
3
4
5
6

UPDATE msdb.dbo.sysjobs
SET owner_sid = SP.sid
FROM msdb.dbo.sysjobs AS J
CROSS JOIN sys.server_principals AS SP
WHERE J.name = 'monJob'
AND SP.name = 'nomDeLogin'

Et le tour est joué

=> Par l’interface graphique :

Il suffit de se rendre dans les propriétés du job en question :

Une fenêtre s’ouvre alors, montrant le propriétaire du job dans la saisie texte à la même étiquette :

On peut dès lors changer ce propriétaire à l’aide du bouton de parcours des utilisateurs, (les 3 points de suspension à droite ce cette saisie) ou bien saisir un nom de connexion existant.

On trouve les connexions existantes toujours dans l’explorateur d’objets (F8) :

Bonne gestion des connexions et des jobs

ElSüket

Voir l’historique d’exécution des jobs par une requête

elsuket — Fri, 24 Jul 2009 06:00:00 +0000

Si la visionneuse du journal est pratique pour voir l’historique des exécutions d’un job, comment peut-on voir s’il existe des jobs dont l’exécution a échoué (ou réussi) pour pouvoir l’encapsuler dans une application ou un rapport SSRS par exemple ?

Les tables système de la base de données MSDB nous permettent de spécifier une requête nous permettant de retrouver tous les informations dont nous avons besoin à propos des jobs :

– msdb.dbo.sysjobs stocke la liste de tous les jobs présents sur l’instance, qu’ils soient activés ou non
– msdb.dbo.sysjobhistory stocke la liste de toutes les exécutions des jobs et de leurs étapes
– msdb.dbo.sysjobsteps stocke la description de toutes les étapes de tous les jobs de l’instance

Voici donc, par exemple, comment retrouver tous les échecs pour le job nommé ‘TEST’, avec leur date :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

---------------------------------
-- Nicolas SOUQUET - 24/07/2009 -
---------------------------------
SELECT nomJob,
CAST(STUFF(STUFF(runDateTime, 12, 0, ':'), 15, 0, ':') AS DATETIME) AS DateEchecExecJob
FROM
(
SELECT J.name AS nomJob,
CAST(H.run_date AS CHAR(8)) + ' ' +
CASE LEN(CAST(H.run_time AS VARCHAR(6)))
WHEN 5 THEN '0' + CAST(H.run_time AS CHAR(5))
ELSE CAST(H.run_time AS CHAR(6))
END AS runDateTime
FROM msdb.dbo.sysjobs J
JOIN msdb.dbo.sysjobhistory H
ON J.job_id = H.job_id
WHERE J.name = 'TEST'
AND J.enabled = 1 -- Le job est activé
AND H.run_status = 0 -- 0 : Echec | 1 : Réussite
AND H.step_id = 0 -- quelle que soit l'étape du job
) AS JOB_FAILED_EXEC (nomJob, runDateTime)

Et si l’on veut être relativement complet :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

---------------------------------
-- Nicolas SOUQUET - 24/07/2009 -
---------------------------------
SELECT nomJob
, nomEtapeJob
, numeroEtapeJob
, msgEtape
, CAST(STUFF(STUFF(dateExecutionEtape, 12, 0, ':'), 15, 0, ':') AS DATETIME) AS dateExecutionEtape
, dureeExecutionEtape
, statutExecutionEtape
FROM
(
SELECT J.name AS nomJob
, S.step_name AS nomEtapeJob
, S.step_id AS numeroEtapeJob
, ISNULL('Erreur : ' + M.description, H.message) AS msgEtape
, CAST(H.run_date AS CHAR(8)) + ' ' +
CASE LEN(CAST(H.run_time AS VARCHAR(6)))
WHEN 1 THEN '00000' + CAST(H.run_time AS CHAR(1))
WHEN 2 THEN '0000' + CAST(H.run_time AS CHAR(2))
WHEN 3 THEN '000' + CAST(H.run_time AS CHAR(3))
WHEN 4 THEN '00' + CAST(H.run_time AS CHAR(4))
WHEN 5 THEN '0' + CAST(H.run_time AS CHAR(5))
ELSE CAST(H.run_time AS CHAR(6))
END AS dateExecutionEtape
, CASE LEN(CAST(H.run_duration AS VARCHAR(10)))
WHEN 1 THEN '00:00:0' + CAST(H.run_duration AS CHAR(1))
WHEN 2 THEN '00:00:' + CAST(H.run_duration AS CHAR(2))
WHEN 3 THEN '00:0' + STUFF(CAST(H.run_duration AS CHAR(3)), 2, 0, ':')
WHEN 4 THEN '00:' + STUFF(CAST(H.run_duration AS CHAR(4)), 3, 0, ':')
WHEN 5 THEN '0' + STUFF(STUFF(CAST(H.run_duration AS CHAR(5)), 2, 0, ':'), 5, 0, ':')
WHEN 6 THEN STUFF(STUFF(CAST(H.run_duration AS CHAR(6)), 3, 0, ':'), 6, 0, ':')
END AS dureeExecutionEtape
, CASE H.run_status
WHEN 0 THEN 'FAILED'
WHEN 1 THEN 'SUCCESS'
WHEN 2 THEN 'RETRY'
WHEN 3 THEN 'CANCELED'
WHEN 4 THEN 'RUNNING' -- Pas fiable
END AS statutExecutionEtape
FROM msdb.dbo.sysjobs AS J
INNER JOIN msdb.dbo.sysjobsteps AS S
ON J.job_id = S.job_id
INNER JOIN msdb.dbo.sysjobhistory AS H
ON S.job_id = H.job_id
AND S.step_id = H.step_id
LEFT JOIN sys.sysmessages AS M
ON H.sql_message_id = M.error
) AS JOB_CHARACTERISTICS (nomJob, nomEtapeJob, numeroEtapeJob, msgEtape, dateExecutionEtape, dureeExecutionEtape, statutExecutionEtape)

ElSuket

Une procédure stockée pour défragmenter les indexes sous SQL Server 2005 et ultérieur

elsuket — Fri, 05 Jun 2009 16:53:33 +0000

Voici une petite procédure stockée que l’on peut exécuter régulièrement dans un job pour défragmenter les indexes de toutes les bases de données, en fixant les seuils de nombre de page et de pourcentage moyen de fragmentation

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169

---------------------------------
-- Nicolas SOUQUET - 05/06/2009 -
---------------------------------
CREATE PROCEDURE [dbo].[Ps_Indexes_Rebuild]
AS
BEGIN
SET NOCOUNT ON

-- Table dans laquelle on va récupérer les noms et caractéristiques des indexes
DECLARE @Tbindexes TABLE
(
DB SYSNAME,
Tables SYSNAME,
IndexName SYSNAME,
Frag VARCHAR(5),
PageUsage VARCHAR(5),
Pages VARCHAR(10),
FillFactors TINYINT,
Seeks VARCHAR(20),
Scans VARCHAR(20),
LastUserSeek VARCHAR(19),
LastUserScan VARCHAR(19),
IsUniqueConstraint BIT,
IsPadded BIT,
IsHypothetical BIT
)

-- Table dans laquelle on récupère les statistiques des indexes
DECLARE @TbIndexesStats TABLE
(
database_id SMALLINT,
object_id INT,
index_id INT,
avg_fragmentation_in_percent NUMERIC(4,2),
avg_page_space_used_in_percent NUMERIC(4,2),
page_count BIGINT,
user_seeks BIGINT,
user_scans BIGINT,
last_user_seek DATETIME,
last_user_scan DATETIME
);

-- Récupération des stats sur les indexes
WITH CTE_DB AS
(
SELECT database_id
FROM sys.databases
WHERE name NOT IN ('master', 'model', 'msdb', 'tempdb', 'ReportServer', 'ReportServerTempDB', 'distribution')
)
INSERT INTO @TbIndexesStats
SELECT IPS.database_id,
IPS.object_id,
IPS.index_id,
IPS.avg_fragmentation_in_percent,
IPS.avg_page_space_used_in_percent,
IPS.page_count,
IUS.user_seeks,
IUS.user_scans,
IUS.last_user_seek,
IUS.last_user_scan
FROM sys.dm_db_index_physical_stats(NULL, NULL, NULL, NULL, 'SAMPLED') IPS
JOIN CTE_DB ON CTE_DB.database_id = IPS.database_id
JOIN sys.dm_db_index_usage_stats IUS
ON IUS.database_id = IPS.database_id
AND IUS.object_id = IPS.object_id
AND IUS.index_id = IPS.index_id
WHERE IPS.index_id > 0
AND IPS.avg_fragmentation_in_percent > 25.0
AND IPS.page_count > 50

-- Récupération des noms et caractéristiques des indexes
DECLARE @SQL VARCHAR(1024),
@Database_id VARCHAR(10),
@Object_id VARCHAR(10),
@Index_id VARCHAR(10),
@AvgFragInPercent VARCHAR(5),
@AvgPageSpaceUsedInPercent VARCHAR(5),
@PageCount VARCHAR(10),
@User_seeks VARCHAR(20),
@User_scans VARCHAR(20),
@Last_user_seek VARCHAR(19),
@Last_user_scan VARCHAR(19)

DECLARE curDBIndexes CURSOR FOR
SELECT CAST(database_id AS VARCHAR(10)),
CAST(object_id AS VARCHAR(10)),
CAST(index_id AS VARCHAR(10)),
CAST(avg_fragmentation_in_percent AS VARCHAR(5)),
CAST(avg_page_space_used_in_percent AS VARCHAR(5)),
CAST(page_count AS VARCHAR(10)),
CAST(user_seeks AS VARCHAR(20)),
CAST(user_scans AS VARCHAR(20)),
COALESCE(CONVERT(VARCHAR(19), last_user_seek, 120), 'NULL'),
COALESCE(CONVERT(VARCHAR(19), last_user_scan, 120), 'NULL')
FROM @TbIndexesStats
FOR READ ONLY

OPEN curDBIndexes
FETCH NEXT FROM curDBIndexes INTO @Database_id, @Object_id, @Index_id, @AvgFragInPercent,
@AvgPageSpaceUsedInPercent, @PageCount, @User_seeks, @User_scans,
@Last_user_seek, @Last_user_scan
WHILE @@FETCH_STATUS = 0
BEGIN
SET @SQL = 'SELECT DB_NAME(' + @Database_id + '),' +
'O.name,' +
'IDX.name,' +
@AvgFragInPercent + ',' +
@AvgPageSpaceUsedInPercent + ',' +
@PageCount + ',' +
'IDX.fill_factor, ' +
@User_seeks + ',' +
@User_scans + ',''' +
@Last_user_seek + ''',''' +
@Last_user_scan + ''',' +
'IDX.is_unique_constraint, ' +
'IDX.is_padded, ' +
'IDX.is_hypothetical' +
' FROM ' + DB_NAME(CAST(@Database_id AS INT)) + '.sys.indexes IDX' +
' JOIN ' + DB_NAME(CAST(@Database_id AS INT)) + '.sys.objects O ON O.object_id = IDX.object_id' +
' WHERE IDX.object_id = ' + @Object_id +
' AND IDX.index_id = ' + @Index_id

INSERT INTO @Tbindexes
EXEC (@SQL)

FETCH NEXT FROM curDBIndexes INTO @Database_id, @Object_id, @Index_id, @AvgFragInPercent,
@AvgPageSpaceUsedInPercent, @PageCount, @User_seeks, @User_scans,
@Last_user_seek, @Last_user_scan
END
DEALLOCATE curDBIndexes

-- Reconstruction des indexes
DECLARE @DB SYSNAME,
@Tables SYSNAME,
@IndexName SYSNAME,
@FillFactors VARCHAR(5),
@IsPadded BIT,
@RebuildCommand VARCHAR(1024)

DECLARE CUR_INDEXES_TO_REBUILD CURSOR FOR
SELECT DB,
Tables,
IndexName,
CAST(
CASE FillFactors
WHEN 0 THEN 99
ELSE FillFactors
END AS VARCHAR(5)
),
IsPadded
FROM @Tbindexes
FOR READ ONLY

OPEN CUR_INDEXES_TO_REBUILD
FETCH NEXT FROM CUR_INDEXES_TO_REBUILD INTO @DB, @Tables, @IndexName, @FillFactors, @IsPadded
WHILE @@FETCH_STATUS = 0
BEGIN
SELECT @RebuildCommand = 'ALTER INDEX ' + @IndexName + ' ON ' + @DB + '.dbo.' + @Tables +
' REBUILD WITH (FILLFACTOR = ' + @FillFactors +
CASE @IsPadded
WHEN 1 THEN ', PAD_INDEX = ON)'
ELSE ')'
END

EXEC (@RebuildCommand)
FETCH NEXT FROM CUR_INDEXES_TO_REBUILD INTO @DB, @Tables, @IndexName, @FillFactors, @IsPadded
END
DEALLOCATE CUR_INDEXES_TO_REBUILD
END

ElSuket

Suivre les plans de maintenance

elsuket — Thu, 09 Jul 2009 20:15:56 +0000

Comment savoir si un plan de maintenance s’est correctement exécuté ?
Comment savoir combien de temps a duré son exécution ?

Une requête simple dans la base de données système MSDB nous donne la réponse …
Valable sous SQL Server 2000 et ultérieur

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

---------------------------------
-- Nicolas SOUQUET - 09/07/2009 -
---------------------------------
SELECT plan_name,
database_name,
activity,
start_time,
end_time,
CASE LEN(CAST(duration / 3600 AS VARCHAR(4)))
WHEN 1 THEN '0' + CAST(duration / 3600 AS VARCHAR(4))
ELSE CAST(duration / 3600 AS VARCHAR(4))
END + ':' +
CASE LEN(CAST(duration / 60 % 60 AS VARCHAR(2)))
WHEN 1 THEN '0' + CAST(duration / 60 % 60 AS VARCHAR(2))
ELSE CAST(duration / 60 % 60 AS VARCHAR(2))
END
+ ':' +
CASE LEN(CAST(duration % 60 AS VARCHAR(2)))
WHEN 1 THEN '0' + CAST(duration % 60 AS VARCHAR(2))
ELSE CAST(duration % 60 AS VARCHAR(2))
END Durée
FROM msdb.dbo.sysdbmaintplan_history
WHERE succeeded = 0 -- 0 : échec | 1 : réussite
-- AND start_time BETWEEN '20090907' AND '20090908'
ORDER BY database_name, start_time

Il est dès lors facile de placer cette requête dans un DataSet sous Reporting Services ou dans une application WinForms pour pouvoir s’afficher l’état des plans de maintenance qui doivent avoir lieu sur une instance de SQL Server

ElSuket

[Agent SQL Server] Gestion de l’historique

elsuket — Fri, 05 Dec 2008 23:01:50 +0000

Outre sa principale fonctionnalité de gestion d’exécutions, l’Agent SQL Server comporte quelques fonctionnalités intéressantes concernant la gestion de son historique.

Par défaut, l’historique pour chaque job est configuré à un maximum de 100 lignes, et de 1000 lignes pour tous les jobs.
Donc si votre job s’exécute plus de 100 fois par jour, et que vous arrivez au travail en souhaitant voir si celui-ci s’est correctement exécuté pendant que vous dormiez paisiblement, c’est râpé

En choisissant l’option « Propriétés » par clic-droit sur la node « SQL Server Agent » sous SQL Server Management Studio, voici ce que l’on trouve :

Autre désagrément : l’historique concernant un job est assez long, par exemple si vous exécutez un job une fois par semaine depuis des mois.
Vous souhaitez maintenant purger l’historique, pour voir ce qui se passera la semaine prochaine, d’un coup d’oeil :

Vous pouvez également supprimer de l’historique les lignes qui sont plus vieilles qu’une date de votre choix, avec l’option « Supprimer l’historique avant » :