Discussion :

[k2011]

Ok je vais essayer mais il ne s'agit que des index non ? Est ce que les données dans les tables peuvent avoir le meme probleme ?

Le resultat des compteurs :
Buffer cache hit ration Avr 98 ; min 94 ; max 99
Page life expectancy Avr 32 ; min 4 ; max 71
Aviable MBytes Avr 1018; min 1011 ; max 1019
% Proc time Avr 52; min 20 ; max 85

[mikedavem]

Non, SQL ne gère pas physiquement où va être enregistré son fichier : c'est l'OS qui fait ce travail.

La gestion des IO ne se fait pas par Windows mais par SQL Server via SQLOS.

Ceci dit, certains SAN proposent un defragmenteur.

Oui mais pour avoir testé et travaillé avec quelques administrateurs SAN, cela ne change pas grand chose (pour les bases de données). La défragmentation est plus néfaste que bénéfique dans ce cas.

Et je suis persuadé (à partir du moment où les fichiers physiques ne sont pas fragmentés) que le defrag dans VM apporte quelquechose.

Même chose ici déjà testé et pas vu de différence (en général les datastores alloués à SQL Server sont sur-dimensionnés et ne présentent pas de fragmentation particulière)

++

[mikedavem]

Le resultat des compteurs :
Buffer cache hit ration Avr 98 ; min 94 ; max 99
Page life expectancy Avr 32 ; min 4 ; max 71
Aviable MBytes Avr 1018; min 1011 ; max 1019
% Proc time Avr 52; min 20 ; max 85

Visiblement vous avez (potentiellement) une pression mémoire ... vu le compteur Page Life expectancy ... enfin est ce que votre relevé est de l'instantanné ou avez cela sur une période plus ou moins longue ...

Est ce que vous avez d'autres applications qui tournent sur ce serveur ?
Est ce qu'au niveau de l'ESX il n'y aurait pas une autre machine qui viendrait vampiriser vos ressources ?

++

[k2011]

J'ai ces message d'erreur quand je lance le script depuis le query analyser

Server: Msg 170, Level 15, State 1, Line 1
Line 1: Incorrect syntax near 'max'.
Server: Msg 137, Level 15, State 1, Line 3
Must declare the variable '@SQL'.
Server: Msg 137, Level 15, State 1, Line 8
Must declare the variable '@SQL'.

[k2011]

Les deux serveur sont sur le meme datastore et le meme esx

[StringBuilder]

Pour le premier, je ne savais pas.
Je me coucherai mon con ce soir

Pour les autres points, d'accord, je veux bien te croire "dans le cas général".

Mais j'ai déjà vécu un gros problème dans une boîte où un DEV qui s'était pris pour un DBA s'était amusé à :
- Mettre un grow size de 1 Mo sur deux fichiers MDF
- Et mettre deux tables intimement liées sur chacun des deux MDF

=> Dans un fichier, les commandes
=> Dans le second, les livraisons

Bah... Quand je suis arrivé, le serveur patinnait dans la semoule tout ce qu'il pouvait au moins select.

J'ai lancé un defrag (il devait y avoir au bas mot 50 000 fragment pour chacun des deux fichiers... le disque apparaissait intégralement rouge).

Le problème de performances avait complètement été résolu sitôt le defrag terminé.

C'est pour ça que je garde en tête ce point, et que je trouve qu'il vaut mieux toujours vérifier, même si à la base ça n'a pas l'air de venir de là

Ceci dit, si le serveur a été changé récemment (le SAN aussi ?) le problème de la fragmentation ne se pose pas : lors de la copie des fichiers, les fragments ont normalement été remis ensemble.

[Jinroh77]

La gestion des IO ne se fait pas par Windows mais par SQL Server via SQLOS.
++

Merci pour le rappel, il me semblait bien avoir lu quelque chose comme cela quelque part...

[k2011]

Le serveur etais installé depuis longtemps et etais 100% physique et les basses etais sur les disques locaux de la machine. Nous l'avons virtualisé et stoké les disque vmware sur le san.
On m'as fait installer une application aussi a cette ocasion pour les sauvegarde de la base qui s'appel netvault fastrecover et on m'as fait modifier des paramettre dans la base :

Microsoft Software Shadow Copy Provider
Volume Shadow Copy
MSDE VSS Writer
base en modèle de récupération FULL.

[mikedavem]

Pour les autres points, d'accord, je veux bien te croire "dans le cas général".

