Que puis-je ajouter à un serveur pour accélérer les restaurations SQL?

J'ai une base de données SQL de 2,8 To (principalement des fichiers de données, quelque 400 Go de fichiers journaux) qui prend actuellement environ 9 heures à restaurer. Cette base de données est utilisée à des fins de test et doit être supprimée et restaurée à partir d'une sauvegarde entre chaque exécution, pour nous assurer que nous partons toujours du même point.

Ma question est, le serveur a actuellement 12 cœurs et 92 Go de RAM, avec un sous-système de disque RAID 5 sur lequel se trouve la base de données. Quels domaines provoquent généralement des goulots d'étranglement pour les processus de restauration SQL? S'agit-il du disque, de la mémoire ou du processeur?

sql-server performance

— Sean Long
source

À partir de quel support de sauvegarde effectuez-vous la restauration? Soit dit en passant, RAID 5 encourt une lourde pénalité en écriture par rapport à la plupart des autres niveaux RAID, donc ce n'est peut-être pas le meilleur pour les tests de performances.

— Chris McKeown

Les .bak (8 d'entre eux sont divisés) sont sur la même matrice RAID 5 sur laquelle ils sont restaurés, ce qui me fait réaliser que je peux probablement mieux gérer cela à l'avenir. Je n'ai pas d'autre baie suffisamment grande pour contenir tous les fichiers .bak, mais je pourrais peut-être les diviser en différents disques connectés directement. En outre, bon point sur le RAID 5. J'en suis conscient, mais nous ne faisons pas encore de tests de résistance, donc ça va si c'est un goulot d'étranglement sur le disque dur en ce moment pendant les tests de charge réels. Une fois que nous irons un peu plus loin, nous augmenterons les performances du disque via SAN, RAID 0 ou RAID 1 + 0

— Sean Long

Vous souffrez certainement trop des sauvegardes sur le disque que vous restaurez également. Combien de disques dans votre RAID5 actuel?

— Mark Storey-Smith

Vous utilisez donc la compression, je suppose. Quelles autres options de sauvegarde utilisez-vous? Comment vos données sont-elles partitionnées? Êtes-vous en mesure de répartir intelligemment les données entre les groupes de fichiers (vous pouvez alors simplement effectuer des sauvegardes et des restaurations de groupes de fichiers sur les données modifiées)?

— swasheck

Le problème est que les tests touchent un très grand pourcentage de la base de données, il nous faudrait donc restaurer sur plusieurs groupes de fichiers (et les tests changeraient en fonction des besoins et du développement de la charge de travail). Il nous faudrait donc constamment examiner la composition du test et restaurer les groupes de fichiers spécifiques. Bien que ce soit une option, je ne suis pas sûr que cela nous ferait gagner beaucoup de temps.

— Sean Long

Réponses:

Votre principal goulot d'étranglement lors d'une restauration sera l'ES du disque. Pour résoudre ce problème, vous avez essentiellement besoin de disques plus rapides ou d'une configuration différente. Je ne connais pas assez le RAID ou les SAN pour suggérer quoi que ce soit. Vous pourriez même envisager des SSD. Ils sont incroyablement rapides. Je ne voudrais pas les utiliser sur quelque chose qui n'est pas recréé régulièrement (tempdb est toujours un bon candidat pour cela) mais puisque vous le restaurez fréquemment, cela pourrait être ok. D'un autre côté, vous souhaiterez probablement vous assurer que votre serveur de test est aussi proche que possible de votre serveur de production si vous effectuez des tests de performances.

Il y a quelques autres choses que vous pouvez faire pour vous aider. Compressez d'abord vos sauvegardes si vous ne l'êtes pas déjà. Cela suppose bien sûr SQL 2008 ou supérieur. Cela réduira non seulement l'espace disque pour stocker la sauvegarde, mais aussi l'IO pour la lire. Il y a un coût CPU impliqué alors soyez conscient. Ne supprimez pas non plus votre base de données, restaurez simplement dessus. De cette façon, les fichiers sont déjà en place et il n'y a pas de surcharge pour les créer. Vous pouvez activer l'initialisation instantanée des fichiers (il s'agit d'une autorisation au niveau du serveur) pour accélérer considérablement la création / croissance de fichiers pour votre fichier de données, mais cela ne fonctionnera pas pour votre fichier journal.

— Kenneth Fisher
source

Bonne information, je ne savais pas que la restauration sur l'existant est meilleure que la suppression / restauration à partir d'une sauvegarde. Nous utilisons déjà la compression et je prévois de vérifier que l'initialisation instantanée des fichiers est activée pour le compte effectuant la restauration. J'apprécie vraiment la clarté de votre réponse, merci!

— Sean Long

Assurez-vous que l'initialisation instantanée des fichiers est également activée sur le compte exécutant SQL Server. Pour une petite base de données, ce n'est probablement pas si grave, mais pour quelque chose de la taille que vous regardez, cela pourrait faire une grande différence.

— Kenneth Fisher

Bon appel. Merci également d'avoir réalisé que les tests de performances ne signifient pas toujours des tests de résistance (et que je suis assez limité par la façon dont ma configuration de production est configurée, actuellement).

— Sean Long

OT: "considérez les SSD. ... Je ne voudrais pas les utiliser sur quelque chose qui n'est pas recréé régulièrement" ... pourquoi?

— Martin

Je serais toujours nerveux à l'idée qu'ils échouent. Tout ce que j'ai lu a dit de les utiliser pour des bases de données comme tempdb qui sont recréées à chaque démarrage de l'instance, mais pas de les utiliser pour des bases de données d'utilisateurs ordinaires. Bien que je sois sûr que cela change avec le temps.

— Kenneth Fisher

Ne faites pas de sauvegarde et de restauration; utiliser des instantanés SQL Server. Il faut beaucoup d'espace disque pour stocker un fichier clairsemé de la même taille que les fichiers que vous avez instantanés, mais la restauration est des centaines de fois plus rapide.

Ils sont disponibles dans les éditions SQL Server Enterprise et SQL Server Developer.

— Mark Henderson
source

C'est une bonne idée, et s'il s'agissait d'un autre serveur qu'un serveur de test de performances, cela semble être une excellente façon de procéder. Cependant, il semble que les instantanés de base de données ne fonctionneront pas car cela entraînera une surcharge supplémentaire pour la base de données source, ce que je ne peux pas avoir. Les tests en cours sont des tests de performance (charge, contrainte, etc.), nous devons donc éviter tout élément externe susceptible de provoquer un stress.

Personnellement, je n'ai pas remarqué de différences de performances avec un instantané, mais je suppose que la copie sur écriture a des frais généraux; ne connaissant pas votre charge de travail, je ne peux pas juger.

— Mark Henderson

La suggestion de @SeanLong Mark est probablement la meilleure option pour votre scénario. Ce que je pense que vous ne comprenez pas, c'est quand et ce que vous prenez. Le plan sur un serveur de test serait de restaurer la base de données de test à partir de votre sauvegarde en direct, puis de créer un instantané de la base de données de test, d'exécuter votre cycle de test, puis de rétablir l'instantané, de rincer et de répéter. Vous pouvez périodiquement revenir à l'étape 1 et restaurer la sauvegarde en direct pour tester à nouveau.

— Mark Storey-Smith

Ah, je vois. Je pensais que la maintenance de l'instantané nécessitait une quantité constante de surcharge de la base de données de test, ce qui affecterait nos tests de charge (très lourds en écriture / lecture). Cela ne me dérange pas si notre charge de travail est à l'origine du goulot d'étranglement sur le lecteur de disque, je ne veux tout simplement pas qu'un facteur externe (que je pensais que la capture instantanée de db le soit) puisse le provoquer.

— Sean Long