Select * KO mais Select <mon_champ> OK

Bonjour,

J'ai fait un DELETE sur MA_TABLE, suivi d'un commit qui s'est bien terminé (pas les droits pour un TRUNCATE et DROP).
J'ai vérifié, il n'y a pas de tables "locked" sur ma base.

SELECT count(*) FROM MA_TABLE = 0

Problème :

Quand je fait
SELECT champ1 FROM MA_TABLE;
J'obtiens instantanément 0 / normal, la table est vide

Mais quand je fais
SELECT * FROM MA_TABLE;
La requête "tourne" à l'infini sans rendre de résultat (pourtant la table étant vide il me semble que cela devrait être quazi-instantané)


Est-ce que vous sauriez ce qui se passe, et comment je pourrais débloquer la situation.

Merci d'avance pour votre aide.

GB

Il s'agit peut-être d'un problème de HWM (High Water Mark) non remis à 0 suite au DELETE (contrairement au TRUNCATE).

un

Code:

---

select count(*) from matable

---

est-il très long aussi ?

Non le count(*) prend environ une seconde.

J'ai pu faire un insert dans la table, et maintenant quand je fais un

SELECT * FROM MA_TABLE WHERE rownum<2; (ou tout autre condition permettant de sélectionner la ligne nouvellement insérée)

J'obtiens bien la ligne en question.

Mais quand je fais le SELECT * : toujours pas de réponse et la requête tourne à l'infini

Requêtes différentes impliquent plan d'exécutions différentes impliquent temps de réponses différentes. Utiliser la facilite autotrace sous sqlplus et investiguez les plans et les statistiques affichés.

L'hypothèse de MCM me paraît très probable.

Le plus simple est alors de réorganiser la table :

Code:

---

1 2	ALTER TABLE la_table ENABLE ROW MOVEMENT; ALTER TABLE la_table SHRINK SPACE;

---

Et ensuite le "SELECT *" devrait être immédiat.

Citation:

---

Envoyé par Pomalaix

L'hypothèse de MCM me paraît très probable.
...

---

Oui bien sûr! Mais la table doit être énorme pour avoir vraiment le sentiment que "la requête tourne à l'infini".
Pour les manipulations suggérées je pense qu'il y a peu des chances vu qu'il n'a pas les droits de faire "truncate" qui reste le moyen le plus simple de résolution du problème dans ce contexte.

Citation:

---

Oui bien sûr! Mais la table doit être énorme pour avoir vraiment le sentiment que "la requête tourne à l'infini".

---

Tout à fait d'accord avec toi, j'ai eu le problème avec une table de 1 Go avec 2 enreg.. et ça répondait en 1 minute (pas l'infini)

Autre cas possible :
La table est en fait une Vue avec trigger Instead of (Je ne pense pas que le Truncate soit autorisé dans ce cas)

Citation:

---

Envoyé par mnitu

... "truncate" qui reste le moyen le plus simple de résolution du problème dans ce contexte.

---

Que ce soit pour un TRUNCATE ou un SHRINK SPACE, s'il n'a pas les droits, il devra faire appel au DBA.

Par ailleurs, le SHRINK SPACE est plus simple, car contrairement au TRUNCATE :
- il ne rend pas les index UNUSABLE, mais les met à jour de manière cohérente vis à vis de la table. On n'a donc pas besoin de REBUILD manuel. (Confusion de ma part, désolé)
- il n'impose pas de désactiver les clés étrangères pointant vers la table à vider

Un Truncate rend les index UNUSABLE ? Non, Ce n'est pas vrai.
le MOVE TABLE oui.

Je vais faire quelques recherches sur le Shrink Space (génréation de logs, etc..) , ça me parait plus facile que le Move Table

C'est relatif.

Citation:

---

•If table is not empty, then the database marks UNUSABLE all nonpartitioned indexes and all partitions of global partitioned indexes on the table. However, when the table is truncated, the index is also truncated, and a new high water mark is calculated for the index segment. This operation is equivalent to creating a new segment for the index. Therefore, at the end of the truncate operation, the indexes are once again USABLE.

---

Citation:

---

Envoyé par McM

Un Truncate rend les index UNUSABLE ? Non, Ce n'est pas vrai.
le MOVE TABLE oui....

---

Oh m..., merci MCM, je me suis violemment mélangé les pinceaux sur ce coup là !!

Je m'en vais digérer ma honte, tiens... :scarymov:

Ohh.. ça va.. Mnitu t'a sauvé la mise ! :mouarf:

Bonjour,

Tout d'abord, merci pour votre aide, j'ai appris plusieurs choses grâce à vous et grâce à ce problème :)

Finalement je me suis rendu-compte que les STATS de la table étaient LOCKED (donc effectivement en lien avec les index), et c'est ce qui causait les inconvénients sus-décris.

Pour les "dé-locker", j'ai utilisé la commande suivante :

Code:

---

1 2	exec dbms_stats.unlock_table_stats('MON_OWNER', 'MA_TABLE');

---

Cordialement

Vous dites que le seul fait de déverrouiller les statistiques a réglé votre problème ? Sans les recalculer ? Et sans réorganiser la table ?
Ça me laisse très sceptique...

Bonjour,

En effet j'ai recalculé les STATS après le "délock", et après cela fonctionnait.

Je reste vraiment dubitatif sur la situation.

Car les statistiques sont par définition indicatives, et Oracle ne peut pas s'y fier de manière aveugle.
Même si les statistiques prétendent qu'il y a 0 lignes dans la table, en l'absence d'index adéquat, Oracle devra tout de même parcourir la table jusqu'au HWM, ce qui prendra le même temps indépendamment de l'exactitude des statistiques.

Je suis dans la spéculation, mais la réponse immédiate suggère que désormais un index est utilisé.
Et je n'arrive pas à imaginer comment les statistiques précédentes (verrouillées) auraient pu disqualifier un index lorsqu'il s'agit de faire un COUNT(*)...

Est-il possible d'avoir le plan d'exécution du "select count(*)" ?

Bonjour,
Il y a un index sur champ1, et champ1 est not null, non?
Donc:
- select de champ1 seulement lit l'index car il est plus petit (moins de blocs) que la table
- select * doit lire toute la table pour les autres colonnes, car si les stats locked donnent beaucoup de lignes, l'accès à la table pour chaque entrée d'index serait trop couteux
- where rownum<2 ajoute implicitment un hint FIRST_ROWS, donc l'optimiseur passe par index en sachant qu'on ira pas voir la table qu'une fois
- le recalcul des stats indique qu'il y a peu de lignes, mais beaucoup de blocs, donc plus optimal de passer par l'index
C'est l'hypothèse la plus probable. Mais il peut y avoir d'autre mécanismes qui rentrent en jeu. Il faudrait regarder les plans d'exécution.
Cordialement,
Franck.