Réplication Vs Schémas de Vue matérialisé

Bonjour,
d'abord ceci est pour l'instant une question théorique, il n'est pas question de la mettre en oeuvre dans l'année qui vient , donc vous n'aurez pas de retour avant longtemps :aie:

Le cas :

Aujourd'hui, une base Oracle est mis à jour pendant le nuit via un fichier et sql server, quand la maj est terminé, certains des schemas sont répliqués sur un deuxième serveur.
Les deux serveurs ne sont pas attaqués par les même applications.

Inconvenient : en dehors des problèmes techniques dut à la maj (mauvais fichier) ou à la réplication (problème avec)
1) On n'est oblige pour des raisons de réplications de droits d'avoir certains schemas sur le serveur 1 qui ne servent que sur le 2
2) surtout, on n'a besoin ni de l'intégralité des données sur le serveur 2, ni de la totalité des tables

Question : serait-il intéressant (et possible) de construire sur le serveur 2 un schema de vue matérialisé (ce qui permettrait un tri aisé de donnée mais aussi de tables) prenant leur source sur le serveur 1 ?


Merci

Citation:

---

Envoyé par Erwy

Bonjour,
Question : serait-il intéressant (et possible) de construire sur le serveur 2 un schema de vue matérialisé (ce qui permettrait un tri aisé de donnée mais aussi de tables) prenant leur source sur le serveur 1 ?

---

oui! :mouarf:

J'aurais aimé plus de détail mais bon... :roll:


Autres Questions :
ma plus grosse table, qui est aussi celle qui est le plus maj,fait 30 colonnes ,de 1 à 10 caractères, pour un total de 131 caractères + 3 date + 3 timestamp
sur le serveur 1 environ 2000000 enregistrements la vue serait à peu près de 300000 .
je n'ai pas les caractéristiques physiques des serveurs(qui sont sur la même baie) mais est ce que quelqu'un à une idée du temps de maj ?( secondes minutes heures ?) Est ce qu'il serait profitable pour un volume de donnée de ce type que je supprime d'abord les indexes avant de faire la maj de la vue ou est ce que je peux m'en passer ?

J'ai aussi quelques tables plus petites et bien moins souvent mis à jour mais qui contiennent des NCLOB est-ce que je dois m'attendre à des surprises ? (ce n'est ^pas ce qui m'a manqué jusqu'ici avec ce type...)

Les vues matérialisées sont adpatées pour faire de la réplication différentielle et conditionelle.

Le principe est que tu crée des journeaux sur ta base maitre dont le role sera de loguer toutes les lignes modifiées.

Il y aura un journal (materialized view log) par table répliquée.

A la création, ou à la demande, il y aura un refresh "complet", c'est à dire l'exécution bete et méchante de la requête qui définie ta vue matérialisée. Et au fil de l'eau, il y aura des refresh 'FAST', c'est à dire requêtes différentielles qui, en se basant sur les mview-log, ne feront transiter que les donnée ayant changés.

Evidement, il y a quelques contraintes pour que ce système fonctionne, en particulier sur le filtrage qui doit être soit sur une colonne simple, soit par référence à une autre table mais à base de "EXIST" basés sur les clef primaires.

C'est un système qui existe depuis la nuit des temps mais que je trouve toujours très efficace.

Lorsque tout est bien mis en place, tu peux te permettre de faire des rafraichissment très fréquents, c'est complètement indolore.

A, ma connaissance, les NCLOB devraient fonctionner, mais à vérifier....

Merci beaucoup pour le complément d'information :D