Discussion :

[StringBuilder]

Bonjour,

Nous avons une dizaine de serveurs SQL Server.
Afin d'hamoniser et simplifier les tâches de sauvegarde/restauration, j'ai écrit un programme (je ne peux pas utiliser le scheduler de SQL Server, ce sont des versions Express) qui exécute des backups FULL (1 par 24 heures) et LOG (1 par 10 minutes) de chaque base de chaque instance de chaque serveur.

Tout ce petit monde est sauvegardé au même endroit, sur le même serveur, qui est un serveur de fichier.

Pour les backups aucun souci. Tout va très vite, jamais eu aucun problème.

En revanche, pour les restauration (tests sur machines de DEV oblige) c'est une autre paire de manches.

Quand on est dans SQL Server Management Studio, si on clique sur "Restaurer" d'une base de données, on doit attendre facilement 5 minutes avant de voir l'écran de restauration s'ouvrir.

Vu qu'on sauvegarde directement à travers le réseau, j'imagine que la lenteur vient du fait que le serveur tente de vérifier la présence de tous les fichiers de backup à travers le réseau.

On conserve 5 jours de rétention. Y'a-t-il un moyen d'améliorer les performances de cet invite en "purgeant", côté SQL Server, les backups ?

En effet, lorsqu'on clique sur "planning" le serveur propose de restaurer la base jusqu'au mois de mars, en indiquant qu'il y a un log toutes les 10 minutes. J'imagine que c'est ça qui met des plombes à charger, surtout si pour chaque entrée dans la table, il fait une requête réseau pour vérifier l'existance du fichier !

[rudib]

Hello,

pour info, "Express" est une édition, pas une version.

Pas sûr du tout qu'il vérifie la présence des fichiers sur le réseau. Si tu traces l'activité de l'ouverture de la fenêtre de restauration, tu va voir le code qui est généré, et qui dans mon cas (le server 2008 R2 que j'ai sous la main à l'instant) donne un gros pavé avec tables temporaires de 788 lignes de code ... ça commence comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
declare @server_name nvarchar(512)
set @server_name = cast(serverproperty(N'Servername') as nvarchar(512))
 
DECLARE 
  @first_full_backupset_id      INTEGER,
  @first_full_backup_startdate  DATETIME,
	@count_entries					INTEGER,
	@in_restore_plan				BIT,
	@last_backupset_type			CHAR(1),
	@last_backupset_id				INTEGER,
	@last_backupset_family_guid		UNIQUEIDENTIFIER,
	@last_backupset_diff_base_guid	UNIQUEIDENTIFIER,
	@last_backupset_recovery_fork_guid	UNIQUEIDENTIFIER,
	@full_backupset_id				INTEGER,
	@full_backupset_start_date		DATETIME,
	@full_backupset_recovery_fork_guid	UNIQUEIDENTIFIER,

et ceux qui on écrit ça chez Microsoft on dû quitter la société et personne ne sait plus le maintenir

Trace ça et regarde les ralentissements des requêtes, peut-être dans msdb ?

[elsuket]

Je doute également que la vérification de l'existence des fichiers se fasse "upstream".
En revanche il est fort probable qu'il faille ajouter des index sur les tables qui sont lues, dans msdb.
Il faut aussi garder à l'esprit que l'edition express utilise au plus un coeur de CPU.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
CREATE INDEX IX_backupset__media_set_id
ON dbo.backupset (media_set_id)
GO
 
CREATE INDEX IX_backupset__backupfinishdate
ON dbo.backupset (backup_finish_date)

@++