Discussion :

[genio]

Bonjour les forumistes... , la question est dans le titre...
Je dois analyser une requette de ouf qui prend squelques 10 minutes à s'effectuer... en faisant l'EXPLAIN, je vois qu'il ne passe pas par un Index que j'ai créé recemment et qui, d'après moi, devrait mieux correspondre à la demande... Il faut dire aussi que la table à analyser est très mal fichue... pas d'index primaire... des index secondaires pas toujours bien à propos etc..
De plus, la requette utilisés est générée par un logiciel et nous ne pouvons pas modifier...
La solution serait de repenser la table mais je m'y attelerait dans un deuxièlme temps... Alors, comment obliger Oracle à passer par mon IndexA alors qu'en ce moment, il passe par l'IndexB qui donne des temps de réponse catastrophiques ?
Avez-vous une solution ?

[nuke_y]

Les statistiques sont-elles à jour ?

Le logiciel permet-il un mode "étendu" qui permettrait de rajouter des hints (GENIO le fait ) ?

Sinon s'il y a une solution ça m'intéresse, je me bats sans arrêt avec des problèmess comme ça...

[genio]

J'avais oublié de dire que les stats étaient à jour...

Quand vous dites :

Le logiciel permet-il un mode "étendu" qui permettrait de rajouter des hints

Qu'est-ce qu'un 'mode 'étendu qui permettrait de rajouter des Hints' '
J'ai cherché sur les docs ce qu'était un Hint, mais je n'ai rien compris !

Cordialement

[nuke_y]

Par exemple disons que cette requête soit très longue :

Code :

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

SELECT * FROM TABLE1 G_T1, TABLE2 G_T2 WHERE G_T1.ID=G_T2.ID

en utilisant cette requête à la place ça sera plus rapide (dans un cas précis, ce n'est pas une généralité) :

Code :

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

SELECT /*+ use_hash (G_T1 G_T2) */ * FROM TABLE1 G_T1, TABLE2 G_T2 WHERE G_T1.ID=G_T2.ID

Mais évidemment pour pouvoir insérer ce hint, il faut pouvoir rajouter des informations "à la main" dans la requête générée par l'outil.

[genio]

Ok, je vais me renseigner..
En fait mon problème est le suivant :
Nous avons une table de 30 000 000 de rows qui n'a pas de clé primaire...
Imaginez :
RUB1
RUB2
RUB3

[nuke_y]

Et ?

[genio]

Je reprends ...

En fait mon problème est le suivant :
Nous avons une table de 30 000 000 de rows qui n'a pas de clé primaire... et qui est alimentée tous les mois par un batch !

Sur cette table sont attachés 4 Index dont 'le plus determinant' est composé des deux premiere rubriques de la table : RUB1 Number (4) et RUB2 Number (2) et... RUB5 (5em rubrique de la table et RUB10 (10em rubrique de la table)...
Pas gégé hein ?

Quand on me demande d'optmiser une requette de la sorte, je réponds ça :
1°)

[genio]

Je reprends ...

En fait mon problème est le suivant :
Nous avons une table de 30 000 000 de rows qui n'a pas de clé primaire... et qui est alimentée tous les mois par un batch !

Sur cette table sont attachés 4 Index dont 'le plus determinant' est composé des deux premiere rubriques de la table : RUB1 Number (4) et RUB2 Number (2) et... RUB5 (5em rubrique de la table)... RUB10 (10em rubrique de la table)... etc...
Pas gégé hein ?

Quand on me demande d'optmiser une requette qui utilise cette table (et qui consomme énorùmément) , je réponds que c'est impossible car :

1°) Même si la requette utilise l'index le + déterminant, étant donné que la table n'est pas triée, en deux 'coups' de select, on peut aller chercher d'abord une row qui se trouve en 30 millionième position et juste après, une autre qui loge en première position de la table...
Ai-je raison ?

2°) Si je demande à trouver une unicité sur la table afin de créer une clé primaire, est-ce une bonne solution ? (L'index primaire sera, très volumineux, car l'unicité doit passer par une dizaines de rubriques)

Merci pour vos réponses !