Quels sont les avantages et les inconvénients des scripts Ola par rapport à l'utilisation d'un plan de maintenance?

9

Pourriez-vous m'aider à comprendre les avantages et les inconvénients de l'utilisation de la solution Ola par rapport au plan de maintenance? J'ai préparé une présentation basée sur SQL Pass ( http://www.pass.org/DownloadFile.aspx?File=ebae1b31 ) que je présenterai.

Je prépare également quelques scénarios auxquels la solution Ola répond et que la solution du plan de maintenance ne permet pas. Pouvez-vous tous m'aider à expliquer cela plus techniquement?

Soit dit en passant, nous gérons près de 150+ serveurs (mix de 2008/2012/2014/2016) avec la solution d'Ola sur au moins 75% d'entre eux. J'ai aimé cet article de Brent Ozar. Mais dans l'un des commentaires, Brent a recommandé d'utiliser une solution basée sur des scripts pour le nombre de serveurs que nous avons. https://www.brentozar.com/archive/2012/04/maintenance-plans-roombas-suck-good-way/

sql-server ola-hallengren Tapoter
la source
Parlons-nous de sauvegardes, de la maintenance des index / statistiques, de la vérification de la corruption ou de tout ce qui précède?
nkdbajoe
Tous. Script de solution de maintenance complet par Ola. J'ai résolu des problèmes de reconstructions d'index inutiles et de mises à jour de statistiques dans le plan de maintenance à l'aide des scripts d'Ola. Je voulais juste des munitions plus techniques d'autres DBA. Je vous remercie.
Pat
2
Personnellement, je crois que la meilleure solution est une solution qui répond à vos besoins commerciaux et à votre capacité à la résoudre en cas d'erreur. La solution d'Ola n'est pas mauvaise en général mais je préfère toujours ma propre solution personnalisée pour mon environnement. Par exemple, pour la maintenance d'index, je veux avoir des exécutions parallèles pour gagner du temps. La solution d'Ola ne fonctionne pas ici. Je veux avoir une mise à jour incrémentielle des statistiques, la solution d'Ola ne fonctionne pas non plus ici.
jyao
Avez-vous des données pour montrer qu'elles sont meilleures ou allez-vous simplement avec ce que vous pensez être meilleur? La meilleure façon de résoudre le problème est d'obtenir des données sur les performances afin de montrer pourquoi une méthode est meilleure
Joe W
Pour la maintenance des index, le facteur limitant est souvent votre SAN et votre sous-système de stockage. Selon votre configuration SAN, il se peut que vous ne voyiez aucune amélioration dans les reconstructions parallèles.
Alen

Réponses:

13

J'ai écrit ici

Les plans de maintenance ne sont pas mauvais, mais lorsque votre environnement se développe, la flexibilité et les fonctionnalités limitées que les plans de maintenance fournissent ne seront pas suffisantes.

Pour en ajouter plus,

  • La solution de maintenance d'Ola est largement acceptée dans la communauté et les grandes organisations .
  • Son open source et les problèmes peuvent être soulevés dans github / issues avec une probabilité de le faire réparer très rapidement.
  • Il est flexible et évolutif (même si vous souhaitez le déployer sur des centaines de serveurs, utilisez simplement Install-DbaMaintenanceSolution à partir de dbatools.)
  • Microsoft a pris près d'une décennie pour corriger l'interface graphique du plan de maintenance qui était elle-même boguée :-)
  • a une documentation et des FAQ étendues et est constamment mis à jour pour s'adapter aux nouvelles versions du serveur SQL.
  • dans la version d'aperçu , vous pouvez même exécuter des sauvegardes en parallèle.
  • pour la solution de maintenance d'index, vous pouvez même chronométrer le processus, par exemple s'il s'exécute plus de X fois, l'abandonner.
Kin Shah
la source
5

