Discussion :

[VSMO]

Suite a une defragementation du disque (en SAN) sous windows serveur 2003 sans avoir arrêter le service SQLServer, les temps d'execution de requêtes ont plus que triplé. La défragmentation a été opérée suite à un constat de lenteur dans le compactage des bases (shrink sur bases de 5 GB).
Cette défragmentation sans avoir arrêter le service SQLServer peut-il être la cause de cette lenteur ?? La présence d'index générés automatiquement WA_Sys peuvent-ils être en cause ?
Comment y remédier proprement ?

[Invité]

Ce que tu appelles les index WA_Sys sont en fait les statistiques. Et par défaut elles sont générées et mises à jour automatiquement.

Analyse la fragmentation physique de tes fichiers de bases de données avec un utilitaire du type contig (www.sysinternals.com). Si chaque fichier est en un seul fragment, inutile de recommencer l'opération.

analyse ta base avec DBCC CHECKDB, pour voir si ta base a des erreurs. Si c'est le cas, repare-le (en priant), sinon, repare d'une sauvegarde correcte.

Analyse tes index avec DBCC SHOWCONTIG. Si ils sont fortement fragmentés, reconstruit-les ou défragmente-les (DBCC DBREINDEX ou DBCC INDEXDEFRAG).

Ce script peut t'aider, il défragmente ou reconstruit tous les index d'une base (commente la ligne DBCC xxx qui est inutile).

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
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
/*
Defrag or re-index all index with origin fillfactor
*/
USE mabase
GO
 
DECLARE @TableName sysname
DECLARE @IndexName VARCHAR(100)
DECLARE @indid int
DECLARE cur_tblfetch CURSOR FOR
SELECT name from sysobjects where xtype='U'
 
OPEN cur_tblfetch
	FETCH NEXT FROM cur_tblfetch INTO @TableName
	WHILE @@FETCH_STATUS = 0
	BEGIN 
		DECLARE cur_indfetch CURSOR FOR
		SELECT indid,name FROM sysindexes WHERE id = OBJECT_ID (@TableName) and keycnt > 0 
		OPEN cur_indfetch
			FETCH NEXT FROM cur_indfetch INTO @indid,@IndexName
			WHILE @@FETCH_STATUS = 0
				BEGIN 
				  print 'Maintenance de ' + (@TableName) + '.' + (@IndexName)
				  IF @indid <> 255 DBCC INDEXDEFRAG (0, @TableName, @indid)
				  --IF @indid <> 255 DBCC DBREINDEX (@TableName, @IndexName,90)
				  FETCH NEXT FROM cur_indfetch INTO @indid,@IndexName
				END
		CLOSE cur_indfetch
		DEALLOCATE cur_indfetch
		FETCH NEXT FROM cur_tblfetch INTO @TableName
	END
CLOSE cur_tblfetch
DEALLOCATE cur_tblfetch

Le BOL te sera d'une aide précieuse : à laisser ouvert !

[VSMO]

Merci. Les disques ne sont plus fragmentés. En fait nous n'avons (volontairenment) pas d'index sur les tables users. Je pense avoir un problème avec ces Stat WA_sys suite à la defrag : exemple select count (*) sur une table de 5'000'000 de lignes: 54 secondes la 1ère fois (jamais vu ça sur notre serveur !) et moins de 1 seconde la deuxième fois !
Le restore de base est aussi devenu très long (5 x plus long). Nous avons une quinzaine de bases et les plus grosse d'environs 5 GB.
Lors de la defragmention, des fichiers MDF ont été déplacés malgré que le service SQL server n'est pas été desactivé. Ca peut faire des dégats ou faut-il chercher ailleurs ?

[Invité]

Pour le select count(*), c'est normal, ta requête a été mise en cache, donc exécutée plus vite.

Je te conseille de faire une analyse de perf sur les ompteur suivants pour isoler le facteur pénalisant:

Counters Optimal
Memory: Pages/sec <1 , <20
Memory: Available Bytes -
Physical Disk: % Disk time <55
Physical Disk: Avg. Disk Queue Length <2
Processor: % Processor Time <80
System: Processor Queue Length <2
SQL Server Buffer: Buffer Cache Hit Ratio >99
SQL Server General: User Connections -

[VSMO]

Merci Kuzco. Désolé de ne pas avoir répondu de suite car j'en suis tombé malade !

L'analyse avec le perfmon des compteurs proposés ne done pas de valeurs hors norme

Plus on va en avant plus en pense que la defrag avec l'utilitaire windows a posé le problème.

J'ai lu: Disk Defragmenter can't defrag open files, so to defrag the server, you'd need to stop the services; doing so wreaks havoc.

Quelle m.
Si après ça on est pas amené à ramonter le serveru complet ...