Discussion :

[eryk71]

Bonjour,

Sous Oracle 11g, j'ai executé la même requête sur 2 tables avec une jointure.
J'aimerai connaitre votre avis sur le résultat dans le plan d'execution.

Table de dimension : dimclient (190 000 lignes)
Table de fait : Faitvente (1 000 000 lignes)

Index Bitmap de jointure créee entre les 2 tables sur les champs clientid :

CREATE BITMAP INDEX idx_faitvente_dimclient
ON faitvente (dimclient.clientid)
from faitvente, dimclient
where faitvente.clientid = dimclient.clientid

1ère requête :

explain plan set statement_id ='38' for
select quantite from faitvente,dimclient
where faitvente.clientid = dimclient.clientid

L'index sur DIMCLIENT est utilisé (la PK) mais l'index sur la table de fait n'est pas utilisé. (Table access full)

2e requête :

explain plan set statement_id ='39' for
select /*+ INDEX_COMBINE (faitvente) STAR */ quantite from faitvente,dimclient
where faitvente.clientid = dimclient.clientid

Je force l'utilisation de l'index de joniture bitmap avec un hint.

Le résultat des 2 requêtes du plan d'execution est en pièce jointe.

Je constate que dans la colonne cost, IO cost et le time, la première requête est la plus avantageuse.
Pour les champs bytes et CPU_cost, c'est la 2e requête le plus avantageuse.

De manière générale, je dirais que l'index de jointure bitmap utilisé dans la 2e requête est moins performante.

J'aimerai connaître votre avis dessus, d'après vous laquelle de ces requête est la plus performante?

Merci

[Waldar]

Je n'ai jamais utilisé d'index joints donc je ne me permettrai aucun avis dessus.
Par contre je travaille fréquement avec des datamarts.

Lorsque j'en réalise, je mets des PK classiques sur les tables de dimension, des index bitmap sur chaque id de la table de fait, et je déclare des FK de la table de fait vers les tables de dimension mais que je désactive.

[fatsora]

Bonjour,

Quel temps de reponse tu as avec tes 2 requetes ?

Les index bitmap join ne sont utiles que si la colonne a une tres faible cardinalité ....
combien de valeur distincte dans la table ?

Sinon aucun interet.

As tu essaye un B-TREE classique ?

[mnitu]

• Dans le plan d’exécution cost = io_cost + f(cpu cost). Si t’analyse tes plans d’exécution il est facile à voir que la partie io_cost contribue le plus à la constitution du cost.
• Je n’aime pas trop ce que le plan montre pour les deux index, est-ce que ils ont été analysés avec dbms_stats ?

[eryk71]

Bonjour et merci de vos réponses.

Lorsque j'en réalise, je mets des PK classiques sur les tables de dimension, des index bitmap sur chaque id de la table de fait, et je déclare des FK de la table de fait vers les tables de dimension mais que je désactive.

A quoi ça sert de créer des FK si tu les désactives après? Quand tu parles d'index bitmap, tu veux dire un index bitmap composé de l'id de la dimension et celui de la table de fait.

Quel temps de reponse tu as avec tes 2 requetes ?

Les temps de réponses sont dans la colonne "time" de la pièce jointe.

Les index bitmap join ne sont utiles que si la colonne a une tres faible cardinalité

Je suis tout à fait d'accord, mais là j'ai utilisé un index bitmap de JOINTURE. En fait j'aimerai savoir quand les utiliser avec un exemple concret. C'est le sujet de mes tests.

As tu essaye un B-TREE classique ?

Dans le nouveau fichier joint, il y a le nouveau plan d'execution avec les tests suivants:

Dimension CLIENT (190 000 lignes): PK sur clientid (BTREE)
FAITVENTE (1 000 000 lignes) : FK sur client id (BTREE)

Plan d'execution
Statement id = 41 : les index ne sont pas utilisés
Statement id = 42 : Je force les index avec un hint
Analyse du plan d'execution : les performances sont meilleurs sans utilisés els index

Dimension CLIENT : PK sur clientid (BTREE)
FAITVENTE : Index bitmap sur client id
Statement id = 43 : index sur la dimension CLIENT utilisé, index dans la table de fait non utilisé

