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.