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
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.
pourquoi ?- préférer une clause IN pour filtrer par rapport à une autre table plutôt qu'une clause INNER JOIN?
c'est une écriture différente et l'optimiseur (CBO j'entends) te sortira le même plan.- préférer les jointures dans le WHERE plutôt que dans l'INNER JOIN?
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)- l'importance des conditions dans la clause WHERE?
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 principesmerci pour ces infos,
Romu
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.
Et bien oui, encore une fois, une proposition hautement constructive. Merci pour nous
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.
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...)
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
+1 orafranceJ'aime autant un tuto qui peut être obsolète sans être faux que ce type de lien qui raconte n'importe quoi
@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.
Les colonnes les plus sélectives peuvent être des références "fortes".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.
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 !
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
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).
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 .....
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à
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 ?
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager