Plan de maintenance du serveur SQL - Meilleures pratiques sur les tâches et la planification
Je suis chargé d'élaborer un plan de maintenance pour nos bases de données Sql Server 2005. Je sais que pour les sauvegardes, je veux effectuer une sauvegarde quotidienne complète de la base de données et des sauvegardes du journal des transactions toutes les 15 minutes. Mon problème vient de déterminer quelles autres tâches je veux faire et à quelle fréquence je dois les faire.
Donc, jusqu'à présent, je pense à cela. Corrigez-moi s'il y a des défauts dans ma façon de penser ou une meilleure façon de le faire.
- Sauvegarde - Toutes les tables, sauvegarde complète (quotidienne)
- Sauvegarde - Tables sélectionnées, sauvegarde complète (toutes les heures)
- Sauvegarde - Journaux des transactions (toutes les 15 minutes)
- Vérifier l'intégrité de la base de données (quotidiennement)
- Réorganiser l'indice (quotidiennement)
- Mettre à jour les statistiques (quotidiennement)
- Rétrécir la base de données (hebdomadaire)
- Indice de reconstruction (hebdomadaire)
- Nettoyage d'entretien (quotidien)
Je me suis souvenu avoir lu il y a quelque temps (lorsque j'ai mis en place un plan similaire pour un autre travail) que certaines de ces tâches n'ont pas besoin d'être exécutées quotidiennement ou ne devraient pas l'être quotidiennement. Quant à celles qui m'échappent. Je pourrais utiliser quelques conseils pour créer un meilleur plan de maintenance qui réduira la perte de données en cas de catastrophe, mais ne taxera pas le système lors de son fonctionnement pendant les heures de pointe (et augmentera également les performances).
Josh,
Il s'agit d'une tâche très courante pour tous les administrateurs de base de données et la bonne réponse n'est PAS la même pour chacun et pour chaque serveur. Comme beaucoup d'autres choses, cela dépend de ce dont vous avez besoin.
Vous ne voulez certainement pas exécuter "Shrink Database" comme déjà suggéré. Son EVIL à la performance et la référence ci-dessous vous montreront pourquoi. Il provoque une fragmentation du disque et de l'index, ce qui peut entraîner des problèmes de performances. Il est préférable de pré-allouer une grande taille pour les fichiers de données et les journaux afin que la croissance automatique ne démarre PAS.
Je n'ai pas compris ton # 2. sauvegarde complète des tables sélectionnées. Pouvez-vous nous en dire plus à ce sujet?
En ce qui concerne la réorganisation de l'index, la mise à jour des statistiques et les reconstructions d'index, vous devez être prudent sur la façon de procéder, sinon vous finirez par utiliser plus de ressources et vous vous retrouverez également avec des problèmes de performances.
Lorsque vous reconstruisez des index, les statistiques des index sont mises à jour avec l'analyse complète, mais si vous mettez à jour les statistiques par la suite, celles-ci seront à nouveau mises à jour avec un échantillon par défaut (qui dépend de plusieurs facteurs, généralement 5% du tableau lorsque la taille du tableau> 8 MB), ce qui peut entraîner des problèmes de performances. Selon l'édition dont vous disposez, vous pourrez peut-être effectuer des reconstructions d'index en ligne. La bonne façon de faire cette activité est de vérifier la quantité de fragmentation et, selon cela, de reconstruire les index ou de réorganiser les index + mettre à jour les statistiques. Et vous pouvez également vouloir identifier les tables qui doivent mettre à jour les statistiques plus fréquemment et essayer de mettre à jour les statistiques plus souvent.
Les plans de maintenance sont corrects, mais il est difficile d'en tirer le meilleur parti en effectuant ces personnalisations, sauf si vous pouvez vous connecter à SSIS et modifier les MP. c'est pourquoi je préfère NE PAS les utiliser et utiliser les scripts gratuits d'Ola Hallengren qui sont plus robustes que les MP. Aussi, je recommanderais de rattraper l'article référencé de Paul Randal sur ce sujet.
Réf: http://technet.Microsoft.com/en-us/magazine/2008.08.database.aspx
Ce n'est PAS une réponse complète à votre question mais un bon point de départ. HTH et faites-nous savoir si vous avez des questions/commentaires supplémentaires.
Je partagerai mon expérience, même si vous avez déjà accepté une réponse. Ce sera peut-être utile :-).
- Sauvegarde quotidienne complète (quotidienne) - génial, mais n'oubliez pas de vérifier l'espace et de supprimer les anciens fichiers après un certain temps prédéfini.
- Sauvegardez les tables sélectionnées (toutes les heures) - ne comprenez pas pourquoi vous en avez besoin, vous feriez mieux de faire des sauvegardes différentielles. Comment sauvegardez-vous uniquement certaines tables: SSIS, scripts, bcp? En ce qui concerne les sauvegardes diff, ne le planifiez pas trop souvent, car vous volerez le rôle de sauvegarde des journaux.
- Sauvegardes du journal des transactions (toutes les 15 minutes) - super, êtes-vous sûr d'avoir besoin de toutes les bases de données? Toutes les bases de données utilisent-elles ou non un modèle de récupération complète?
- Vérifiez l'intégrité de la base de données - oui, mais vous devez vous assurer que vous ne tuez pas votre environnement. Les instructions de vérification DBCC sont assez égoïstes sur les ressources et analysent les dbs complètes, elles doivent donc être planifiées en dehors des heures.
- Réorganiser l'index (quotidiennement) - ne le forcez pas, ne le faites que si nécessaire. Vérifiez les DMV d'index concernant la fragmentation et réorganisez uniquement en fonction des besoins. Je déplacerais toutes les opérations d'index et de statistiques sur une seule tâche hebdomadaire.
- Mettre à jour les statistiques (quotidiennement) - Veuillez voir ma réponse à une question précédente. Au lieu de simplement forcer la mise à jour de toutes les statistiques, chaque jour, vous feriez mieux de vérifier quand les statistiques ont été enfin mises à jour et seulement dans certains cas de les mettre à jour.
- Réduire la base de données (hebdomadaire) - Oh, non. Veuillez lire Paul Randal article concernant le rétrécissement du fichier.
- Indice de reconstruction (hebdomadaire) - voir 5.
Nettoyage d'entretien (quotidien) - d'accord avec ça.
Vous feriez mieux d'ajouter également une tâche pour vérifier vos sauvegardes - il existe une version de la commande RESTORE (verifyOnly .. si je me souviens bien) - disons hebdomadaire, bien que je la préfère quotidiennement.
Vous mentionnez que vous souhaitez être protégé en cas de perte de données, je dirais donc que vous devez ajouter les bases de données système dans cette procédure de maintenance. Et prenez également soin de sauvegarder les fichiers sur une machine différente de celle du serveur lui-même. Gardez quelque part un fichier avec quoi faire au cas où vous auriez besoin de reconstruire le master db, msdb..etc. Bonne chance dans votre tâche!
Réponse tardive mais pourrait être utile à d'autres lecteurs.
Veuillez garder à l'esprit qu'il existe de nombreuses tâches de maintenance ou de génération de rapports, que vous pouvez créer, qui comportent des risques invisibles qui leur sont associés.
Que se passerait-il lorsqu'un lecteur se remplit lors de sauvegardes différentielles effectuées quotidiennement? Et que se passe-t-il si un travail de reconstruction d'index s'exécute sur une durée inhabituelle? Que diriez-vous si un processus de chargement de données provoque une contention de ressources étendue, mettant à genoux les opérations normales? Tous ces événements sont planifiés, mais peuvent perturber considérablement les processus mêmes que nous essayons de protéger.
Considérez toujours comment les différents travaux interagissent et chronométrez-les de manière à ce qu'il n'y ait pas de chevauchement dans les tâches sensibles ou gourmandes en ressources.
Je suggère de lire cet article en premier: http://www.sqlshack.com/removing-the-risk-from-important-maintenance-tasks-in-sql-server/
Il décrit comment effectuer des tâches de maintenance importantes dans SQL Server - sans risque. Par exemple, vous pouvez intégrer à vos travaux de maintenance de simples vérifications qui vérifient les ressources disponibles ainsi que ce dont une opération aura besoin avant l'exécution. Cela vous permet de vous assurer que votre environnement peut gérer ce que vous êtes sur le point de faire et d'interrompre avec une erreur significative si les ressources sont insuffisantes.
Semble bien
Vous pourriez bénéficier de faire des sauvegardes différentielles ici. Regardez-les à coup sûr
Semble bien
Semble bien
Comme indiqué précédemment, la réduction de la base de données est mauvaise car elle crée une fragmentation physique de vos données et fichiers journaux, provoquant ainsi des lectures plus aléatoires IO.
5, 6 et 8: Voir ci-dessous.
Celles-ci vont vraiment de pair, car les index s'appuient sur des statistiques à jour et l'ordre de ces opérations est assez important. La méthode de base que j'emploie, qui ne peut certes pas fonctionner pour tout le monde, est que j'effectue deux cycles de maintenance d'index. Tout d'abord, je fais les index clusterisés puis les index non clusterisés. La méthode que j'emploie pour les deux est la suivante. Si un index est assez grand et suffisamment fragmenté (sys.dm_db_index_physical_stats), je reconstruirai l'index (qui comprend une mise à jour des statistiques avec analyse complète). Si un index est soit trop petit pour une reconstruction ou pas assez fragmenté pour une reconstruction (moins de 100 pages et entre 5% et 15% de fragmentation), je vais d'abord effectuer une réorganisation de l'index. Je vais ensuite effectuer une mise à jour des statistiques avec analyse complète. Si l'index n'est pas suffisamment fragmenté pour l'un ou l'autre de ces éléments de maintenance d'index, je mettrai toujours à jour les statistiques avec une analyse complète.
Maintenant, cela couvre les statistiques d'index, mais néglige de faire quoi que ce soit pour les statistiques de colonne. Chaque semaine, je mettrai à jour les statistiques des colonnes.
J'espère que cela a aidé d'une manière ou d'une autre!
J'ai incliné votre commentaire "La perte de données pourrait avoir des ramifications légales ici".
Ensuite, vous voulez vraiment obtenir un puissant outil tiers (comme DPM) qui peut gérer les sauvegardes (et récupérer des événements catastrophiques en un éclair et un minimum d'agitation) beaucoup plus rapidement et beaucoup mieux que n'importe quel script que vous pouvez retirer d'Internet.
Avoir des sauvegardes est une chose. Savoir comment les utiliser en cas d'urgence en est une autre.
N'oubliez pas que si vous êtes sur le point de restaurer une sauvegarde après une défaillance majeure, vous êtes probablement déjà soumis à un stress de stress et de pression. Vous n'avez pas besoin de la charge supplémentaire de déterrer et d'écrire parfaitement l'instruction RESTORE DATABASE avec 12 fichiers journaux de transactions ... Et prier pour que cela ne vous manque pas ...
Sur mon lieu de travail, je peux récupérer/restaurer une base de données de 350 Go à tout moment dans un délai de 5 minutes pour la dernière semaine en utilisant DPM. Avec une interface graphique. Ça vaut le coup, dans mon livre.
Pour le reste, regardez certainement dans le script d'index d'Ola Hallengren et ajustez les paramètres à vos besoins. Personnellement, je l'ai couplé à une tâche planifiée qui le fait fonctionner pendant une heure chaque nuit sans nouvelle analyse, donc il gère les pires index à chaque fois, et force une nouvelle analyse complète de la fragmentation tous les samedis, ou lorsque tous les index de la liste ont été défragmentés.
Enfin, j'ajoute ma voix au groupe "ne réduisez pas vos fichiers automatiquement, jamais". File Shrink n'est qu'un outil à utiliser de façon sporadique lorsqu'un événement irrégulier se produit qui a envahi vos journaux ou fichiers DB (boucle infinie ou autre). Ce n'est pas censé être un outil de maintenance. Si vous avez une pression d'espace disque, le rétrécissement ne fera que retarder l'inévitable de toute façon.