DATAGUARD 10g

Introduction
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.
L'ensemble de cette installation a été réalisé sur une machine
assemblée avec un disque dur de 250Go, 4Go de RAM et
processeur i3.
Il est supposé une connaissance de Oracle, notamment sur la
configuration réseau Oracle*Net et le fonctionnement des
redologs. Il faut aussi connaitre le fonctionnement de RMAN.
Deux serveurs Oracle seront mis en place. Le premier
supportera la base dite primaire ( primary ) et nommée YODA. Le second supportera la base
standby ( Physical Standby ) nommée LUKE.
L'environnement est le suivant :
Serveur adi100.concarnux.fr sous CentOS 5.7 version 64 bits, IP 192.168.1.100/24
Deux machines virtuelles sous XEN pour simuler deux serveurs Oracle.
vm01.adi100.concarnux.fr : IP 192.168.1.101/24, disque dur de 25Go et RAM de 1Go
vm02.adi100.concarnux.fr : IP 192.168.1.102/24, disque dur de 25Go et RAM de 1Go
La version de oracle utilisée sur les deux VM est la 10.2.0.5 version Enterprise. la licence
Enterprise est indipensable pour exploiter toutes les fonctionnalités du dataguard. Toutefois la
base standby peut être en licence standard, mais certains automatismes ne seront pas
disponibles.
En environnement de production, il est bien sur conseillé d'utiliser des serveurs distincts et si
possible sur des sites distants.
Le schéma ci-dessous montre la configuration utilisée.
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.
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é.
Pré-requis
Un dataguard s'appuie sur deux fonctionnalités :
Le transport de l'information
L'application des transactions.
Le réseau est donc solicité pour transporter les informations d'un serveur à l'autre. Il s'appuie
sur la couche Oracle*Net. Ce principe permet d'alléger le transit réseau par rapport à d'autre
procédures de réplication type DRBD par exemple.
Il faut donc que la configuration réseau soit parfaitement fonctionnelle.
Résolution des noms de machines via /etc/hosts ( ce qui sera utilisé dans le cas présent ) ou
DNS
Configuration correcte des listeners oracle ( listener.ora ) et de la résolution TNS ( sqlnet.ora et
tnsnames.ora ).
Mise en place de l'environnement
Le serveur de base sera configuré avec le minimum requis ( package core ). Puis sera mis en
place le nécessaire pour utiliser XEN. Se reporter à l'article suivant pour plus de détails.
Une fois le serveur CentOS installé, mettre en place XEN en installant les packages suivants :
yum -y install kernel-xen xen
Puis rebooter le serveur sur le noyau XEN. Vérifier ceci par la commande uname -r.
Machines virtuelles
Pour simuler les deux serveurs, deux VM vont être créées, identiques en tout point. L'objectif ici
n'est pas de décrire en détail la création de VM avec XEN, il sera fait appel à un fichier kickstart
et à l'utilitaire virt-install.
Pour faciliter le déploiement, je vais utiliser un script shell recevant en paramètre l'IP et le nom
de ma VM. J'ai volontairement allégé le kickstart afin de présenter la configuration pas à pas de
chaque serveur dans un but didactique.
L'installation se fait via une distribution CentOS 5.7 disponible sur un serveur http ( pour plus
de détail voir cet article ).
Chaque VM disposera de 1Go de RAM et d'un disque dur de 25Go partitionné ainsi :
Point de
montage
Format
Taille
Primaire
/boot
ext2
100Mo
swap
2Go
/
ext3
500Mo
Logique
/usr
ext3
5Go

/var
ext3
2Go
/tmp
ext3
1Go
/home
ext3
5Go
/u01
ext3
Le
reste
Les disques durs des VM sont mis en place sous forme de fichiers situés sous /disquesvm sur le
serveur adi100.concarnux.fr.
Le mot de passe affecté au root sur les VM est azerty
Le script createVM.sh
Sous l'identité du root sur le serveur adi100.concarnux.fr créer le fichier createVM.sh avec les
lignes suivantes :
#!/bin/sh
IP=$1
NOM_DNS=$2
VM=$(echo $(echo $NOM_DNS | cut -d '.' -f1))
echo "La VM portera le nom : $VM et aura pour nom DNS : $NOM_DNS et pour IP : $IP"
rm -f /etc/xen/$VM
cat <<EOF > /var/www/html/${VM}-ks.cfg
install
url --url http://192.168.1.100/centos
lang fr_FR.UTF-8
keyboard fr-latin9
text
network --device eth0 --bootproto static --ip $IP --netmask 255.255.255.0 --gateway 192.168.1.1 --nameserver
80.10.246.2 --hostname $NOM_DNS
rootpw azerty
firewall --disabled
authconfig --enableshadow --enablemd5
selinux --disabled
timezone --utc Europe/Paris
bootloader --location=mbr --driveorder=xvda
reboot
clearpart --all --initlabel --drives=xvda
part /boot --fstype ext2 --size=100 --asprimary
part / --fstype ext3 --size=500 --asprimary
part swap --size=2048 --asprimary
part /usr --fstype ext3 --size=5000
part /var --fstype ext3 --size=2000
part /tmp --fstype ext3 --size=1000
part /home --fstype ext3 --size=5000
part /u01 --fstype ext3 --size=1 --grow
%packages --excludedocs --nobase
@core
EOF
virt-install --name $VM -p -r 1024 --disk path=/disquesvm/${VM}.img,size=25 --location http://192.168.1.100/centos \
-x "cmdline ks=http://192.168.1.100/${VM}-ks.cfg ip=$IP netmask=255.255.255.0 gateway=192.168.1.1
dns=80.10.246.2 hostname=${NOM_DNS}" --nographics

Mise en place de NFS
Afin de faciliter le déploiement de Oracle sur les VM, un montage NFS sera mis en place, pour
cela sur le serveur adi100.concarnux.org, installer le serveur NFS
yum install nfs-utils
Lancer NFS server
service portmap start
service nfs start
Exporter le répertoire /home en mode lecture en éditant le fichier /etc/exports et en ajoutant
la ligne suivante
/home *(ro,sync)
Lancer l'export par la commande exportfs -a. Le répertoire /home sera disponible en mode
read-only sur toute machine du réseau. La configuration NFS n'est pas top mais sufisante pour
notre besoin.
Création des 2 VM
Création de la première VM
sh /root/createVM.sh 192.168.1.101 vm01.adi100.concarnux.fr
Le script lance la création de la VM et se connecte en mode console dessus, pour en sortir utiliser
la combinaison de touches "Ctrl" + "Alt Gr" + "]"
Création de la seconde VM
sh /root/createVM.sh 192.168.1.102 vm02.adi100.concarnux.fr
Sortir du mode console par "Ctrl" + "Alt Gr" + "]"
A ce stade, le serveur adi100.concarnux.fr comporte deux VM → commande xm list
[root@adi100 ~]# xm list
Name ID Mem(MiB) VCPUs State Time(s)
Domain-0 0 822 4 r----- 154.6
vm01 5 1024 1 -b---- 11.3
vm02 7 1024 1 -b---- 11.0
[root@adi100 ~]#
Post-installation des VM
Ces phases sont à faire sur chaque VM
Dans un premier temps, mettre à jour les packages de la distribution
yum -y update
Fichier /etc/hosts
Il faut mettre en place une résolution de noms. Contenu du fichier /etc/hosts
127.0.0.1 localhost.localdomain localhost