[Tuning] Temps execution

Version imprimable

Bonjour,

Je suis débutant (mais alors vraiment débutant !), et j'ai "hérité" d'une BD et d'un site intranet déjà développés, mais à faire évoluer...
Je suis sous Oracle 8i, et l'une de mes requêtes met un temps assez exeptionnel à s'exécuter ( 1 min 30 s) ; et comme je dois l'utiliser à plusieurs reprises, j'atteins plus d'une heure d'attente...
Cette requête est utilisée de la même façon sur plusieures tables différentes, mais le temps de chargement varie selon la table changée. Je m'explique, voici le code :
Code:

1 2 3 4 5 SELECT numaff FROM donnees, communes, agents, delais WHERE to_char(communes.code_insee)=donnees.code_insee AND (donnees.ident=agents.initiales or donnees.ident=agents.code) AND delais.maj<=10 AND delais.numaff=donnees.numaff and to_char(donnees.datemaj)=2006
Ici, tout va très bien, seulement si je remplace la table 'donnees' par 'archives' (cette table est une table archivant les données de la table 'donnees', donc avec les mêmes colonnes) le temps de chargement explose.
J'ai rajouté numaff en clé primaire dans la table 'archives' et indexé cette table (ces 2 manip' avaient déjà été effectuées sur la table 'donnees') en pensant que ça permettrait de raccourcir le temps de chargement, mais ça n'a rien changé.
Comme ces 2 tables sont similaires et que mes connaissances sont plus que limitées, je sèche vraiment !

Si quelqu'un avait une idée sur le pourquoi du comment de cette bizarrerie...

03/08/2006, 16h18
Jaouad

Peux t'on avoir la volulmétrie pour chaques tables et surtout l'explain Plan
03/08/2006, 16h18
davy.g

Les fonctions (ici TO_CHAR) dans la clause WHERE, c'est pas terrible pour les performances il me semble !!!
03/08/2006, 16h21
Jaouad

Citation:

Envoyé par davy.g

Les fonctions (ici TO_CHAR) dans la clause WHERE, c'est pas terrible pour les performances il me semble !!!

Par forcément , si un index fonction ( voir la partie : Pourquoi un index n'est pas utilisé )
a été crée pour pallier à cela
03/08/2006, 16h23
davy.g
Peux tu donner une description de ta table ? :
Code:

1 2 DESC nom_table
La clause WHERE suivante semble bizarre non ? :
Code:

1 2 and to_char(donnees.datemaj)=2006
ca devrait être plutôt :
Code:

1 2 and to_char(donnees.datemaj)='2006'
non ?
03/08/2006, 16h25
Ne0zenith

Citation:

Envoyé par Jaouad

Peux t'on avoir la volulmétrie pour chaques tables

=> environ 800 données dans la première table et 1500 dans la table 'archives', le tout pour 46 colonnes...

Citation:

Envoyé par Jaouad

l'explain Plan

kesako ?!

Citation:

Envoyé par davy.g

Les fonctions (ici TO_CHAR) dans la clause WHERE, c'est pas terrible pour les performances il me semble !!!

Je sais, mais je ne crois pas avoir vraiment le choix... :?

tu ne dois pas passer par l'index :

sous Sql*Plus :

Code:

1
2
3
4
5
6
set autot trace exp stat 
set timing on 
WHERE to_char(communes.code_insee)=donnees.code_insee 
AND (donnees.ident=agents.initiales or donnees.ident=agents.code) 
AND delais.maj<=10 
AND delais.numaff=donnees.numaff and to_char(donnees.datemaj)=2006 ;

03/08/2006, 16h37
Arvulis

Jaouad a fait un bon tuto ici pour l'explain plan : http://oracle.developpez.com/guide/tuning/tkprof/
;)

Citation:

Envoyé par Jaouad

tu ne dois pas passer par l'index :

sous Sql*Plus :

Code:

1
2
3
4
5
6
set autot trace exp stat 
set timing on 
WHERE to_char(communes.code_insee)=donnees.code_insee 
AND (donnees.ident=agents.initiales or donnees.ident=agents.code) 
AND delais.maj<=10 
AND delais.numaff=donnees.numaff and to_char(donnees.datemaj)=2006 ;

