0

Production SQL Server : Ordonnancement

twitterlinkedinmail

Second article de la série Une approche pragmatique de la production SQL Server, il s’agit ici de voir comment gérer efficacement l’automatisation des tâches de maintenance.
Inutile de réinventer la roue:

  • Si un ordonnanceur est déjà en place dans le Système d’Informations ($Universe, Control-M, OPC…), le suivi des tâches ordonnancées est  a priori déjà assuré. Les tâches de maintenance SQL Server seront donc gérées (déployées, exécutées, surveillées) par une équipe experte.
  • Sinon, l’ordonnanceur de SQL Server, SQL Agent, convient tout à fait, à condition de mettre en place la remonté des erreurs d’exécution de tâches et de surveiller que l’Agent est toujours opérationnel. L’utilisation du mécanisme  natif centralisation de tâches SQL Agent, MSX/TSX, facilitera le déploiement et la mise à jour des tâches (voir par exemple cet article pour la mise en place de MST/TSX).

La tâche exécutée par l’ordonnanceur doit être la plus générique possible pour que sa maintenance reste simple. Pas question par exemple d’avoir à mentionner à chaque appel le nom des bases sur lesquelles effectuer les sauvegardes.
Il existe un moyen simple de répondre à ce besoin: la table de paramètre.
Sur toutes les instances du parc, une table contenant les paramètres de chaque tâche permettra de définir le périmètre et les options de chaque tâche:

TACHEPARAMETRECIBLEVALEUR
‘Sauvegarde’‘Chemin’‘Défaut’‘E:\sauvegardes’
‘Sauvegarde’‘Chemin’‘model’‘C:\temp’
‘Sauvegarde’‘Exclusion’‘base_temp’

En se basant sur l’exemple, la tâche de sauvegarde se déroule donc comme ceci:
Pour chaque base:
S’il existe une ligne ‘Sauvegarde’, ‘Exclusion’, <nom de la base> alors je ne sauvegarde pas cette base
S’il existe une ligne ‘Sauvegarde’, ‘Chemin’, <nom de la base> alors j’utilise le chemin indiqué.
Sinon, j’utilise le chemin indiqué dans la ligne ‘Sauvegarde’, ‘Chemin’, ‘Défaut’

Pour que la tâche soit maintenable facilement, deux possibilités:

  • Le script exécuté est stocké sur un répertoire partagé, accessible par tous les SQL Agent du parc. La définition du script n’est pas dupliquée, il n’existe donc qu’une seule version.
  • Le script se contente d’appeler une Procédure Stockée, déployée sur chaque instance. Cette méthode a ma préférence puisque le DBA aura accès depuis Management Studio au code et pourra facilement exécuter ces tâches manuellement.

Continuez votre lecture sur le blog :

twitterlinkedinmail

Benjamin VESAN

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.