L'un des principaux avantages d'une solution basée sur un script est la facilité de déploiement - quelque chose qui est clairement pertinent dans votre cas, car vous avez plus de 150 serveurs. Essayer de déployer plusieurs plans de maintenance (c'est-à-dire au moins 2, un pour les bases de données système et un pour les bases de données utilisateur) sur 150 serveurs serait un cauchemar. Les maintenir une fois en place est tout aussi compliqué.

Une solution basée sur un script est beaucoup plus facile à déployer et à entretenir au fil du temps. Les scripts d'Ola sont assez complets et couvrent la plupart des besoins. Ils représentent un excellent point de départ pour toute organisation à ajuster ensuite pour répondre à leurs propres exigences uniques.

Dans notre cas, nous avons environ 40 instances SQL dans notre environnement DEV, et nous utilisons des scripts Ola modifiés avec la fonctionnalité de connexions multiples de SSMS pour pouvoir déployer les modifications du régime de maintenance sur les 40 instances en un seul clic. Tous les cas particuliers sont traités par nos modifications.

Mike
la source
3

Je ne suis pas sûr à 100% de ses scripts, mais les scripts personnalisés sont bien meilleurs que les plans de maintenance. Les plans intégrés reconstruiront chaque index d'une table, quelle que soit la fragmentation. Si vous avez Always On, cela créera une tempête de trafic.

Scripts personnalisés, vous pouvez reconstruire tout ce qui dépasse 20% ou quel que soit votre seuil. Moins d'index reconstruits à la fois. Données Always Always On à envoyer aux secondaires. Reconstruction plus rapide car vous reconstruisez moins d'index. Fenêtre de maintenance plus courte requise.

La dernière fois que j'ai utilisé des plans de maintenance, j'avais une table de 300 millions de lignes et Always On aurait des heures de retard à chaque fois que les reconstructions d'index démarraient et que les problèmes avec le journal des transactions débordaient. Je suis retourné aux scripts et tout est parti.

Alen
la source
1
À l'origine, j'ai écrit le mien pour SQL 2005 vers 2007. J'ai utilisé les livres en ligne comme base et je l'ai un peu changé. À l'époque, il semblait que la plupart des gens utilisaient les plans et maintenant, il semble s'être inversé. Et avant de commencer à faire des trucs DBA, le DBA précédent avant moi avait des scripts personnalisés pour SQL 2000. La seule chose que j'ai différemment était de tout reconstruire. Il était plus rapide de reconstruire quelque chose de plus de 20% ou 30% que de réorganiser également. Pour les sauvegardes, nous avons toujours utilisé des produits tiers
Alen
1

En plus de ce qui précède, ma raison préférée est de pouvoir changer automatiquement de type de sauvegarde afin qu'une nouvelle base de données ait une sauvegarde complète la première fois que le travail de sauvegarde du journal s'exécute au lieu d'attendre que le prochain travail de sauvegarde complète s'exécute.

SQLDBAWithABeard
la source
0

Les plans de maintenance feront l'affaire la plupart du temps. Les scripts d'Ola Hallengren feront très bien l'affaire la plupart du temps.

Dans de très rares cas, vous devrez peut-être cultiver le vôtre.

Comme l'a dit Jyao, il s'agit de celui avec lequel vous êtes le plus à l'aise de travailler. Si votre collègue est plus à l'aise avec les plans d'entretien, pourquoi mettre votre culotte dans une torsion?

S'il base de données depuis plus de 20 ans, il a déjà écrit ses propres scripts de maintenance. Juste au moment où vous appreniez à conduire, il y avait probablement de jeunes punk en short cargo et fliplops qui sont venus et qui ressemblaient tous à "hé, vieux codger, les plans de maintenance sont meilleurs - et baissez votre pantalon, vous avez l'air ridicule! ".

Puis il y a probablement eu une bataille de 4 ans où le jeune uppity a glissé dans un plan d'entretien chaque fois qu'il le pouvait. Maintenant, cet autre jeune punk avec un jean skinny et un noeud papillon freakin lui dit de revenir aux scripts. Il suffit de rendre vos cheveux gris.

Trois choses à considérer:

Ces exemples de supériorité de Hallengrenite sont-ils réellement applicables à votre environnement?

Est-ce que ça va vous causer un vrai problème s'il utilise des plans de maintenance?

Si vous le convaincez d'utiliser les scripts de Hallengren et qu'il y a un problème, pourra-t-il le résoudre lui-même ou devra-t-il vous appeler?

James
la source
Réponse aux deux premières questions Oui. Nous avons déjà vu des problèmes avec les plans de maintenance et j'ai résolu ceux avec la solution d'Ola. Il y avait également une tâche de journal de réduction (??) sur le serveur de production que j'ai immédiatement désactivée. Troisième question, je ne sais pas. Je ne sais pas s'il sera en mesure de résoudre les problèmes créés par le plan de maintenance lui-même. Quand je lui ai demandé au cas où nous verrions des problèmes, que devrions-nous faire? Sa réponse a été d'appeler le support technique de Microsoft. (??)
Pat
@Pat, ahh, on dirait qu'il a atteint sa limite en vertu du principe de Peter. Soyez prudent en essayant de le rendre meilleur - il est peu susceptible d'apprécier l'aide.
James