Réplication de table sur un serveur "isolé"

[neo.51]

Bonjour,

Je suis confronté à un problème un peu particulier :
J'ai un serveur A qui est dans une DMZ et les administrateurs ne veulent pas que le serveur A puisse accéder au serveur B par SQLNET (problème de sécurité).
J'ai un serveur B central qui lui peut accéder à A via tns(on l'appellera tnsA). Il dispose donc d'un dblink (qu'on appellera dblinA).

Je veux que B replique une table sur A. Mais la table répliqué sur A n'est jamais modifié et la table sur B n'a pas besoin d'être fréquement mise à jours (genre une fois par jour).

Bon pour ceux qui suivent c'est B qui doit faire tout le boulot au travers de dblinkA.

Ce que je voulais faire, c'est virer la table sur A au travers de dblinkA et copier la table de B vers A au travers de dblinkA. ça donnait en gros :

Code :

1
2
TRUNCATE TABLE matable@dblinkA
INSERT INTO matable@dblinkA SELECT * FROM matable

C'est ultra bourrin mais mes besoins de réplication sont trés modeste : virer la table de A et la remplacer par celle de B une fois par jours.

Le soucis c'est que

Code :

1
2
TRUNCATE TABLE matable@dblinkA
ORA-02021: opérations DDL non autorisées pour base de données distante

et

Code :

1
2
3
4
 
INSERT INTO matable@dblinkA SELECT * FROM matable
ORA-22804: opérations distantes interdites sur des TABLES objet ou sur des
colonnes de type défini par l'utilisateur

Alors à votre avis comment procéder ?

[orafrance]

à la place de TRUNCATE tu fais DELETE... bien entendu, ça supprime les bénéfices du TRUNCATE : pas de conso de UNDO, instantanée, etc...

[neo.51]

Merci pour la réponse mais je viens de mettre à jours le post j'ai aussi un pb sur le insert

[orafrance]

si t'as des LOB en effet ça ne peut pas fontionner

Tu as 2 solutions Streams (elle est où la version ? ) ou la commande COPY de SQL*Plus

[neo.51]

Pas de lob mais un champ SDO GEOMETRY

Version 10.2.0.1 dsl

[orafrance]

c'est la même cochonerie

regarde du coté de streams

[neo.51]

bon copy ça passe pas non plus donc reste les streams mais bon ça semble TRES compliqué à mettre en place. Si vous avez des how to je suis prenneur

merci en tous cas

[orafrance]

avec la DB console ça se fait bien

[neo.51]

wai mais bon le client aime pas la dbconsole enfin bref je regarde les stream mais je suis tourjours preunneur pour une solutions plus simple

[pifor]

L'utilisation du Data Pump avec l'option network_link semble séduisante mais ne supporte pas "les types évolués" .

Vous pouvez vous rabattre sur le Data Pump avec un simple fichier que vous pouvez transférer avec le package DBMS_FILE_TRANSFER qui peut utiliser les database links.

Si la table est volumineuse, vous pouvez aussi envisager de l'isoler dans un tablespace spécifique et de transporter le tablespace avec RMAN (sans RMAN, il faudra qu'à un moment donné, avant le transfert du tablespace, il n'y a aucune transaction en cours sur la base source).