Discussion :

[grouhan]

Bonjour,

sur une base oracle oracle 12C en environnement Linux

le métier a une requête dite de positionnement héritée d'un portage Iseries vers Unix pour laquelle le résultat du portage donne plusieurs sous requête "reliées" par un union all permettant de retourner l'ensemble des enregistrements d'une table à partir d'un enregistrement.

La requête utilse un hint FIRST et INDEX_ASC pour forcer l'utilisation de l'index répondant aux critères métiers.

Code :

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

Select /*+ FIRST_ROWS INDEX_ASC(table index) */ * from matable where a=:1, b=:2, c=:3, d >= :4 union all select *+ FIRST_ROWS INDEX_ASC(table index) */ * matable where a= :1, b= :2, c > :3 union all select *+ FIRST_ROWS INDEX_ASC(table index) */ * from matable where a = :1 and b > :2

La requête permet de retourner l'ensemble des enregistrements à partir d'un enregistrement donnée jusqu'à la fin de la table. Par rapport au besoin métier, la requête retourne plus d'enregistrement que nécessaire; elle est gérée par un curseur qui effectue un next si l'enregistrement courant correspond au besoin métier et sort de la boucle si l'enregistrement courant est en dehors du besoin.

Donc potentiellement, la requête initiale retourne plus d'enreg que nécessaire.

La question que je me pose est sur l'utilisation du HINT FIRST et de l'échange entre le process client et le process server pour savoir si malgré tout le moteur oracle retourne l'ensemble des enregistrements dans la PGA du process serveur et que ensuite l'échange entre le process client et le process server s'effectue au rythme des next de mon programme métier ou bien est que l'ensemble des enregistrements répondant à ma requête sont transmis dans la mémoire du process client ?

L'utilisation du hint FIRST permet-il ici de transmettre plus rapidement les données au process client dès qu'une des sous requêtes a été traitée par Oracle ?

Merci par avance pour vos retour

[Waldar]

L'indice FIRST ne m'évoque rien du tout et je ne le retrouve pas dans la documentation Oracle, il est traité comme un commentaire et n'a aucun impact sur les performances de la requête.
J'imagine que le développeur voulait utiliser FIRST_ROWS.

Je ne suis pas sûr aussi du résultat de cette requête sans aucun critère de tri, je suppose que le métier souhaite en premier les résultats du premier bloc, puis ceux du second et enfin ceux du dernier.

[grouhan]

Bonjour,

oui il s'agit effectivement du FIRST_ROWS.

Le besoin est effectivement que les résultats soient retournées triés dans l'ordre de l'index et dans l'ordre des sous requêtes.

L'utilisation du UNION ALL garantie t'elle qu'Oracle retourne les enregistrements de la première sous-requête puis ensuite de la secondes .... ?


A quel moment le FIRST_ROWS retourne le résultat de la requête au client ? Dès que la première sous requête est terminée ? dès que la première sous requête a ramené un certains nombre d'enregistrement ?

Une fois que les premier enregistrement sont retournés, il attend que le client lui en demande de nouvelles ou bien il les envois quoi qu'il arrive sauf si le client a fermé le curseur ?

[Ikebukuro]

/* + n'est pas bon, il faut écrire /*+ pour que la suite soit considéré comme un hint; pas d'espace entre * et +

[grouhan]

Oui merci, il s'agit d'un mauvais copié / collé.

Mes interrogations concernent plus le comportement d'Oracle avec ce type de requête pour le hint /*+ FIRST_ROWS */ et les union all comme indiqué dans mon post précédent.

[Ikebukuro]

Question complexe... je te propose de simplifier ta requête en éliminant les deux INDEX_ASC(table index) car, quand tu utilises FIRST_ROWS, l'optimiseur privilégie déjà les index.
Autre point, laisse tomber le hint FIRST_ROWS, il est deprecated depuis Oracle 9i et remplacé par FIRST_ROWS_n avec FIRST_ROWS_1, FIRST_ROWS_10, FIRST_ROWS_100, FIRST_ROWS_1000.