Mais j'ai déjà vécu un gros problème dans une boîte où un DEV qui s'était pris pour un DBA s'était amusé à :
- Mettre un grow size de 1 Mo sur deux fichiers MDF
- Et mettre deux tables intimement liées sur chacun des deux MDF

=> Dans un fichier, les commandes
=> Dans le second, les livraisons

Bah... Quand je suis arrivé, le serveur patinnait dans la semoule tout ce qu'il pouvait au moins select.

J'ai lancé un defrag (il devait y avoir au bas mot 50 000 fragment pour chacun des deux fichiers... le disque apparaissait intégralement rouge).

Encore une fois il faut prendre avec partimonie ce que voit l'OS lorsque cela concerne SQL Server. Je veux bien croire qu'avec un autogrowth de 1Mo une fragmentation physique peut être engendré. Cependant quel était le type de stockage derrière tout ca ? Du SAN ? Sur ce dernier la fragmentation des fichiers a beaucoup moins d'impact que sur du stockage plus traditionnel ou local.

++

[StringBuilder]

Encore une fois il faut prendre avec partimonie ce que voit l'OS lorsque cela concerne SQL Server. Je veux bien croire qu'avec un autogrowth de 1Mo une fragmentation physique peut être engendré. Cependant quel était le type de stockage derrière tout ca ? Du SAN ? Sur ce dernier la fragmentation des fichiers a beaucoup moins d'impact que sur du stockage plus traditionnel ou local.

++

Non, c'était du stockage local.
Deplus, c'était autour de 2000/2001 : le serveur avait bien moins de mémoire que la taille des données sur le disque (ce qui n'est plus le cas aujourd'hui).
Du coup des accès disques étaient nécessaires à chaque select, ce qui augmentait d'autant l'impact de la fragmentation.

[k2011]

Êtes vous sure que ce script fonctionne avec SQL2k

Code :

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

1
2
3
4
5
6
7
8
DECLARE @SQL VARCHAR(max); 
SET @SQL ''; 
SELECT  @SQL  =  @SQL + 'ALTER INDEX ' + dbo.sys_INDEX_NAME(object_id, index_id) +' ON ' + 
       dbo.sys_COMPLETE_NAME(object_id) + ' REBUILD;' 
FROM   sys.dm_db_index_physical_stats(DB_ID(), NULL, NULL, NULL, NULL) 
WHERE  avg_fragmentation_in_percent > 15 
  AND  page_count > 8 
EXEC (@SQL);

Au passage je suis tombé sur ce post et je suis perdu après sa lecture :
http://www.developpez.net/forums/d75...server-2000-a/

Juste pour info ma base fait 20Go

[mikedavem]

Non ceci n'est valable qu'à partir de SQL Server 2005 (sys.dm_db_index_physical_stats)

Vous pouvez créer simplement un plan de maintenance temporaire avec la reconstruction des index pour votre base de données et l'exécutez ensuite (attention au journal des transactions si votre base est en mode de récupération FULL). Vous pourrez supprimer ce plan par la suite.

++

[k2011]

ok merci !
- Concernant le defrag au niveau de l'OS est ce que je peux utiliser le defragmenteur de windows ou alors un autre ?
- En ce qui concerne la fragmentation des donnée dans les table je n'ai pas compris quelle commande je dois utiliser.
- Au niveau du stokage de la base j'ai plusieurs disques sur lesquel sont répartis plusieurs fichiers de la base. Cela n'as plus de sens a mon avis puisque tout est vritualisé et stoké sur la meme baie alors je me demande si il est possible de joindre ces differents fichiers. Je peux deja les déplacer sur un seul disque mais je voudrais qu'il n'y ai plus qu'un seul fichier. ( Peux etre que fussionner ces fichier n'est pas non plus une bonne idée )

[dbaffaleuf]

Non, SQL ne gère pas physiquement où va être enregistré son fichier : c'est l'OS qui fait ce travail.
=> La gestion des IO ne se fait pas par Windows mais par SQL Server via SQLOS.
===> Pour le premier, je ne savais pas.
Je me coucherai mon con ce soir

Ce que tu dis est juste. Lorsque un fichier de données ou un journal de transactions doit croître sur disque et quand ses options le lui permette (auto-extension automatique), SQL Server peut utiliser SetEndOfFile() / SetFileValidData() en fonction des cas (IFI et autres). La fonction demande à l'I/O Manager de windows d'étendre la limite physique / logique du fichier sur le disque mais n'a aucune maîtrise sur la localisation des nouveaux clusters alloués. La portion étendue peut être allouée sur des secteurs éloignés des allocations initiales. Donc le fichier se retrouve bien fragmenté physiquement sur disque. C'est pour cela qu'il vaut mieux gérer soit-même l'allocation de l'espace dans une base (pas d'option par défaut, surveillance volumétrie et extensions manuelles) et ne pas laisser SQL Server auto-étendre tout seul.

