Discussion :

[SheikYerbouti]

Non je n'ai pas toujours raison simplement j'esaie d'argumenter mon point de vue.

Il y a 2 types d'argumentations, selon moi. La positive, consistant à apporter un conseil ou une solution, et la négative qui consiste à ne chercher que ce qui ne va pas dans les autres propositions.

[fatsora]

les optimisations 7 evidemement peuvent deconcerter les novices
mais il y a les fondamentaux !


Pour les versions plus actulles

il y a un lien ici

http://www.dba-village.com/dba/villa...A=0&SortA=Date

bon ce reprend quan meme en gros ce qui a été dis auparavant
(les fondamentaux):
indexing ,explain plan ....

sinon lire la doc

http://download.oracle.com/docs/cd/B...b14211/toc.htm

[orafrance]

Je ne vois pas pour quoi " vous critiquer" ça sera "non constructif". Il me semble que j'ai argumenté mes remarques, n'est pas vrai ?

c'est intéressant de nous corriger, mais le plus important n'est-il pas de répondre au premier post ?

[Emmanuel Lecoester]

Bonjour,

je cherche à optimiser des requêtes SQL trop longues à exécuter.
Existent t'ils des règles standards pour optimiser une requête SQL du type :
- l'importance de l'ordre des tables dans les jointures INNER JOIN?

plus d'importance avec le CBO. On te trouvera toujours un cas aux limites mais si les stats et les histo sont à jour tu auras à 99% toujours le même plan quelque soit l'ordre des tables.

- préférer une clause IN pour filtrer par rapport à une autre table plutôt qu'une clause INNER JOIN?

pourquoi ?

- préférer les jointures dans le WHERE plutôt que dans l'INNER JOIN?

c'est une écriture différente et l'optimiseur (CBO j'entends) te sortira le même plan.

- l'importance des conditions dans la clause WHERE?

Peu importe. Sauf dans le cas concet ou tu fais des outer join avec des restrictions sur la table ouverte (çà fait drole la première fois)

merci pour ces infos,

Romu

Le mieux c'est l'explain plan et tu adaptes la requête . Les grands principes existent mais la mise en pratique peut être moins puriste que les principes

[mnitu]

Il y a 2 types d'argumentations, selon moi. La positive, consistant à apporter un conseil ou une solution, et la négative qui consiste à ne chercher que ce qui ne va pas dans les autres propositions.

Voilà ce qu'on peut trouver aussi comme conseils d'optimisation (ce ne sont que des conneries). Je me demande quel type d'argumentation peut t'on faire.

[SheikYerbouti]

Et bien oui, encore une fois, une proposition hautement constructive. Merci pour nous

[plaineR]

mnitu, comme il n'existe pas de tuto sur l'optimisation (sauf erreur de ma part) et comme tu as l'air de maîtriser ce sujetpeut-être pourrais-tu en rédiger un. Ce serait constructif et utile pour plus d'un.
Car à moins de suivre une formation oracle, il est difficile de trouver des informations fiables sur ce sujet.

[pacmann]

Salut !

Un peu comme tout le monde... :
- Ne pas casser les indexes en appliquant des fonctions sur les colonnes jointes
- Vérifier le plan d'exécution et le cas échéant utiliser des hints, parce que même si l'optimiseur progresse, il y a des spécificités dans la distribution de tes données, dans la corrélation qui existe entre tes différentes colonnes, ..., que les statistiques ne permettent de détecter...
- Etre particulièrement vigilent avec les vues et inline views, parce que ça se transforme parfois de manière suboptimal...
(je dis ça parce que j'ai vu récemment des merge pas sympas, ou des prédicats que j'aurais préféré voir pushés)

Mnitu : je trouve ton lien génial !
(par contre, c'est dommage que les commentaires d'insulte se trouvent en bas : il y a des gens qui pourraient croire que l'article est pertinent...)

[orafrance]

Voilà ce qu'on peut trouver aussi comme conseils d'optimisation (ce ne sont que des conneries). Je me demande quel type d'argumentation peut t'on faire.

c'est peut-être pas que des conneries mais ça part mal :
1) FTS (Full Table Scans) are always bad and Index usage is always good.

Voila une assertion bien cavalière est particulièrement fausse

J'aime autant un tuto qui peut être obsolète sans être faux que ce type de lien qui raconte n'importe quoi

[Emmanuel Lecoester]

J'aime autant un tuto qui peut être obsolète sans être faux que ce type de lien qui raconte n'importe quoi

+1 orafrance

[mnitu]

@plainer
Et pourquoi pas si cella intéresse les gens vraiment.

@sheikyerbouti
J’ai déjà poste ce lien « constructif » sur un autre fil de discussion. Et celle ci aussi .
Par ailleurs je trouve que pointer ce qui ne va pas dans une affirmation ou un exemple c’est toute à fait constructif qu’une démi-vérité. Ce n’est pas que je ne suis pas d’accord avec vous dans vos conseils c’est seulement que, pour une partie

• Ils sont vrai dans certaines contextes mais pas toujours et vous ne le précisez pas
• Ils sont dépassés par l’évolution de l’optimisateur et cella n’est pas précisé non plus.

La où nous somme (peut être) d’accord est que le document a un peu (trop) vieilli.
Et c’est aussi vrai que je n’aime pas trop les conseils de type « Exists est toujours mieux que IN », etc. Cella dépende du contexte, de la version de l’optimiseur, etc. Mais bon je ne tiens pas a vous convaincre sur ce dernière point.

A propos vous ne m’avez pas répondu d’une manière constructif sur ma question sur l’ordre des colonnes dans un index composite.

@orafrace
Si ma blague concernant le Saint Graal vous a gêné je fait mon mea culpa.

[plaineR]

@plainer
Et pourquoi pas si cella intéresse les gens vraiment.

Moi, en tout cas cela m'intéresse vraiment. Et je pense ne pas être le seul.

[pacmann]

A propos vous ne m’avez pas répondu d’une manière constructif sur ma question sur l’ordre des colonnes dans un index composite.

Les colonnes les plus sélectives peuvent être des références "fortes".
Si les données de la table sont découpées de manière logique selon plusieurs colonnes, le fait de mettre des colonnes les moins sélectives au début peut permettre à l'utilisation de l'index à plus de requêtes...

Exemple ?

Employes (IdDep, Idemploye, Salaire).

Mettre un indexe sur (IdEmploye, IdDep), c'est un peu dommage, vu que dans l'autre sens, (IdDep, IdEmploye), ça aurait permis par exemple de calculer les salaires moyen par département assez facilement...

Par ailleurs, si vraiment on a besoin d'une recherche sur IdEmploye sans le IdDep, on peut supposer que le skip scan ne sera pas trop mauvais (à moins qu'il y ait des millions de départements avec un gens tout seul à chaque fois...)