Conclusion ( voir plan d'execution dans la pièce jointe):
Les performances sont meilleures pour la requête 41, ensuite pour la requête 43 et enfin la requête 42.

Je n’aime pas trop ce que le plan montre pour les deux index, est-ce que ils ont été analysés avec dbms_stats

L'analyse a été faite avec un compute statistique sur l'integralité des index.

[fatsora]

Bonjour et merci de vos réponses.



A quoi ça sert de créer des FK si tu les désactives après? Quand tu parles d'index bitmap, tu veux dire un index bitmap composé de l'id de la dimension et celui de la table de fait.



Les temps de réponses sont dans la colonne "time" de la pièce jointe.



Je suis tout à fait d'accord, mais là j'ai utilisé un index bitmap de JOINTURE. En fait j'aimerai savoir quand les utiliser avec un exemple concret. C'est le sujet de mes tests.

justement je parle de BITMAP JOIN !!! , c'est utile uniquement dans le cas de faible cardianilité

Dans le nouveau fichier joint, il y a le nouveau plan d'execution avec les tests suivants:

Dimension CLIENT (190 000 lignes): PK sur clientid (BTREE)
FAITVENTE (1 000 000 lignes) : FK sur client id (BTREE)

As tu crée un index b-tree sur ton FK ????

Plan d'execution
Statement id = 41 : les index ne sont pas utilisés
Statement id = 42 : Je force les index avec un hint
Analyse du plan d'execution : les performances sont meilleurs sans utilisés els index

Dimension CLIENT : PK sur clientid (BTREE)
FAITVENTE : Index bitmap sur client id
Statement id = 43 : index sur la dimension CLIENT utilisé, index dans la table de fait non utilisé

Conclusion ( voir plan d'execution dans la pièce jointe):
Les performances sont meilleures pour la requête 41, ensuite pour la requête 43 et enfin la requête 42.

le meilleur temps en 47 le second 48 , c'est kif kif ca !!!


Remarque : ton "plan " n'indique pas hash_join, nested loop ...

c'est pas parce qu'il fait table full sacn que c'est mauvais...

[eryk71]

Bonjour,

As tu crée un index b-tree sur ton FK ?

Lorsque tu créees une FK, celle-ci est déjà indéxée avec une BTREE (c'est également le cas avec une PK)

Remarque : ton "plan " n'indique pas hash_join, nested loop ...
c'est pas parce qu'il fait table full sacn que c'est mauvais...

Effectivement c'est du FULL SCAN, je n'ai pas forcé la jointure j'ai laissé oracle choisir.

[mnitu]

...
Lorsque tu créees une FK, celle-ci est déjà indéxée avec une BTREE ...

Peut être pour des autres bases mais pas pour Oracle.

[fatsora]

Bonjour,





Lorsque tu créees une FK, celle-ci est déjà indéxée avec une BTREE (c'est également le cas avec une PK)

no comment

verifie par select index_name from user_indexes la prochaine fois !

[Waldar]

A quoi ça sert de créer des FK si tu les désactives après ?

http://download.oracle.com/docs/cd/B...23/constra.htm

[lallio]

Pour effectuer une comparaison, tu peux également utiliser sql plus et AUTOTRACE

exemple d'utilisation : http://www.lao-dba.com/article-23644046.html

Laurent.

[eryk71]

Bonjour,

Je vous remercie pour vos réponses.

http://download.oracle.com/docs/cd/B...a.htm#i1006284

Si j'ai bien compris le site, je récapitule la conception d'un DWH:

1) Je crée les PK dans les tables de dimension ( donc les contrainte d'unicité et non null sont crées en même temps)

2) Je crée des FK sur la table de fait correspondant aux tables de dimension en les désactivant avec ENABLE NOVALIDATE.

3) Je crée les index dans les FK (btree ou bitmap suivant les cardinalités)

3) L'objectif de désactiver les containtes des FK est d'améliorer l'alimentation des tables avec l'ETL.

4) Une fois l'alimentation ETL effectuée, je réactive les contrainte FK avec ENABLE VALIDATE

Pour effectuer une comparaison, tu peux également utiliser sql plus et AUTOTRACE

exemple d'utilisation : http://www.lao-dba.com/article-23644046.html

Laurent.

Je n'ai pas le temps de voir ça aujourd'hui mais je vais le faire prochainement, je te remercie pour le lien.

Pour ce qui est du type de joinure entre les dimensions et les tables de fait, vous avez des suggestions où bien Oracle le gère bien lorsque les statistiques des tables et index sont à jour?

Cordialement,
Eryk

[Waldar]

Non il ne faut pas valider vos FK, ça va être très long.
Si votre DWH est bien conçu vos données sont déjà nettoyées et sûres.

Vous pouvez mettre vos FK en RELY DISABLE NOVALIDATE, en gros vous dites à Oracle ne vérifie pas, je l'ai déjà fait et c'est ok.