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 [2011/12/22 17:32]
admin [Configuration du broker]
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 549: Ligne 560:
 Activer les trois paramètres suivants : Activer les trois paramètres suivants :
 <​code>​ <​code>​
-SQL> alter system set standby_file_management = auto scope=both+SQL> alter system set standby_file_management=auto scope=spfile
-SQL> alter system set archive_lag_target=900;​+SQL> alter system set archive_lag_target=900 ​scope=spfile;
 SQL> alter system set db_unique_name=YODA scope=spfile;​ SQL> alter system set db_unique_name=YODA scope=spfile;​
 SQL> shutdown immediate; SQL> shutdown immediate;
Ligne 557: Ligne 568:
   * standby_file_management active la création automatique de fichiers depuis la base primaire vers la standby, par exemple lors de la création ou l'​agrandissement d'un tablespace.   * standby_file_management active la création automatique de fichiers depuis la base primaire vers la standby, par exemple lors de la création ou l'​agrandissement d'un tablespace.
   * archive_lag_target=900 force un archivelog toutes les 15 minutes ( 900 secondes ) quelque soit l'​activité.   * archive_lag_target=900 force un archivelog toutes les 15 minutes ( 900 secondes ) quelque soit l'​activité.
-  * db_unique_name=YODA donne un nom unique à une base de données, dans le cas de YODA il est directement dérivé de db_name, mais pour LUKE le db_name reste YODA et db_unique_name=LULE permet de les différentier.+  * db_unique_name=YODA donne un nom unique à une base de données, dans le cas de YODA il est directement dérivé de db_name, mais pour LUKE le db_name reste YODA et db_unique_name=LUKE permet de les différentier.
 ===== Préparation de la base standby LUKE ===== ===== Préparation de la base standby LUKE =====
-Il s'agit maintenant de mettre en place la configuration pour la standby database qui sera située sur la VM vm02.adi100.concarnux.fr. Le principe général est d'uliser ​une sauvegarde RMAN de la base primaire ( YODA ) et de demander une duplication en base standby ( LUKE ).+Il s'agit maintenant de mettre en place la configuration pour la standby database qui sera située sur la VM vm02.adi100.concarnux.fr. Le principe général est d'utiliser ​une sauvegarde RMAN de la base primaire ( YODA ) et de demander une duplication en base standby ( LUKE ).
  
 Dans un premier temps, générer un fichier de paramètre pour LUKE depuis le spfile de YODA. Dans un premier temps, générer un fichier de paramètre pour LUKE depuis le spfile de YODA.
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 685: Ligne 701:
 </​code>​ </​code>​
 ===== Sauvegarde de la base YODA ===== ===== Sauvegarde de la base YODA =====
-Il faut maintenant générer une sauvegarde ​RMAn de la base YODA qui sera ensuite copiée sur la VM vm02.adi100.concarnux.fr et qui permettra la création de la standby database LUKE.+Il faut maintenant générer une sauvegarde ​RMAN de la base YODA qui sera ensuite copiée sur la VM vm02.adi100.concarnux.fr et qui permettra la création de la standby database LUKE.
  
 Sur la VM vm01.adi100.concarnux.fr,​ lancer RMAN Sur la VM vm01.adi100.concarnux.fr,​ lancer RMAN
Ligne 736: Ligne 752:
 </​code>​ </​code>​
 ===== Création des standby redolog ===== ===== Création des standby redolog =====
-Il s'agit de redolog chargés de récupérer les transactions de la base primaire pour ls rejouer sur la standby database. leur nombre doit être égal au nombre de groupe de redolog + 1 et d'une taille identique. La base YODA ayant 2 groupes de redolog, il faut donc 3 standby redolog.+Il s'agit de redolog chargés de récupérer les transactions de la base primaire pour les rejouer sur la standby database. leur nombre doit être égal au nombre de groupe de redolog + 1 et d'une taille identique. La base YODA ayant 2 groupes de redolog, il faut donc 3 standby redolog.
  
 Le fichier alertYODA.log montre bien cette demande Le fichier alertYODA.log montre bien cette demande
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;
Ligne 905: Ligne 921:
 </​code>​ </​code>​
 ==== Cas des tempfiles ==== ==== Cas des tempfiles ====
-Il y a un bug ( une fonctionnalité ? ) avec les tempfiles, qui se voit d'​ailleurs dans l'​alert.log. les fichier ​des tablespace temporaire ​ne sont pas recréés. Il faut le faire manuellement avec la commande alter tablespace <​temp>​ ad tempfile...+Il y a un bug ( une fonctionnalité ? ) avec les tempfiles, qui se voit d'​ailleurs dans l'​alert.log. les fichiers ​des tablespaces temporaires ​ne sont pas recréés. Il faut le faire manuellement avec la commande alter tablespace <​temp>​ ad tempfile...
  
 Extrait de l'​alert.log de la base YODA lors de son passage en base primaire quand le tablespace temporaire TEMP_BOB fut créé sous LUKE Extrait de l'​alert.log de la base YODA lors de son passage en base primaire quand le tablespace temporaire TEMP_BOB fut créé sous LUKE
Ligne 1036: Ligne 1052:
 Il peut y avoir au démarrage des messages de ce type : Avertissement : ORA-16610: commande '​Broker automatic health check' en cours d'​exécution. Cette situation est normale, le temps de la configuration. Il peut y avoir au démarrage des messages de ce type : Avertissement : ORA-16610: commande '​Broker automatic health check' en cours d'​exécution. Cette situation est normale, le temps de la configuration.
  
-Le broker modifie la configuration du dataguard, par défaut il passe en maximum performance ( utilisation de ARCH au lieu de LGWR ). Au bout d'​un ​temp la configuration s'​affiche :+Au bout d'​un ​temps la configuration s'​affiche :
 <​code>​ <​code>​
 DGMGRL> show configuration DGMGRL> show configuration
Ligne 1043: Ligne 1059:
   Name:                JEDI   Name:                JEDI
   Enabled: ​            YES   Enabled: ​            YES
-  Protection Mode:     MaxPerformance+  Protection Mode:     MaxAvailability
   Fast-Start Failover: DISABLED   Fast-Start Failover: DISABLED
   Databases:   Databases:
-    ​YODA - Primary database+    ​yoda - Primary database
     luke - Physical standby database     luke - Physical standby database
  
mise_en_place_d_un_dataguard_avec_oracle_10g.1324571527.txt.gz · Dernière modification: 2011/12/22 17:32 par admin