Je ne peux pas passer sous sql plus : je l'exécute dans une page internet (.jsp) (rectifiez moi si je me trompe)
Voici les "codes" des tables :
donnees :

Code:

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
26
27
28
29
30
CREATE TABLE "COMMUN"."DONNEES"("CDCHAN" NUMBER NOT NULL, "NUMAFF" 
    VARCHAR2(6) NOT NULL, "ZONA4" NUMBER, "DEPCHA" VARCHAR2(10), 
    "CMMCHA" VARCHAR2(10), "ADRCHA" VARCHAR2(33), "LIBELCHA" 
    VARCHAR2(55), "LIBCHA" VARCHAR2(20), "AUTORIS" VARCHAR2(2), 
    "SRCHA" NUMBER, "RESPMCH" VARCHAR2(4), "DRSCHA" NUMBER, "NUMVS1" 
    NUMBER, "NUMVS2" NUMBER, "ZONA8" VARCHAR2(10), "ZONB8" VARCHAR2(
    10), "ZONA9" VARCHAR2(10), "ZONB9" VARCHAR2(10), "AGENTCHA" 
    VARCHAR2(4), "TYPAFG" VARCHAR2(10), "INDCA" VARCHAR2(2), "INDBR" 
    VARCHAR2(2), "INDSR" VARCHAR2(2), "INDHR" VARCHAR2(2), "JUSCHA1" 
    VARCHAR2(60), "JUSCHA2" VARCHAR2(60), "JUSCHA3" VARCHAR2(60), 
    "RETCHA1" VARCHAR2(70), "RETCHA2" VARCHAR2(70), "RETCHA3" 
    VARCHAR2(70), "ZONA10" VARCHAR2(10), "RESPAUT" VARCHAR2(4), 
    "ZCAL13A" VARCHAR2(20), "ZCAL13B" VARCHAR2(20), "ZCAL13C" 
    VARCHAR2(20), "SERVICE" VARCHAR2(2), "ALARCHA" VARCHAR2(2), 
    "COMPLOT" VARCHAR2(2), "ZCAL11A" VARCHAR2(20), "ZCAL11B" 
    VARCHAR2(20), "ZCAL11C" VARCHAR2(20), "ZCAL9D" VARCHAR2(20), 
    "ZCAL15A" VARCHAR2(20), "ZCAL15B" VARCHAR2(20), "ZCAL15C" 
    VARCHAR2(20), 
    CONSTRAINT "NUMCHAKEY" PRIMARY KEY("NUMCHA") USING 
    INDEX  
    TABLESPACE "COMMUN" 
    STORAGE ( INITIAL 40K NEXT 40K MINEXTENTS 1 MAXEXTENTS 505 
    PCTINCREASE 50 FREELISTS 1 FREELIST GROUPS 1) PCTFREE 10 
    INITRANS 2 MAXTRANS 255) 
    TABLESPACE "COMMUN" PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 
    255 
    STORAGE ( INITIAL 16K NEXT 960K MINEXTENTS 1 MAXEXTENTS 121 
    PCTINCREASE 50 FREELISTS 1 FREELIST GROUPS 1) 
    PARALLEL ( DEGREE DEFAULT ) 
    NOLOGGING

archives :

