Discussion :

[ldiaz]

Bonjour a tous

(oracle 11g -- windows 2003)

j'ai un doute, soit 2 tables, article et produit. Ces 2 tables possedent un champs pour le JOIN, dans la tabla article c'est ID varchar2(8) et dans la table produit c'est PRODUIT varchar2(8) aussi.

le code:

Code :

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

1
2
FROM article a
INNER JOIN produit p ON a.id=p.produit

est present dans multitude de requete
D'ou l'idée de creer un cluster:

Code :

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

1
2
3
4
5
6
7
8
9
10
create cluster artprod(id VARCHAR2(8 CHAR));
create index idx_artprod on cluster artprod;
 
CREATE TABLE productos_cls
   CLUSTER artprod (id)
   AS SELECT * FROM productos;
 
CREATE TABLE articulos_cls
   CLUSTER artprod (producto)
   AS SELECT * FROM articulos;

Si j'execute ceci:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
SQL> select /*+ gather_plan_statistics */ count(1) from articulos a
  2  inner join productos p on a.PRODUCTO=p.ID;
 
 
Plan de Ejecuci¾n
----------------------------------------------------------
Plan hash value: 175009287
 
-------------------------------------------------------------------------------------------------
| Id  | Operation              | Name                   | Rows  | Bytes | Cost (%CPU)| Time     |
-------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT       |                        |     1 |    18 |   315  (12)| 00:00:04 |
|   1 |  SORT AGGREGATE        |                        |     1 |    18 |            |          |
|   2 |   NESTED LOOPS         |                        |   367K|  6467K|   315  (12)| 00:00:04 |
|   3 |    INDEX FAST FULL SCAN| IDX_ARTICULOS_PRODUCTO |   367K|  3233K|   281   (1)| 00:00:04 |
|*  4 |    INDEX UNIQUE SCAN   | PK_PRODUCTOS           |     1 |     9 |     0   (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------
 
Predicate Information (identified by operation id):
---------------------------------------------------
 
   4 - access("A"."PRODUCTO"="P"."ID")
 
 
EstadÝsticas
----------------------------------------------------------
          1  recursive calls
          0  db block gets
       2488  consistent gets
        916  physical reads
          0  redo size
        547  bytes sent via SQL*Net to client
        524  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

J'ai un meilleur resultat que si j'execute avec le cluster

Je comprend pas, ça devrait ameliorer les perfs n'est ce pas?
Les 2 tables sont bien candidates pour un cluster ?

Des pistes?
D'avance merci

[pachot]

Bonjour,

Ici le fait que toutes les colonnes nécessaires soient dans les index sans avoir besoin d'aller voir la table rendent l'accès par index plus efficace que l'accès par cluster.

Supprimez les index sur les tables, ou selectionnez d'autres colonnes et l'accès par cluster sera probablement plus efficace que les full scan des 2 tables. L'accès par cluster sera aussi plus interessant si vous filtrez sur un ID particulier.

Vous pouvez forcer l'accès cluster avec les hints suivants: /*+ cluster(a) cluster(p) */ pour comparer et foir si l'optimizeur a vu juste.

Cordialement,
Franck.

[ldiaz]

Bonjour Pachot,

entre temps je suis tombé sur cet article:
http://www.frontiernet.net/~rhode/cluster.html

Ouulala.

Si tu remarques, les nouvelles tables que j'ai cree n'ont pas d'index, vue que selon ce que j'avais compris, l'index est celui que tu asigne au cluster, mais bon j'ai peu être mal pigé la logique.

Autre chose, que je comprends pas bien, dans la doc ils disent que les tables candidates sont (entre autre) celles qui sont frequement dans les joins par PK.
D'apres ce que tu dis:

Ici le fait que toutes les colonnes nécessaires soient dans les index sans avoir besoin d'aller voir la table rendent l'accès par index plus efficace que l'accès par cluster.

je comprends que dans le cluster tu dois placer d'autres colonnes que celle utilisée pour le JOIN?

Le printemps se fait attendre, ça a ue influence c'est sûr !! haha

Merci encore

[mnitu]

Pour ce type de requête si vous ajoutez la contrainte de type clé étrangère entres les deux tables un plan bien plus efficace encore peut être utilisé.

[pachot]

Si tu remarques, les nouvelles tables que j'ai cree n'ont pas d'index

Le plan d'exécution en montre pourtant. Mais il semble que c'est le plan du select sur articulos/productos et non sur articulos_cls/productos_cls

je comprends que dans le cluster tu dois placer d'autres colonnes que celle utilisée pour le JOIN?

Non. Je parlais des index sur les tables. Mais je me basais sur le plan d'exécution qui semble n'être pas le bon.

[ldiaz]

ha d'accord...
Bon demain je fais le point et je vous posterais les infos.
J'ai testé sur un autre jeux de tables avec la relation PK=>FK et oui effectivement on gagne.
Comment ça ce fait? Oracle va plus vite grace a cette relation?
Ou c'est juste parce que le fait d'avoir un FK oblige a avoir les même Keys exactement dans les 2 tables ?

[mnitu]

Pour cette type de requête si on peut garantir que toutes les valeurs non-nulles d’une colonne provient d’une relation master-detail, ce que la clé étrangère en principe garanti, on pourrait éliminer la table master et chercher la réponse directement sur l’index de la colonne de jointure de la table détail.

[pachot]

Comment ça ce fait? Oracle va plus vite grace a cette relation?

Oracle fait quelques transformations pour optimiser les requêtes. Ici Primary Key-Foreign Key Table Elimination élimine les tables qu'il n'est pas nécessaire d'aller voir lors d'une jointure.

[ldiaz]

D'accord
ça limite le nombre de blocks a visiter en fait.