Discussion :

[ouadie99]

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.

[orafrance]

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

[ouadie99]

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?

[Vincent Rogier]

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

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

[agdid04]

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

[orafrance]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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

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

[13thFloor]

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

[ouadie99]

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

[ouadie99]

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

[Vincent Rogier]

g pa kmpri la ktion .....




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

[ouadie99]

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

[Vincent Rogier]

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

[ouadie99]

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 ?

[Vincent Rogier]

oui

[fatsora]

oui mais


Non dit Tom Kytes entre autre


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


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

[bouyao]

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.

[ouadie99]

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

[fatsora]

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

[orafrance]

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