Bonjour,
 
Je cherche (toujours) à améliorer mon appli web qui fait des appels à une grosse base Oracle.
Certaines requêtes sont assez énormes (tant la requête elle-même que le volume qu'elle retourne) et prennent beaucoup de temps, qui conduit parfois à des timeout.
 
Après avoir optimisé au maximum les requêtes, la base, créé des index etc, j'ai entendu parler de vues matérialisées. Apparemment, celles-ci seraient une image des données résultant d'une requête à un moment donné.
 
Mon problème est, si je crée une vue matérialisée (VM à partir de maintenant) sur la requête

 
est-ce que la requête
 

 
utilisera la VM créée ci-dessus ?
 
D'autre part, si je crée une VM sans clause WHERE, sera-t-elle utilisée par toutes mes requêtes utilisant ces données ?
 
En gros, est-ce qu'une requête n'utilisera qu'une VM construite sur une requête strictement identique, ou est-elle capable de n'utiliser qu'un "bout" de VM (champs sélectionnés, tables, jointures différents).
 
J'espère que c'est assez clair, ça l'est moyennement dans ma tête
 
Merci d'avance

ben si tu veux l'utiliser dans une autre requete, au lieu de mettre le nom de la table, tu met le nom de la vue matérialisée. Sinon c'est absurde, si tu ne fais pas un sélect dans la vue (donc que tu utilises la table de base), il n'ira jamais dans ta vue, c'est totalement logique (ils ne saurait pas deviner non plus)...
 
donc si ta vue s'appele "MAVUE" (génial le nom lol )
dans le FROM tu fais le select dans ta vue!  
 
pour avoir tout ce que tu as dans ta vue
 
SELECT *
FROM MAVUE;
 
et plus la table! enfin voila j'espère t'avoir aider! Une vue est un objet au même titre qu'une table...

Je ne peux pas modifier le code de l'appli (donc les requêtes) : trop lourd à modifier, le client n'acceptera pas.
 
Donc seules des optimisations en base sont possibles.
 
Est-ce que les VM peuvent m'aider pour ça ?
 
Merci

un index sur C (qui ne veut rien dire, tu as dû te planter en tappant) et sur C.E et sur D.E doivent déjà te tailler sévèrement la complexité.

Pour les index je pense avoir blindé, mais ça ne suffit toujours pas... (j'ai créé des index sur quasi toutes les jointures utilisées).
 
D'après toi la VM ne me ferait rien gagner / n'est pas complémentaire avec les index au niveau perf ?
 
Merci

ça dépend du domaine, tu vas reporter sur l'insert et le update ce que tu vas gagner au select, sur des données type site web dynamique c'est très rentable, sur des logs d'activité, c'est contreproductif.

ça concerne bien un site web, qui ne fait pas d'insert ni d'update mais seulement des select (les données sont alimentées par des traitements quotidiens externes au site).
 
Le problème que je vois aux VM, c'est qu'il me semble qu'il en faudrait une par requête possible sur le site (pour simplifier, si un écran propose une requête REQ1 et une requête REQ2, il faudrait réaliser une VM pour REQ1, et une autre pour REQ2, et ce pour tous les clients différents susceptibles de se logger (le critère de jointure dépendant du client loggé)).
 
Je ne suis pas sûr que ça marche comme ça, mais c'est ce que j'ai cru comprendre en lisant... Et dans ce cas ce n'est pas vraiment envisageable pour moi (une vingtaine de requêtes différentes, pour plusieurs centaines de milliers de clients différents).
 
Merci

je pense sincèrement pas que ça t'apportera des gains de performances, car comme je l'ai déjà dit, si tu ne sélectionne pas directement dedans, il ira toujours voir auprès des tables de départ (malheureusement ça ne fonctionne pas comme les index qui sont implicitement utilisé).
 
Donc comme je vois tu es un peu dans la merde! car si tu ne peux modifier ton programme d'application, ça ne va pas être génial. :s enfin moi je ne vois pas de solution! tu peux éventuellement administré ta base de donnée (la tuné) afin qu'éventuellement les requêtes se déroule un peu plus rapidement, mais une fois encore tu ne gagneras pas grand chose...  

ok merci bien, c'est ce que je craignais.
 

Salut tout le monde.
Je voulais juste apporter une précision sur les vues matérialisées puisque ce que je viens de lire est globalement faux !  
Les vues matérialisées servent la plupart du temps dans les datawarehouses. Ce sont des requêtes qui agrègent les données d'origine de manière à optimiser les temps de réponse de demandes portant justement sur ces agrégations.  
Il ne faut ABSOLUMENT pas réécrire le code d'origine et contrairement à ce que dit moi23372, il n'y a pas besoin de mentionner la vm dans le code pour y faire appel, contrairement à une simple vue !
Il suffit simplement de placer le paramètre d'instance QUERY_REWRITE_ENABLED à true dans l'init.ora et de préciser lors de la création de la vm qu'on autorise la réécriture de toutes les requetes pouvant l'utiliser.
Quant à savoir si les vm peuvent t'être utiles dans ton cas, le mieux est de faire un test pour une requete en particulier.

Ah merci beaucoup
 
Ta réponse m'intéresse beaucoup, même si j'ai un peu fermé le dossier pour l'instant, mais je pourrais le réouvrir. (dommage que certaines personnes répondent sans connaître le sujet, mais ça semble être la spécialité de moi0000)
 
Si je n'ai effectivement pas à modifier le code, les vm reprennent de l'intérêt. Pourrais-tu me dire sous quelle condition elles sont utilisées exactement stp ?  
 
Comme dans l'exemple de mon premier post, si la vue ne correspond pas exactement à la requête (champs demandés différents, un ou 2 critères en moins...), sera-t-elle utilisée quand même, ou faut-il que la vm soit construite exactement comme la requête ?
 
Merci encore

-> tout d'abord, les VM ne fonctionnent qu'à partir de la 8i d'Oracle (je suppose que c'est ton cas).
-> l'optimiseur doit être basé sur les coûts (OPTIMIZER_MODE=choose dans l'init.ora)
-> paramètre QUERY_REWRITE_ENABLED=true dans l'init.ora
-> prendre en compte le fait que le raffraichissement des VM n'est pas en temps réel : il faut choisir un mode de raffraichissement.
-> le stockage du résultat d'une VM est stocké dans une table => possibilité de créer des index sur cette table pour booster encore plus les temps de réponse. Par contre, il faut prendre en compte la taille de cette table (qui peut etre très volumineuse ) dans l'étude de volumétrie de la base.
 
