Question sur l'utlisation des index sous oracle?

Bonjour,

on sait déja que les index permet d'effectuer plus rapidement des recherches.
donc ici pour les requetes de type select

mais si des requetes d'insertion, modification et suppression est ce que c la meme chose?

par exemple j'ai une table qui contient un champ nom comme colonne j'ai crée un index pour ce champ dans la requete de seletion c'est bien parfait

mais lorsque j'ai effectué une requete de suppression est ce que index sera supprimé également ou bien il y a autre action pour l'update et insert ?

si vous avez des réponses n'hésitez pas de m'aider.

Imagine toi le Quid. Quelques milliers de pages et donc un index pour s'y retrouver. Pour trouver un article c'est très efficace puisqu'il suffit de parcourir 10 pages d'index rangé par ordre alphabétique plutôt que des milliers de pages sans ordre particulier. Par contre, si un article est ajouté, supprimé ou déplacé, non seulement il y a la modification de l'article à faire mais aussi l'index à mettre à jour pour changer le numéro de page ou de colonne dans la page.

Pour Oracle c'est pareil :mrgreen:

d'abord merci ,mais j'ai lu une documentation en anglais sur les indexes sur oracle
dans la rubrique les avantages et les inconvénients il décrit que parmi les inconvénients
Ne pas créer un index lorsque The table is updated frequently est ce que tu me confirme dans ce sens?

Citation:

---

Envoyé par ouadie99

Ne pas créer un index lorsque The table is updated frequently

---

C'est un conseil stupide ! Cela dépend bien sur du contexte... Mais un index a pour but d'optimiser les recherches.

Donc si la table est mise à jour fréquemment mais aussi consultée fréquemment avec des critères, un index s'imposera si elle gagne en volume.. De plus cela dépend aussi de la nature des données et leur répartition....

Que préfères-tu ?
perdre un chouia de seconde lors d'une mise à jour mais booster les lectures
ou accélérer les mises à jour mais ne pas booster les lectures et se taper des full table scan ?
Dans beaucoup d'ERP, il arrive de voir des tables avec 5, 10 voire plus de 15 index.

Citation:

---

Envoyé par 13thFloor

Que préfères-tu ?
perdre un chouia de seconde lors d'une mise à jour mais booster les lectures
ou accélérer les mises à jour mais ne pas booster les lectures et se taper des full table scan ?
Dans beaucoup d'ERP, il arrive de voir des tables avec 5, 10 voire plus de 15 index.

---

Bonsoir,
En cas de chargemnts massifs: drop index, chargement puis create index ...
Crdlt,
SDR

Citation:

---

Envoyé par ouadie99

Ne pas créer un index lorsque The table is updated frequently est ce que tu me confirme dans ce sens?

---

comme je l'ai dis, un update met l'index à jour, c'est donc couteux. Ceci étant dit, l'index peut servir aussi à accélérer l'exécution de l'update, exemple :

Code:

---

1 2 3

UPDATE tab col = 'toto' WHERE col = 'titi'

---

S'il y a un index sur col, tu as des chances que l'aide qu'il apporte pour trouver la ligne compense la perte de temps lors de la mise à jour de l'index... et on peut en plus espérer que tu sélectionnes plus souvent que tu updates ;)

Donc je ne confirme pas :mouarf:

PS : t'as un lien sur la source qui dit ça ?

Citation:

---

Envoyé par agdid04

Bonsoir,
En cas de chargemnts massifs: drop index, chargement puis create index ...
Crdlt,
SDR

---

Perso, je préfère l'alter index unusable (avec skip_unusable_indexes à true) suivi d'un rebuild => pas de risque de perdre le ddl

merci bcp donc selon les réponses les index optimise la racherche et garde la performance??

Citation:

---

Envoyé par vicenzo

C'est un conseil stupide ! Cela dépend bien sur du contexte... Mais un index a pour but d'optimiser les recherches.

Donc si la table est mise à jour fréquemment mais aussi consultée fréquemment avec des critères, un index s'imposera si elle gagne en volume.. De plus cela dépend aussi de la nature des données et leur répartition....

---

Merci monsieur vicenzo pour la réponse cité au dessus mais ici lorsque j'ai une requete de select et update et delete ce ne pose pas probléme au niveau des indexe car on utilise la clause where.

mais on sait déja que la requete de type insert n'utilise pas la clause where
donc est ce que c la meme chose c à d optimal ou bien ca pose un probléme :cry:

g pa kmpri la ktion .....

:nosms:


Traduction : Je n'ai pas compris ton dernier post...

est ce que l'utilisation des index influence les requetes de type insert ??

oui, un insert sur une table indexée prends plus de temps puisque l'index doit être mis à jour.

Maintenant ce "surcout" en terme de temps est souvent transparent ou négligeable.

Mais même si cela ralentissait des inserts sur une grosse table de plusieurs dizaine de millions de lignes, le gain sur la sélection ou la mise à jour utilisant des critères peut être d'un facteur impressionnant...

Merci bcp Monsieur Vienzo bcp et désolé pour le dérangement
mais svp j'ai une autre question ou bien recommandation?

est ce que c'est recommandé de créer des indexes dans un tablespace tablespace à part des données ?

oui

oui mais


Non dit Tom Kytes entre autre


http://wordpress.com/tag/oracle-myths/


http://asktom.oracle.com/pls/asktom/...:1463404632043

Mais notre Tom oublie que lorsque un utilisateur accede à un index, un autre utilisateur peut accéder au data.
De plus avoir un index dans un tablespace avec un grand extent c'est plus performant de mélanger les datas et les indexes.

j'espere plus de justifications c quoi la raison principale de placer les index dans un tablespace autre tablespace de données ???

Bref Il faut tester ,tester ....


entre
rebuilder un index sur le meme tablespace

et
rebuilder
sur un autre que les datas

car rebuilder sur un autre tout court .... n'est pas suffisant

surtout quand tu perds un datafile, tu as une chance sur deux pour que ce soit les indexes uniquement qui sont perdus alors que si tu mélanges data et index, en cas de perte de datafile t'as plus qu'à jeter ta base :?

En plus c'est une recommandation d'Oracle :mrgreen: