|
Publicité ' | |||||||||||||||||||||||
|
|
#1 | ||
|
Candidat au titre de Membre du Club
![]() Inscription : août 2003 Messages : 43 ![]() |
Bonjour,
Est-il possible d'améliorer la requête ci-dessous sachant que les deux tables ont un index sur ID_CONTACT @MinId et @MinIdUp sont des bornes de 3000 enregistrements afin de ne pas remplir les logs. Merci de votre aide Code :
Table #LAST_CURE : 300.000 enregistrements |
||
|
|
00
|
|
|
#2 | ||
![]() ![]() |
Je pense que non.
Pour en etre sur, pouvez-vous nous retourner le showplan ? Soit Code :
|
||
|
|
00
|
|
|
#3 | ||||
|
Candidat au titre de Membre du Club
![]() Inscription : août 2003 Messages : 43 ![]() |
C'est le showplan d'une autre requete du même style.
Code :
Code :
|
||||
|
|
00
|
|
|
#4 | ||
![]() ![]() |
Le probleme, c'est l'update en mode defered venant de la clause from...
En terme d'index, on ne peut pas faire bcp mieux que ce qu'il y a a present (2 index cluster)... Vous serait-il posible d'executer un sp_sysmon pendant un update afin de voir ou cela peche ? Code :
Quant aux 5 secondes, tout est relatif (il peut par exemple s'agir d'un verrou bloquant)... votre update execute quand meme plus de 88000 acces a des pages de 2K |
||
|
|
00
|
|
|
#5 | ||
|
Candidat au titre de Membre du Club
![]() Inscription : août 2003 Messages : 43 ![]() |
Le problème est que je ne suis pas seul sur le serveur. le sp_sysmon sera pollué par les autres utilisateurs.
Concernant le temps d'exécution, ce n'est pas 5 secondes mais plutôt 5-10 minutes pour 4500 enregistrements Je vais reformuler le contexte, cela pourra peut être ouvrir une autre piste. Objectif : Mettre à jour un champ de la table CONTACTS (champ non indexé) par une valeur de la table #TMP_RECENCE. La jointure se fait sur l'ID_CONTACT Contraintes : Afin de ne pas bloquer le serveur en remplissant les logs, on nous a demandé de splitter les requêtes. Nous faisons donc plusieurs requetes selon un interval sur ID_CONTACT. 2 tables : Table CONTACTS : 800.000 enregistrements (ID_CONTACT unique) Table #LAST_CURE : 300.000 enregistrements (ID_CONTACT unique) Requete : Code :
Merci |
||
|
|
00
|
|
|
#6 |
![]() ![]() |
Il y a aussi la possibilite peu elegante de faire des UPDATES successifs en utilisant le afin de ne pas saturer le log... mais ca depend de l'update implique.
En ce qui concerne la "POLLUTION" et sp_sysmon, c'est justement elle qui est interessante : si les autres utilisateurs posent des verrous sur ladite table, cela se verra. |
|
|
00
|
|
|
#7 | ||||||||||||
|
Candidat au titre de Membre du Club
![]() Inscription : août 2003 Messages : 43 ![]() |
Non, je suis le seul à attaquer ces tables.
Voici dans tous les cas quelques résultats du sp_sysmon. SI tu as besoin de certaine partie plus particulièrement, je pourrais également les poster. Dans tous les cas, merci de ton aide sur ce sujet. Code :
Code :
Code :
Code :
Code :
Code :
|
||||||||||||
|
|
00
|
|
|
#8 |
![]() ![]() |
Rien a redire du sp_sysmon si ce n'est les 2 points suivants:
1) les 38% de data qui ne se trouvent pas en cache (mais c'est peut-etre normal si la table en question n'est pas tres utilisee) 2) l'ULC a plus de 70%... la il vaudrait mieux la passer a 2048 (au cas ou elle est a 1024) |
|
|
00
|
|
|
#9 |
|
Candidat au titre de Membre du Club
![]() Inscription : août 2003 Messages : 43 ![]() |
Merci pour votre aide
|
|
|
00
|
Copyright © 2000-2012 - www.developpez.com