Discussion :

[MAGNUM_HEAD]

Bonjour,

Os : Win2k
db : Oracle9i

J'aimerais réaliser un "clone" automatique entre deux bases de données pour une période spécifique.

En effet, l'idée est la suivante.

1 base A de production avec maximum 2 ans en ligne
1 base B de consultation à long terme avec un accès sur plus de 10 ans

Il faudrait tout les X jours alimenter la base B avec les données de "date from" à "date to" de la base A.

Ex :

Le 1 dimanche du mois : Insert de 3 mois de la base A sur la base B.

Existe-il un produit oracle ou autre qui effectue cette opération ?

Faut-il se diriger sur Database Link ou la Replication, Imp/Exp ?

Merci pour toutes vos informations,

Magnum_head

[pifor]

Les outils d'export/import sont assez limités pour ce type d'activité même si on peut exporter une liste de tables et ajouter une clause de sélection (paramètre QUERY): mais ces 2 options ne fonctionnent pas bien ensemble car il me semble que la clause QUERY est appliquée à toutes les tables exportées. L'outil d'import est aussi couteux en temps d'exécution. Vous pouvez créer des tables temporaires dans A avec CREATE TABLE AS SELECT ... qui représentent les données à archiver, exporter ces tables, les importer dans la base B, fusionner les données dans B avec INSERT INTO ... SELECT * FROM ... et à la fin supprimer les tables temporaires dans les bases A et B. Cette solution nécessite un espace important dans A et B pour les tables temporaires.

Je conseillerais d'étudier le database link ainsi que le déchargement en fichier plats (avec UTL_FILE) et le chargement avec sqlldr en mode direct si le volume est vraiment important. Je me demande s'il n'y a pas aussi une solution avec partitionnement de tables et/ou les tablespaces transportables ?

Je ne connais ni la réplication Oracle ni les solutions ETL que propose Oracle qu'il faudrait aussi étudier.

[LeoAnderson]

Si, bien sûr une solution basée sur des partitions (par exemple une partition par année) basées sur des tablespaces que l'on peut passer en read/only afin de les déplacer est le plus simple et le plus rapide mais l'on déplace année par année...

et cela nécessite la licence Enterprise.

[Pomalaix]

...on peut exporter une liste de tables et ajouter une clause de sélection (paramètre QUERY): ... la clause QUERY est appliquée à toutes les tables exportées.

Si le volume le permet, c'est la solution qui me paraît la plus simple, et que j'aurais spontanément proposée.
Reste à voir si les tables concernées ont toutes un champ DATE de même nom, qui puisse servir de critère commun.

[MAGNUM_HEAD]

Reste à voir si les tables concernées ont toutes un champ DATE de même nom

Non malheureusement.

La solution du database link pourrait être envisagé.

Par contre LeoAnderson pourrais-tu mexpliquer ton idée sur le partionnement comment mettre cela en oeuvre sur une base de donnée existente ?

Nous avons la licence enterprise.

Merci à tous,

[LeoAnderson]

Sur une base existante, en 10g EE, il suffit d'appeller le package DBMS_REDEFINITION qui, d'une table non partitionnée va la transformer en table partitionnée (et à chaud, pendant l'exploitation s'il vous plait ! )

Par exemple, vous pourrez dire que votre tables des COMMANDES sera "découpée" logiquement par ANNEE (partition by range) en répartissant chaque partition sur un tablespace dédié.

Après, vous passez les tablespaces non-courant en read-only et vous les déplacez (tablespaces transportables)

c'est très intérêssant comme solution car elle combine plusieurs techniques sympas !

[remi4444]

Etant donné que les 2 bases doivent avoir des vies différentes (car ce ne sont pas les mêmes requêtes de purge de données) Il n'y aura pas de solution toutes packagées. Donc d'une manière ou d'une autre, il va faloir faire de la programmation. Ensuite le choix dépendra des partucularités de la base.
Si tu dois traiter de tres tres gros volumes, la solution des partitions a l'air très bien.
Si tu veux un traitement plus fin il faudra passer par des requêtes à travers des dblink. La complexité de cette mise en oeuvre dépendra beaucoup de la complexité de ton applicatif.

Par exemple:
- Est-ce que les données sont seulement insérées ou peuvent-elles être updatées ou supprimées (en dehors des purges).
- Est-ce qu'il peu y avoir des suppressions de lignes dans des tables de références ce qui pourrait poser des problèmes de consistance des données dans des tables d'historique
- ... etc...

Il y a quelques petits trucs que tu peux utiliser pour simplifier la vie:
- faire une table contenant le nom des tables a répliquer ainsi que le nom colonnes DATE afin de faire du SQL dynamique
- tenir à jour une table contenant les dates des dernières mises à jour
- créer des snapshot-logs sur les tables de prod afin de s'en servir de base pour faire de la réplication différentielle (très pratique).