Discussion :

[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 :

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

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 :

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

select count(*) from MaTable;

cela rend la main très rapidement

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

[Yanika_bzh]

Bonjour à tous

je fais un simple

Code :

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

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]

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]

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]

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]

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.