IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Administration Oracle Discussion :

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


Sujet :

Administration Oracle

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre averti
    Inscrit en
    Avril 2010
    Messages
    42
    Détails du profil
    Informations forums :
    Inscription : Avril 2010
    Messages : 42
    Par défaut 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 : Sélectionner tout - Visualiser dans une fenêtre à part
    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
    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

    Merci !

  2. #2
    Expert éminent
    Avatar de orafrance
    Profil pro
    Inscrit en
    Janvier 2004
    Messages
    15 967
    Détails du profil
    Informations personnelles :
    Âge : 48
    Localisation : France

    Informations forums :
    Inscription : Janvier 2004
    Messages : 15 967

  3. #3
    Membre averti
    Inscrit en
    Avril 2010
    Messages
    42
    Détails du profil
    Informations forums :
    Inscription : Avril 2010
    Messages : 42
    Par défaut
    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

  4. #4
    Expert éminent
    Avatar de orafrance
    Profil pro
    Inscrit en
    Janvier 2004
    Messages
    15 967
    Détails du profil
    Informations personnelles :
    Âge : 48
    Localisation : France

    Informations forums :
    Inscription : Janvier 2004
    Messages : 15 967
    Par défaut
    Du ON DEMAND avec des schedule fréquent ou une vue.

  5. #5
    Membre averti
    Inscrit en
    Avril 2010
    Messages
    42
    Détails du profil
    Informations forums :
    Inscription : Avril 2010
    Messages : 42
    Par défaut
    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.

  6. #6
    Membre habitué
    Inscrit en
    Juin 2002
    Messages
    13
    Détails du profil
    Informations forums :
    Inscription : Juin 2002
    Messages : 13
    Par défaut
    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

  7. #7
    Expert éminent
    Avatar de orafrance
    Profil pro
    Inscrit en
    Janvier 2004
    Messages
    15 967
    Détails du profil
    Informations personnelles :
    Âge : 48
    Localisation : France

    Informations forums :
    Inscription : Janvier 2004
    Messages : 15 967
    Par défaut
    Citation Envoyé par Damien.020 Voir le message
    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.

  8. #8
    Membre émérite
    Inscrit en
    Décembre 2003
    Messages
    493
    Détails du profil
    Informations forums :
    Inscription : Décembre 2003
    Messages : 493
    Par défaut
    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 ...

  9. #9
    Membre averti
    Inscrit en
    Avril 2010
    Messages
    42
    Détails du profil
    Informations forums :
    Inscription : Avril 2010
    Messages : 42
    Par défaut
    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 ...

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

    Merci

Discussions similaires

  1. Réponses: 9
    Dernier message: 16/07/2015, 14h17
  2. Réplication de données avec DBLINK
    Par Le-DOC dans le forum Administration
    Réponses: 2
    Dernier message: 10/12/2013, 15h59
  3. Réponses: 0
    Dernier message: 24/11/2008, 16h58
  4. Réponses: 5
    Dernier message: 03/04/2008, 19h02
  5. Réponses: 7
    Dernier message: 22/05/2006, 14h44

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo