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:

---

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.

Cela n'est pas faisable. Ce sont des procédures interne qui sont exécutées de manières masquées à l'usage exclusif de l'analyseur de requête, seul capable de les interprétées.
Vous pouvez cependant obtenir le plan de requête en XML et donc l'incorporer dans une variable pour usage spécifique...

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 +

Citation:

---

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