Discussion :

[ukanoldai]

Bonjour,
je dois charger des données d'une application de production et pour le moment l'incrémentiel n'est pas possible, les tables grossissent rapidement et mon chargement s'éternise, pour l'instant je rapatrie les données via un select en passant par un dblink, existe t'il quelque chose de plus rapide?

les deux oracle sont en 9.2.0.6

merci a vous

[orafrance]

faudrait commencer par nous expliquer le besoin... tu veux faire de la réplication en temps réel ? Tu as omis de préciser la version d'Oracle aussi

[ukanoldai]

non juste un chargement de donnée journalier que j'effectue dans la nuit pour faire mes traitements hors production dans le cadre d'un datawarehouse, pour la version je ne vois pas quoi dire de plus :/

[orafrance]

j'avais pas vu la version

Utilise plutôt des vue matérialisées avec leur log pour pouvoir faire des synchros incrémentales

[Scual]

Si tu es sous 10g, tu peux aussi envisager les tablespaces transportables.

++

[ukanoldai]

ca a l'air pas mal du tout
apparement ce serait donc avec CREATE MATERIALIZED VIEW LOG

si je comprend bien il va capter et queuer les logs de modification de la table et les rejouer lors de la mise a jour de la vue?
est ce que tu as une expérience de ces materialized view log et de l'impact sur la table cible en production?

par contre j'y pense juste la mais je me demande comment il va s'en sortir si je crée ma vue sur une table attaquée en dblink, pour accéder les log, testons ca

[orafrance]

en 9i aussi

Par contre en 10gR2 il peut envisager Streams... mais il est en 9.2.0.6

[Harry Potter]

Ca ne pose pas de problèmes (et c'est même fait pour) de créer des snapshots (Materialized View) sur une base attaquée par un DBLink.
Par contre pour ta base de production, s'il y a beaucoup de mises à jour sur tes tables maîtres, les snapshot_logs (ou MATERIALIZED VIEW LOG) vont grossir assez rapidement (il faut prévoir un tablespace dédié à ces tables) et peuvent ralentir le transactionnel (chaque fois que tes tables de production sont impactées il y a création d'un tu^ple dans la table du snapshot_log correspondante).

A noter que dans ce cas le mode de rafraîchissement des snapshots (sur la base de datawarehouse) il faudra pendre le mode force (qui utilise les snapshot_logs en mode fast si possible ou sinon le mode complete qui realimente le snapshot [truncate puis alimentation]).

[orafrance]

l'overhead généré par un snapshot log est minime, je ne pense pas qu'il y a d'inquiétude à avoir

[ukanoldai]

merci de vos réponses.

j'ai regardé l'article sur downstreams http://fadace.developpez.com/oracle/downstreams/ et ils conseillent d'être en 10.2, mais est il possible d'avoir sa source en 9i et sa cible en 10.2? et cela arrange t'il les bidons? (en belsh)


parceque ca a l'air un peu magique pour tous mes imports de données oracle (reste l'informix, db2, et mssql apres )