Reprise du message précédent :
Une petite question bête : est-ce que vous savez pourquoi quand je lance une requête avec TOAD, ce dernier occupe 100% du CPU durant toute la requête
 
Genre on dirait que c'est lui qui execute la requête !

Je suis pas réveillé non plus j'avais même pas regardé les index de msk ... je regardais ceux de pro
 
M'enfin faut dire que c'est tellement peu lisible
 
Ce qui pourrait être intéressant, c'est de couper la dernière requête que je t'ai passée, et de créer des tables temporaires contenant les résultats intermédiaires. Dans certains cas on peut y gagner.
Surtout si tu veux le résultat pour tous les produits ...

Je crois qu'on peut lui decerner la palme de la plus grande requete

bah j'ai déjà fait très largement pire (mais alors largement de chez largement )
 
J'aime bien faire des requêtes de 10 Ko
 
(curieusement, sur celles-là, j'ai très rarement de problème de perf )
 
Pis quand j'en ai, j'ose pas demander, parceque vu la tronche du bidule, c'est à coup faire planter le forum de peur

la fonction analytique LEAD devrait faire l'affaire alors, elle permet de récupérer la ligne précédente dans les lignes fetchées... avec un order by bien senti ça devrait le faire.
 
Je suis désolé j'ai vraiment pas le temps mais si tu peux me faire un modéle simple avec un échantillon de données, je pourrais peut-être te pondre un début d'idée

Je me lance mais comme je comprends rien ça risque de merder... mais ça te donnera peut-être des idées
 

 
Devient :
 

     
Si je comprends bien, tu veux pas le max, mais celui juste avant... alors :
 

 
Ca s'approche pas de ce que tu voudrais ?
 
Avec la fonction RANK tu peux faire plus joli encore

Pour la première requête :
-> Nan, ma requête n'est pas intuitive. Elle ne retourne pas UNE ligne, mais autant de lignes qu'il y a de produits différents attachés au fournisseur. Le coup du ROWNUM ne peut donc pas marcher dans mon cas.
 
Pour ta seconde requête :
-> Non plus Là tu vas me retourner le résultat de l'éventuel avant dernier inventaire dans l'inteval de dates. Moi je veux le dernier mouvement (codosk != 'INICPT') avant le dernier inventaire (codosk = 'INTCPT')
 
Donc ça marche pas non plus

Je suis en train de me demander par contre...
 
NUMMSK du dernier inventaire :
 

 
Je veux le MAX() du NUMMSK parmis les NUMMSK inférieurs à cette valeur pour chaque produit :
 

 
Et je veux récupérer les infos de la ligne qui correspond à ce max pour chaque produit :
 

 
A priori, à un ou deux détails près, c'est la réécriture de ma première requête en mode peut-être plus compréhensible...
 
Vais tester ce que ça donne. Mais je doute fortement que ça change grand chose à la vitesse d'execution, les sous-requêtes sont les mêmes, on les fait juste pas au même moment...

Merdoum ! Je viens de perdre un gros post avec une énorme requête

Alors... Ma requête (après quelques nouvelles corrections - passé de 26 secondes à 13 secondes -) :
 

 
13 secondes - 96 lignes
 
La nouvelle requête (après quelques corrections aussi) :
 

 
4 minutes et 29 secondes / 96 lignes
C'est le même résultat.
 
Visiblement, à moins que je ne me soit planté quelque part, les sous-select dans le FROM sont foutus en table temporaire avant, ce qui prends beaucoup de temps car il ne sont presque pas filtrés.
 
M'enfin ça vous permettra peut-être de mieu comprendre ce que fait la requête...

J'ai beau la tourner dans tous les sens, j'arrive pas à voir une solution pour l'écrire autrement...

c'est mieux... maintenant tu introduits les fonctions analytiques pour remplacer le ROWNUM par ton besoin : http://lalystar.developpez.com/fon [...] ques/#L3.8
 
Et ça devrait le faire

ça moi je veux bien mais :
- je vois toujours pas comment ça peut m'aider
- et j'ai pas de rownum dans mes requêtes
 
pendant un moment je me suis dit "mais oui, c'est sa requête que je dois étudier". saufqu'après l'avoir charcutée un peu, je me suis rendu compte de ce que j'ai répondu hier : l'est complètement à côté de la plaque ta requête, au mieu je récupère l'inventaire de n'année d'avant

Ce sont des tables très souvent mises à jour ?
 
Tu pourrais peut-être préparer des données dans une vue matérialisée  ...
 
Sinon des fonctions analytiques bien écrites comme proposait orafrance, mais je suis pas un expert dans ce domaine

j'arrive pas à comprendre le besoin fonctionnel donc je peux pas aider mieux désolé

 
Explain Plan :
 
SELECT STATEMENT Hint=RULE                                  
  FILTER                                  
    SORT GROUP BY                                  
      TABLE ACCESS BY INDEX ROWID MSK                                
        NESTED LOOPS                                  
          NESTED LOOPS                                  
            NESTED LOOPS                                  
              VIEW                                  
                SORT GROUP BY                                  
                  TABLE ACCESS FULL MSK                                
              TABLE ACCESS BY INDEX ROWID PRO                                
                INDEX RANGE SCAN WI_PRO                                
            TABLE ACCESS BY INDEX ROWID MSK                                
              INDEX RANGE SCAN MSK_IDX1                                
          INDEX RANGE SCAN MSK_IDX1                                

Impossible de faire une vue matérialisée : la table MVT est mise à jour en permanance, à la fois "à la volée" par les fonctions utilisateurs et par lot la nuit lors de batchs.
 
En effet, c'est la table des mouvements de stocks.
 
Sauf que c'est un ERP. Et les stocks ça se limite pas à un stock physique dans un unique dépôt.
 
Y'a 16 compteurs en tout (ici, seuls les 9 premiers sont paramétrés).
On y trouve notamment :
- Stock physique
- Préparation (ce qui est dans le physique, en cours de prépération pour l'envois)
- Réservation (ce qui n'est pas dans le physique, mais qui a été vendu - attente d'approvisionnement)
- Les réceptions (ce qui n'est pas encore dans le physique, mais matériellement au dépôt - en cours de comptage et validatio qualité -)
- Les approvisionnement (les commandes d'approvisionnement)
Plus des calculés :
- Disponible à la vente (physique - prépa)
- A terme (physique - prépa - résa + réception + appro)
- Ventes (prepa + résa)
- Achats (réceptions + appro)
 
Et ce pour 9 dépôts différents.
 
Donc à chaque fois qu'une commande d'achat ou de vente est saisie, on met à jours des compteurs. Idem pour les factures, les bons de livraisons, etc.
Sans parler des transferts, les retours SAV, etc.
 
Vu qu'ici c'est une centrale d'une chaîne de magasins, tu imagines bien que les gens passent leur temps à saisir ce genre d'infos. C'est pas par hasard si en janvier (mois très calme, car les magasins ont déjà leurs stocks constitués avant noël, et c'est prériode de soldes puis inventaire, donc appro interdite) y'a eu près de 30 000 nouvelles lignes dans la table.
 
Donc la vue matérialisée est à abandonner. La vue tout court, why not, mais ça devrait pas changer grand chose.
 
Sinon, pour les fonctions analytiques, je suis à fond partant, mais avec un exemple qui marche. Jusqu'à présent, la doc que j'ai lu ou les tentatives d'orafrance n'entre jamais dans le cadre de mon besoin...

Ben le fonctionnel, je l'ai expliqué
 
Début janvier, il y a eu un inventaire. (première vague de saisie 'INICPT' le 2 janvier, puis saisie des variations d'inventaire 'INVV' dans la semaine qui suivait (recomptage et correction).
 
On me demande, pour chaque produit -ici je me suis limité aux produits d'un fournisseur- :
1/ Le cumul des entrées saisies depuis l'inventaire
2/ Le cumul des sorties saisies depuis l'inventaire
3/ La quantité inventoriée
4/ Le cumul des quantités rcomptées
5/ L'état des stocks avant l'inventaire
 
Afin de refaire un inventaire et valider que le premier était juste (je but de ce second inventaire n'est pas d'inventorier, mais de faire sauter des têtes en montrant qu'il y a eu des erreurs d'inventaire).
J'ai aucun scrupule à faire cette requête, car les quelques erreurs qu'on a vu passer, ce sont des erreurs ponctuelles et indépendantes de l'inventaire (valorisation des stocks en se basant sur un prix exprimé dans une unité différente que cette de stockage). Pis de toute façon je suis pas là pour prendre position dans les questions politiques de la société
Enfin voilà, ça explique pourquoi ces chiffres qui, il est vrai, ont à la base, un intérêt plus que limité.
 
Pour les 1, 2, 3 et 4, aucun souci, c'est le reste de ma requête énorme, et ça tourne en moins d'une seconde.
 
L'état des stocks avant inventaire (uniquement le compteur physique, qui est C01 de la table MSK) est retrouvé comme suit :
-> Dans la période de dates, on recherche le plus grand numéro de mouvement (NUMMSK) dont l'oppération est une initialisation du compteur physique (codosk = 'INICPT'). Ca correspond à la saisie du résultat d'inventaire.
-> On recherche, parmi les NUMMSK plus petits que ce numéro d'inventaire, le plus grand qui correspond au même produit dans le même dépôt (y'a pas de gestion de lots ni d'emplacements ici, donc on peut en faire abstraction)
-> On récupère le C01 de cette ligne, c'est l'état du stock physique avant inventaire.
 
Donc, ma requête est bien (pseudo SQL)
 
select c01 from msk where nummsk = (select max(nummsk) from msk where nummsk < (select max(numsk) from msk where codosk = 'INICPT' and datmsk between ...))
 
(avec les jointures qui vont bien sur la société, le produit et le dépot)
 
Je pense que c'est plus clair comme ça

PS: et ma requête ne retourne pas UNE ligne, mais une ligne pour chaque produit (à condition qu'il y ait un iventaire ce de produit dans la prériode, sinon ça retourne rien )

et en PL/SQL ce serait pas plus simple ?