select trop lent

[cyclone_yas]

Bonjour à tous

une question qui me taraude !
je suis sur une base oracle 10.2.04, j'utilise le client sqldeveloper.

je fais un simple

Code :

SELECT * FROM MaTable;

cela prend des années avant de retourner un résultat ! pourtant ca doit juste lire le début de la table et afficher le résultat !
(la table fait environ 300 000 ligne sur 5 colonne)

même quand je fais un

Code :

SELECT count(*) FROM MaTable;

cela rend la main très rapidement

est ce que quelqu'un aurait une idée !

[Yanika_bzh]

Envoyé par cyclone_yas

Bonjour à tous

je fais un simple

Code :

SELECT * FROM MaTable;

cela prend des années avant de retourner un résultat ! pourtant ca doit juste lire le début de la table et afficher le résultat !

Pourquoi cela ne lirait que le debut de la table ???
Cela vous lit votre table entierement, donc vous renvoie le maximum de données possibles, donc un flux important, donc lenteur !!

[cyclone_yas]

Envoyé par Yanika_bzh

Pourquoi cela ne lirait que le debut de la table ???
Cela vous lit votre table entierement, donc vous renvoie le maximum de données possibles, donc un flux important, donc lenteur !!

Désolé l'ami, il va lire que le début de la table
et au fur et à mesure que tu scrole il lit la suite

[Yanika_bzh]

Envoyé par cyclone_yas

Désolé l'ami, il va lire que le début de la table
et au fur et à mesure que tu scrole il lit la suite

C'est moi qui suis désolé pour vous ...
Comment faites vous donc pour lire completement un table alors ?

[cyclone_yas]

si ta table fait 10 000 000 de ligne
un select * ne ramènera pas toutes les lignes en mémoire

le select * s'affichera instantanément, il ramènera les première lignes !

[Yanika_bzh]

Je ré itère donc ma question, comment faites vous pour selectionner TOUTES les lignes de votre table !

[pachot]

Bonjour,

Un count(*) peut utiliser un index de clé primaire, sans aller lire la table.
Le select * va effectivement aller chercher que les premières lignes (en fonction du fetch size). Il peut y avoir plusieurs raisons pour lesquelles c'est plus long.

Par exemple: une table qu'on remplit de bcp d'enregistrement, puis où on delete tous les enregistrements sauf les derniers. Alors, le full scan devra lire bcp de blocs vides avant de trouver les premiers enregistrements.

Ou une table vidée par des delete mais remplie par des inserts en direct path.

Cordialement,
Franck.

[McM]

Ca dépend aussi du type des colonnes. Si tu as un blob alors là le select * va prendre beaucoup de temps.

[skuatamad]

Bonjour Pachot,

Le select * va effectivement aller chercher que les premières lignes (en fonction du fetch size).

Je précise qu'en même que le fetchsize n'influe pas sur le nombre de lignes retournées, il influe seulement sur le nombre d'aller/retour entre le client et le serveur pour ramener toutes les lignes demandées (et par conséquent sur le consistent get nécessaire).

Certes le client commence à récupérer des données mais il ne récupère pas la main avant d'atteindre la dernière ligne comme avec sqlplus par exemple.

Par contre, le comportement décrit par cyclone_yas ressemble à celui de Toad qui effectivement pagine la requête automatiquement pour ne renvoyer que les 500 1eres lignes il me semble.

Donc si rien ne se passe pendant longtemps avant d'obtenir les 1eres lignes ça ressemble effectivement à un problème de High Water Mark.

[pachot]

Envoyé par skuatamad

Certes le client commence à récupérer des données mais il ne récupère pas la main avant d'atteindre la dernière ligne comme avec sqlplus par exemple.

ici, il s'agit de sqldeveloper. Donc les lignes ne sont fetchées que pour les afficher. Si on ne scroole pas jusqu'en base, toutes les lignes ne sont pas lues.

[skuatamad]

Ah oui je n'avais pas vu que c'était SqlDeveloper mais je pense que ça ne change rien, à mon avis SqlDeveloper comme Toad réécrit la requête pour paginer et refetch les lignes au fur et à mesure du scroll, à mon avis rien à voir avec le fetch size.

