Le présent texte ne prétend pas résoudre l'ensemble de la problématique de la gestion efficace d'une base de données en quelques lignes. Son ambition est juste de présenter un exemple simple de maintenance automatisée d'une base de données SQL Server 2000©. Le lecteur pourra s'en inspirer afin d'établir une stratégie de maintenance efficace pour la situation à laquelle il est confronté. En tout état de cause, ce texte ne doit pas être vu comme une "recette de cuisine", l'objectif est avant tout d'expliquer des concepts.
SQL Server 2000© est fourni en standard avec deux outils puissants qui vont nous permettre de répondre à la question posée dans le titre de l'article ; il s'agit de l'Enterprise Manager et du SQL Server Agent. Pour le premier, il est présent sur le cdrom d'installation, il faut juste s'assurer de l'avoir installé (il est alors présent dans le menu Microsoft SQL Server). L'Enterprise Manager n'est pas fourni avec MSDE. Concernant le SQL Server Agent, c'est un service qui peut être piloté depuis le SQL Server Service Manager (l'icône qui s'installe dans le système tray, à gauche de l'horloge). Le plus commode est de cocher la case visant à le faire démarrer automatiquement avec Windows.
L'Enterprise Manager nous permettra de paramétrer facilement les opérations de maintenance tandis que c'est bien le SQL Server Agent qui les effectuera.
Dans l'Enterprise Manager, créons un nouveau plan de maintenance.
La base de données Master contient des informations essentielles au bon fonctionnement de SQL Server. Elle n'est modifiée qu'occasionnellement, lors d'opérations sur les bases de données mêmes (création d'une nouvelle etc.). Cependant, vu sa taille très modeste et son caractère indispensable, nous l'incluons dans notre plan de maintenance. Evidemment, il faut aussi sélectionner la ou les bases de données Mercator (ici "Mercatorfullv4").
Les options que nous sélectionnerons par la suite libéreront un espace potentiellement considérable mais qui restera cependant, sur le disque dur, toujours affecté à la base de données. Cocher l'option "Supprimer l'espace inutilisé des fichiers de base de données" permet de rendre cet espace à nouveau disponible pour d'autres applications. De façon logique, cette opération doit être planifiée de façon à s'exécuter en dernier (ici tous les jours à 1h du matin).
Cet écran permet de paramétrer le backup des bases de données en tant que telles. Dans notre exemple, on le planifie pour qu'il se déroule en premier, à minuit tous les jours.
L'option ci-dessus est très intéressante car elle permet d'effacer automatiquement les backup trop anciens (ici, ceux qui ont plus de 4 semaines).
L'ensemble des opérations effectuées sur une base de donnée SQL Server est réalisé au travers de transactions. Au cas ou il est impossible de terminer une transaction, le serveur SQL annule toute la partie de la transaction déjà effectuée. C'est ce que l'on appelle un "roll back". Il est également possible de réaliser l'opération inverse : réappliquer les transactions à une base de données, on parle alors de "roll forward". L'intérêt est par exemple de rétablir un backup pour ensuite restaurer les transactions jusqu'à une certaine heure, moment où une mauvaise manipulation a été effectuée. Pour ce faire, SQL Server stock un journal des transactions qui enregistre l'ensemble des transactions effectuées.
Par défaut, une base de données MSDE est paramétrée selon un modèle de récupération simple, une base de données SQL Server l'est selon le modèle complet ("full recovery model"). Dans ce dernier modèle, le journal des transactions n'est jamais effacé, sauf lorsque l'on en réalise un backup. Dans le premier, les transactions sont effacées au fur et à mesure de leur achèvement. Le journal des transactions étant paramétré par défaut pour croître indéfiniment, on comprend donc bien l'intérêt de réaliser un backup du journal des transactions sur une base régulière dans le cas où on opte pour le modèle complet.
A noter que, peut importe le modèle choisi, le fichier du journal des transactions ne diminue jamais de taille. Tout au plus écrase-t-il d'anciennes transactions avec des nouvelles. Pour qu'il diminue de taille, il faut "compacter la base de données" ("shrink database"). Cette opération est effectuée automatiquement si vous avez bien coché " Supprimer l'espace inutilisé des fichiers de base de données" au début du wizard.
L'option d'effacement automatique des anciens backups est également disponible ici.
Une fois que votre plan de maintenance est entièrement configuré, il est conseillé de vérifier régulièrement qu'il s'exécute correctement. Il pourrait par exemple arriver que l'Agent SQL Server ne se charge par correctement au démarrage. Pour vous aider à identifier les problèmes, chaque plan de maintenance a un journal d'erreurs associé. Celui-ci indiquera par exemple systématiquement une erreur du type "Backup can not be performed on this database. This sub task is ignored" lors du backup d'une base de données configurée selon le modèle de récupération simple. C'est notamment le cas de la base de données Master. A ce stade, le lecteur aura compris que cette erreur est logique et sans conséquence. Elle peut cependant être évitée en créant deux plans de maintenance distincts, l'un avec et l'autre sans backup du journal des transactions. Selon le modèle de récupération des différentes bases de données, on en confierait la maintenance au plan de maintenance idoine.