Bonjour à tous
 
Une petite question sur l'utilisation d'index sous Oracle :
 
J'ai une application effectuant de nombreuses requêtes sur une base. J'aimerais optimiser le tout en ajoutant les index qui vont bien. Notamment des index composites sur mes tables de référence, de manière à ce que les tables ne soient plus (ou presque plus) sollicitées, mais que tout passe par les index.
 
Mais voilà, mettons une table A contenant les champs A.1, A.2 et A.3.
Elle dispose d'un index sur les champs 1, 2 et 3.
J'effectue une requête en utilisant que les champs 1 et 2.
 
L'index suscité est-il utilisé lors de cette requête ? Ou faut-il créer un index spécifiquement sur les champs 1 et 2 ?
 
C'est peut être con, mais j'arrive pas à en être sûr.
 
Merci d'avance

me semblait avoir vu des experts Oracle dans le coin

Oui, l'index sera utilisé, mais Oracle va faire un range-scan dessus. Ce sera toujours plus rapide que sans index, mais loin d'être aussi efficace que si tu mets un second index uniquement sur A.1 et A.2
 
N'hésite pas à mettre une tétrachiée d'index par table.

ok merci pour ta réponse très précise
 
Le problème est que j'ai vraiment beaucoup de requêtes, et certaines tables contiennent beaucoup de colonnes Bon je vais devoir faire une étude détaillée, tant pis

fait attention, oracle défini automatiquement un index sur la primary key de la table, donc pas besoin de le faire en double celui la

Bonjour, je profite de ce topic pour poser mes questions de debutant.
 
Je possede une table relativement importante ( dans les 20 000 lignes), et voulait savoir si il etait pertinent d'utiliser des indexs (voir autre methodes, si vous connaissez) pour optimiser son acces. Dans le cas ou oui, il faut signaler que cette table sera mise a jour tous les jours, car j'avais lu qu'il etait deconseille de mettre des index sur des tables qui bouggent souvent. Est-ce le cas ?
 
Jusqu'a combien de ligne par table peut on aller sans que l'eficacité de recherche au sein de cette table (avec une quinzaine de champs) soit reelement touchée ?
 
Sinon, autre question, existe-t-il une methode 'insert or update' en sql pour qu'il soit verifier dans la base que l'entree n'existe pas deja, et qu'elle soit mise a jour seulement si elle existe, inseree sinon ?
 
Merci

20000 lignes c'est petit
 
Les index servent à accéder à des données rapidement, il faut donc les créer sur les données 'clé' de la table, càd les données par lesquelles on accède souvent à la table.
 
Si tu ne fais que des recherches multi-critères portant sur une dizaine de champs, un index ne te servira pas beaucoup.
 
Un index sur une table aussi petite ne changera pas beaucoup les perfs lors des insertions / effacements / mises à jour.
 
A ma connaissance, il n'y a pas d'insert or update sous Oracle. Il vaut mieux faire un SELECT d'abord pour vérifier si l'élément existe, puis l'INSERT.

 
J'ai pas d'experience, donc pas de reference, c'est pour ca cette table me parraisait assez importante. Bon comme ca tu me fais gagner du temps, c'est cool !   Merci pour les reponses !
 
Makko

En gros :
Un index, dès que t'as plus d'une ligne, c'est indispensable. Même si ça change pas grand chose, c'est comme faire rouler une voiture sans pneu. A 10 km/h, ça changera rien, mais c'est mal.
 
Sinon, non, Oracle ne supporte pas les trucs pourris de MySQL. Oublie ce dernier, tu n'apprendras que de la merde et de mauvaises habitudes.
 
Pour faire l'équivalent de ce truc, tu devras faire un trigger, "on insert, unpdate" qui fera la vérification lui-même avant l'insertion afin de décider de l'action à prendre.

 
C'est con mais je n'y avais meme pas pensé ! bah c'est cool je vais faire ca, merci du tuyaut !
 
Sinon je posais la question car j'avais trouvé des informations allant dans le sans contraire dans un bouquin complet sur oracle (je cite les deux qui m'ont choquées):
"Ne pas creer d'index pour des tables de petite taille. Le gain de vitesse de recherche n'est pas superieur au temps d'ouverture et de recherche dans l'index."
et  
"Ne pas creer d'index sur une table frequement mise a jour."
 
Mon bouquin oracle est si pourri que ca ?

Non, il n'est pas pourri.
 
Un index est en effet "inutile" sur une petite table, puisque la recherche des infos dans les données brutes sera aussi rapide que la recherche dans l'index.
Et après ? Dans tous les cas, tu vas passer 1 ou 2 ms pour trouver les données. Y'a pas mort d'homme. Par contre, si tu mets pas d'index, le jour ou, pour une raison X, ta table qui contenait 20 lignes, en contient 20 millions, tu seras bien content de ne pas avoir oublié l'index.
 
Pour les tables mises à jours fréquement, c'est vrai aussi : chaque mise à jour de données équivaut à une mise à jour des index. Donc si t'as 1 index sur une table, chaque mise à jour va nécessiter 2 mises à jour sur le disque, donc c'est lent.
Mais quand tu vas faire un SELECT sur cette table, tu seras bien content de trouver l'index pour éviter de passer deux heures à retrouver les données (surtout que si la table est souvent mise à jour, sa représentation physique doit être un vrai gruyère).
 
