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.

[docr1]

En fait, la base dupliqué est seulement pour un acces en lecture seul,
Aucune modification n'y est apporté mise a part celle faite par la base principale.

[docr1]

Dans le cas, ou j'utiliserai deux serveurs sous windows, pour utiliser l méthode stand-by, il faut:
- faire un backup total de la BD1 vers le second serveur
- activer archivelog de la BD1 et les envoyer sur la BD2
- pendant le jour, je place la BD2 en lecture seul et je met a jour la BD2 chaque soir avec les archiveslog envoyes par la BD1
-ensuite je la repasse en lecture seul.

En gros, ca peut fonctionner comme cela?

[NGasparotto]

Dans le cas, ou j'utiliserai deux serveurs sous windows, pour utiliser l méthode stand-by, il faut:
- faire un backup total de la BD1 vers le second serveur
- activer archivelog de la BD1 et les envoyer sur la BD2
- pendant le jour, je place la BD2 en lecture seul et je met a jour la BD2 chaque soir avec les archiveslog envoyes par la BD1
-ensuite je la repasse en lecture seul.

En gros, ca peut fonctionner comme cela?

Oui. C'est de loin la méthode la plus simple pour faire une base de reporting.
1. Mode archivelog
2. Créer un controlfile de standby, ajouter une destination aux fichiers d'archives
3. Copie (à chaud ou à froid) les datafiles vers la destination
4. Mise en mode recovery de la standby (nuit)
5. Mise en lecture seule de la standby (jour), la production continuant à envoyer ces archives.
PS : pour le mode lecture, la base a besoin d'un tablespace temporaire, ne donc pas oublier de créer un tablespace temp sur la standby avant ouverture en lecture seule aux utilisateurs (quelques oublis de ce côté là dans la doc 8i...).

Nicolas.

[Harry Potter]

Dans le cas ou les deux bases sont sur le même os oui, mais justement il me semble que dans le cas dont on parle, il y a une base sour Windows et l'autre sous Linux.
dans ce cas, étant donné que la seconde base est en lecture seule, je conseille de faire une base de snapshot sur la base "cible", avec un database link pointant vers la base source sur laquelle on aura crée des snapshots logs dans un tablespace réservé de manière à pouvoir rafraîchir la base cible en mode fast grâce à un groupe de refresh snapshot.
Ca marche et ça permet de fonctionner avec des environnements hétérogènes.

[NGasparotto]

Dans le cas ou les deux bases sont sur le même os oui, mais justement il me semble que dans le cas dont on parle, il y a une base sour Windows et l'autre sous Linux.
...

La dernière question était

Dans le cas, ou j'utiliserai deux serveurs sous windows,[...]

Nicolas.

[docr1]

Pour pouvoir creer une base standby, est ce qu'il faut obligatoirement que les versions d'Oracle soient les mêmes ou, la base standby peut utiliser un moteur plus recent que la 8i.
Merci

[NGasparotto]

Les versions d'Oracle doivent être les mêmes.
Tu peux voir la doc : Compatibility and Operational Requirements

Nicolas.

[Wurlitzer]

Si je me souviens bien la replication se fait table par table. Cela peut etre un peu lourd a administrer. Non ?

Si la base n'est pas trop grosse le bon veil import/export est une solution rustique mais toujours efficace...

[NGasparotto]

Si je me souviens bien la replication se fait table par table. Cela peut etre un peu lourd a administrer. Non ?

Comprend pa bien la remarque. Sur quel point as-tu réagis ?

Nicolas.

[Wurlitzer]

Je réagis a la discussion en général.

Tout le monde mets en avant la réplication avec les vues matérialisées. C'est effectivement une solution élégante mais je pense qu'elle doit être lourde a mettre en place parce que selon moi il faut définir les MV une a une sur chaque table.

[NGasparotto]

Je réagis a la discussion en général.

Tout le monde mets en avant la réplication avec les vues matérialisées. C'est effectivement une solution élégante mais je pense qu'elle doit être lourde a mettre en place parce que selon moi il faut définir les MV une a une sur chaque table.

Oui, une à une. Mais tout çà peut se scripter, et aller très vite. Ensuite tu fais des groupes de vues matérialisées pour les rafraîchissements.
La où ca devient délicat à gérer, c'est au changement de version de logiciel, si des tables viennent s'ajouter, s'enlever, ou sont modifiées.
Ca demande pas mal de rigueur. Effectivement, pas évident à mettre en oeuvre, délicat à maintenir. Le mieux, le plus maintenable en tout cas, est tout même de passer via standby database.

Bon, après tout, il faut remettre la discussion dans le contexte du premier post : maintenir deux bases Oracle sur 2 OS différents (à noter la version - 8i).

Nicolas.

[Harry Potter]

Puisque l'on a deux OS différents, les snspshots apparaissent effectivement le mieux, sachant qu'il faut tout faire par script générés dynamiquement (par exemple en prenant toute les tables commençant par TAU), sachant que les snapshots logs de la base source se crée,t aussi de manière dynamique, les scripts sont un peu emmerdant à mettre en place mais une fois que c'est fait au moins on peut ajouter les tables que l'on veut dans l'archi. Idem pour les groupes de rafraîchissement.
Ca paraît lourd mais c'est robuste et une fois que l'on a planifié les jobs, ça marche bien.
Après on peut ajouter des petits plus, des scripts de recréation unitaire de snapshots ....