Plan de maintenance du serveur SQL - Meilleures pratiques en matière de tâches et de planification

Je suis chargé de concevoir un plan de maintenance pour nos bases de données SQL Server 2005. Je sais que pour les sauvegardes, je souhaite effectuer une sauvegarde quotidienne complète de la base de données et des journaux transactionnels toutes les 15 minutes. Mon problème vient de déterminer quelles autres tâches je veux faire et à quelle fréquence je devrais les faire.

Donc, jusqu'à présent, j'ai cela à l'esprit. Corrigez-moi s'il y a des défauts dans ma pensée ou une meilleure façon de le faire.

1. Sauvegarde - Toutes les tables, sauvegarde complète (quotidienne)
2. Sauvegarde - Tables sélectionnées, sauvegarde complète (toutes les heures)
3. Sauvegarde - Journal des transactions (toutes les 15 minutes)
4. Vérifier l'intégrité de la base de données (quotidiennement)
5. Réorganiser l'index (quotidiennement)
6. Mise à jour des statistiques (quotidiennement)
7. Réduire la base de données (hebdomadaire)
8. Reconstruire l'index (hebdomadaire)
9. Nettoyage d'entretien (quotidien)

Je me suis souvenu d'avoir lu il y a quelque temps (lorsque j'ai mis en place un plan similaire à un autre emploi) que certaines de ces tâches n'ont pas besoin d'être exécutées quotidiennement ou ne devraient pas l'être quotidiennement. Quant à ceux-là, ça m'échappe. Je pourrais utiliser un peu de conseils pour créer un meilleur plan de maintenance qui réduira les pertes de données en cas de sinistre, mais ne taxera pas le système lorsqu’il fonctionnera 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 tous les serveurs. Comme beaucoup d'autres choses, cela dépend de ce dont vous avez besoin.

Très certainement, vous ne voulez pas exécuter "Shrink Database" comme déjà suggéré. Son EVIL to performance et le ref ci-dessous va vous montrer pourquoi. Cela entraîne une fragmentation des disques et des index, ce qui peut entraîner des problèmes de performances. Il est préférable de pré-allouer une taille importante pour les fichiers de données et les fichiers journaux afin que la croissance automatique n'entre pas en jeu.

Je n'ai pas compris votre # 2. Sauvegarde complète des tables sélectionnées. Pouvez-vous élaborer davantage à ce sujet?

Pour réorganiser Index, mettre à jour les statistiques et reconstruire les index, vous devez faire attention à la façon dont vous procédez. Sinon, vous utiliserez plus de ressources et vous aurez également des problèmes de performances.

Lorsque vous reconstruisez des index, les statistiques des index sont mises à jour avec fullscan, mais si vous les mettez à jour par la suite, elles seront à nouveau mises à jour avec un exemple par défaut (qui dépend de plusieurs facteurs, généralement 5% du tableau lorsque la taille du tableau est> 8). MB) pouvant entraîner des problèmes de performances. Selon votre édition, vous pourrez peut-être reconstruire des index en ligne. La bonne façon de faire cette activité est de vérifier l’ampleur de la fragmentation et, en fonction de cela, de reconstruire l’index ou de réorganiser l’index + les statistiques de mise à jour. Vous voudrez peut-être également identifier les tables qui doivent mettre à jour les statistiques plus fréquemment et essayer de les mettre à jour plus souvent.

Les plans de maintenance sont acceptables, mais il est difficile d'en tirer le meilleur parti en effectuant ces personnalisations, à moins que vous ne puissiez 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, plus robustes que ceux de MP. Aussi, je recommanderais de rattraper l’article cité par 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 laissez-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. Peut-être que ce sera utile :-).

1. Sauvegarde quotidienne complète (quotidienne) - excellent, mais n'oubliez pas de vérifier l'espace disponible et de supprimer les anciens fichiers après un délai prédéfini.
2. Sauvegarder les tables sélectionnées (toutes les heures) - vous ne comprenez pas pourquoi vous en auriez besoin, vous feriez mieux d'utiliser des sauvegardes différentielles. Comment ne sauvegarder que 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 du journal.
3. Sauvegardes du journal des transactions (toutes les 15 minutes) - tant mieux, êtes-vous sûr de vouloir utiliser toutes les bases de données? Toutes les bases de données utilisent-elles un modèle de récupération complète ou non?
4. Vérifiez l'intégrité de la base de données - oui, mais vous devez vous assurer de ne pas tuer votre environnement. Les instructions de contrôle DBCC sont assez égoïstes sur les ressources et analysent des fichiers DBS complets; elles doivent donc être planifiées pendant les heures creuses.
5. Réorganisez l'index (quotidiennement) - ne le forcez pas, ne le faites que si nécessaire. Vérifiez l'index DMV en ce qui concerne 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.
6. Mise à jour des statistiques (quotidiennement) - Veuillez consulter ma réponse à une question précédente. Au lieu de simplement forcer la mise à jour de toutes les statistiques, tous les jours, vous feriez mieux de vérifier quand les statistiques ont été mises à jour pour la dernière fois et, dans certains cas, de les mettre à jour.
7. Réduire la base de données (hebdomadaire) - Oh, non. Veuillez lire l' article de Paul Randal concernant la réduction de fichier.
8. Indice de reconstruction (hebdomadaire) - voir 5.

