Rebuild après create unique index

[Jeanpierre080]

Bonjour,

Je rencontre un problème de "performance" après construction d'un index.

Nous importons quotidiennement des tables de tarifs automobile via le script suivant :

Code :

1
2
3
4
5
6
7
8
9
10
DROP TABLE EUROTAX_ADDITION;
ALTER TABLE EUROTAX_ADDITION_TEMP RENAME TO EUROTAX_ADDITION;
CREATE INDEX EUROTAX_ADDITION_ADDVAL ON EUROTAX_ADDITION ("ADDVAL") ;
CREATE INDEX EUROTAX_ADDITION_ADDVALUNTIL ON EUROTAX_ADDITION ("ADDVALUNTIL") ;
CREATE INDEX EUROTAX_ADDITION_MARKET ON EUROTAX_ADDITION ("ADDMARKET");
CREATE INDEX EUROTAX_ADDITION_VEHTYPE ON EUROTAX_ADDITION ("ADDVEHTYPE") ;
CREATE INDEX EUROTAX_ADDITION_NATCODE ON EUROTAX_ADDITION ("ADDNATCODE") ;
CREATE INDEX EUROTAX_ADDITION_ADDFLAG ON EUROTAX_ADDITION ("ADDFLAG");
CREATE INDEX EUROTAX_ADDITION_ADDEQCODE ON EUROTAX_ADDITION ("ADDEQCODE");
CREATE UNIQUE INDEX EUROTAX_ADDITION_PK ON EUROTAX_ADDITION ("ADDMARKET", "ADDVEHTYPE", "ADDNATCODE", "ADDEQCODE", "ADDVAL") ;

Le problème se situe au niveau du dernier index créé :
INDEX EUROTAX_ADDITION_PK
Lorsque nous requetons sur la table via les clés indexées, le temps de réponse est de 10 secondes
Si dans le manager oracle, je fais un rebuild de cet index, le temps de réponse tombe à 2 secondes pour le même jeu de clés

Pourquoi suis-je obligé de faire un rebuild alors que l'index est recréé ?

Pour infos
(La table contient 7,5 Millions de lignes)
Le select count(*) prend 15 sec
Cela me parait également long

Cordialement

[Waldar]

Essayez plutôt de rafraîchir les statistiques :

Code :

1
2
3
4
5
6
7
DBMS_STATS.GATHER_TABLE_STATS
(
    OWNNAME          => 'votre_owner' ,
    TABNAME          => 'EUROTAX_ADDITION',
    ESTIMATE_PERCENT => DBMS_STATS.AUTO_SAMPLE_SIZE,
    CASCADE          => TRUE
);

[Jeanpierre080]

Merci de votre réponse Fabien,

Etant donné que le simple fait de lancer le rebuild de cet index via le manager divise le tps de réponse par 4 ou 5, dois je comprendre que la commande rebuild du manager execute également un recalcul des stats ?

[Waldar]

Il faut voir ce qui se passe dans la requête avant et après la reconstruction avec plan d'exécution et trace Oracle pour voir ce qui influe réellement sur les performances.

Sans ces outils, on ne peut qu'émettre des hypothèses.

[pachot]

Bonjour,
CREATE INDEX calcule les stats depuis la 10g.
Mais ton résultat peut dépendre: de la version, du partitionnement de la table, des options ti gather_stats que tu lqnce pqr la suite.
Cordialement,
Franck.

[Ahmed AANGOUR]

Bonjour,

Pouvez-vous effectuer le test suivant et nous renvoyer le résultat:

Sous SQLPLUS:
1) Recréer votre table et les index
2) Activer la collecte des stats d'execution avec la commande suivante:

Code :

1
2
 
ALTER session SET statistics_level=ALL;

3) Exécutez votre requête

4) Affichez le plan avec les stats d'exécution:

Code :

1
2
3
4
 
SET LINES 300
SET PAGES 500
SELECT * FROM TABLE(dbms_xplan.display_cursor(NULL,NULL, 'allstats last'));

5) Rebuild de votre index

6) Exécutez votre requête

7) Affichez le plan avec les stats d'exécution:

Code :

1
2
3
4
 
SET LINES 300
SET PAGES 500
SELECT * FROM TABLE(dbms_xplan.display_cursor(NULL,NULL, 'allstats last'));

A noter que pour pouvoir utiliser la fonction DISPLAY_CURSOR du package DBMS_XPLAN le USER que vous utilisez doit posséder les droits sur les vues suivantes: v$session, v$sql, v$sql_plan, and v$sql_plan_statistics_all
Le plus simple c'est de granter au user le privilege "SELECT ANY DICTIONARY"

cdmt,
Ahmed

[mongolic]

Une aute éventualité : lors de te seconde requête, tes blocs de données sont en cache. Te reqûete est beaucoup plus rapide mais cela n'a rien à voir avec le rebuild en lui-même.