bonjour
C’est Qui Ola Hallengren ?
Ola Hallengren est un DBA ,développeur de base de données qui travaille actuellement avec une grande société financière en Suède Il travaille avec SQL Server depuis 2001
Ola est l’auteur de la solution de maintenance populaire à http://ola.hallengren.com
En 2007, Ola a lancé un projet visant à améliorer la maintenance de la base de données dans un grand environnement SQL Server. À cette époque, une combinaison de travaux de maintenance de base de données créés à l’aide de l’Assistant SQL Server, ainsi qu’une collection de scripts Transact-SQL personnalisés, ont été utilisées dans l’ensemble de l’organisation. Son objectif était d’éliminer la collection de travaux de mélange et de créer une solution facile à déployer qui pourrait être facilement développée dans un vaste environnement de serveurs critiques
Pourquoi les script de maintenance d’Ola?
Si vous êtes un administrateur de la base de données de production responsable des sauvegardes, de la vérification de la corruption et de la maintenance des index sur SQL Server et vous n’été pas capable de faire développez des script PowerSHELL
Alors Essayez les scripts gratuits de maintenance de la base de données Ola Hallengren . Ils sont meilleurs que le vôtre et ils vous offrent plus de flexibilité que les plans de maintenance intégrés
Comment utiliser le script de maintenance d’Ola?
Si vous êtes un DBA débutant, ou peut-être que vous êtes pressé d’obtenir un plan de maintenance exécuté sur vos instances SQL Server, vous pouvez rapidement mettre en œuvre le plan de maintenance d’Ola. Voici comment:
- Téléchargez le script MaintenanceSolution.sql à partir du site Web d’Ola et ouvrez-le dans une fenêtre de requête à l’intérieur de SSMS.
- Dans vos script Remplacez C: \ Backup ‘par le chemin d’accès de l’emplacement où vos sauvegardes doivent être stockées
- Exécutez le script. À ce stade, une table, une fonction et quatre procédures stockées sont créées dans la base de données principale, ainsi que 11 nouveaux travaux pré-créés pour effectuer toutes les tâches de maintenance décrites précédemment
- Programmez manuellement les travaux préconfigurés à exécuter aux moments appropriés.
- Vous êtes maintenant terminé
Lorsque vous regardez de plus près le script MaintenanceSolution.sql, vous verrez qu’il est divisé en essentiellement en sept sections différentes (j’ai arbitrairement divisé le script en sept sections pour le rendre plus facile à décrire), notamment:
- Paramètres essentiels
- Création de la table CommandLog
- Création de la procédure stockée CommandExecute
- Création de la procédure stockée DatabaseBackup
- Création de la procédure stockée DatabaseIntegrityCheck
- Création de la procédure stockée IndexOptimize
- Création d’emplois de maintenance
Vers le haut du script MaintenanceSolutions.sql, cinq paramètres affectent la façon dont le script s’exécute et peuvent éventuellement être modifiés en modifiant directement le script avant de l’exécuter. J’ai décrit l’une des options de la section précédente, mais il y a d’autres paramètres que vous souhaitez modifier
Ci joint les paramètres dans MaintenanceSolutions.sql que vous pouvez modifier
SET @CreateJobs = ‘Y’ — Specify whether jobs should be created.
SET @BackupDirectory = N’C:\Backup’ — Specify the backup root directory.
SET @CleanupTime = NULL — Time in hours, after which backup files are deleted. If no time is specified, then no backup files are deleted.
SET @OutputFileDirectory = NULL — Specify the output file directory. If no directory is specified, then the SQL Server error log directory is used.
SET @LogToTable = ‘Y’ — Log commands to a table
Dans la première option vous e spécifier dans quelle base de données sera créée la table, la fonction et les procédures stockées. Par défaut, ils sont créés dans la base de données master, mais vous pouvez le modifier dans la base de données msdb ou dans une base de données utilitaire dba si vous le préférez.
La deuxième option est utilisée pour indiquer au script si vous souhaitez qu’il serai crée automatiquement des tâches d’agent SQL Server préconfigurées et prêtes à être exécutées, même si elles doivent toujours être programmées. La valeur par défaut est ‘Y’, Si vous ne voulez pas que le script crée automatiquement les travaux pour vous, remplacer ‘Y’ par ‘N’.
Dans la troisième option, vous pouvez entrer l’emplacement où vous souhaitez stocker vos sauvegardes. Comme je l’ai déjà mentionné, tout ce que vous avez à faire est de remplacer C: \ Backup ‘par le chemin approprié. Ce paramètre n’est requis que si vous disposez également du script pour créer les travaux de maintenance, car ce chemin d’accès est utilisé comme emplacement des fichiers de sauvegarde pour les travaux de sauvegarde créés. Si vous n’avez pas l’intention d’utiliser les travaux créés par le script, ce paramètre n’est pas pertinent car vous pouvez ajouter un emplacement de sauvegarde en tant que paramètre de la procédure stockée DatabaseBackup. Plus à cela plus tard.
La quatrième option est utilisée pour entrer l’emplacement pour les fichiers journaux. Par défaut, le répertoire du journal des erreurs SQL Server est utilisé.
La cinquième option est utilisée pour indiquer le script si vous souhaitez vous connecter à une table, en plus des fichiers journaux. La valeur par défaut est ‘Y’, ou oui. Si vous ne voulez pas que le script se connecte à une table, remplacer ‘Y’ par ‘N’ ..
Remarque:Lorsqu’une sauvegarde est effectuée, une hiérarchie de dossiers est créée dans ce dossier racine qui commence par le nom du serveur suivi du nom de la base de données, puis le type de sauvegarde créée
Outre de ces cinq changements potentiels, le script ne doit pas être modifié (même si vous avez cette option si vous souhaitez personnaliser le script). Après avoir apporté des modifications au script, vous pouvez exécuter le script, à quel point la table
Création des travaux de maintenance (et travaux de nettoyage)
En supposant que vous avez spécifié au début du script Maintenance Solution.sql que vous souhaitez créer des travaux de maintenance, l’exécution du script créera une série de 11 emplois, notamment:
- CommandLog Cleanup
- DatabaseBackup – USER_DATABASES – FULL
- DatabaseBackup – USER_DATABASES – DIFF
- DatabaseBackup – USER_DATABASES – LOG
- DatabaseBackup – SYSTEM_DATABASES – FULL
- DatabaseIntegrityCheck – USER_DATABASES
- DatabaseIntegrityCheck – SYSTEM_DATABASES
- IndexOptimize – USER_DATABASES
- Nettoyage des fichiers de sortie
- Sp_delete_backuphistory
- Sp_purge_jobhistory
Tous ces travaux ont été créés avec des paramètres par défaut à partir du script, mais vous pouvez modifier les paramètres, si vous le souhaitez, directement à partir des travaux eux-mêmes. En outre, aucun des travaux n’a été planifié, car vous, en tant que DBA, devez décider quels travaux vous souhaitez exécuter, et quand, afin de minimiser l’impact sur les performances, ces travaux peuvent avoir leur exécution. Bien que ces onze emplois aient été créés, ils peuvent ou non être utilisés, selon votre environnement SQL Server. Cela signifie que vous pouvez finir par modifier ou supprimer certains de ces emplois
Examinons rapidement un de ces Travaux et voyons comment ils fonctionnent. Une fois que vous l’avez fait, vous pouvez décider si vous souhaitez les utiliser tel quel, les modifier ou ignorer tout à fait et créer vos propres travaux personnalisés
Lorsque je clique sur le bouton Modifier, nous pouvons visualiser le script de travail pour ce travail particulier
le paramètre @CleanupTime est pour spécifier la période de rétention des Fichier backup
Chacun deces Travaux créés par le script MaintenanceSolution.sql crée une seule étape, et cette étape s’exécute en tant que travail d’un système d’exploitation (CmdExec)
Maintenant que le code de travail a été examiné, nous devons maintenant examiner une autre partie du travail, et c’est l’option Fichier de sortie de l’onglet Avancé, qui est présenté ci-dessous
Le fichier de sortie pour un travail est important car il vous montre exactement ce que le travail a fait (ce que je vous suggère d’examiner régulièrement), ce qui peut être utile pour le dépannage.
Périodiquement, Ola met à jour ses scripts, corrige les petits bogues ou ajoute de nouvelles fonctionnalités. Si la version actuelle du script d’Ola que vous utilisez fonctionne bien pour vous, alors vous n’avez probablement pas besoin de mettre à niveau lorsqu’il met à jour son script. D’autre part, s’il présente une nouvelle fonctionnalité que vous souhaitez utiliser, la mise à niveau est facile. En supposant que vous n’avez pas personnalisé son script original, vous pouvez exécuter le nouveau script comme s’il s’agissait d’une nouvelle installation.
Lorsque vous exécutez le nouveau script, Ola garantit une compatibilité ascendante. Si vous avez modifié l’un des emplois créés par son script, ils sont laissés seuls par le processus de mise à niveau. Si vous avez créé vos propres travaux personnalisés, ils continueront également à fonctionner sans modification.
Si vous avez modifié son script directement (sauf les cinq paramètres essentiels), vous pouvez envisager de contacter Ola pour savoir si les personnalisations que vous avez effectuées sont encore nécessaires dans la nouvelle version
ci joint une présentation faite par Ola Hallengren à SQLBits XII
https://sqlbits.com/Sessions/Event12/Inside_Ola_Hallengrens_Maintenance_Solution
Bonne lecture
DBA SQL Server BLOG 