Discussion :

[Slaveak]

Bonjour à tous,

J'ai une requête en select avec une jointure entre deux tables de grosse volumétrie (100M sur la table principale et 15 dans la table secondaire) et j'ai un status suspended.
Le but est de select une seule colonne d'ID pour récupérer ces ID et les récupérer pour pouvoir les delete.
la clé de jointure repose sur huit colonnes, indexées dans les deux tables.

la première table est une table définitive et la deuxième une table temporaire, je joins les deux le la clé métier pour trouver les ID des lignes présentes dans ma table définitive à virer avant que les lignes de la temporaire les remplacent.

Et donc mon problème c'est que ça n'avance pas et quand je regarde le status de la requête elle est suspended et je ne sais pas comment faire pour récupérer ma liste d'ID.
la requête fonctionne bien, mais sur des plus petites volumétries.

Avez-vous une idée de comment débloquer la situation ?

Merci d'avance pour votre coup de main

[al1_24]

Je n'ai pas bien compris : c'est une requête SELECT ou une requête DELETE ?
Peut-être qu'en voyant la requête ce sera plus simple pour t'aider...

[Slaveak]

Effectivement, je vais être plus précis.

En fait via SSIS, je charge un fichier brut et en source de ce chargement ma requête select qui bloque :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
select ID_TABLE_DEFINITIVE
from TABLE_DEFINITIVE as DEF
JOIN TABLE_TEMP as TEMP
	ON DEF.COLONNE_1 = TEMP.COLONNE_1
	AND DEF.COLONNE_2 = TEMP.COLONNE_2
	AND DEF.COLONNE_3 = TEMP.COLONNE_3
	AND DEF.COLONNE_4 = TEMP.COLONNE_4
	AND DEF.COLONNE_5 = TEMP.COLONNE_5
	AND DEF.COLONNE_6 = TEMP.COLONNE_6
	AND DEF.COLONNE_7 = TEMP.COLONNE_7
	AND DEF.COLONNE_8 = TEMP.COLONNE_8
	AND DEF.DATE_1 = TEMP.DATE_1

Donc je fais ce select dans ma source OLEDB et celle ci va charger mon fichier brut. Une fois le fichier brut chargé, je fais un DELETE en fonction des ID présent dans le fichier brut.

Mais j'ai testé directement la requête select dans SSMS et à ce point de volumétrie, ça bloque...

[SQLpro]

...la clé de jointure repose sur huit colonnes, indexées dans les deux tables....

Votre problème vient très certainement de là !!!!

Il est déjà moyennement performant d'avoir une clef comportant 2 colonnes. Alors avec 8 'est parfaitement imbécile ! Je suppose en sus que ce sont des colonnes fonctionnelles genre VARCHAR... (ce qui serait le pire du pire...)
Commencez par réduire la clef et vous verrez que tout ira mieux !

A +

[Slaveak]

Et bien je veux bien la réduire, mais je la réduit comment ? C'est une clé fonctionnelle donc je n'ai pas le choix, il faut que j'ai ces 8 colonnes, ou tout du moins leur contenu... je créé une colonne concaténée avec les 8 valeurs (qui ne sont que des numerics ou des int) ?

En tout cas merci pour la piste.

Autre question n'aurais je pas intérêt à partitionner ma grosse table de fait ? (vous allez me dire que oui mais bon...) mais selon quel critère ? par rapport à une date qui va être utilisé dans l'outils de restitution ? ou plus se mes critères techniques d'intégrateur ?

[escartefigue]

Et bien je veux bien la réduire, mais je la réduit comment ? C'est une clé fonctionnelle donc je n'ai pas le choix, il faut que j'ai ces 8 colonnes, ou tout du moins leur contenu... je créé une colonne concaténée avec les 8 valeurs (qui ne sont que des numerics ou des int) ?

Surtout pas !
Il faut une colonne unique de type integer et dont le contenu est un identifiant technique. Le plus simple est d'utiliser une valeur attribuée par la base de donnée.
Ca vous garantira une clef stable et concise, donc performante.

Autre question n'aurais je pas intérêt à partitionner ma grosse table de fait ? (vous allez me dire que oui mais bon...) mais selon quel critère ? par rapport à une date qui va être utilisé dans l'outils de restitution ? ou plus se mes critères techniques d'intégrateur ?

Partitionner oui, le(s) critère(s) dépend(ent) de l'exploitation et des contraintes de service

[SQLpro]

Et bien je veux bien la réduire, mais je la réduit comment ? C'est une clé fonctionnelle donc je n'ai pas le choix, il faut que j'ai ces 8 colonnes, ou tout du moins leur contenu... je créé une colonne concaténée avec les 8 valeurs (qui ne sont que des numerics ou des int) ?

En tout cas merci pour la piste.

Autre question n'aurais je pas intérêt à partitionner ma grosse table de fait ? (vous allez me dire que oui mais bon...) mais selon quel critère ? par rapport à une date qui va être utilisé dans l'outils de restitution ? ou plus se mes critères techniques d'intégrateur ?

Une solution consiste à rajouter une colonne calculée sous la forme d'un hachage des colonnes clef. Ceci suppose que vous intégrez le fichier en temps que table temporaire puis rajouter cette colonne calculée persistance, la modifiez en NOT NULL et en faites un index unique CLUSTERED.

A +

[Slaveak]

Une solution consiste à rajouter une colonne calculée sous la forme d'un hachage des colonnes clef. Ceci suppose que vous intégrez le fichier en temps que table temporaire puis rajouter cette colonne calculée persistance, la modifiez en NOT NULL et en faites un index unique CLUSTERED.

C'est une superbe idée ! Merci beaucoup !

Je ne sais pas trop comment faire techniquement pour faire ce hachage de colonnes clés mais je vais chercher tout ça. (oui car à la base, je ne suis qu'un humble intégrateur de données quasi autodidacte).

Je vous tiens au courant des résultats de mes développements.

[elsuket]

Bonjour,

Utilisez pour cela la fonction HASHBYTES avec un algorithme costaud (SHA2_256 ou SHA2_512) de façon à éviter les collisions.
Ne persistez pas la colonne (vous ne l'afficherez à priori jamais), mais indexez-la pour supporter la jointure.

Cela dit il serait intéressant de voir quel est le type d'attente qui place la requête à SUSPENDED.
Que donnent les colonnes wait_type et wait_time de la vue sys.dm_exec_requests pour la session considérée ? Je parie sur CXPACKET.

@++

[Slaveak]

@ SQLpro et elsuket : J'étais justement en train ( et pour la énième fois) de reparcourir votre bouquin sur le sujet et justement il est bien écrit qu'il peut y avoir des colisions si j'utilise un CHECKSUM et j'aillais justement vous demander si c'était pas un peu risqué de tenter via un CHECKSUM donc merci pour ta précision.

Mais je peux faire un HASHBYTES sur plusieurs colonnes ? Vous écrivez dans votre ouvrage, que le HASHBYTES renvoie une clé en fonction d'une valeur scalaire, mais justement, cette valeur serait donc le résultat de mes 8 colonnes non ?

Sinon oui je vais vérifier le wait_type et je vous fais un retour.

Encore une fois merci pour les coups de mains.

EDIT : @elsuket tu es trop fort ! le wait_type est bien un CXPACKET !