Discussion :

[gwendal86]

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

[McM]

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 :

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

select count(*) from matable

est-il très long aussi ?

[gwendal86]

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

[mnitu]

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.

[Pomalaix]

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

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

Code :

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

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

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

[mnitu]

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.

[McM]

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)

[Pomalaix]

... "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