Quels sont les avantages et les inconvénients des scripts Ola par rapport à l'utilisation d'un plan de maintenance?
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 fait 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/
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 à github/issues avec une probabilité de le faire réparer très rapidement.
- Son 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 vaste documentation et FAQ et est constamment mis à jour pour accueillir les nouvelles versions de serveur SQL.
- dans version d'aperç , 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, abandonnez-le.
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, puis Tweak 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.
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.
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.
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. À peu près au moment où vous appreniez à conduire, il y avait probablement de jeunes punk en short cargo et fliplops qui sont venus et qui étaient tous comme "hé, vieux codger, les plans de maintenance sont meilleurs - et baissez votre pantalon, vous avez l'air ridicule! ".
Ensuite, 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?