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 !

[genio]

Excuse pour les deux messages envoyés à tort... il faut lre le dernier !

[dyvim]

Une remarque en passant...
Tu peux éditer tes messages ou même les supprimer s'ils ne sont pas pertinents ...

[dyvim]

Ils nous manque des éléments pour te répondre:
- Est ce que ta requete passe par l'index que tu mentionnes?
- Est ce que tu as des index qu'Oracle n'utilise pas pour ce select?
- Quel est l'explain plan?
- Comment est configuré l'optimiseur de requete? (CHOOSE ou RULE?)
- Quelle est ta version d'Oracle?
- Quel est le code de la requete?
- Quel est le format de la table?

[dyvim]

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...

Moi j'éviterais toujours de dire çà ... professionellement parlant....

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 ?

Si tes index ne sont pas utilisés, c'est pire que çà... C'est toute la table qu'il va falloir scanner à chaque fois que tu veux une info.

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)

J'aurais tendance à dire que toute table doit disposer d'une clef primaire mais cette norme Merise n'est que trop rarement respectée.
Cela peut s'expliquer surtout dans le cas de tables à gros volume... Une dénormalisation choisie est quelquefois une bonne chose.
Sinon pour le volume tu as raison il sera sans doute important. Cela pourrait aussi plomber les performances de ton batch d'insertion (et oui pour chaque ligne il faudra vérifier l'unicité et en plus insérer dans l'index).
Il faudra sans doute faire des tests exhaustifs pour décider ce qui est le mieux.

[gregory.broissard]

Ta table est elle partitionnée?

Si non, pense à le faire. A 30 millions de lignes, il faut y songer serieusement !