Comment puis-je sauvegarder une grande base de données SQL Server sans affecter les performances?
Nous avons eu des rapports de requêtes s'exécutant lentement ou expirant tôt le matin, et le seul travail que je vois en cours d'exécution qui pourrait affecter cela est notre travail de sauvegarde de base de données.
La base de données elle-même fait environ 300 Go et le travail de sauvegarde commence à 4h30 et ne se termine que peu après 7h00. La syntaxe actuelle de notre travail de sauvegarde est la suivante:
BACKUP DATABASE [DatabaseName]
TO DISK = N'E:\Database Backups\DatabaseName.Bak'
WITH INIT, NOUNLOAD, NAME = N'DatabaseName.Bak',
NOSKIP, STATS = 10, NOFORMAT
E:\ est une partition sur le serveur qui contient à la fois les bases de données et les sauvegardes de bases de données.
Il convient également de noter qu'il s'agit d'un serveur virtuel, et non d'un serveur autonome dédié. Nous avons commencé à recevoir des plaintes concernant les ralentissements pendant le processus de sauvegarde juste après notre passage à un serveur virtuel, donc je pense que cela peut être lié.
Existe-t-il un moyen d'exécuter ce travail de sauvegarde afin qu'il n'affecte pas les performances de la requête pendant son exécution?
Nous utilisons SQL Server 2005
- Isolez les E/S de sauvegarde du reste des E/S de votre système. Bien que cela puisse prendre plus de temps et être plus sujet aux hoquets, la sauvegarde sur le réseau plutôt que sur un disque local peut aider à atténuer l'impact direct sur l'instance. Même dans une machine virtuelle, vous devez être en mesure d'exposer un autre stockage afin que SQL Server puisse écrire sur un sous-système d'E/S différent.
- Il est peu probable que cela fasse une différence, mais si cela est exécuté à partir d'un travail, pourquoi devez-vous utiliser l'option
STATS? Êtes-vous sûr d'avoir besoin des autres options (NOUNLOAD,NOSKIP,NOFORMAT)? Je n'ai effectué aucun test de performances approfondi sur l'ensemble de la matrice d'options, mais à mon humble avis, vous ne devez utiliser que les options dont vous savez avoir besoin. - Exécutez vos sauvegardes complètes à un moment différent qui n'interfère pas avec l'activité normale des utilisateurs. Ce n'est pas toujours possible, mais même dans les opérations 24h/24 et 7j/7, il y a des périodes de pointe et d'accalmie.
- Si vous passez à 2008+, vous pouvez profiter de la compression de sauvegarde (Enterprise sur 2008, Standard ou Enterprise dans 2008 R2 +). Si vous ne pouvez pas passer à 2008 ou ne disposez pas de l'édition adéquate, il existe des outils de sauvegarde tiers qui effectueront la compression pour vous, et ils sont tous très bons dans ce domaine. Depuis 2008, j'ai pu utiliser la compression native, et je suis assez satisfait à la fois de la vitesse et du% de compression, sans avoir besoin d'investir davantage dans une tierce partie. Mais avec 2005, je me souviens avoir eu un bon succès avec Red-Gate SQL Backup ; Quest LiteSpeed est également assez bon, mais je n'ai aucune idée du genre d'efforts qui y sont déployés depuis l'acquisition de Dell.
- Si vos bases de données sont en récupération complète, vous pouvez passer plus de temps entre les sauvegardes complètes, en échange de cela sachant que si vous devez récupérer à un moment donné, vous aurez potentiellement plus de journaux à restaurer. Vous pouvez combiner cette option avec la suggestion d'ALi ci-dessous de prendre des diffs tout au long de la semaine - si vous deviez récupérer jeudi, vous devrez restaurer 1 complet, 1 diff et les journaux depuis le diff.
- Si vous avez beaucoup de données périmées et immuables, vous pouvez envisager de les héberger dans une base de données différente avec un plan de récupération différent, ou au moins sur différents groupes de fichiers, et de diviser vos opérations de sauvegarde de cette façon. Si vous avez des données de référence ou d'archivage qui peuvent être rendues en lecture seule, et si vous êtes en récupération simple, vous pouvez les déplacer vers son propre groupe de fichiers en lecture seule, les sauvegarder une fois et ne pas avoir à les inclure dans vos sauvegardes nocturnes jamais. Consultez ces rubriques MSDN:
Il s'agit d'un problème courant, il existe plusieurs solutions et dépend vraiment de votre environnement. Passons en revue:
1 - Compression de sauvegarde à la volée
En 2008, la compression de sauvegarde R1 est devenue disponible dans Enterprise, en 2008R2, elle est devenue disponible dans Standard. C'est énorme. Cela vous fera gagner beaucoup de temps. Si vous pouvez mettre à niveau, allez-y. Si vous ne le pouvez pas, consultez l'utilitaire HyperBak de RedGate , ou Quest LiteSpeed . Les deux ont un essai gratuit.
2- Sauvegardes complètes et diff.
J'ai hérité d'une base de données de prod de 2 To, ce qui a entraîné de nombreux délais d'attente pour une grande société Internet 24h/24 et 7j/7 sur laquelle j'ai travaillé. Nous avons activé les sauvegardes complètes et différentielles, ce qui nous a fait gagner beaucoup de temps. Je prendrais une sauvegarde complète le dimanche à midi lorsque l'activité était faible et je prendrais des diffs pendant la semaine. Cela a permis d'économiser beaucoup d'espace. Le travail de Diff est différent des journaux de transactions car ils fonctionnent sur les pages de base de données qui ont été modifiées. Toutes les pages modifiées sont sauvegardées. Ainsi vous effectuez une restauration complète, puis la restauration diff pour ajouter les pages modifiées.
3- Quel est votre goulot d'étranglement?
L'analyse des goulots d'étranglement est importante à diagnostiquer. Sauvegardez-vous sur la même baie de disques que vos fichiers de données? Vos fichiers de données sont-ils indexés? Quel est votre DISK SEC/READ et DISK SEC/WRITE pour les disques de données pendant les sauvegardes? J'ai modifié les sauvegardes pour créer 4 fichiers. Chaque fichier a son propre rédacteur de threads et dans notre SAN qui a très bien fonctionné. Testez-le, j'ai réduit 45 minutes en créant simplement 4 fichiers de sauvegarde. Assurez-vous simplement que vos mesures de disque répertoriées ci-dessus sont Obtenez une ligne de base.
4- Réplication sur un autre serveur et sauvegarde
Celui-ci est légèrement avancé. Vous devez vous assurer que votre base de données répliquée est à jour et vous avez besoin d'une surveillance appropriée pour cela. Si c'est le cas, vous pouvez simplement sauvegarder la base de données répliquée.