Discussion :

[n8ken]

Bonjour,
J'ai des soucis de performance avec ma base sql server.
Elle fait pour le moment 7Go (fichier mdf situé sur un disque), le system (tempdb...) est sur un autre disque et le .ldf (de 140 Mo) encore sur un autre (mode recuperation en mode simple).
Je fais des updates en masse et je remarque que je suis bloque par l'ecriture sur le disque de log ou j'ai 100% de Wait time (3000 ms) de type write log pour des requete de commit tran: ce disque contenant les logs travaille donc a fond (100 % Disk write) et empeche des performances honorables.
Comment puis je regler ce probleme?
merci

[ylarvor]

Bonjour,
J'ai des soucis de performance avec ma base sql server.
Elle fait pour le moment 7Go (fichier mdf situé sur un disque), le system (tempdb...) est sur un autre disque et le .ldf (de 140 Mo) encore sur un autre (mode recuperation en mode simple).
Je fais des updates en masse et je remarque que je suis bloque par l'ecriture sur le disque de log ou j'ai 100% de Wait time (3000 ms) de type write log pour des requete de commit tran: ce disque contenant les logs travaille donc a fond (100 % Disk write) et empeche des performances honorables.
Comment puis je regler ce probleme?
merci

Première proposition : matériel : vous avez du y penser, il suffit d'utiliser un disque plus rapide. On dit que plus le disque est rapide, mieux c'est puisque c'est lui qui entraine les pires performances. Ensuite, dans sql serveur 2000 au quotidien expert, il précise que le journal de transaction doit etre place sur un peripherique de haute performance.

Deuxième proposition : avez vous pensez à supprimer les index avant le traitement batch ? pour les recreer apres ? je ne sais pas si cela une influence sur le fichier de log mais il parrait que cela donne des resultats exceptionnels dans la gestion des transactions de gros volume.

Bonne chance.

[n8ken]

je me suis mal exprimé, quand je parle d'update en masse je veux dire que je fais beaucoup d'update dans la base (sur une table en particulier) en temps réel avec donc beaucoup de commit.

[Fabien Celaia]

Suivez donc la 1ere proposition d'ylarvor : placez votre journal de log sur un disque rapide (je dis bien un disque, pas une partition sur le même disque que les datas !

Ensuite, déterminez la taille max de vote fichier de log pendant ces traitements et forcez lui sa taille en ne lui laissant pas l'opportunité dynamique (ce qui évitera des traitements fastidieux au niveau du log et de son allocation). Il n'est malheureusement pas possible de multiplexer les fichiers de logs.

[SQLpro]

Il n'est malheureusement pas possible de multiplexer les fichiers de logs

Logiquement non, mais physiquement oui !!! Il suffit de passer en RAID 0, mieux en RAID 10 ou 0 + 1...

A +

[SQLpro]

Cela dit j'aimerais bien voir la gueule des transactions... D'ou partent elles ? Que contiennent-elles ? Quel est le niveau d'isolation ?
Parce que souvent ce genre de problème se résoud par une meilleure organisation du code...

A +