Réplication de données avec DBLINK sur Oracle XE

Bonjour à tous,

Voilà, j’ai installé Oracle Express sur 2 serveurs :
 1 serveur A en production
 1 serveur B pour la réplication de donnée
J’aimerai faire de la redondance de donnée synchrone du serveur A vers le serveur B.
On ne peut pas faire de STREAM avec Oracle Express, c’est pour cela que j’aimerai utiliser des vues matérialisé.
Après avoir créé mon DBLINK sur mon serveur B, j’aimerai créer une vue matérialisé de ce type :

Code:

---

1 2 3 4 5

CREATE MATERIALIZED VIEW MV_GAMME_SUIVI_DM USING INDEX REFRESH ON COMMIT FAST DISABLE QUERY REWRITE AS SELECT * FROM GAMME_SUIVI_DM@LINK_BTRCR_NHB

---

Impossible de créer cette vue matérialisée, j’ai une erreur

Citation:

---

ORA 12054 « cannot set the ON COMMIT refresh attribute for the materialized view”

---

Je n’ai pas cette erreur si je change ON COMMIT par ON DEMAND.

Si quelqu’un à une solution je suis preneur :D

Merci !

Premier lien google : http://www.dba-oracle.com/t_ora_1205...lized_view.htm

Et sur ce forum : http://www.developpez.net/forums/d15...resh-attribut/

Bonne lecture :)

:recherch:

A priori on ne peut pas faire de ON COMMIT sur une vue matérialisé qui contient un DBLINK ..
Il y a-t-il une parade à ça ??

Merci 8-)

Du ON DEMAND avec des schedule fréquent ou une vue.

Le problème du ON DEMAND avec des schedule fréquent est que je n'ai pas un rafraîchissement instantané de mes données et le problème de la vue est que je n'est pas ces données physiquement dans mon serveurs redondant.

Dataguard en Manuel, déclarer la base sur le serveur B en standby et envoyer les archvielog et les faire appliquer ensuite.

voir ce tutoriel : http://www.arkzoyd.com/2012/07/06/mi...itory/?lang=fr

Citation:

---

Envoyé par Damien.020

Le problème du ON DEMAND avec des schedule fréquent est que je n'ai pas un rafraîchissement instantané de mes données et le problème de la vue est que je n'est pas ces données physiquement dans mon serveurs redondant.

---

Tu peux faire des tables dans ce cas qui seront alimentés par un trigger sur les tables à répliquer. Mais moi j'aime pas ajouter un risque sur des données juste pour répliquer.

J'ai au final fait des vues matérialisées avec des rafraichissement toutes les 30s, ça marche plutôt bien à part que ... Ma table grossi sur mon serveur en production et le rafraichissement des vues sont de plus en plus longue !!
J'imagine pas dans quelques mois ...

Savez vous si je peux gérer les STREAMS sur un serveur A avec une licence (standard ou entreprise) vers un serveur B en Oracle XE ?

merci ;)

Si tu as quelques tables à répliquer, t'as pas besoins de configurer streams ou data guard,
-Tu créer un dblink dans le schema, qui hébergera la materialized view contenant la table de la base source à répliquer
-Tu créé un journal de vue matérialisé (create materialized view log on nom_table) dans le schema, qui contient la table source
à répliquer, (serveur A)
-Sur le serveur B, la base cible, tu accorde les privileges : grant on commit refresh to nom_schema (serveur B), et
grant select on schema.nom_table_log@dblink to nom_schema(serveur B), afin qu'il puisse lire dans le journal de vue
materialisé (nom_table_log) les modif dans la table source .
- et pour finir, tu rééxécute ton code avec refresh on commit, et chaque fois une activité transactionnel sur la table source
est éffectuée, ta vue materialisé est jour en TEMP REEL !

Merci de ta réponse !

Malheureusement .. Je crains que je ne puisse pas créer de LOG de vue matérialisée sur un Oracle Express Edition :(

J'ai ce paramètre :

Code:

---

1 2 3

PARAMETER VALUE ---------------------------------------------------------------- ---------------------------------------------------------------- Materialized view rewrite FALSE

---

Bonjour,

Les tables ne grossiront pas plus que 11GB vu la limitation en XE.

Sinon pourquoi pas la solution des triggers ? ou alors répliquer directement au niveau de l'appli ...

Pour la limite de 11Go ce n'est pas un problème puisque nous purgeons les données tout les 6 mois, je ne dépasse pas les 4Go.

Concernant les triggers, je trouve la solution un peu "lourde", et si j'ai un problème sur mon trigger, je risque de perdre ma donnée ... 8O

Répliquer au niveau de l'appli ? c'est à dire ?

Merci ;)