Discussion :

[remi4444]

Certes remi, mais est-ce qu'au niveau architecture il y a des préférences pour une table complètement couverte par un index ? Je veux dire, ça reste une table hein ? Il n'y a pas d'option particulière à lui préciser ? (à part l'index forcément)

Si une table est compltement couverte par un index (ou presque completement) à ce moment là on spécifie la clause "ORGANIZATION INDEX" ça veux dire qu'il y a plus qu'une construction de clef primaire et que le reste des données suivent.

[nuke_y]

Ok, merci.

J'ai bien fait de demander

[remi4444]

Merci pour vos précisions.

Effectivement, j'ai une tres grosse table 20 colonnes, j'y peu rien, y'a pas eu de modélisation de la BD quand je suis arrivé ca existé déjà comme ca.
Si je fais une table index, c'est a dire couvrant toutes les colonnes, je suppose que les performances seront réduites d'un autre coté, lesquel, insert? update ?

Merci

Attention, dans le cas d'une table à 20 colonnes, il nr faut surtout pas faire un index qui couvre toutes les colonnes, juste les 2/3 colonnes concernées par le comptage.

C'est sur que plus il y a d'index plus les insertions seront lentes et plus les update des colonnes concernées par les index seront lent aussi... tout est une question d'équilibre...

Par exemple, si j'ai un index sur table1(col1,col2,col3,col4)
et un autre sur table1(col1,col3)

Ces 2 indexs ne sont pas à redondants au sens strict du terme mais le 2ieme n'est pas forcément très utile, tout dépend du taux de "discrimination" de ta colonne col1. Si pour une valeur donnée de col1, tu ne ramènes pas plus qu'une vingtaine de lignes, alors le fait de rajouter le 2ieme index ne t'amènera pas grand chose, par contre si une valeur de col1 donnée te ramène 10000 lignes alors là oui le 2ieme sera utile (mais à ce moment là c'est pas très judicieux de commencer l'index par une colonne aussi peu discriminante...)

avec
index table1(col1,col2),

si je rajoute un index sur table1 tel que :
table1(col1)

Par contre là, le 2ieme est complètement redondant avec le 1ier! pour savoir pourquoi il y a dégradation des perfs, il faudrait voir le plan d'exécution, il est possible qu'oracle choisisse de passer par le premier index puis de revenir dans le bloc de donnée pour faire la liaison avec la 2ieme colonne.

D'autre part ta requête n'est pas terrible je trouve, il vaut mieux que tu fasse celle que t'a donnée plaineR avec les EXISTS. EXISTS, c'est l'instruction de filtrage, or ce que tu veux faire, c'est du filtrage... CQFD.

y' a t il une requete qui permet de supprimer TOUS les index d'UNE table donnée?

Je ne crois pas, par contre tu as la vue USER_INDEXES qui te permetra d'avoir la liste de tous les index d'une table donnée.

[nuke_y]

J'utilise ça pour vider un schéma entier (ici nommé MON_USER). Tu peux l'adapter en remplacant la requête sur ALL_OBJECTS par la vue USER_INDEXES donnée plus haut par remi.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
Declare
   CURSOR C_OBJ_NAME_TAB IS select OBJECT_NAME from ALL_OBJECTS where OWNER='MON_USER' and OBJECT_TYPE='TABLE';
   CURSOR C_OBJ_NAME_IDX IS select OBJECT_NAME from ALL_OBJECTS where OWNER='MON_USER' and OBJECT_TYPE='INDEX';
   CURSOR C_OBJ_NAME_PRO IS select OBJECT_NAME from ALL_OBJECTS where OWNER='MON_USER' and OBJECT_TYPE='PROCEDURE';
   CURSOR C_OBJ_NAME_VIE IS select OBJECT_NAME from ALL_OBJECTS where OWNER='MON_USER' and OBJECT_TYPE='VIEW';   
Begin
 
   For Cur In C_OBJ_NAME_VIE Loop
   EXECUTE IMMEDIATE 'DROP VIEW '||'"MON_USER"'||'.'||'"'||Cur.OBJECT_NAME||'"';
   End Loop;
 
   For Cur In C_OBJ_NAME_PRO Loop
   EXECUTE IMMEDIATE 'DROP PROCEDURE '||'"MON_USER"'||'.'||'"'||Cur.OBJECT_NAME||'"';
   End Loop;
 
   For Cur In C_OBJ_NAME_TAB Loop
   EXECUTE IMMEDIATE 'DROP TABLE '||'"MON_USER"'||'.'||'"'||Cur.OBJECT_NAME||'"'||' CASCADE CONSTRAINTS';
   End Loop;
 
   For Cur In C_OBJ_NAME_IDX Loop
   EXECUTE IMMEDIATE 'DROP INDEX '||'"MON_USER"'||'.'||'"'||Cur.OBJECT_NAME||'"';
   End Loop;
 
