Outils pour utilisateurs

Outils du site


mise_en_place_d_un_dataguard_avec_oracle_10g

Différences

Cette page vous affiche les différences entre la révision choisie et la version actuelle de la page.

Lien vers cette vue comparative

mise_en_place_d_un_dataguard_avec_oracle_10g [2012/06/08 07:00]
admin [Cas des tempfiles]
mise_en_place_d_un_dataguard_avec_oracle_10g [2013/04/16 13:02] (Version actuelle)
admin [Modification du stockage]
Ligne 1: Ligne 1:
 +~~ODT~~
 ====== Introduction ====== ====== Introduction ======
 {{ :​logo_oracle10g.gif?​200|}}Je vais décrire ici l'​installation pas à pas d'une solution dataguard avec Oracle 10g. Tout se fait en ligne de commande, aucune interface graphique n'est mise en place. {{ :​logo_oracle10g.gif?​200|}}Je vais décrire ici l'​installation pas à pas d'une solution dataguard avec Oracle 10g. Tout se fait en ligne de commande, aucune interface graphique n'est mise en place.
Ligne 21: Ligne 22:
  
 L'​objectif est d'​avoir la base YODA comme base en production et de basculer sur LUKE en cas de défaillance. L'​objectif est d'​avoir la base YODA comme base en production et de basculer sur LUKE en cas de défaillance.
 +
 +=====Principe du dataguard=====
 +Un site primaire contenant une base de données est en production. Les connexions clients et transactions s'​effectuent sur ce site primaire. En temps réel ou différé, selon la configuration dataguard, les transactions sont transmises pour être appliquées sur le site secondaire ou standby.
 +
 +La base standby n'est pas accèssible ( sauf en 11g sur active dataguard ). Elle est montée mais non ouverte et en mode recouvrement. Le transfert des transaction se fait via la couche oracle*net et 2 processus :
 +  * lsn0 qui pousse les information de redolog ou d'​archivelog vers le site standby
 +  * rfs qui écrit les transaction reçues dans des standby redologs.
 +Les standby redologs ont une taille identique aux redologs. Il doit y avoir 1 standby redolog de plus que le nombre de redologs. Sur le site standby c'est le processus mrp0 qui écrit le contenu des standby redologs dans la base standby.
 +
 +{{:​data_guard.jpg?​|}}
  
 Attention, un dataguard n'est pas équivalent à une configuration RAC. Il s'agit juste d'​avoir une copie, à jour en temps réel ou différé, de la base de données de production afin de poursuivre l'​activité en cas d'​arrêt de celle-ci. Le dataguard implique un arrêt, faible certes, mais une non activité pendant le basculement. En clair, le dataguard n'est pas une solution de haute-disponibilité. Attention, un dataguard n'est pas équivalent à une configuration RAC. Il s'agit juste d'​avoir une copie, à jour en temps réel ou différé, de la base de données de production afin de poursuivre l'​activité en cas d'​arrêt de celle-ci. Le dataguard implique un arrêt, faible certes, mais une non activité pendant le basculement. En clair, le dataguard n'est pas une solution de haute-disponibilité.
Ligne 617: Ligne 628:
 scp $HOME/​initLUKE.ora oracle@vm02.adi100.concarnux.fr:/​u01/​app/​oracle/​admin/​LUKE/​pfile scp $HOME/​initLUKE.ora oracle@vm02.adi100.concarnux.fr:/​u01/​app/​oracle/​admin/​LUKE/​pfile
 </​code>​ </​code>​
-Sur la VM vm02.adi100.concarnux.fr créer le lien symbolique vers le fichier de paramètre ainsi que le fichier de mot de passe pour l'icentifiaction ​privilégiée.+Sur la VM vm02.adi100.concarnux.fr créer le lien symbolique vers le fichier de paramètre ainsi que le fichier de mot de passe pour l'identifiaction ​privilégiée.
 <​code>​ <​code>​
 cd $ORACLE_HOME/​dbs cd $ORACLE_HOME/​dbs
 ln -s /​u01/​app/​oracle/​admin/​LUKE/​pfile/​initLUKE.ora initLUKE.ora ln -s /​u01/​app/​oracle/​admin/​LUKE/​pfile/​initLUKE.ora initLUKE.ora
 orapwd file=orapwLUKE password=manager10 orapwd file=orapwLUKE password=manager10
 +</​code>​
 +**Très important, la création du mot de passe d'​identification privilégiée est vitale. Il doit être identique sur les deux machines. De plus si en g la commande orapwd est possible, en 11g il faut copier physiquement le fichier de mot de passe sur l'​autre machine sinon rien ne fonctionne.**
 +<​code>​
 +cd $ORACLE_HOME/​dbs
 +scp orapwYODA oracle@vm02.adi100.concarnux.fr:/​u01/​app/​oracle/​product/​11.2.0/​dbhome_1/​dbs/​orapwLUKE
 </​code>​ </​code>​
 Sur la VM vm02.adi100.concarnux.fr,​ démarrer la base LUKE en mode nomount Sur la VM vm02.adi100.concarnux.fr,​ démarrer la base LUKE en mode nomount
Ligne 889: Ligne 905:
 Si la base primaire est LUKE et qu'un fichier est créé ainsi : Si la base primaire est LUKE et qu'un fichier est créé ainsi :
 <​code>​ <​code>​
-SQL> alter tablespace_data_alice ​add datafile '/​u01/​app/​oracle/​oradata/​LUKE/​data_alice_02.dbf'​ size 5M;+SQL> alter tablespace data_alice ​add datafile '/​u01/​app/​oracle/​oradata/​LUKE/​data_alice_02.dbf'​ size 5M;
 </​code>​ </​code>​
 Ce fichier sera bien créé sous la base YODA, mais dans la même arborescence ! Hors il serait plus logique que ce fichier soit sous /​u01/​app/​oracle/​oradata/​YODA. Pour gérer ce cas, il faut activer sous YODA les paramètres suivants : Ce fichier sera bien créé sous la base YODA, mais dans la même arborescence ! Hors il serait plus logique que ce fichier soit sous /​u01/​app/​oracle/​oradata/​YODA. Pour gérer ce cas, il faut activer sous YODA les paramètres suivants :
Ligne 897: Ligne 913:
 <​code>​ <​code>​
 sqlplus sys/​manager10@yoda as sysdba sqlplus sys/​manager10@yoda as sysdba
-SQL> alter system set db_file_name convert='​LUKE','​YODA'​ scope=spfile;​ +SQL> alter system set db_file_name_convert='​LUKE','​YODA'​ scope=spfile;​ 
-SQL> alter system set log_file_name convert='​LUKE','​YODA'​ scope=spfile;​+SQL> alter system set log_file_name_convert='​LUKE','​YODA'​ scope=spfile;​
 SQL> shutdown immediate; SQL> shutdown immediate;
 SQL> startup mount; SQL> startup mount;
mise_en_place_d_un_dataguard_avec_oracle_10g.1339131657.txt.gz · Dernière modification: 2012/06/08 07:00 par admin