Discussion :

[docr1]

Bonjour,

Je dois dupliquer une base oracle situé sur un serveur windows vers un serveur linux.
Sachant que les deux bases doivent etre utilisable; en fait la base sur linux doit etre une copie de la base windows a J+1.

J'aimerais avoir quelque conseil afin de mettre cela en oeuvre, car je me suis renseigné sur certaine méthode et j'ai remarque que dans certain cas le systeme d'exploitation doit être le même.

Donc si quelqu'un pouvait me diriger vers une méthode viable.

La version d'oracle est la 8i.

Merci d'avance.

[NGasparotto]

Il y aurait bien eu des possibilités comme le transport tablespace entre plateforms (mais seulement depuis la 10g), la standby database (mais seulement entre même OS)... il ne reste plus guère que le vieil export/import...
Ou bien des materialized view régénrées chaque nuits, ou bien la replication oracle :
http://download-west.oracle.com/docs...epli.htm#14855

Nicolas.

[orafrance]

il existe aussi Shareplex développé par Quest Software qui permet de faire ça. en fait il rejoue tout ce qui est dans les archives.

Sinon, les vues matérialisées peuvent effectivement t'aider

[docr1]

Si je comprend bien, les replications sont en fait une copie de ma base mais qui est mise a jour periodiquement en fonction des mises a jour effectue sur la base maitre

Est ce que ca?

Mais je n'arrive pas a voir la différence avec les vues matérialisés.

[remi4444]

Si je comprend bien, les replications sont en fait une copie de ma base mais qui est mise a jour periodiquement en fonction des mises a jour effectue sur la base maitre

Est ce que ca?

Mais je n'arrive pas a voir la différence avec les vues matérialisés.

Normal.... puisqu'il n'y en a pas!

Simplement oracle fourni quelques fonctions qui encapsulent la gestion des vues matérialisées.

Ps: Dommage que tu ne sois pas sous le meme OS, car la standby physique avec rafraichissement à J+1 était vraiment la solution idéale...

[Harry Potter]

Si tu as besoin d'aligner ta base B sur ta base A toute les nuits, tu peux utiliser des snapshots sur ta base B, qui seront rafraîchis de manière "fast" grâce à des snapshots logs présents sur ta base A.

Mais il manque dans ton besoin à savoir s'il peut y avoir des modifs sur la base B (sur Linux). Si oui, ça devient plus compliqué :

Pour répliquer tes données entre la base DB1 et DB2 tu as plusieurs solutions :
- une réplication par snapshot
- la réplication procédurale
- la réplication en utilisant l'AQ

En fait le type de réplication dépend surtout de tes bases DB1 et DB2.
Si elles sont identiques, la réplication par snapshots est l'idéale, tu crées des tables snapshots sur DB2 à partir de tes tables maîtres de DB1, des snapshots logs sur DB1 et tu schédules un rafraîchissement de tes snapshots suivant tes besoins.
Si les maj doivent se faire dans les deux sens ou que DB2 a le droit de rajouter des données à celles qui lui viennent de DB1, la réplication procédurale est sans doute la meilleure.
Enfin si tu as des tables différentes ou que la réplication doit être possible dans les deux sens (DB1 => DB2 et DB2 => DB1), alors l'utilisation de l'Advanced Queuing peut être préférable (tu gères des messages et peut ainsi gérer le côté hétérogène des tables, les deux sens de réplication et enfin les problèmes de priorité en mise à jour).

Enfin si tu migres tes bases en 10G, tu peux utiliser Oracle Streams mais c'est un peu gourmand.

Pour résumer, il faut surtout que tu définisses tes besoins des deux côté, tes sens de mise à jour.... afin de choisir l'architecture la plus adaptée.