Discussion :

[sgora]

sauf si ça limite suffisamment le nombre de lignes de t1 Si la concaténation des colonnes de t2 limite l'échantillon de ligne de t1 alors l'index est intéressant.





Bah voila, tu raménes plus de 87% des lignes de t1, alors pourquoi passer par un index ? Ce qu'il faudrait c'est une jointure avec t3 pour réduire encore le nombre de ligne ramenée.

Pourquoi t'as t3 qui traine tout seul ?

@ orafrance Apparemment, tu ne fais pas la différence entre un clause de jointure et une clause de filtre de données

Ta clause de jointure t'empêche seulement d'avoir un produit cartésien entre les deux tables, cependant elle ne filtre pas les données.
C'est à dire qu'au lieu de d'avoir une cardinalité exponenetielle, elle sera seulement géométrique : youpi !

Et comme dans ce cas, on a des cardinalités en base qui ce comptent en million, passer par les index voudrait dire faire n millions d'accès aux index, plus n millions d'accès mono bloc aux tables, ceci comparé à deux full scan, soit pour deux tables de 10 000 blocs avec un DBMRC de 16 environ 2000 I/O disques, certes plus longues, mais à comparer avec les millions générées par le plan avec index.

Et vu la quantité de données maniées dans la requête, elle devrait durer quelques minutes au plus en FTS, on est sur des dizaines de Mo, pas sur des Gigas.

[orafrance]

Et comme dans ce cas, on a des cardinalités en base qui ce comptent en million, passer par les index voudrait dire faire n millions d'accès aux index, plus n millions d'accès mono bloc aux tables, ceci comparé à deux full scan, soit pour deux tables de 10 000 blocs avec un DBMRC de 16 environ 2000 I/O disques, certes plus longues, mais à comparer avec les millions générées par le plan avec index.

on est bien d'accord Mais ce n'est, je pense , pas un problème de filtre ou de jointure mais bien un problème de pourcentage de lignes traités. Si il ramenait 30% des lignes au lieu de 87%, Oracle utiliserait bien l'index

[sgora]

Non, il il utiliserait sans doute l'index pour un pourcentage de lignes ramenées moindre, aux alentours de 10%, mais tout cela dépend de divers facteurs, la distribution des données, le paramétrage Oracle,etc.

Mais la question n'est pas là, as-tu déjà vu beaucoup de jointures qui ramènent 10 ou même 30% de la cardinalité ?
Moi pas, quand je vois la plupart des jointures utilisées par les applications, je constate qu'elles expriment des relations 1:1 ou 1:n, ce qui fait qu'on a au minimum 100% de la cardinalité de la table la plus petite.

Tu conviendras que comme filtre, on fait mieux...

Donc une condition a.col = b.col est a priori pas sélective du tout (elle n'est pas faite pour ça, d'ailleurs), alors que a.col = 'literal' est un filtre de sélection potentiellement puissant (ça dépend du NDV de col et de la
distribution de ces valeurs dans la colonne considérée)

Mais au delà de cela, il est incompréhensible qu'une requête de ce style prenne 16 heures à finir en FTS vu les volumétries annoncées, il existe sûrement un autre problème quelque part.

Je conseille donc de faire si possible une trace de l'exécution de la requête, on y verra peut-être plus clair...

[orafrance]

C'est pas faux, c'est bien ce qui m'améne à penser qu'il y a un soucis dans la modélisation Si il n'y a pas de filtre c'est que le modéle de données n'est pas adapté tout du moins à ce type d'interrogation (une MV peut suffire pour régler le problème)

Sur le fond, nous sommes d'accord

[Waldar]

Pas d'accord, l'auteur précise :

La requête est genéree par un outil Informatica

Un des outil phare d'informatica c'est leur ETL powercenter.
Donc potentiellement il peut alimenter un datawarehouse, recalculer des agrégats, bref manipuler de grandes quantité de données de manière justifiée.

[sgora]

L'auteur précise également que c'est la requête telle qu'il nous la décrit qui prend 16 heures, pas l'ensemble du job Informatica, qui peut faire beaucoup d'autres opérations, mais qui ne nous concernent pas.

C'est pourquoi une trace d'exécution de la requête serait utile pour évaluer les dégâts.

Et si la requête SQL en dehors de powercenter s'exécute en deux minutes, on pourra en déduire que le problème se situe au niveau d'Informatica, ce qui ne m'étonnerait pas plus que ça.

[Waldar]

Tout à fait d'accord cette fois-ci, sans trace point de salut.

[nax71]

Desole pour mon silence mais hieri j'ai travaille sur un autre sujet.

Je pense que le pb vient de l'augmentation de la taille de la table t1 ce qui par rapport aux autres tables.

Au fait sur la base de dev j'ai modifié cette taille pour que le nombres de lignes retounées soit a moins de 50%. Et je passe par l'index.

Je vous remercie pour votre aide.