End;
/

[remi4444]

nuke_y:
tu sais que quand tu as supprimé tes tables, ce n'est plus la peine de supprimer tes index, vu qu'ils ont été jetés avec...

Si tu traçais ta dernière boucle je pense que tu constaterais que ton dernier curseur est toujours vide....

[crazykangourou]

Bonsoir et encore merci à vous d'avoir bien voulut suivre cette discussion avec moi.

Dernière question et je [resoud] le sujet si vous voulez bien sur...

Remi4444 tu disais que
si j'ajoute un index tel que
table1(col1)
alors qu'il existe deja un index
table1(col1,col2)

Le premier table1(col1) est, je te cite "complètement redondant".
Est ce que au niveau des perfs c'est la même chose? bien sur si on interroge que sur la col1? Je pense quand même que c'est l'index table1(col1) qui aura de meilleurs résultats.

J'aimerai bien utiliser la requete la plus pure de plaineR, mais mon parseur perd la boule pour des requetes compliquées et ne reconnait pas les mots clefs exists, il faudrait que je l'améliore.
N'oublie pas, il injecte, compte, fais le café, mais faut pas trop lui en demander

Nuke_y, merci pour ton code de suppression, il va m'être fort utile

Voilà.
Disez moi quand je peux clore la discussion et à bientot

[nuke_y]

Tu as sûrement raison remi, mais est-ce qu'il ne peut pas exister des index dans un schema qui portent sur des tables d'un autre schema ? Et dans ce cas, les tables de l'AUTRE schema n'ayant pas été supprimées, les index ne le sont pas non plus. Et si je ré-importe mon utilisateur complet, crash (ou pas d'ailleurs, mais c'est juste pour être sur).

Il me semble que j'ai ce cas d'index et de tables qui n'appartiennent pas au même schéma, et que j'ai fait ça pour ça.

[remi4444]

mais est-ce qu'il ne peut pas exister des index dans un schema qui portent sur des tables d'un autre schema ?

j'ai déja vu beaucoup de trucs tordus, mais là j'avoue que je m'étais jamais encore posé la question! ça se teste......

[remi4444]

bien sur si on interroge que sur la col1? Je pense quand même que c'est l'index table1(col1) qui aura de meilleurs résultats.

Dans l'absolu tu as raison, mais il faut voir le "gain" obtenu, ça va être très faible... le seul cas ou le gain serait un peu significatif, c'est si tu faisais un gros select de col1 et que col2 soit une colonne très large... dans ce cas limite, ton index (col1) serait beaucoup plus petit que le (col1,col2) et son parcours complet se ferait en ramenant moins de blocs... dans tous les cas, ça se teste... par contre, ce qui est sur c'est que ça pénélisera les insertions...

J'aimerai bien utiliser la requete la plus pure de plaineR, mais mon parseur perd la boule pour des requetes compliquées et ne reconnait pas les mots clefs exists, il faudrait que je l'améliore.

D'expérience, c'est beaucoup plus facile à programmer un requêteur avec des EXISTS car tu ajoute des blocs sql de filtrage qui portent en eux meme la bonne jointure et tu n'as pas de risques de doublons... c'est dommage que si peu de concepteurs y pensent...

N'oublie pas, il injecte, compte, fais le café, mais faut pas trop lui en demander

petit aparté philosophique... (ne le prends par contre toi, c'est général)

Comme je te l'avais dit, à un moment c'est la quadrature du cercle, tu ne peux pas espérer avoir un comptage instantané de 20000 trucs dans 80000 machins, la base va forcément parcourir les 80000 machins... rajouter à ça un parseur générique sur lequel tu n'as pas la main et tu atteint les limites du possible... le problème est que les bases et les machines étant puissantes, on se permet de concevoir des programmes ou l'on parcours allègrement les grosse tables, ou l'on compte et on re-compte toujours les mêmes choses sans se creuser la tete à prévoir des compteurs de suivi dans l'applicatif lui même. Il y a quelques années, avec des machines moins puissantes, personne n'aurait imaginer sérieusement programmer ce genre de comptage répétitif en interactif. En fait, le gain de puissance est capté par les informaticiens qui économisent du temps de programmation, par contre pour les utilisateurs ça rame toujours autant voir plus!

[crazykangourou]

Remi4444, message bien recu!!!

Pour vous tenir au courant des évolutions : j'ai fait un index couvrant et supprimé des index sur 1 seule colonne (col1) et bien, je passe de 8 sec pour la requete incriminé à .....
0,01 sec !!!!!!

Merci à vous vous avez été de très bons conseils.
Je pense qu'on aura l'occasion de discuter à nouveau ensembe.