[edit]OK il semble que le fetch size de SqlDeveloper correspond au nombre de lignes fetch par SqlDeveloper contrairement à l'array fetch size de sqlplus.
Donc SqlDeveloper s'appuie bien sur le fetch size pour paginer la requête (mais on est d'accord, il s'agit bien de pagination ?)

[Yanika_bzh]

Envoyé par pachot

ici, il s'agit de sqldeveloper. Donc les lignes ne sont fetchées que pour les afficher. Si on ne scroole pas jusqu'en base, toutes les lignes ne sont pas lues.

Donc ca n'a pas grand chose a voir avec SQL, mais devrait plutot etre posté dans la rubrique outil.

[skuatamad]

Envoyé par Yanika_bzh

Donc ca n'a pas grand chose a voir avec SQL, mais devrait plutot etre posté dans la rubrique outil.

Son problème pourrait être un problème de HWM donc plus à voir avec Oracle qu'avec l'outil, par contre votre incompréhension du début avait tout à voir avec l'outil utlisé.

[pachot]

Envoyé par skuatamad

Ah oui je n'avais pas vu que c'était SqlDeveloper mais je pense que ça ne change rien, à mon avis SqlDeveloper comme Toad réécrit la requête pour paginer et refetch les lignes au fur et à mesure du scroll, à mon avis rien à voir avec le fetch size.

Envoyé par Yanika_bzh

Donc ca n'a pas grand chose a voir avec SQL, mais devrait plutot etre posté dans la rubrique outil.

C'est pas pour polémiquer, mais non ! il y a une grosse confusion dans ces remarques.

Ni TOAD ni SQLDeveloper ne réécrivent quoi que ce soit.
Et oui ça a à voir avec le SQL et pas l'outil.

En SQL on EXECute une requête en ouvrant un CURSEUR, puis on FETCH les enregistrements un par un ou plutôt par paquets.

Et sous sqlplus, c'est pareil. Par défaut, ARRAYSIZE=15 donc on va chercher les lignes 15 par 15 et on est jamais obligés d'aller jusqu'au bout: 'set pause on' si on veut lire écran par écran et 'control-C' lorsqu'on en veut plus.

Il n'existe pas d'appel qui va chercher tout les enregistrements d'un coup.

Cordialement,
Franck.

[skuatamad]

Ah ok, tu fais bien de polémiquer je ne connaissais pas set pause on et je pensais que Toad réécrivait les requêtes...

Donc j'ai bien fais de dire des bétises et tu as bien fait de polémiquer car j'en ai appris plus sur ces outils.

Merci Pachot

[laurentschneider]

c'est toute la différence entre first_rows et all_rows

Code :

SELECT /*+ FIRST_ROWS(10) */ * FROM T

optimise le temps de réponse pour les 10 premières lignes

Code :

SELECT /*+ ALL_ROWS */ * FROM T

optimise le temps de réponse pour la requête complète

http://download.oracle.com/docs/cd/E...6.htm#BABGCCFG

[cyclone_yas]

1000 merci à tous

J'ai trouvé la cause, il ne s'agit pas d'une table, il s'agit d'une vue re-compilée à chaque fois elle est appelée dans une requête !

la personne ayant crée cet objet n'a pas respecté la syntaxe.

par contre ce qui demeure incompréhensible c'est le pourquoi cette vue est re-compilée à chaque appel ?

[laurentschneider]

qu'est qui te fait dire qu'elle est recompilée?

[cyclone_yas]

C'est un collègue qui m'a expliqué qu'elle était re-compilée à chaque fois.
Supposition corroborée par le temps de réponse extrêmement lent.

j'ai regardé dans la all_objects et la all_views mais rien ne semble indiquer cela ! le Last_ddl_time et le timestamp n'ont pas changé après requetage !?

[laurentschneider]

ouais, ton collègue dit n'importe quoi, sans doute qu'il a googlé sur la mauvaise page

même si elle était "recompilée", tu perdrais quelques dizièmes de secondes à tout casser !

essaye quand même avec mon "hint".