taille d'une requ�te par une autre requ�te

J'ai une requ�te R1 pour laquelle j'ai besoin de savoir le nombre
de lignes retourn�es. 2 solutions imm�diates:
1) j'ex�cute R1 et j'attends et l� j'obtiens le nombre "exact" de lignes
2) je demande le plan d'ex�cution et l� j'ai une "estimation" du nombre de lignes.

Comme ce qui m'int�resse c'est la rapidit� de l'estimation et comme j'ai beaucoup de requ�tes pour lesquelles je veux estimer la taille, j'aimerai savoir s'il est possible
de d�finir une requ�te R2 qui elle affiche le nombre de lignes estim� retourn�es par R1.

Grosso modo, je voudrais savoir comment interroger les plans d'ex�cution.

Merci

J'ai consult� la doc et j'ai vu qu'avec un
set showplan_all off
l'ex�cution de la requ�te revient � afficher son plan dans une table dans laquelle,
il y a entre autres l'estimation de la taille du r�sultat. Ce qui me manque maintenant
c'est comment r�cup�rer cette table pour l'interroger par la suite.
J'ai essay� :
set showplan_all off

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
 
select A
Into temp
From ma_table

En pensant na�vement que le plan sera stock� dans temp :-) j'ai bien s�r obtenu
le plan de la requ�te c-dessus.

Envoy� par SQLpro

Quel est votre but en demandant � l'avance le nombre de ligne, sachant qu'une base de donn�es �tant par nature dynamique entre le moment ou vous aurez demand� le nombre de ligne et le moment ou vous voudrez ex�cuter la requ�te cela aura probablement chang� ?
A moins de verrouiller de mani�re exclusives toutes les tables en jeu dans votre requ�te pendant tout le traitement, mais l� on en revient � l'�ge de pierre de l'informatique, c'est � dire � travailler en fichier COBOL !
A +

Mon but est le suivant: partant d'une table de faits � D dimensions (j'utilise la terminologie datacube) il y a en th�orie 2^D aggr�gations possibles (voire plus si l'on tient compte des
hi�rachies). SQL Analysis (ou ses successeurs) permet de s�lectionner un sous ensemble
de ses agr�gations pour les mat�rialiser. Je ne suis pas satisfait du r�sultat mais je pr�sume que dans son algorithme, il fait des estimations de tailles. Je veux tester un autre algorithme sachant qu'il ne faut surtout pas calculer toutes les tailles (�a prendrait trop de temp).

Quant aux mises � jour, comme vous voyez, je me place dans un contexte o� la base n'est pratiquement utilis�e qu'en consultation. Ce qui m'int�resse ce sont les ordres de grandeur. Par exemple, D1 peut �tre calcul�e � partir de l'agr�gation D1,D2 mais quelle est le rapport taille(D1,D2)/taille(D1). Ayant calcul� ces rapports � un instant t, il y a de fortes chances que ce rapport soit pr�serv� au temps t+1 (si l'on ne consid�re que des insertions).

Conclusion: il ne s'agit pas d'une utilisation d'une BD op�rationnelle mais plust�t d�cisionnelle.

Merci pour vos r�ponses.

Up,
Je fais un peu la m�me chose que toi Tachaout.
As-tu trouver une solution pour utiliser le plan d'ex�cution ?

Merci
Kumkaya