Discussion :

[dyvim]

Bonjour,

Je me posais une question. Je travaille sur un systeme de facturation basé sur une base Oracle (sur serveur Unix).
Dans le processus de facturation il existe un process qui migre des clients d'une méthode de facturation à une autre.
Ce process est un shell script.
Chaque mois, s'il y a des clients à migrer le script est lancé (donc presque tous les mois).

La première opération de ce script est de créer une table temporaire et de la remplir. Les données changeant de mois en mois, la table est à chaque fois supprimée et reconstruite. Cette table est ensuite utilisée pour le processus de migration.

J'ai la possibilité de mettre les informations que contient cette table dans une Vue. Cette vue sera mise à jour dynamiquement sans effort et donc plus besoins de droper et de recréer la table.

Je sais que je gagne du temps la dessus... 8)
Mais après cela des requetes sont jouées sur cette table/vue. Est ce que ces requetes ne risquent pas d'être plus lentes sur la vue que sur la table? (sachant quand même qu'il n'y a pas d'index sur la table)
C'est à dire, est ce que je ne risque pas de reperdre le temps gagné en construisant ma vue ??

J'ai un doute sur le sujet... Si quelqu'un pouvait éclairer ma lanterne...

[McM]

Pourquoi DROPPER une table pour la reconstruire, un TRUNCATE/INSERT n'irait pas ?
Ensuite si tu as des requetes à passer sur ta TABLE/VUE (SELECT uniquement je suppose), tout dépend de ta vue et du nombre de lignes.

Je préfère l'insertion dans une table non temporaire que je truncate.
Si l'insertion est longue, ensuite tout est beaucoup plus rapide.

Tout ça dépend de tes volumétries.

[dyvim]

Pourquoi DROPPER une table pour la reconstruire, un TRUNCATE/INSERT n'irait pas ?

Oui, j'ai cette possibilité là aussi.

Ensuite si tu as des requetes à passer sur ta TABLE/VUE (SELECT uniquement je suppose), tout dépend de ta vue et du nombre de lignes.

Cette vue contient environ 400 lignes et elle est basée sur plusieurs tables. Ce qui je le pense va rendre mes select plus long que s'ils étaient basés sur une table de 400 lignes (même sans index)

Je préfère l'insertion dans une table non temporaire que je truncate. Si l'insertion est longue, ensuite tout est beaucoup plus rapide.
Tout ça dépend de tes volumétries.

Je vais opter pour cette solution là aussi.

Merci pour ton avis éclairé.

[McM]

C'est un traitement mensuel sur 400 lignes que tu cherches à optimiser ?

Tu vas pas gagner beaucoup.

[dyvim]

Tu as raison...

Mais pour des raisons de simplification je n'ai pas précisé qu'il y avait 8 tables comme celle ci et que certaines comptaient beaucoup plus de lignes...

[bpprive]

Mais pour des raisons de simplification je n'ai pas précisé qu'il y avait 8 tables comme celle ci et que certaines comptaient beaucoup plus de lignes...

Personnellement, je ne considère pas ça comme une simplification mais une complication. C'est une information importante de savoir d'où provient ton information et la charge qu'il faut prévoir pour extraire l'information.

Personnellement, je préfère travailler avec des vues. Moins de gestion d'espace disque qu'avec une table. Tout le travail que la BD doit se tapper alors que dans une vue, il s'agit d'une simple exécution d'un SÉLECT. Et avant de freaker que ce ne sera pas performant, il faut l'essayer et optimiser un peu le SELECT de la vue. Et dans le cas ouè ce n'est vriament pas performant (c'est à dire que ça ne répond pas à TON besoin de performance, et non pas que c'est pas performant), tu as toujours l'option de matérialiser ta vue, alors ça répondra comme une table ordinaire. De plus, quand ton traitement doit repartir le mois d'après, un simple REFRESH et le tour est joué.

