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:
TACHE | PARAMETRE | CIBLE | VALEUR |
‘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 :
- Production SQL Server : Sauvegardes (Benjamin VESAN) [SQL Server]
- Production SQL Server: Suivi et Contrôle du parc (Benjamin VESAN) [SQL Server]
- Production SQL Server : banalisation des instances (Benjamin VESAN) [SQL Server]
- Production SQL Server : Contrôle de cohérence (Benjamin VESAN) [SQL Server]
- Production SQL Server : L’approche (Benjamin VESAN) [SQL Server]