Cette page vous affiche les différences entre la révision choisie et la version actuelle de la page.
flux_streams [2016/03/04 00:55] admin [Introduction] |
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 12: | Ligne 15: | ||
====== Création du user Streams ====== | ====== Création du user Streams ====== | ||
- | Création des tablespaces dédiés sur YODA | + | Pour la mise en place de streams il est conseillé de dédier un utilisateur à cette fonction. Cet utilisateur aura un privilège type DBA et sera nommé STRMADMIN. |
+ | |||
+ | Création des tablespaces dédiés à STRMADMIN sur YODA. | ||
<code> | <code> | ||
CREATE TABLESPACE "STRM_DATA" DATAFILE | CREATE TABLESPACE "STRM_DATA" DATAFILE | ||
Ligne 19: | Ligne 24: | ||
'/u02/app/oracle/oradata/YODA/strm_temp_01.dbf' SIZE 50M; | '/u02/app/oracle/oradata/YODA/strm_temp_01.dbf' SIZE 50M; | ||
</code> | </code> | ||
- | Création des tablespaces dédiés sur LUKE | + | Création des tablespaces dédiés à STRMADMIN sur LUKE |
<code> | <code> | ||
CREATE TABLESPACE "STRM_DATA" DATAFILE | CREATE TABLESPACE "STRM_DATA" DATAFILE | ||
Ligne 26: | Ligne 31: | ||
'/u02/app/oracle/oradata/LUKE/strm_temp_01.dbf' SIZE 50M; | '/u02/app/oracle/oradata/LUKE/strm_temp_01.dbf' SIZE 50M; | ||
</code> | </code> | ||
- | Création du user à faire sur les deux bases YODA et LUKE. | + | Création du user STRMADMIN à faire sur les deux bases YODA et LUKE. |
<code> | <code> | ||
create user strmadmin identified by strmadmin default tablespace strm_data temporary tablespace strm_temp; | create user strmadmin identified by strmadmin default tablespace strm_data temporary tablespace strm_temp; | ||
</code> | </code> | ||
- | Affectation des droits à faire sur les deux bases YODA et LUKE. | + | Affectation des droits pour STRMADMIN à faire sur les deux bases YODA et LUKE. |
<code> | <code> | ||
alter user strmadmin quota unlimited on strm_data; | alter user strmadmin quota unlimited on strm_data; | ||
Ligne 37: | Ligne 42: | ||
</code> | </code> | ||
====== Objet Directory ====== | ====== Objet Directory ====== | ||
- | La première synchro entre YODA et LUKE se fera via DataPump. Mettre en place sur chaque base un objet directory. | + | La première synchronisaton entre YODA et LUKE se fera via DataPump. Mettre en place sur chaque base un objet directory. |
Sur YODA | Sur YODA | ||
Ligne 60: | Ligne 65: | ||
====== Création des files d'attente ====== | ====== Création des files d'attente ====== | ||
+ | Sur chaque base définir deux files d'attente. Une pour l'envoi vers l'autre base et l'autre pour la réception depuis l'autre base. | ||
+ | |||
Sur les deux bases en strmadmin | Sur les deux bases en strmadmin | ||
<code> | <code> | ||
Ligne 76: | 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 95: | 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 133: | 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 166: | 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 257: | 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 309: | Ligne 363: | ||
/ | / | ||
</code> | </code> | ||
+ | Arrivé à ce stade la réplication bi-directionnelle en streams est opérationnelle. |