Pour moi, une table, ça stock de l'information permanente. Sinon, si c'est de l'information transiante (session, panier d'achat, etc.) : global temporary. Pour tout autre besoin : vue ou vue matérialisé.

[dyvim]

Personnellement, je ne considère pas ça comme une simplification mais une complication. C'est une information importante de savoir d'où provient ton information et la charge qu'il faut prévoir pour extraire l'information.

Oui ca se discute... Je pensais que cela rendrait la chose moins lourde à lire aussi...

Personnellement, je préfère travailler avec des vues. Moins de gestion d'espace disque qu'avec une table. Tout le travail que la BD doit se tapper alors que dans une vue, il s'agit d'une simple exécution d'un SÉLECT. Et avant de freaker que ce ne sera pas performant, il faut l'essayer et optimiser un peu le SELECT de la vue. Et dans le cas ou ce n'est vriament pas performant (c'est à dire que ça ne répond pas à TON besoin de performance, et non pas que c'est pas performant), tu as toujours l'option de matérialiser ta vue, alors ça répondra comme une table ordinaire. De plus, quand ton traitement doit repartir le mois d'après, un simple REFRESH et le tour est joué.

Alors là je vais faire mon débutant... Mais je suis vivement interessé et même enthousiaste .
Comment est ce que l'on fait celà ?? (matérialiser et rafraichir une vue matérialisée)
Est il possible de matérialiser une vue temporairement ?? (matérialiser puis dématérialiser puis...) :

Pour moi, une table, ça stocke de l'information permanente. Sinon, si c'est de l'information transiante (session, panier d'achat, etc.) : global temporary. Pour tout autre besoin : vue ou vue matérialisé.

Je suis assez d'accord avec le concept...

[bpprive]

Petite précision. On ne peut matérialiser ou dématérialiser une vue. En réalité, une vue est une vue et une vue matérialisé est une vue matérialisé, ce sont deux types d'objets bien distincts dans ORACLE.

On commence souvent par une vue et si le traitement ne réponds pas assez rapidement, on cherche d'autres solutions. Une de ces solutions est de faire un "snapshot" (une photo) des données sur lesquelles on veut travailler. On prend tout simplement le script de la vue et on rajoute la clause materialized et la fréquence de refresh et c'est pas mal tout. Ça crée donc un deuxième objet de type vue matérialisée. L'Ancienne vue demeure présente et valide, on peut même la supprimer.

Alors petit briefing :

• 1. Ça te prend le droit d'en créer (create materialized view)
  2. Ça te prend les droits sur les tables (en select) auxquelles tu désires faire le SELECT
  3. Ça te prends des quotas d'espaces suffisants dans le tablespace dans lequel la vue va se créer (faut pas oublier qu'une vue matérialisée est écrite sur le disque)
  4. Tu définis la fréquence de refresh que tu veux, le défaut est sur demande! Tu utilises le package DBMS_MVIEW pour la refraichir quant tu veux. Tu peux aussi spécifier un intervale de temps auquel elle va se rafraîchir automatiquement.

Oracle fournit également de la doc :
http://download-east.oracle.com/docs...2.htm#i2063793

[dyvim]

Petite précision. On ne peut matérialiser ou dématérialiser une vue. En réalité, une vue est une vue et une vue matérialisé est une vue matérialisé, ce sont deux types d'objets bien distincts dans ORACLE.

Ah tant pis pour moi... Ce n'était qu'un joli rêve...

On commence souvent par une vue et si le traitement ne réponds pas assez rapidement, on cherche d'autres solutions. Une de ces solutions est de faire un "snapshot" (une photo) des données sur lesquelles on veut travailler. On prend tout simplement le script de la vue et on rajoute la clause materialized et la fréquence de refresh et c'est pas mal tout. Ça crée donc un deuxième objet de type vue matérialisée. L'Ancienne vue demeure présente et valide, on peut même la supprimer.

