Discussion :

[Monstros Velu]

Bonjour,

j'ai une requête qui dure, en dev, 1jour et 6heure (identification e traitement de doublons sur une très grosse table), avec le processeur qui tourne à 99%. Or, les utilisateurs ont besoin que la base reste réactive, et celle de prod est utilisée H24.

Existe-t-il un moyen pour dire "cette requête, il faut l'exécuter, mais s'il y a d'autres demandes, on ralentit pour exécuter les autres en priorité." ?

[elsuket]

Bonjour,

Cela n'est possible que dès SQL Server 2008 avec le Gouverneur de Ressources.
Néanmoins plus d'un jour me semble un temps terriblement long pour traiter des doublons. N'utiliseriez-vous pas un curseur pour faire cela ?

Essayez plutôt d'optimiser votre requête ...
Nous pouvons regarder cela si vous nous en donnez le code et le DDL des tables.

@++

[Monstros Velu]

Je n'ai fait que de l'ensembliste, mais j'utilise une CTE pour remonter des anciens vers les nouveaux, c'est ce qui prends du temps : Il ne s'agit pas juste de les détecter (ça, ça prend 3min16s ;o) ).


Ensuite, j'ai optimisé en faisant des paquets de 10000 (j'ai testé des paquets de 10, 100, 1000, 10000 et 25000, et 10000 semble avoir le meilleur ratio.) qui tournent dans un while.

[elsuket]

OK

Quid de l'indexation ?

@++

[Monstros Velu]

Toutes les colonnes utilisées sont indexées. Mais parmis les 6 critères pour retrouver un doublon, il y a

Code :

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

YEAR(EMP_BIRTHDATE)%100

, qui ne doit pas utiliser d'index, car nous venons d'apprendre que seul les 2 derniers chiffres sont significatifs dans les fichiers d'import que nous recevons depuis près de 3ans (d'où une partie des doublons)