Replication de donnée et table mutante

[kramer Mc Barreth]

Bonjour,

J'ai sur mes tables un trigger pour l'auto_increment:

Code :

1
2
3
4
5
6
7
CREATE   SEQUENCE SEQ_C_PORT		INCREMENT BY 1 START WITH 1 NOMAXVALUE NOCYCLE CACHE 10;
 
CREATE   TRIGGER TRIG_C_PORT BEFORE INSERT ON C_PORTFOLIO FOR EACH ROW 
	BEGIN
		SELECT SEQ_C_PORT.NEXTVAL INTO :NEW.C_PORT_CODE FROM DUAL;
	END;
/

Et un trigger de replication:

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
CREATE TRIGGER REPLIC_C_PORT BEFORE UPDATE OR INSERT ON C_PORT
FOR EACH ROW
BEGIN
INSERT INTO C_PORT@HISTO.ORDI5 
	(PORT_CODE, 
	PORT_NAME, 
	PORT_CURRENCY, 
	CLIENT_TEL, 
	CLIENT_CODE)
	VALUES 
	(:NEW.PORT_CODE, :NEW.PORT_NAME, :NEW.PORT_CURRENCY, :NEW.CLIENT_TEL, :NEW.CLIENT_CODE);
END;
/

L'enchainement de ces deux triggers provoquent une erreur de table mutante venant du trigger de replication (le deuxieme).

Existe t'il un moyen de passer outre ce probleme ?
S'agit il d'un mauvais emploi de :NEW ?
Le but etant d'avoir deux base totalement synchronisées, existe t'il un autre moyen d'effectuer cela ?

[orafrance]

pourquoi ne pas utiliser une vue matérialisée ?

[kramer Mc Barreth]

parceque je ne sais pas comment faire...
je me renseigne, mais si tu as le temp de m'en dire un peu plus...

[Michel SALAIS]

Indémndamment du problème, si l'application est modifiable alors il faut enlever le premier trigger et utiliser la séquence dans l'application directement. D'un autre côté, le deuxième trigger doit être after et non before.

[orafrance]

Envoyé par Michel SALAIS

D'un autre côté, le deuxième trigger doit être after et non before.

ha oui, en effet

[kramer Mc Barreth]

Meme avec le deuxieme trigger en AFTER, ca provoque une erreur de table mutante...

[orafrance]

c'est pas le DBLink qui serait erroné par hasard ? Parce que là ça réagit comme si C_PORTFOLIO@HISTOVOT.HEGOA5 et C_PORTFOLIO étaient les mêmes tables

[kramer Mc Barreth]

Merci beaucoup.
En fait tu m'as fais remarqué que dans mon script de creation de la table histovot, j'avais laissé les triggers de replication...

Shame on me shame on me

------------

Autre question:
Existe t'il des outils de developpement gratuits pour oracle avec une interface graphique ??
Parceque passer sans cesse d'un editeur de texte a la ligne de commande me provoque souvent de erreurs du genre de celle ci...

[orafrance]

non, pas d'éditeur graphique au sens AGL. Pour revenir au souci, je persiste à t'encourager à te documenter sur les vues matérialisées (materialized view ou snapshot).

[kramer Mc Barreth]

oui c'est ce que je fais mais les courts temps de developpement qui me sont imposé me forcent parfois a prendre des solutions batardes mais qui marche au niveau de mon patron (qui, comme beaucoup de patrons y connais rien et se fout que ce soit mal foutu du moment que ca marche)...

Quelques questions sur les vues materialisées.
J'ai compris que l'on peut synchroniser la vue au commit de la table observée.
Mais comment au meme moment deverser les données de la vue dans ma base distante ?
Avec un trigger sur la vue ?

[orafrance]

Si ta base distante à besoin d'être mise à jour ça commence à devenir plus compliqué que ta méthode. Sinon, tu remplaces la table distante par la vue matérialisée

c'est de la réplication bi-directionnelle ? (modification de la table distante répliqué en local aussi ?)

[kramer Mc Barreth]

non, il s'agit d'un replication uni-directionnelle...
En fait la base distante est une base historique devant etre identique a la base de production, elle ne seras pas mise a jour directement, si ce n'est par mes triggers de replication.

Au sujet des vues, j'ai lu qu'il fallait les utiliser avec parcimonie.
Sachant que j'ai une 15 aine de tables a repliquer est ce judicieux d'utiliser cette methode ?
Sinon, pourrais tu me donner un morceau de code pour comprendre se remplacement et quand le declencher ...

[orafrance]

http://www.developpez.net/forums/d25258/bases-donnees/oracle/commit-on-refresh/

j'vois pas pourquoi faudrait limiter leur usage

t'as rien à faire d'autre que supprimer ta table historique et créer la vue matérialisée à la place avec l'option REFRESH ON COMMIT pour qu'elle soit mise à jour à chaque modif de la source.

[kramer Mc Barreth]

le probleme viens du client en lui meme qui n'y connais pas grand chose mais veux absoluement une vraie base historique distante.
Comme il y connais rien, je pense qu'il seras pas d'accord d'avoir une vue materialisée. il ne jure que par les base de bonnées....
( je sais c'est con ta methode as l'air au point)

[orafrance]

sauf que c'est une vraie base de données. Une vue matérialisée c'est une table (contrairement à ce que le nom indique ) qui stocke physiquement le résultat d'une requête (la vue) obtenu soit au commit de la source soit à la demande soit à interval régulier. Contrairement à une vue qui ne stocke que la requête et la réexécute à chaque appelle à la vue.

vue matérialisée = vue contenant les données = table qui a en plus des propriétés de réplication

est-ce plus clair ?

[kramer Mc Barreth]

oui pour moi ca l'est maintenant.
Mais expliquer ca a un responsable de service qui ne veux pas perdre la face et avouer qu'il nage plus que es subalternes, c'est totalement impossible.
P'tain je deteste la politique d'entreprise !!
Mais merci, ca me serviras dans mes futurs developpement.

[orafrance]

tu lui dis rien sur la technique puisque de toute façon c'est pas son problème. Tu dis juste que tu as répondu au besoin au mieux

[Michel SALAIS]

Ca sort peut-être du cadre de la question mais il y a d'autres solutions valables comme par exemple l'utilisation des bases standby (éventuellement logiques)

[orafrance]

malheureusement, les standby logique avant la 10g c'est plus l'arlésienne qu'autre chose

quand à la standby physique, ici il parle de 15 tables à répliquer, ça parait donc une peu cher comme solution

[Michel SALAIS]

Envoyé par orafrance

malheureusement, les standby logique avant la 10g c'est plus l'arlésienne qu'autre chose

quand à la standby physique, ici il parle de 15 tables à répliquer, ça parait donc une peu cher comme solution

En fait, nous avons peu d'éléments permettant d'en décider ...
Les 15 tables sont peut être toute sa base. La deuxième base dans laquelle nous répliqons possède-t-elle d'autres tables? Quelle est l'objectif de la réplication? C'est la protection? C'est la consultation à part? N'oublions pas que de toute façon, il y a déjà deux bases actuellement

Une phrase laissait entendre que les deux bases doivent être identiques ...