Ah l'interêt alors c'est d'avoir une "table" qui rafraichit ses données toute seule...
Sinon, ça ne pose pas de probleme d'avoir 2 objets de même nom?

Question: à partir de quelle version d'Oracle est ce que cette fonctionalité est disponible?

[bpprive]

Ah l'interêt alors c'est d'avoir une "table" qui rafraichit ses données toute seule...
Sinon, ça ne pose pas de probleme d'avoir 2 objets de même nom?

En langage très simple, dans le but de ton traitement, ça ressemble à ça. En réalité, il y a un tas de différences qui différencient ces deux types d'objets.

Les deux objets n'auront pas le même nom. La vue matérialisée devra porter un autre nom, ou un nom dérivé. Bref la vue créée en second ne peut porter un nom utilisé ailleurs dans le schéma, peu importe le type d'objet.

Pour la disponibilité de cette commande, je peux pas te répondre, mais je sais que ça existe depuis 9i rel1 c'est sur.

[plabrevo]

Je ne suis pas sur d'etre d'accord sur tout ce qui est ecrit dans ce post.

En ce qui concerne la difference de performance entre un acces a travers une vue (requete A) ou a travers une table (requete B), c'est le temps qu'il faut pour le noyau pour transformer A en B. L'overhead est tres, tres, (tres!) negligeable.
Le principal interet des vues c'est de masquer l'implementation physique pour raisons multiples et variees, pas d'influer sur les performances.

[bpprive]

Je suis d'accord avec toi.

C'est vrai que table de 400 lignes et une vue basée sur une table de 400 lignes, l'overhead est très négligeable et la performance presqu,exacte.

Par contre, le cas de dyvim est que la vue serait basée sur 8 tables de plusieurs milliers de lignes. D'où la suggestion de vues matérialisées.

Il est certain que la charge "refresh de la vue + traitement" va drolement ressembler à "pré-alimentation de la table + traitement".

Je me suis mal exprimé.

[plabrevo]

Hum... 8 tables en jointure et quelques milliers de lignes, ca me semble etre assez courant et toujours dans du petit volume.

Je reconnais que dans certains cas particuliers, les MVs peuvent apporter une solution a des problemes de performance, mais leur usage a des avantages et des inconvenients. Il faut en tout cas resister a la tentation de les utiliser pour masquer une faiblesse du datamodel ou du design.

[bpprive]

100% en accord

[dyvim]

Je vais essayer d'être plus précis pour que vous voyez mieux la question que je me pose...

