Cette page vous affiche les différences entre la révision choisie et la version actuelle de la page.
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; |