[SQLpro]

ok merci !
- Concernant le defrag au niveau de l'OS est ce que je peux utiliser le defragmenteur de windows ou alors un autre ?

Trop tard !

- En ce qui concerne la fragmentation des donnée dans les table je n'ai pas compris quelle commande je dois utiliser.

Solution déjà donnée : relire http://www.developpez.net/forums/d11...k/#post6261004

- Au niveau du stokage de la base j'ai plusieurs disques sur lesquel sont répartis plusieurs fichiers de la base. Cela n'as plus de sens a mon avis puisque tout est vritualisé et stoké sur la meme baie alors je me demande si il est possible de joindre ces differents fichiers. Je peux deja les déplacer sur un seul disque mais je voudrais qu'il n'y ai plus qu'un seul fichier. ( Peux etre que fussionner ces fichier n'est pas non plus une bonne idée )

Dans ce cas il faut faire un CREATE INDEX .... WITH DROP EXISTING de tous les index de toutes les tables. Lisez l'article que j'ai écrit à ce sujet :
http://blog.developpez.com/sqlpro/p5...pace-de-stock/

A +

[k2011]

Trop tard

???? Là j'ai rien compris.

Solution déjà donnée : relire http://www.developpez.net/forums/d11...k/#post6261004

Ben non pas déja donnée car cette solution ne fonctionne pas avec SQL2K et ma question converne le contenu des table et non les index !

Pour la troisieme réponce je ne comprend rien il va me falloir le temps de lire l'article tranquilement

Merci

[SQLpro]

Il faudrait commencer par vous former un peu au métier de DBA. Sans cela vous ne comprendrez rien à rien :
1) toute table SQL server est considérée comme un index au niveau physique
2) à peu de choses près les scripts SQL donnés peuvent être adaptés et fonctionner sous SQL Server 2000.
3) SQL Server 2000 étant maintenant vieux de 11 ans et plus maintenu par Microsoft depuis au moins 3 ans, vous auriez sans doute intérêt à prévoir une migration vers 2008... Je rappelle que SQL 2000 n'est pas compatible 64 bits donc ne tournera plus sur aucun OS windows du futur !

A +

[k2011]

Bonjour,
Bien evidement je comprend votre point de vue mais toutes les entreprises ne peuvent pas se payer un DBA. Bref.
Cette nuit j'ai déplacé les fichiers des bases et reconstruit les index mais cela n'as eu aucun effets sur les performance.
Par contre j'ai trouvé une piste serieuse pour ce pb de performance. Quand je fait une copîe de fichier le temps est tres long lorsque c'est a travers le réseau. J'ai donc sois un pb de reseaux sois un pb d'acces disque.
Si vous avez un nom de soft pour tester ces point je suis preneur.
En tout cas je tiens a remercier tout le monde pour l'aide que vous m'avez apportés.

[k2011]

Mon probleme est résolu, il y avais un pb sur la config du reseaux vmware.
MErci encore à tous

[mikedavem]

Ce que tu dis est juste. Lorsque un fichier de données ou un journal de transactions doit croître sur disque et quand ses options le lui permette (auto-extension automatique), SQL Server peut utiliser SetEndOfFile() / SetFileValidData() en fonction des cas (IFI et autres). La fonction demande à l'I/O Manager de windows d'étendre la limite physique / logique du fichier sur le disque mais n'a aucune maîtrise sur la localisation des nouveaux clusters alloués. La portion étendue peut être allouée sur des secteurs éloignés des allocations initiales. Donc le fichier se retrouve bien fragmenté physiquement sur disque. C'est pour cela qu'il vaut mieux gérer soit-même l'allocation de l'espace dans une base (pas d'option par défaut, surveillance volumétrie et extensions manuelles) et ne pas laisser SQL Server auto-étendre tout seul.

Oui excuse après avoir lu ton post je rectifie le tir (lecture trop rapide du post à StringBuilder). SQL Server gère quand et comment faire une I/O mais les opérations sur le sous système disque est effectuée par l'intermédiaire de la couche OS. Merci pour la rectification c'était important ici.

Mais ca ne change pas le problème de fragmentation vu de l'OS sur les sous systèmes virtuels ou SAN.

++