Discussion :

[Ikebukuro]

Bonjour,

Je suis embêté avec une table qui a 4 806 570 enregistrements selon dba_tables.

Si sous SQL*Plus ou Toad je fais un select count(*) from cette_table, j'ai le résultat au bout de 4, 5 minutesaprès le lancement; idem avec une autre table de 40 000 000 millions de lignes où c'est encore bien plus long.

Là où c'est gênant c'est qu'avec le même Select sur une autre table qui a 1 247 073, j'ai un retour en 5 secondes donc ce n'est pas un problème d'environnement.

Est-ce qu'il pourrait y avoir un verrou sur cette table ralentissant le select count(*)?

je précise que si je fais un select * from cette_table, SQL*Plus m'affiche les résultats immédiatement donc il accède bien à cette table.

J'avoue être un peu perdu face à ce problème; merci pour vos conseils

[skuatamad]

Un verrou ne bloque pas la lecture, mais par contre de très nombreuses transactions en parallèles vont ralentir la lecture.
La requête est-elle juste select count(*) from t ? Et y a-t-il une clé primaire sur la table ?

De base j'aurais pensé à un problème de High Water Mark, mais il faut lire les blocs de la table pour être impacté.

[Ikebukuro]

Voici des infos en plus :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
set autotrace traceonly explain
select count(*) from pfo_date;
 
COUNT(*)
----------
   4825974
1 row selected.
 
Execution Plan
----------------------------------------------------------
           SELECT STATEMENT Optimizer Mode=ALL_ROWS (Cost=34640 Card=1)
   1         SORT AGGREGATE (Card=1)
   2    1      INDEX FULL SCAN AFPL.PK_PFO_DATE (Cost=34640 Card=4 M)

Il y a une clé primaire dans cette table sur trois colonnes et un index sur les mêmes colonnes.
PFO_LOT, PFO_LOT_LIGNE, IL_CDR_ID

Index leaf blocks : 33 449
Table blocks : 52 809
Le clustering factor a l'air très mauvais mais on n'accède pas à la table, juste à l'index donc c'est pas gênant.