[EDIT]
Bon, j'ai aussi vaguement la sensation que le choix de l'ordre des colonnes impacte fortement le clustering factor.
... et je ne pense pas que mettre systématiquement la colonne la plus sélective en premier soit la bonne solution de ce point de vue
=> Mais tout ça ne sont que des suppositions sans aucun fondement !

[orafrance]

@orafrace
Si ma blague concernant le Saint Graal vous a gêné je fait mon mea culpa.

Pas vraiment, ce qui me gène c'est de critiquer 2 réponses dont une qui contient une tutoriel rédigé par celui qui répond, alors que tu ne proposes pas une seule ressource rédigé par toi même. Un tuto a été écrit et proposé par Sheikyerbouti et ce tuto reste d'actualité même si ce qui justifie les recommandations sont obsolétes... venir sabrer ce tuto parce que le CBO s'est amélioré, je trouve pas ça constructif. En effet, c'est pas parce qu'Oracle s'efforce de prendre en compte les mauvaises habitudes des users qu'il ne faut pas corriger ces habitudes.

Après, tes remarques sont exactes et permettent de corriger nos réponses, c'est très bien mais ce serait encore mieux si tu proposais des ressources parfaites ou une réponse personnelle et pas seulement un partage de ton bookmark

[Waldar]

Et si la solution était de remettre le tutoriel de Sheikyerbouti à jour ?

Il me semble que le but d'un site communautaire comme celui-ci est bien le partage de la connaissance (en français en l'occurence) et non pas de se tirer dans les jambes (pour ça nous avons des collègues de boulot).

[SheikYerbouti]

Et si la solution était de remettre le tutoriel de Sheikyerbouti à jour ?

Justement nous recherchons des rédacteurs

[fatsora]

J'ai surtout l'impression que les administrateurs oracle ont tendance a faire comme les dentistes, c'est a dire , critiquer ce que font les confreres ....

Ah cest untel qui a mis ce dentier, ah c'est lui qui a mis fais ca sur cette dent..

moi j'aurais fais ci , fais ca ...

C'est ptet humain , mais le resultat est que le client final se regale de ce genre de pagaille .....

[orafrance]

Je ne pense pas... pour ma part, j'ai plus souvent vu des DBA travailler avec le DBA en place que contre lui

Après, bah le métier de DBA étant sous-estimé, c'est un rôle qu'est souvent tenu par un mec qui n'y connait pas grand chose et forcément il y a des erreurs de faites... mais dans ce cas, on critique le choix de la personne plutôt que le malheureux qui a été parachuté là

[mnitu]

...

[EDIT]
Bon, j'ai aussi vaguement la sensation que le choix de l'ordre des colonnes impacte fortement le clustering factor.
... et je ne pense pas que mettre systématiquement la colonne la plus sélective en premier soit la bonne solution de ce point de vue
=> Mais tout ça ne sont que des suppositions sans aucun fondement !

Merci pacmann pour ton effort mais franchement si toi même n’est pas convaincu …
Mais, j'ai peur que je resterai sur ma faim en ce qui concerne ce conseil.

[pacmann]

Bah, je sais pas trop comment le clustering factor est calculé, mais d'une certaine manière, ça mesure le degré de regroupement dans les blocs des valeurs adjacentes de l'index...

Donc bon, je me dis que dans certains cas, "hiérarchiser" les colonnes de son indexe selon des critères logiques en partant du plus large, pourrait avoir des chances d'augmenter ce degré de regroupement...

Bien entendu, ça dépend de comment les données sont alimentées... mais le but était justement de ne pas opter pour une solution dogmatique, non ?