Lenteur subite de SQLServer 2000

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 ?

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:

---

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 !

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 ?

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 -

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 ...