L'objectif du process (le shell script en l'occurence) est de créer des fichiers (ces fichiers seront ensuite réinjectés dans la base mais c'est une autre histoire)...

Pour créer ces fichiers le script détruit, recrée et remplit tout les mois un certain nombre de tables temporaires (qui contiennent à peu de choses près les données qui iront dans les fichiers). Les données stockées dans ces tables temporaires proviennent de plusieurs autres tables qui peuvent éventuellement contenir des millions de lignes et en tout cas des milliers le plus souvent.

Mon objectif était de gagner du temps. Je pensais le faire en transformant ces tables temporaires en vues ce qui éviterait de les recréer et les mettra à jour automatiquement.

Mon souci est qu'ensuite un select est joué sur chacune ces tables pour constituer les fichiers un par un...
Voici un exemple type de select

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
select                                                                            
substr (rpad (nvl (replace(trim(record_type),' ','='),'='),1,'='),1,1),           
substr (rpad (nvl (replace(trim(custcode),' ','='),'='),10,'='),1,10),            
substr (rpad (nvl (replace(trim(usernbr),' ','='),'='),8,'='),1,8),               
substr (rpad (nvl (replace(trim(username),' ','='),'='),25,'='),1,25),            
substr (rpad (nvl (replace(trim(custname),' ','='),'='),25,'='),1,25),            
substr (rpad (nvl (replace(trim(nwcode),' ','='),'='),4,'='),1,4),                
...            
substr (rpad (nvl (replace(trim(todate),' ','='),'='),10,'='),1,10),              
$rfs_date,                                                                        
substr (rpad (nvl (replace(trim(billdate),' ','='),'='),10,'='),1,10),            
substr (rpad (nvl (replace(trim(stopdate),' ','='),'='),10,'='),1,10),            
...       
substr (rpad (nvl (replace(trim(COUNTRY_NAME),' ','='),'='), 35,'='),1, 35),      
substr (rpad (nvl (trim(semicolon),'='),1,'='),1,1)                               
from TEMP_FR_011 ; -- avec eventuellement des clauses where pour filtrer

Ma question était donc: Est ce que je ne vais pas reperdre le temps gagné à ne pas reconstruire (recréer et reremplir) la table temporaire en effectuant mes select sur des vues plutôt que sur des tables? Voire même est ce que je ne vais pas en perdre?

Je pense que la différence entre des tables temporaires et des vues matérialisées va être minime en terme de performances si ce n'est que je pourrais automatiser le refresh tous les mois eventuellement...

L'idéal selon moi aurait quand même été des vues non matérialisées (pas de place ni de traces dans la base)mais j'ai bien peur d'y perdre en performances...

[Pomalaix]

Bonjour

J'ai beau relire la présentation initiale et les explications complémentaires, je ne parviens pas à comprendre le but recherché.

Une préextraction ou un précalcul n'a d'intérêt que si le résultat est utilisé plusieurs fois. Si votre traitement ne manipule un même ensemble de données qu'une seule fois, alors il y a toutes les chances que vos tables intermédiaires (une table temporaire, au sens Oracle, c'est autre chose) ou des vues matérialisées ne vous apportent aucun gain.

De plus, si ce traitement de masse ne tourne qu'une fois par mois, il n'est sans doute pas nécessaire qu'il réponde instantanément, je suppose.
Mais s'il doit réellement être optimisé, il est probable que l'aspect à améliorer soit la formulation des requêtes, plutôt que de s'orienter vers des stockages intermédiaires à usage unique.

En effet, votre optique actuelle, si je l'ai bien comprise (ce qui est loin d'être gagné) consiste non pas à réduire réellement le temps du traitement global, mais à le découper en plusieurs phases dont la dernière paraîtra plus courte, du fait qu'elle s'appuiera sur des données prémâchées.

[dyvim]

Une préextraction ou un précalcul n'a d'intérêt que si le résultat est utilisé plusieurs fois. Si votre traitement ne manipule un même ensemble de données qu'une seule fois, alors il y a toutes les chances que vos tables intermédiaires (une table temporaire, au sens Oracle, c'est autre chose) ou des vues matérialisées ne vous apportent aucun gain.

Le traitement peut éventuellement avoir à être relancé (si on a constaté des erreurs dans les fichiers ou si le process a été interrompu par exemple)... Et dans ce cas on a le choix de ne pas recréer les tables temporaires.

De plus, si ce traitement de masse ne tourne qu'une fois par mois, il n'est sans doute pas nécessaire qu'il réponde instantanément, je suppose.
Mais s'il doit réellement être optimisé, il est probable que l'aspect à améliorer soit la formulation des requêtes, plutôt que de s'orienter vers des stockages intermédiaires à usage unique.

Je cherche surtout à ne pas perdre en performances.

En effet, votre optique actuelle, si je l'ai bien comprise (ce qui est loin d'être gagné) consiste non pas à réduire réellement le temps du traitement global, mais à le découper en plusieurs phases dont la dernière paraîtra plus courte, du fait qu'elle s'appuiera sur des données prémâchées.

Le traitement est déjà séparé en deux phases: la (re)création de la table temporaire et la récupération de certaines des données qu'elle contient pour les mettre dans un fichier en les reformatant un peu...
Je pense que les deux phases existent pour gagner du temps lorsqu'il faut recréer à nouveau les fichiers.