Code:

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
26
27
28
29
30
CREATE TABLE "COMMUN"."ARCHIVES"("CDCHAN" NUMBER NOT NULL, 
    "NUMAFF" VARCHAR2(6) NOT NULL, "ZONA4" NUMBER, "DEPCHA" VARCHAR2(
    10), "CMMCHA" VARCHAR2(10), "ADRCHA" VARCHAR2(33), "LIBELCHA" 
    VARCHAR2(55), "LIBCHA" VARCHAR2(20), "AUTORIS" VARCHAR2(2), 
    "SRCHA" NUMBER, "RESPMCH" VARCHAR2(4), "DRSCHA" NUMBER, "NUMVS1" 
    NUMBER, "NUMVS2" NUMBER, "ZONA8" VARCHAR2(10), "ZONB8" VARCHAR2(
    10), "ZONA9" VARCHAR2(10), "ZONB9" VARCHAR2(10), "AGENTCHA" 
    VARCHAR2(4), "TYPAFG" VARCHAR2(10), "INDCA" VARCHAR2(2), "INDBR" 
    VARCHAR2(2), "INDSR" VARCHAR2(2), "INDHR" VARCHAR2(2), "JUSCHA1" 
    VARCHAR2(60), "JUSCHA2" VARCHAR2(60), "JUSCHA3" VARCHAR2(60), 
    "RETCHA1" VARCHAR2(70), "RETCHA2" VARCHAR2(70), "RETCHA3" 
    VARCHAR2(70), "ZONA10" VARCHAR2(10), "RESPAUT" VARCHAR2(4), 
    "ZCAL13A" VARCHAR2(20), "ZCAL13B" VARCHAR2(20), "ZCAL13C" 
    VARCHAR2(20), "SERVICE" VARCHAR2(2), "ALARCHA" VARCHAR2(2), 
    "COMPLOT" VARCHAR2(2), "ZCAL11A" VARCHAR2(20), "ZCAL11B" 
    VARCHAR2(20), "ZCAL11C" VARCHAR2(20), "ZCAL9D" VARCHAR2(20), 
    "ZCAL15A" VARCHAR2(20), "ZCAL15B" VARCHAR2(20), "ZCAL15C" 
    VARCHAR2(20), "DATE_ARCHIVE" DATE NOT NULL, 
    CONSTRAINT "NUMCHAARCHKEY" PRIMARY KEY("NUMCHA") USING 
    INDEX  
    TABLESPACE "COMMUN" 
    STORAGE ( INITIAL 40K NEXT 64K MINEXTENTS 1 MAXEXTENTS 505 
    PCTINCREASE 50 FREELISTS 1 FREELIST GROUPS 1) PCTFREE 10 
    INITRANS 2 MAXTRANS 255) 
    TABLESPACE "COMMUN" PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 
    255 
    STORAGE ( INITIAL 16K NEXT 1440K MINEXTENTS 1 MAXEXTENTS 121 
    PCTINCREASE 50 FREELISTS 1 FREELIST GROUPS 1) 
    PARALLEL ( DEGREE DEFAULT ) 
    NOLOGGING

03/08/2006, 16h41
Jaouad

Dans ce cas là est ce que tu peux me donner les ordres de création de l'index

Citation:

Envoyé par Jaouad

Dans ce cas là est ce que tu peux me donner les ordres de création de l'index

Les voici :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
CREATE UNIQUE INDEX "COMMUN"."SYS_C001265" 
    ON "COMMUN"."DONNEES"("NUMAFF") 
    TABLESPACE "COMMUN" PCTFREE 10 INITRANS 2 MAXTRANS 255 
    STORAGE ( INITIAL 176K NEXT 136K MINEXTENTS 1 MAXEXTENTS 121 
    PCTINCREASE 50 FREELISTS 1) 
    LOGGING
 
CREATE UNIQUE INDEX "COMMUN"."NUMAFFARCHKEY" 
    ON "COMMUN"."ARCHIVES"("NUMAFF") 
    TABLESPACE "COMMUN" PCTFREE 10 INITRANS 2 MAXTRANS 255 
    STORAGE ( INITIAL 40K NEXT 64K MINEXTENTS 1 MAXEXTENTS 505 
    PCTINCREASE 50 FREELISTS 1) 
    LOGGING

désolé, je comprend pas tout ce que vous me demandez, j'ai vraiment l'impression d'être ignorant là...:oops:

03/08/2006, 16h51
Jaouad

il faut éviter de créer les objets avec des doubles quotes

Il nous faut absolument l'explain plan , est ce qu'il n'y a pas de DBA a coté de vous ou de sesion SQL

je viens de taper sous sql plus :

Code:

explain plan for select * from commun.donnees

et j'ai obtenu
"Explicité"

[edit]
J'ai créé la table plan_table (sans trop savoir comment : le fichier utlxplan.sql n'existe pas...), j'ai exécuté plustrce.sql, j'ai exécuté
SQL> explain plan for select * from commun.donnees ;
Explicité.

