Discussion :

[roda]

sur deux bases différentes je fais le même select count(*) il est 10 000 fois plus long sur une base alors que sur l'autre il répond instantanément.

Quelqu'un peut-il m'aider à comprendre en sachant que j'ai passé les statistiques sur toutes les deux bases.

Qu'est ce que je peux regarder d'autres ? Le nombre d'extents est de 4.

[Jaouad]

Bonjour Roda et bienvenue sur le forum Oracle de developpez.com ,
Avant de poster merci de bien lire les régles et otamment de bien préciser le contexte technique.

Pour ta question , tu reste assez évasif :
Est ce la même version d'oracle?
Compte t'il le même nombre de ligne ?
Est ce le même réglage OS ?
Est ce le même réglage Oracle?
...

Quelles sont les différences entre les deux versions ?

[roda]

Ok désolé.
Oracle 8.1.7 même machine même Os.
Avant le temps de réponse etait OK.
On a réinitialiser la table par un chargement sqlldr est ce que le problème peut venir de là.

[orafrance]

les stats ont bien été calculées APRES le chargement ? Les indexes sont les mêmes ?

[rouardg]

Bonjour,

N'y aurait-il pas une différence au niveau des index de la table ?
Merci de vérifier si il n'y a pas eu d'index de supprimé, ou bien de désactivé.

[Jaouad]

Un rebuild des index et un calcul des stats sur les index et tables seraient le bienvenue à mon avis

[roda]

Il n'y a aucun index sur la table c'est un select count(*) from table
Tout bete.
Toutes les stats ont bien été calculés.

[orafrance]

pas de clause WHERE et le même nombre d'enregistrements ?

[lalystar]

Peut etre que la High Water Mark est bcp plus haute sur la table qui souffre du temps le plus long. A t'elle été bcp plus grosse de par le passé ?


Laly.

[roda]

Pas de clause where !
Le même nombre d'enregistrements dans la table.

Cette table n'est jamais mise à jour elle est est toujours tronquer (truncate) et ensuite il y a un chargement par sqlldr.
Le pctused=98 et le pctfree=0

[rouardg]

Résumons : puisqu'il n'y a pas d'index sur cette table, le select count (*)... ne peut que provoquer un balayage complet de la table.

Il semble donc y avoir un pb au niveau de la lecture des blocs Oracle de la table.

A mon humble avis, cela peut venir de 3 raisons :

1 ) un stockage complétement différent entre les 2 tables. Pour le voir, que donne un :

Code :

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

select * from user_extents where segment_name = 'nom_de_la_table' order by extent_id ;

entre les 2 bases.

2 ) une différence au niveau du paramétrage de la base, notamment du paramètre db_file_multiblock_read_count. Que donne un :

Code :

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

select value from v$parameter where name = 'db_file_multiblock_read_count' ;

3 ) un pb d'accès disque, genre contention ???

Dernière piste : lors du select count (*) sur cette table, la table n'est pas en modification ???

Pas d'autres sessions actives qui seraient en train de modifier cette table ???

[bouyao]

sur les deux bases tu fait

Code :

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

1
2
set autotrace on
select count(*) from ...

et tu nous donne les resultats

Tu charge tes données avec sqlloader puis aprés tu lance l'analyse et non pas l'inverse ?