Cette page vous affiche les différences entre la révision choisie et la version actuelle de la page.
flux_streams [2016/03/04 01:01] admin [Création des files d'attente] |
flux_streams [2016/03/14 13:40] (Version actuelle) admin [Introduction] |
||
---|---|---|---|
Ligne 1: | Ligne 1: | ||
+ | ~~ODT~~ | ||
====== Introduction ====== | ====== Introduction ====== | ||
+ | Ce document suppose une connaissance de Streams dans son principe et ses possibilités. Bien que devenue obsolète en 12c Streams peut être intéressante pour disposer simplement d'un site de réplication. Mettre en place ce type de configuration n'est pas complexe à condition d'être très rigoureux, notamment dans l'utilisation des databases link. | ||
+ | |||
L'objectif ici est de mettre en place une réplication streams bi-directionnelle entre deux bases Oracle 11gR2 nommées YODA et LUKE. Les deux bases sont sur 2 serveurs Linux distincts. | L'objectif ici est de mettre en place une réplication streams bi-directionnelle entre deux bases Oracle 11gR2 nommées YODA et LUKE. Les deux bases sont sur 2 serveurs Linux distincts. | ||
* ora01 : 192.168.56.21 -> base YODA | * ora01 : 192.168.56.21 -> base YODA | ||
Ligne 80: | Ligne 83: | ||
/ | / | ||
</code> | </code> | ||
+ | Sur YODA les données seront envoyées dans file_envoi sur YODA pour être reçues, via l propagation, dans file_reception sur LUKE. Pour la réplication LUKE -> YODA le principe est identique. | ||
====== Création des databases link ====== | ====== Création des databases link ====== | ||
- | Très important, en raison du positionement de global_names à true, les dblinks doivent avoir le même nom que la chaine Oracle*Net ( tnsnames.ora ). | + | **Très important**, en raison du positionement de global_names à true, les dblinks doivent avoir le même nom que la chaine Oracle*Net ( tnsnames.ora ). |
Depuis YODA -> LUKE | Depuis YODA -> LUKE | ||
Ligne 99: | Ligne 103: | ||
<code> | <code> | ||
begin | begin | ||
- | dbms_capture_adm.prepare_schema_instantiation( | + | dbms_capture_adm.prepare_schema_instantiation( |
- | schema_name=>'ALICE', | + | schema_name=>'ALICE', supplemental_logging => 'keys'); |
- | supplemental_logging => 'keys'); | + | |
end; | end; | ||
/ | / | ||
</code> | </code> | ||
+ | Cette action est indispensable afin d'activer pour le logminer le SUPPLEMENTAL LOGGING. | ||
====== Création des captures ====== | ====== Création des captures ====== | ||
Sur YODA | Sur YODA | ||
Ligne 137: | Ligne 141: | ||
</code> | </code> | ||
====== Création des propagations ====== | ====== Création des propagations ====== | ||
+ | Attention la définition de la propagation diffère selon le fait d'être en stand alone ou en RAC | ||
+ | ===== Bases en Stand Alone ===== | ||
Propagation de YODA -> LUKE | Propagation de YODA -> LUKE | ||
<code> | <code> | ||
Ligne 170: | Ligne 176: | ||
queue_to_queue=>false | queue_to_queue=>false | ||
); | ); | ||
+ | end; | ||
+ | / | ||
+ | </code> | ||
+ | ===== Cas des RAC ===== | ||
+ | La propagation ci-dessus est définie pour des bases stand alone, dans le cas d'une configuration RAC celle-ci doit être définie différemment. Il faut en effet activer une autre option, queue_to_queue, à la valeur TRUE ( dans le cas des stand alone cette valeur est à FALSE ). De plus il faut définir la notion d'instance primaire et secondaire au niveau des queues d'envoi. | ||
+ | |||
+ | Au cas où YODA et LUKE seraient des bases RAC, les propagations doivent avoir la forme suivante : | ||
+ | |||
+ | Propagation de YODA -> LUKE | ||
+ | <code> | ||
+ | begin | ||
+ | dbms_propagation_adm.create_propagation( | ||
+ | propagation_name=>'PROPA_TO_LUKE', | ||
+ | source_queue=>'file_envoi', | ||
+ | destination_queue=>'file_reception', | ||
+ | database_link=>'LUKE', | ||
+ | queue_to_queue=>TRUE | ||
+ | ); | ||
+ | end; | ||
+ | / | ||
+ | </code> | ||
+ | Propagation de LUKE -> YODA | ||
+ | <code> | ||
+ | begin | ||
+ | dbms_propagation_adm.create_propagation( | ||
+ | propagation_name=>'PROPA_TO_YODA', | ||
+ | source_queue=>'file_envoi', | ||
+ | destination_queue=>'file_reception', | ||
+ | database_link=>'YODA', | ||
+ | queue_to_queue=>TRUE | ||
+ | ); | ||
+ | end; | ||
+ | / | ||
+ | </code> | ||
+ | Association des queues d'envoi. A faire sur YODA et LUKE | ||
+ | <code> | ||
+ | begin | ||
+ | dbms_aqadm.alter_queue_table( | ||
+ | queue_table=>'file_envoi', | ||
+ | primary_instance=>1, | ||
+ | secondary_instance=>2 ); | ||
end; | end; | ||
/ | / | ||
Ligne 261: | Ligne 308: | ||
schemas=alice | schemas=alice | ||
flashback_scn=855547 | flashback_scn=855547 | ||
+ | parallel=8 | ||
</code> | </code> | ||
+ | Oracle conseille de lancer en parallèle un nombre de processus égal à deux fois le nombre de coeurs soit pour un quad core → 8 processus. | ||
+ | |||
Lancer ensuite l'import DataPump sur LUKE. | Lancer ensuite l'import DataPump sur LUKE. | ||
<code> | <code> | ||
Ligne 313: | Ligne 363: | ||
/ | / | ||
</code> | </code> | ||
+ | Arrivé à ce stade la réplication bi-directionnelle en streams est opérationnelle. |