Voici le résumé des opérations...
Code:

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 26 27 28 29 30 31 32 33 34 35 SQL> Connecté. Explicité. drop role plustrace * ERREUR à la ligne 1 : ORA-01919: rôle 'PLUSTRACE' n'existe pas Rôle créé. grant select on v_$sesstat to plustrace * ERREUR à la ligne 1 : ORA-00942: Table ou vue inexistante grant select on v_$statname to plustrace * ERREUR à la ligne 1 : ORA-00942: Table ou vue inexistante grant select on v_$session to plustrace * ERREUR à la ligne 1 : ORA-00942: Table ou vue inexistante Autorisation de privilèges (GRANT) acceptée. Explicité. select plan_table_output from table(dbms_xplan.display('plan_table',null,'serial')) * ERREUR à la ligne 1 : ORA-22905: impossible d'accéder aux lignes d'un élément qui n'appartient pas à une table imbriquée
Les locaux du taf ferment, je repasserai demain... Merci de votre aide tout de même !

03/08/2006, 21h19
Ne0zenith

Dsl, je me suis trompé, c'est jour ferié demain, je repasserai lundi, si quelqu'un arrive à m'aider bien sur... Sinon tant pis, mon cas restera désespéré...
03/08/2006, 22h05
remi4444
800 ou 1500 lignes sont des nombres ridiculement petits pour une base oracle Le problème dois venir d'un mauvais plan d'exécution sur les jointures entre les différentes tables.

- Il faudrait que tu fasses un état des lieux de toutes tes tables en présences à savoir pour les 4 tables le nombre de lignes, et les index créés.

- A mon avis , ce n'est pas la clause "to_char(donnees.datemaj)=2006" qui pose problème mais la jointure " to_char(communes.code_insee)=donnees.code_insee" en fonction du nombre de ligne dans la table "communes" ce to_char est-il indispensable ? ne peut-il pas etre remplacer par une égalité simple ?

- Enfin tu dois aussi passer les stats sur ton schéma (indispensables pour que l'optimiseur oracle fasse bien son travail d'optimisation...):

Par exemple par la commande:
Code:

1 2 3 4 5 BEGIN SYS.DBMS_UTILITY.ANALYZE_SCHEMA('COMUN','COMPUTE'); END; /
Normalement ça devrait aller beaucoup mieux apres...
04/08/2006, 13h01
McM

C'est marrant ça :

Citation:

SELECT numaff
FROM donnees, communes, agents, delais
WHERE TO_CHAR(communes.code_insee)=donnees.code_insee
AND (donnees.ident=agents.initiales OR donnees.ident=agents.code)
AND delais.maj<=10
AND delais.numaff=donnees.numaff
AND TO_CHAR(donnees.datemaj)=2006

Dans les desc de tes tables donnees et archive :
code_insee n'existe pas
ident n'existe pas
datemaj n'existe pas
04/08/2006, 13h32
Ne0zenith

Euh...:oops:
En réalité, j'ai modifié les noms des champs que je vous ai donné, pour 2 raisons :
- Close de confidentialité oblige (ils sont très à cheval là dessus, et je crois qu'ils n'apprécieraient pas de retrouver ça sur internet :aie: )
- Simplification de la requête que tu as quoté, en réalité le code insee de la table donnees est séparé en 2 champs : DEPCHA et CMMCHA. il suffit de "coller" ces 2 champs pour obtenir le champ "code insee". le champ ident est en fait numcha et l'expression "to_char(donnees.datemaj)" correspond en fait au champ "ZONA4".

Mea culpa, dsl si ça pose un problème...
Concernant les solutions que vous me proposez, je les testerai lundi prochain, et je vous donnerai les résultats !
04/08/2006, 17h23
remi4444

8O
Ben... déja qu'un tout petit detail peut changer entierement le plan d'execution d'une requête, si tu la modifie avant de nous la soumettre... c'est un peu comme si tu nous demandais de t'aider à chercher une aiguille dans une botte de foin pour nous dire apres coup qu'en fait tu avais perdu l'aiguille dans le champs de maïs d'à coté....c'est pas gagné quoi ;)
04/08/2006, 18h36
Ne0zenith

arf c'est vrai...
Bon je vous remets tous les bons champs non modifiés lundi, je pensais pouvoir m'en sortir en modifiant quelques trucs, mais ça devient vraiment trop compliqué, pour moi comme pour vous !

Bon voici les vraies données de mes tables :
La table que je vous ai présenté comme table "donnees" se nomme en réalité commun.gdtc1 et la table archive "commun.gdtc1archive".
La requête qui "bugge" avec la table "gdtc1archive" mais pas "gdtc1" se présente ainsi (il suffit de remplacer "gdtc1" par "gdtc1archive") :