Voilà pour les pré-requis, je te laisse trouver la syntaxe sur le net.
D'autre part, la VM ne sera pas utilisée si certaines informations que tu demandes ne figurent pas dedans ! Donc, mieux vaut écrire des VM trop exhaustives que pas assez si on veut pouvoir les utiliser ! En gros, le niveau de détail que tu recherches doit absolument figurer dans la VM. Après, tu pourras toujours faire des clauses restrictives pour affiner ton résultat.
Encore une fois, tout l'intérêt des VM réside dans le fait de pouvoir stocker des résultats d'agrégats ou même de jointures très couteuses sans avoir à réécrire tout le code !
Si on reprend l'ex de ton premier post, l'info F ne figure pas dans la VM, elle ne sera donc pas utilisée ! Il te faudra créer la VM   SELECT A, B, F FROM C,D WHERE C.E=D.E
D'où la nécessité de reprendre toutes les requêtes gourmandes de ton code pour voir comment écrire des VM utilisables.
 
Je pense qu'en prenant un peu de temps, tu dois pouvoir arriver à améliorer tes temps de réponse en créant de tels objets.
Et si leur création est couteuse en temps (tu reportes en fait le temps d'exécution des requêtes Temps Réel sur le temps de création et de raffraichissement des VM), pense à les raffraichir à un moment qui ne pénalise personne (de nuit par ex).
 
hum, je viens de me relire et je me dis que j'ai un style un peu lourd....

Non non tu as un style... exhaustif
 
Merci beaucoup pour tes réponses, ça répond vraiment à mes questions. Et je pense pouvoir les utiliser dans mon appli, je vais faire des tests de perf dès maintenant
 
Merci