Index or not ?

[jeremzzz]

Bonjour à tous.

Actuellement je travaille sur plusieurs base de données différentes (allant de 6i à 10g) et je me pose la question suivante : Un index est-il vraiment utile sur certaines de mes tables, qui ont des problèmes de performances.

Je vous explique :

Mon entreprise utilise pas mal de tables temporaires pour un peu tout, notamment l'édition des reports.

Ayant parfois plusieurs utilisateurs, nous utilisons un numéro d'identifiant unique par utilisateur qui n'est pas clé primaire sur la table puisque, dans le cas d'une commande par exemple, un utilisateur peut avoir x lignes de commande donc x fois ce numéro.

Ces tables sont donc soumises à de forts changements très fréquents, passant parfois de plusieurs centaines de milliers à 0 ligne en quelques minutes à longueur de journée.

Donc faut-il vraiment qu'il y ait un index sur nos tables temporaires, où cela ralentit-il au contraire les opérations sur les tables ?

Je précise aussi que nous avons parfois plusieurs index, mais ce numéro unique par utilisateur est toujours présent dans chaque index.

Merci d'avance pour votre aide

[ldiaz]

Bonjour,

ton index sera util si la selectivité est bonne sur ta table. On entend par selectivité le fait qu'il y est beaucoup d'ID differents. Exemple.
Si dans une table tu fais un index sur "genre" ici homme ou femme. Ta selectivité risque d'etre naze vu que sur 100 000 lignes tu peux avoir je sais pas: 40 000 hommes et 60 000 femmes.
Donc si tu filtre ta requete par

select blabla, blibli from table
where genre ='homme';

Tu risques d'avoir un full scan et donc une query lente.
Tel que tu explique, cet ID est unique, donc la selectivité sera bonne, donc pas de full scan, sauf si ta table au moment de la requete n'a que tres peu de ligne. Dans ce cas l'optimizeur d'oracle risque de preferer le full scan.

Donc je ferais un index sur la table.

D'autre part pense a executer des stats regulieres d'autant plus si la quantite de ligne change souvent.

Aussi tu peux sortir les snap de toute une journée et regarder le top 5 events avec index et sans index. La probablement tu verras une diference.

J'espere que cela pourra t'aider.

Ciao

[jeremzzz]

Vu le client dont il s'agit, j'ai très rarement peu de lignes, ça tourne souvent à plus de 5000 et ça monte facilement à 100 000 voire même 400 000 parfois (s'il n'y a qu'un seul utilisateur qui utilise le programme)

Merci pour les informations. Je laisse donc mes index.

Pour le moment, j'ai mis en place un script qui recréé la table tous les week end. C'est pas le mieux, mais au moins je n'ai plus mes problèmes de performances.

[ldiaz]

Tu peux aussi faire un simple test

Tu fais une requete avec une conditions where qui utilise un champ indexé (ou pas).
Avant la requete tu fais un set autotrace on
comme ça tu verras les consistent gets et phsysical reades.
Tu test avec et sans index et tu verras les differences.
L'objectif etant d'avoir un minimum de physical reads vu qu'il s'agit des lecture a disque, les plus couteuse, les consistent gets etant les acces aux block de données en memoire (plus rapide).

Bonne chasse

[pachot]

Bonjour,

Envoyé par jeremzzz

Ayant parfois plusieurs utilisateurs, nous utilisons un numéro d'identifiant unique par utilisateur qui n'est pas clé primaire sur la table puisque, dans le cas d'une commande par exemple, un utilisateur peut avoir x lignes de commande donc x fois ce numéro.

Il pourrait par contre faire partie de la clé peut-être, même s'il nêst pas identifiant à lui tout seul.

(allant de 6i à 10g)

6i ça n'existe pas.
Est-ce que tu utilise des global Temporary Tables ? Ce serait bien si chaque session ne doit voir que ses données.

Cordialement,
Franck.