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.