9. Entretien de nettoyage (quotidien) - ok avec ça.

10. Vous feriez également mieux d'ajouter 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 le préfère tous les jours.

Vous indiquez 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 veillez également à sauvegarder les fichiers sur une machine différente de celle du serveur. Conservez quelque part un fichier avec la procédure à suivre au cas où vous auriez besoin de reconstruire la base de données principale, msdb..etc. Bonne chance dans votre tâche!

Réponse tardive mais pourrait être utile aux autres lecteurs.

N'oubliez pas que vous pouvez créer de nombreuses tâches de maintenance ou de génération de rapports comportant des risques invisibles.

Que se passe-t-il lorsqu'un disque est rempli pendant les sauvegardes différentielles effectuées quotidiennement? Et que se passe-t-il si un travail de reconstruction d'index est exceptionnellement long? Et si un processus de chargement de données provoquait un important conflit de ressources, amenant les opérations normales à genoux? Tous ces événements sont planifiés, mais ils peuvent perturber considérablement les processus mêmes que nous essayons de protéger.

Tenez toujours compte de la façon dont les différents travaux interagissent et synchronisez-les de manière à éviter tout chevauchement des tâches sensibles ou gourmandes en ressources.

Je suggère de lire d'abord cet article: 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 tâches de maintenance des contrôles simples qui vérifient les ressources disponibles ainsi que les besoins d'une opération avant leur 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'abandonner avec une erreur significative si les ressources sont insuffisantes.

1. Semble bien

2. Vous pourriez bénéficier des sauvegardes différentielles ici. Regardez-les à coup sûr

3. Semble bien

4. Semble bien

5. Comme indiqué précédemment, les restrictions de la base de données sont mauvaises car elles créent une fragmentation physique de vos données et de vos fichiers journaux, ce qui entraîne davantage de lectures d'E / S aléatoires.

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'utilise, qui peut ne pas convenir à tout le monde, consiste à effectuer deux cycles de maintenance de l'index. Tout d'abord, je fais les index clusterisés, puis les index non clusterisés. La méthode que j'utilise pour les deux est la suivante. Si un index est suffisamment grand et suffisamment fragmenté (sys.dm_db_index_physical_stats), je reconstruirai l'index (qui comprend une mise à jour de statistiques avec une analyse complète). Si un index est trop petit pour une reconstruction ou pas assez fragmenté pour une reconstruction (moins de 100 pages et une fragmentation comprise entre 5% et 15%), je commencerai par effectuer une réorganisation d'index. Je vais ensuite effectuer une mise à jour des statistiques avec analyse complète.

Maintenant, cela couvre les statistiques d'index, mais néglige de faire quoi que ce soit pour les statistiques de colonne. Toutes les semaines, je mettrai à jour les statistiques de la colonne.

J'espère que cela a aidé d'une certaine manière!

J'ai incliné sur votre commentaire "la perte de données pourrait avoir des ramifications légales ici".

Ensuite, vous voulez absolument obtenir un puissant outil tiers (comme DPM) capable de gérer les sauvegardes (et de récupérer les événements catastrophiques de manière rapide et sans encombre) beaucoup plus rapidement et bien mieux que n’importe quel script que vous pouvez extraire d’Internet.

Avoir des sauvegardes est une chose. Savoir les utiliser en cas d'urgence en est un 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à sous le poids du stress et de la pression. Vous n'avez pas besoin du fardeau supplémentaire de fouiller et d'écrire parfaitement l'instruction RESTORE DATABASE avec 12 fichiers de journal des transactions ... Et prier pour que cela ne vous fasse pas défaut ...

Sur mon lieu de travail, je peux récupérer / restaurer une base de données de 350 Go à tout moment en moins de 5 minutes au cours de la dernière semaine à l'aide de 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 associée à une tâche planifiée qui la fait fonctionner pendant une heure chaque nuit sans nouvelle analyse. Elle gère donc 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 automatiquement vos fichiers, jamais". File Shrink n’est qu’un outil à utiliser sporadiquement lorsqu’un événement anormal survient qui surcharge vos journaux ou vos fichiers de base de données (boucle infinie ou autre). Ce n'est pas censé être un outil de maintenance. Si vous avez une pression d’espace disque, la réduction ne fera que retarder l’inévitable.