Discussion :

[LEK]

Bonsoir,
j'ai toujours quelques questions sur les vues matérialisées :
- je n'ai pas réussi à trouver le nombre maximum de vues matérialisées que l'on peut créer en tout cas comment connaître la limite à partir de laquelle on commence à pénaliser la base... Mon but n'est pas d'en faire une utilisation outrancière mais j'ai un traitement à réaliser chaque jour sur la base de plusieurs données agrégées et pour lequel j'avais écris des vues (normales), mais il se trouve que mon traitement doit parfois interroger de manière récursive certaines de ces vues assez coûteuses : mon premier réflexe a été de me dire que je pouvais stocké le résultat de mes vues dans des tables avant de lancer mon traitement mais les vues matérialisées me semblent plus adaptées à considérer que je n'aurais théoriquement plus qu'à les rafraîchir à la demande...
J'ai actuellement une trentaine de vues de ce type (peut être une dizaine d'autre à venir) et je ne sais pas du tout si donc 30/40 vues matérialisées ne serait pas un abus dommageable de cette fonctionnalité..
Comme autre alternative, j'aurais pu récrire mon traitement pour qu'il n'interroge qu'une fois ces vues puis au lieu de requêter dessus ne fasse plus que filtrer les données en mémoire, mais malheureusement cette tâche est trop fastidieuse pour même y songer...
Donc si vous pouvez me donnez votre avis sur le sujet ou me conseiller une solution de repli, je serais ravis...

Merci encore,
Lek.

[pachot]

Bonjour,

Comme autre alternative, j'aurais pu récrire mon traitement pour qu'il n'interroge qu'une fois ces vues puis au lieu de requêter dessus ne fasse plus que filtrer les données en mémoire, mais malheureusement cette tâche est trop fastidieuse pour même y songer...

Ce serait effectivement mieux

Sinon, non il n'y a pas de limite au nombre de vues matérialisées. La limite sera surtout le temps de rafraîchissement. Mais de toute façon, ce sera toujours plus rapide que de reconstruire leur résultat à chaque requête.

Si c'est la solution choisie, alors il sera bon de choisir les attributs de stockage optimums pour ces vues matérialisées en fonction de la manière dont elles sont interrogées: PCTFREE à 0, compression éventuelle, peut-être IOT ou CLUSTER ...

Cordialement,
Franck.

[LEK]

Merci pachot pour les précisions, je retourne me plonger dans la doc pour en apprendre plus sur les paramètres que tu cites.
Merci encore.

[Pomalaix]

Donc si vous pouvez me donnez votre avis sur le sujet ou me conseiller une solution de repli, je serais ravis...

Pour éviter de faire des propositions dans le vide : quelle est votre version d'Oracle ? Etes-vous en édition Standard ou Entreprise ?

[LEK]

Mon projet se trouve sur des plateformes 10g et 11g
(les nouveaux clients passent directement en 11g)
et toujours en édition standard.

[Pomalaix]

Bon, pour le cache de résultats, c'est mort alors !
Il faut être en V11, édition Entreprise...

Mais peut-être qu'un simple WITH pourrait vous aider, si vous devez faire appel plusieurs fois à un même résultat partiel au sein d'une requête globale.

[LEK]

J'utilise déjà ce genre de technique (with) pour amortir quelque peu le coût de mes requêtes...
Effectivement pour le result cache je peux encore attendre.
Comme je l'indiquais l'emploi de vues matérialisées ou tables me semble la seule bonne mauvaise idée dans l'instant car mon traitement a juste besoin d'un pré-calcul et mise en snapshot des résultats pour pouvoir ensuite travailler dessus à sa guise, pendant que le reste de la base opérationnelle continue de tourner... Avec les vues qui prennent un coût faramineux (je n'en suis pas le seul auteur, aussi je dois tuner et voir régulièrement si des outer joins ou autres produits cartésiens abusifs ne sont pas présents pour miner les perfs.. Cela-dit même pour les vues qui semblent bien écrites il y a quand même des coûts montant à 1000/1500 et des temps de réponses allant jusqu'à 30 secondes, les rapports en résultants commencent à mettre quelques heures pour être générés et effectivement ça en agacent certains!)