Discussion :

[doukem]

Bonjour,

J'utilise des vues (assez complexes) sur des tables dont l'accès est principalement en lecture seule (accès très rare en écriture, du genre une fois par an).
Comme ces requêtes sont assez complexes, je pensais utiliser des vues matérialisées, pour gagner du temps.

Je n'arrive pas à créer une vue matérialisée toute simple.

Code :

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

1
2
3
 
CREATE MATERIALIZED VIEW MV1
AS SELECT * FROM MA_TABLE

Cependant, j'ai le message "privilèges insuffisants".
N'y a t-il pas un type de vue matérialisée (une option ?) que je puisse créer en utilisant les droits de base ?

Merci

[orafrance]

tu as bien le droit de créer la vue matérialisé (create snapshot il me semble) ? Si tu fais juste le SELECT est-ce que ça fonctionne ?

[doukem]

tu as bien le droit de créer la vue matérialisé (create snapshot il me semble) ? Si tu fais juste le SELECT est-ce que ça fonctionne ?

Quelle est la différence entre MATERIALIZED VIEW et SNAPSHOT ?

Le SELECT seul fonctionne. Il semble que je n'ai pas les privilèges suffisants pour la création de la vue matérialisée.

Merci

[orafrance]

c'est pareil, depuis la 9i un snapshot s'appelle une vue matérialisée c'est tout.

essaye :

Code :

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

grant create snapshot to owner_vue;

[doukem]

c'est pareil, depuis la 9i un snapshot s'appelle une vue matérialisée c'est tout.

essaye :

Code :

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

grant create snapshot to owner_vue;

Merci pour tes conseils.
Je ne suis pas DBA, je ne peux donc pas m'auto-accorder de privilège :
"privilèges insuffisants"

Je pense que mon problème était tout simple, je ne doit pas avoir le privilège pour CREATE SNAPSHOT

Merci

[remi4444]

Si tu ne peux vraiment pas obtenir les droit de création de vue matérialisée, tu peux te la faire toi même car il faut savoir que ce n'est jamais qu'une table dans laquelle est stockée le résultat d'une requête. La seule limite qu'il y a, c'est que tu ne pourra pas bénéficier d'un rafraichissement différentiel (ou alors c'est plus compliqué). Mais si ta requête est complexe, de toute façon tu n'aurais pas pu non plus utiliser cette methode par une vue matérialisée.

[nuke_y]

Mais il n'a peut-être aucun droit CREATE.

[remi4444]

Mais il n'a peut-être aucun droit CREATE.

Ah oui effectivement, faut-il préciser qu'il faut aussi avoir le droit de se connecter à la base ainsi que de rentrer dans le bureau

[Hugues_78]

La vue matérialisée n'est pas vraiment comparable a une table :
- elle permet la mise à jour incrémentale moyennant les MV logs, y compris dans le cas de requête un peu complexe
- et surtout elle permet le query rewriting, ce qui peut donner de gros boost de perfs (sur certaines applis, j'ai divisé mes temps de réponse moyen par 20...)

[nuke_y]

query rewriting ? C'est le fait qu'une requête qui va ramener les mêmes données que celles contenues dans la VM va plutôt aller lire la VM que de reproduire la requête ?

Mais dans ce cas il y a le problème de l'obsolescence des données non ?

[Hugues_78]

query rewrite : on s'en sert surtout en datawarehouse sur les agrégats. Ce qui marche le mieux, c'est avec les modèles en étoile ou en flocon.
Coté rafraichissement, c'est en général quotidien ou hebdo dans ce contexte. Du coup, je travaille également fréquement en compress pctfree 0 pctused 99

Imagine une table des ventes énorme dans laquelle tu stocke le temps, le client et l'article et les données financières (CA, marge...).

Par ligne :
temps = 8 octets
article = 10 octets
client = 10 octets
CA et marge et quantité = 10 octets chaque

Tu as 10 millions de lignes ==> 580Mo

En général, un client achète 10 articles. Donc on n'a plus que 1 millions de lignes, qui ne font plus de 48 octets (y a plus l'article) ==> on arrive à 48Mo
C'est la taille de la vue matérialisée...

tu passe la requête :

Code :

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

select id_cln, sum(mt_cab) from mes_ventes group by id_cln

sans vue matérialisée = full table scan sur 580Mo + sort sur un gros resultat
avec vue matérialisée et les paramétres qui vont bien, le full table scan n'est plus que sur 48Mo et le résultat trié est 10/12 fois plus petit

Tu peux aller beaucoup plus loin que ces exemples basiques. Par exemple déclarer des dimensions qui vont définir des liens hiérarchique entre différentes tables et augmenter les chances que l'optimiseur utilise la vue matérialisée...

[orafrance]

comme ce serait bien d'un un tutoriel sur le datawarehousing

[Hugues_78]

J'essaierais de m'y pencher quand j'aurais du temps... Mais les journées sont trop courtes...
Ca fait un an que je dois passer le 1z-32/33 et j'ai du mal à trouver le temps... (à chaque fois, il faut 2 jours pour bachoter + la journée de passage)

[nuke_y]

Certes mais j'en reviens à ce que je disais : la requête qui utilise la VM utilise des données mises à jour depuis un certain temps. C'est tout à fait praticable dans le décisionnel mais il faut en avoir conscience.

Si je viens de faire une mise à jour dans les tables de faits (par exemple insertion d'une donnée) et que l'optimiseur d'Oracle s'obstine à me ressortir des données vieilles d'une heure sans me demander mon avis, je peux chercher un moment avant de comprendre.

Ce que je ne comprend pas (trop) c'est l'intérêt du query rewriting. Si on fait une VM, on requête sur la VM et pas sur la table et c'est tout, non ? Les seuls cas où je vois un intérêt c'est quand l'utilisation d'une VM plutôt que la table doit être transparente pour l'utilisateur et là on tombe dans le problème des données obsolètes.

[Hugues_78]

Pour les problèmes d'intégrités et de cohérence de données, il y a le paramétre query_rewrite_integrity qui peut autoriser le rewrite que si les données sont à jour.

Si tu programme en PL/SQL, effectivement, tu fait ta requête sur la vue matérialisée.

Par contre, si tu utilises un outils d'analyse de données (discoverer ou business object ou...), tu va configurer tes tables, jointures, etc... dans le module d'administration (ou créer un univers...).

L'utilisateur va voir des "dossiers" (ventes, articles, clients...) dans lequel il va piocher. A aucun moment il n'a de jointure à réaliser (car déjà fait coté admin). S'il ne peut pas prendre un élément (parcequ'il n'y a pas de jointure qui existe), le dossier sera grisé.

Il n'a pas a se poser la question d'utiliser la table ou la vue matérialisée. Il veut les ventes, c'est tout.
Il ne doit pas perdre son temps à se poser la question d'utiliser la vue matérialisée numéro 8 : il n'est pas payé pour ça, c'est risque d'erreur...

Le dernier avantage, c'est que c'est un objet "global". Si à un instant T, je crée une vue, tous mes traitements vont en profiter sans avoir à toucher au code. Il y a quelques mois, j'ai divisé par 3 un traitement de nuit sans avoir à toucher à une seule ligne de PL/SQL. C'est un peu comme quand on crée un index.

[nuke_y]

Avec le paramètre query_rewrite_integrity ok, je ne l'avais pas vu dans les docs.