Code:

1
2
3
4
5
6
select gdtc1.numcha  from commun.gdtc1, egs.agents, carto.communes,carto.moyenne_echelle 
where to_char(communes.code_insee)= gdtc1.depcha||gdtc1.cmmcha 
and (egs.agents.INITIALES=gdtc1.agentcha or egs.agents.KND=gdtc1.agentcha) 
and (moyenne_echelle.date_maj_gdo - moyenne_echelle.date_ameo)<=93 
and (moyenne_echelle.date_maj_gdo - moyenne_echelle.date_ameo)>=0 
and moyenne_echelle.num_ident=gdtc1.numcha and to_char(date_maj_gdo,'YYYY')='2006'

Voici les desc de mes tables :

Code:

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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
CREATE TABLE "COMMUN"."GDTC1"("CDCHAN" NUMBER NOT NULL, "NUMCHA" 
    VARCHAR2(6) NOT NULL, "ZONA4" NUMBER, "DEPCHA" VARCHAR2(10), 
    "CMMCHA" VARCHAR2(10), "ADRCHA" VARCHAR2(33), "LIBELCHA" 
    VARCHAR2(55), "LIBCHA" VARCHAR2(20), "AUTORIS" VARCHAR2(2), 
    "SRCHA" NUMBER, "RESPMCH" VARCHAR2(4), "DRSCHA" NUMBER, "NUMVS1" 
    NUMBER, "NUMVS2" NUMBER, "ZONA8" VARCHAR2(10), "ZONB8" VARCHAR2(
    10), "ZONA9" VARCHAR2(10), "ZONB9" VARCHAR2(10), "AGENTCHA" 
    VARCHAR2(4), "TYPAFG" VARCHAR2(10), "INDCA" VARCHAR2(2), "INDBR" 
    VARCHAR2(2), "INDSR" VARCHAR2(2), "INDHR" VARCHAR2(2), "JUSCHA1" 
    VARCHAR2(60), "JUSCHA2" VARCHAR2(60), "JUSCHA3" VARCHAR2(60), 
    "RETCHA1" VARCHAR2(70), "RETCHA2" VARCHAR2(70), "RETCHA3" 
    VARCHAR2(70), "ZONA10" VARCHAR2(10), "RESPAUT" VARCHAR2(4), 
    "ZCAL13A" VARCHAR2(20), "ZCAL13B" VARCHAR2(20), "ZCAL13C" 
    VARCHAR2(20), "SERVICE" VARCHAR2(2), "ALARCHA" VARCHAR2(2), 
    "COMPLOT" VARCHAR2(2), "ZCAL11A" VARCHAR2(20), "ZCAL11B" 
    VARCHAR2(20), "ZCAL11C" VARCHAR2(20), "ZCAL9D" VARCHAR2(20), 
    "ZCAL15A" VARCHAR2(20), "ZCAL15B" VARCHAR2(20), "ZCAL15C" 
    VARCHAR2(20), 
    CONSTRAINT "NUMCHAKEY" PRIMARY KEY("NUMCHA") USING 
    INDEX  
    TABLESPACE "COMMUN" 
    STORAGE ( INITIAL 40K NEXT 40K MINEXTENTS 1 MAXEXTENTS 505 
    PCTINCREASE 50 FREELISTS 1 FREELIST GROUPS 1) PCTFREE 10 
    INITRANS 2 MAXTRANS 255) 
    TABLESPACE "COMMUN" PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 
    255 
    STORAGE ( INITIAL 16K NEXT 960K MINEXTENTS 1 MAXEXTENTS 121 
    PCTINCREASE 50 FREELISTS 1 FREELIST GROUPS 1) 
    PARALLEL ( DEGREE DEFAULT ) 
    NOLOGGING 
 