Bref, le bouquin a raison, mais je suis fondamentalement contre ce genre d'arguments, ça ils ne représentent pas la réalité d'entreprise.
 
Idéalement aussi, il faudrait supprimer tous les index avant une insertion de lot, pour les remettre ensuite : recalculer un index tout entier, c'est plus rapide que le remettre à jour 1 million de fois. Sauf que t'iras expliquer ça au mec qui a attendu la matinée pour obtenir le résultat de son select dans ta table, parceque l'index a pris un peu de temps à se reconstruire...
 
Trop théorique, tout juste bon à un formateur certifié Oracle.

juste pour info : l'équivalent d'un "insert or update" existe depuis la 9i : il s'agit du "merge". Quand les outils existent, autant les utiliser...  
Sinon, je suis quand meme assez d'accord avec le formateur certifié alors !  
Trop d'index, dès que la table est grosse, c'est : une volumétrie à gérer de près et des pbs de perfs en TP ! On a un datawarehouse de 800 Go, et je te garantie qu'on droppe chaque nuit les index sur certaines tables mises à jour par batch avant de les recréer, sans quoi on quadruplerait les temps de traitement des batchs ! Le formateur a raison , il s'agit d'analyser finement chaque situation afin de créer les index les plus utiles sans tomber dans des dérives qu'on rencontre parfois (genre 10 index sur une seule table). En tous les cas, créer des index à tout va n'est certainement pas la solution...

Je maintiens que hormis les 3 cas spécifiques dans le monde, ta problématique ne se pose pour ainsi dire jamais, et n'est absolument pas à prendre comme une règle.
 
Par contre, les tables de 100 000 lignes sans index, "parcequ'on a des mouvements de stock tous les jours et faut pas indexer les tables souvent modifiées", ça on en trouve dans toutes les boîtes, à cause de ce genre de bouquins qui sont incapable de relativiser par des exemple concrets.
 
Une base de 800 Go, y'en a 2 par multi-nationnales. Des base de 1-10 Go, qui nécessitent pas les mêmes optimisations, y'en a des centaines dans n'importe quelle entreprise de taille moyenne. Chez GE, on avait une réplication d'une base Oracle de 2 Go toutes les nuits, via DBLink entre deux serveurs, faisant un trucate puis un insert de masse pour chaque table, et on n'a jamais eu de problèmes de perfs, alors que la base de destination était bourrée d'index (base dédiée au reporting). La machine n'était pourtant pas puissante du tout, un vieux Piii avec 512 Mo de mémoire et un seul disque dur. En une heure c'était terminé, aucun intérêt donc à shooter les index.
 
Sinon, pour le coup du "merge", connait pas, mais perso, je préfère un trigger : MySQL et Oracle sont les seuls SGBD à supporter en natif cette fonction de "insert or update" à ma connaissance, et ne sont pas foutus d'utiliser la même syntaxe. Dans une perspective de portabilité, utiliser un trigger me semble donc un choix évident.

En tout cas, merci pour ces informations !

Sinon, autre question, existe-t-il une methode 'insert or update' en sql pour qu'il soit verifier dans la base que l'entree n'existe pas deja, et qu'elle soit mise a jour seulement si elle existe, inseree sinon ?
 
Salut
La fonction existe à partir de Oracle 9i
c'est "MERGE INTO"

(question et réponse dans le même post sans édition, et au milieu d'un déterrage des familles... jamais vu ça encore )

T'as surtout des SGBD qui n'utilisent pas l'index quand la table fait moins d'1 page.

surtout oracle si tu te mets en mode CHOOSE et que tu as des statistiques à jour...
 
à celui qui a updaté ce post : mais quel était l'intérêt de déterrer un post aussi vieux ?

surtout pour se répondre direct sans même faire éditer (genre j'ai commencé à poster, trouvé la réponse avant de valider "oh et puis merde, je poste quand même" )

Ben non, c'est juste quelqu'un qui ne sait pas quoter  

ah ben oui.
 
et en plus la réponse avant déjà été donnée

Quelqu'un peut décrire le fonctionnement des index dans les moteurs SGBD ? Il s'agit d'un tri pour ranger les données et les retrouver rapidement ?
Pourquoi ça ralentit les insert/update ?

tu as les réponses à cette page : http://fr.wikipedia.org/wiki/Index [...] C3%A9es%29

Il sera utlisé que si l'index est dans le bonne ordre.
 
Après c'est USELESS de foutre des index partout hein... faut les mettres quand on a des soucis de performances pas avant. Car un index à un coup, mettre plein d'index = ajout/supression/modif ralenties...
 
Si c'est pour de l'OLTP c'est tout sauf recommandé de mettre des index sans justification.

L'intérêt de l'index ne dépends pas de la taille de la table, mais plus de la sélectivité de la requête. Moins c'est sélectif, moins l'index a d'intérêt.
A forcer un index (ou en créer un et avoir des stats qui font penser au SGBD que c'est profitable) ou peut se retrouver à lire des dizaines de fois le même bloque de donnée physique pour rien...

Sauf que ça se trouve les dev qui avait faire la procedure de replication étaient pas des boeufs et desactivait les index, truncate, insert, reactivation des index.
 
Et même sans ça, osef, c'est un traitement de nuit donc c'est pas un soucis. Mais si t'as un OLTP en prod tu ne fait que des index utilisent par rapport à ton application, et pas un index par colonne à vue de nez on ne sait pas pourquoi...