Version imprimable
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.
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 ?
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à.
les stats ont bien été calculées APRES le chargement ? Les indexes sont les mêmes ?
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é.
Un rebuild des index et un calcul des stats sur les index et tables seraient le bienvenue à mon avis :wink:
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.
pas de clause WHERE et le même nombre d'enregistrements ?
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.
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
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 :
entre les 2 bases.Code:select * from user_extents where segment_name = 'nom_de_la_table' order by extent_id ;
2 ) une différence au niveau du paramétrage de la base, notamment du paramètre db_file_multiblock_read_count. Que donne un :
3 ) un pb d'accès disque, genre contention ???Code:select value from v$parameter where name = 'db_file_multiblock_read_count' ;
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 ???
sur les deux bases tu fait
et tu nous donne les resultatsCode:
2
Tu charge tes données avec sqlloader puis aprés tu lance l'analyse et non pas l'inverse ?