CREATE TABLE "COMMUN"."GDTC1ARCHIVE"("CDCHAN" NUMBER NOT NULL, 
    "NUMCHA" VARCHAR2(6) NOT NULL, "ZONA4" NUMBER, "DEPCHA" VARCHAR2(
    10), "CMMCHA" VARCHAR2(10), "ADRCHA" VARCHAR2(33), "LIBELCHA" 
    VARCHAR2(55), "LIBCHA" VARCHAR2(20), "AUTORIS" VARCHAR2(2), 
    "SRCHA" NUMBER, "RESPMCH" VARCHAR2(4), "DRSCHA" NUMBER, "NUMVS1" 
    NUMBER, "NUMVS2" NUMBER, "ZONA8" VARCHAR2(10), "ZONB8" VARCHAR2(
    10), "ZONA9" VARCHAR2(10), "ZONB9" VARCHAR2(10), "AGENTCHA" 
    VARCHAR2(4), "TYPAFG" VARCHAR2(10), "INDCA" VARCHAR2(2), "INDBR" 
    VARCHAR2(2), "INDSR" VARCHAR2(2), "INDHR" VARCHAR2(2), "JUSCHA1" 
    VARCHAR2(60), "JUSCHA2" VARCHAR2(60), "JUSCHA3" VARCHAR2(60), 
    "RETCHA1" VARCHAR2(70), "RETCHA2" VARCHAR2(70), "RETCHA3" 
    VARCHAR2(70), "ZONA10" VARCHAR2(10), "RESPAUT" VARCHAR2(4), 
    "ZCAL13A" VARCHAR2(20), "ZCAL13B" VARCHAR2(20), "ZCAL13C" 
    VARCHAR2(20), "SERVICE" VARCHAR2(2), "ALARCHA" VARCHAR2(2), 
    "COMPLOT" VARCHAR2(2), "ZCAL11A" VARCHAR2(20), "ZCAL11B" 
    VARCHAR2(20), "ZCAL11C" VARCHAR2(20), "ZCAL9D" VARCHAR2(20), 
    "ZCAL15A" VARCHAR2(20), "ZCAL15B" VARCHAR2(20), "ZCAL15C" 
    VARCHAR2(20), "DATE_ARCHIVE" DATE NOT NULL, 
    CONSTRAINT "NUMCHAARCHKEY" PRIMARY KEY("NUMCHA") USING 
    INDEX  
    TABLESPACE "COMMUN" 
    STORAGE ( INITIAL 40K NEXT 64K MINEXTENTS 1 MAXEXTENTS 505 
    PCTINCREASE 50 FREELISTS 1 FREELIST GROUPS 1) PCTFREE 10 
    INITRANS 2 MAXTRANS 255) 
    TABLESPACE "COMMUN" PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 
    255 
    STORAGE ( INITIAL 16K NEXT 1440K MINEXTENTS 1 MAXEXTENTS 121 
    PCTINCREASE 50 FREELISTS 1 FREELIST GROUPS 1) 
    PARALLEL ( DEGREE DEFAULT ) 
    NOLOGGING

Et voici pour les clés primaires (leur ajout n'a pas modifié le temps de réponse) :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
CREATE UNIQUE INDEX "COMMUN"."SYS_C001265" 
    ON "COMMUN"."GDTA1"("NUMAFF") 
    TABLESPACE "COMMUN" PCTFREE 10 INITRANS 2 MAXTRANS 255 
    STORAGE ( INITIAL 176K NEXT 136K MINEXTENTS 1 MAXEXTENTS 121 
    PCTINCREASE 50 FREELISTS 1) 
    LOGGING
 
CREATE UNIQUE INDEX "COMMUN"."NUMCHAARCHKEY" 
    ON "COMMUN"."GDTC1ARCHIVE"("NUMCHA") 
    TABLESPACE "COMMUN" PCTFREE 10 INITRANS 2 MAXTRANS 255 
    STORAGE ( INITIAL 40K NEXT 64K MINEXTENTS 1 MAXEXTENTS 505 
    PCTINCREASE 50 FREELISTS 1) 
    LOGGING

Mon problème est donc que pour la même requête (présentée plus haut), l'exécution est tout à fait correcte avec la table "gdtc1" (850 données), mais vraiment très lente avec la table "gdtc1archive" (environ 1550 données).
Ces 2 tables étant similaires en tous points (enfin je le crois), le temps d'exécution devrait être le même ??!! (+ d'1mn30 pour la table d'archives contre 2 sec pour la 1ère...)

07/08/2006, 09h15
Ne0zenith

Citation:

Envoyé par remi4444

BEGIN
SYS.DBMS_UTILITY.ANALYZE_SCHEMA('COMUN','COMPUTE');
END;

Remi4444, à quoi sert cette commande ? Est ce que l'exécution prend du temps ?
07/08/2006, 11h12
remi4444

Je ne suis pas un habitué de longue date mais je pense que les problèmes d'analyse et de plan d'exécution ont été maintes fois abordés sur le site mais je vais résumer.

Lorsque tu fais une demande à oracle, tu as pu constater que tu n'as pas eu besoin de concevoir un algorithme.

Imagine que tu doives faire un programme (en n'importe quel language tel que C, java, VB ....) pour récupérer des données situées dans 4 ou 5 fichier différents croisements entre les données. Tu peux programmer tes boucles de 36 manières différentes pour que arriver à tes fins, seulement lorsque les fichiers sont trés gros, selon l'algorithme que tu va choisir, tu va avoir de très grandes disparités dans les performances. Si tu veux optimiser ton algorithme, tu va avoir besoin de connaître en gros la répartition de tes données (quels sont les gros fichiers, quels sont les petit, tel fichier à une donnée qui se répète pour la moitié des lignes etc...). Une fois que tu connais ça, tu va pouvoir adapter ton algorithme par exemple en évitant de faire un parcours complet d'un gros fichier en creu de boucle...

Eh bien, une base de donnée fait tout ce travail pour toi, elle fabrique l'algorithme à ta place, alors que toi tu lui a posé une simple question (requête). Cet algorithme fabriqué automatiquement s'appelle le "PLAN D'EXECUTION". Et donc de la même manière que n'importe qu’un programmeur à besoin de savoir ou il met les pieds, si on veux que l'algorithme ne sois pas fait au hasard, il faut que la base ait un maximum d’information sur les données. C’est ce qui s’appelle « L’ANALYSE » de la base. Cette ne dois pas se faire à chaque requête évidement, elle dois se faire régulièrement selon l’évolution de la base. (Ex : 1 fois par semaine + à chaque gros chamboulement dans les données…)
07/08/2006, 11h38
Ne0zenith

Rapport à l'une de tes questions précédentes, la table "communes" comporte 300 données (communes d'Ille et Vilaine), ce qui n'est pas très important non plus... Mais je ne peux pas supprimer le "to_char(code_insee)", car les champs "dep" et "cmm" correspondant dans la table "gdtc1" sont des caractères et pas des nombres comme dans "communes"...

Donc si je comprend bien, l'exécution de la commande que tu m'as fourni va calculer les stats, et donc établir un plan d'exécution ?!
07/08/2006, 11h56
remi4444

oui ça devrait l'aider à en établir un le plus efficace possible en effet...

Sinon il faudrait au moins que tu saches le nombre de lignes (grosso modo) de chacune de tes tables pour envisager de comprendre ce qui peut se passer, parceque des ordre de grandeur de 1000, c'est vraiment que-dale....
07/08/2006, 13h09
Ne0zenith
ça marche, ça marche ça maaaaaarche !!!!!!!!!!!!!!!!
J'ai bien exécuté ta commande
Code:

1 2 3 BEGIN SYS.DBMS_UTILITY.ANALYZE_SCHEMA('COMUN','COMPUTE'); END;
et ça marche nickel !
Je vais l'appliquer à tous les autres schémas, histoire d'améliorer un peu tout ça, mais ça marche !!!!
youpi, je suis trop content, merci merci merci, et encore merci !

J'ai juste une autre question : c'est quoi un schéma ?! :? :oops:
07/08/2006, 14h22
remi4444

normal que ça marche puisque tu n'as que peu de données, si ça ramait tant c'est peut etre que les analyses avaient été passées il y a longtemps au moment ou certaines tables était vides, ce qui devait induire gravement l'optimiseur en erreur....

Un schéma est un groupement de tables, et sous oracle un user est d'autorité attaché à un schéma qui porte exactement le meme nom que lui. Ce qui fait qu'on fait l'équivalence USER=SCHEMA et vice versa... ;)
07/08/2006, 14h30
Ne0zenith

Merci beaucoup pour tes explications et ta patience, tu m'as permis d'enlever une sacré épine !
En effet, je crois que la seule fois où une analyse a été passée sur ces tables date de 2003, c'est à dire de la création de la base... Pas facile de récupérer tout ça ! (ça ne fais que 3 mois que je travaille dessus, et encore...)

Eh bien, je crois que je peux rajouter le tag "résolu" !

Merci encore !