~~ODT~~
====== 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.
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.
{{:dg01.jpg?|}}
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é.
====== 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 à [[virtualisation_sur_centos_5.6|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 [[clustering_avec_centos_5.6|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 < /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
::1 localhost6.localdomain6 localhost6
192.168.1.100 adi100.concarnux.fr
192.168.1.101 vm01.adi100.concarnux.fr vm01
192.168.1.102 vm02.adi100.concarnux.fr vm02
=== Installation de Oracle ===
Les binaires de Oracle sont sur le serveur adi100.concarnux.fr dans le répertoire /home. Afin de simplifier le déploiement sur les VM, ce répertoire sera monté sur chaque VM via NFS. Il faut donc installer la configuration cliente NFS.
yum install nfs-utils
lancer portmap et monter le répertoire /home de adi100.concarnux.fr sous /mnt
service portmap start
mount -t nfs adi100.concarnux.fr:/home /mnt
L'installation de oracle se fera en 2 temps.
* Installation de la version 10.2.0.1
* Installation du patch 10.2.0.5
Dans les deux cas, il sera fait appel à l'installation silencieuse.
== Mise en place de l'environnement Oracle ==
Voir l'article suivant pour plus de détail : [[installation_oracle_10g_64_bits_sur_centos_5.7|Oracle 10g sur CentOS]]
Les commandes ci-dessous sont directement tirées des précaunisations Oracle pour Linux.
**Packages requis**
yum -y install compat-libstdc++-296 compat-libstdc++-33 make pdksh elfutils-libelf-devel \
glibc-devel glibc-headers gcc gcc-c++ libaio-devel sysstat unixODBC unixODBC-devel \
xorg-x11-deprecated-libs xorg-x11-utils libgcj-4.1.2-51.el5
**Utilisateur er groupes**
groupadd oinstall
groupadd dba
groupadd oper
useradd -g oinstall -G dba -s /bin/bash oracle
passwd oracle
Comme mot de passe oracle, nous utiliserons //manager10//
**Paramètres noyau linux**
echo "kernel.shmmni = 4096" >> /etc/sysctl.conf
echo "kernel.sem = 250 32000 100 128" >> /etc/sysctl.conf
echo "fs.file-max = 65536" >> /etc/sysctl.conf
echo "net.ipv4.ip_local_port_range = 1024 65000" >> /etc/sysctl.conf
echo "net.core.rmem_default = 4194304" >> /etc/sysctl.conf
echo "net.core.rmem_max = 4194304" >> /etc/sysctl.conf
echo "net.core.wmem_default = 262144" >> /etc/sysctl.conf
echo "net.core.wmem_max = 262144" >> /etc/sysctl.conf
Activer la configuration par la commande sysctl -p
**Paramètres des limites**
echo "oracle soft nproc 2047" >> /etc/security/limits.conf
echo "oracle hard nproc 16384" >> /etc/security/limits.conf
echo "oracle soft nofile 1024" >> /etc/security/limits.conf
echo "oracle hard nofile 65536" >> /etc/security/limits.conf
**Fichier /etc/profile**
echo "if [ $USER = "oracle" ]; then" >> /etc/profile
echo " if [ $SHELL = "/bin/ksh" ]; then" >> /etc/profile
echo " ulimit -p 16384" >> /etc/profile
echo " ulimit -n 65536" >> /etc/profile
echo " else" >> /etc/profile
echo " ulimit -u 16384 -n 65536" >> /etc/profile
echo " fi" >> /etc/profile
echo "fi" >> /etc/profile
**Simuler une RedHat**
echo "RedHat Enterprise Linux ES release 3 (Taroon Update 4)" > /etc/redhat-release
**Création des répertoires**
mkdir -p /u01/app/oracle
chown -R oracle:oinstall /u01/app
chmod -R 775 /u01/app
Très important à partir de cet instant, sauf indication contraire, toutes les manipulations se font en étant **connecté sous l'identité oracle.**
== Installation silencieuse de oracle 10.2.0.1 ==
Se connecter oracle et créer un fichier db.rsp avec les lignes suivantes :
RESPONSEFILE_VERSION=2.2.1.0.0
UNIX_GROUP_NAME=oinstall
FROM_LOCATION="../stage/products.xml"
ORACLE_HOME=/u01/app/oracle/product/10.2.0/db_1
ORACLE_HOME_NAME=OraDbHome1
TOPLEVEL_COMPONENT={"oracle.server","10.2.0.1.0"}
DEINSTALL_LIST={"oracle.server","10.2.0.1.0"}
ORACLE_HOSTNAME=vm01.adi100.concarnux.fr
COMPONENT_LANGUAGES={"en","fr"}
INSTALL_TYPE="EE"
s_nameForDBAGrp=dba
s_nameForOPERGrp=oper
n_configurationOption=3
Attention la ligne ORACLE_HOSTNAME=vm01.adi100.concarnux.fr doit être changée en ORACLE_HOSTNAME=vm02.adi100.concarnux.fr sur la seconde VM.
Lancer l'installation de oracle
/mnt/database/runInstaller -silent -responsefile $HOME/db.rsp
En fin d'installation, ouvrir un second terminal sur la VM et se connecter root pour exécuter les deux scripts suivants :
/home/oracle/oraInventory/orainstRoot.sh
/u01/app/oracle/product/10.2.0/db_1/root.sh
Sur le second script accepter la valeur par défaut : /usr/local/bin
Editer le fichier .bash_profile du user oracle et ajouter les lignes suivantes :
export ORACLE_BASE=/u01/app/oracle
export ORACLE_HOME=$ORACLE_BASE/product/10.2.0/db_1
export LD_LIBRARY_PATH=$ORACLE_HOME/lib
export ORACLE_OWNER=oracle
export PATH=$PATH:$ORACLE_HOME/bin
export NLS_LANG=FRENCH_FRANCE.UTF8
Sourcer ce fichier par la commandde suivante :
. .bash_profile
== Installation silencieuse du patch 10.2.0.5 ==
Créer le fichier patch.rsp et y ajouter les lignes suivantes
RESPONSEFILE_VERSION=2.2.1.0.0
UNIX_GROUP_NAME="oinstall"
FROM_LOCATION="../stage/products.xml"
ORACLE_HOME="/u01/app/oracle/product/10.2.0/db_1"
ORACLE_HOME_NAME=OraDbHome1
TOPLEVEL_COMPONENT={"oracle.patchset.db","10.2.0.5.0"}
OUI_HOSTNAME=vm01.adi100.concarnux.fr
COMPONENT_LANGUAGES={"en","fr"}
MYORACLESUPPORT_USERNAME=votre.nom@votre.mail.com
MYORACLESUPPORT_PASSWORD=votre_mot_de_passe
L'utilisation du patch 10.2.0.5 est soumis à la création d'un compte My Oracle Support, donc à licence. Pour information la version 10.2.0.4 de Oracle est librement chargeable sur le site Oracle. Ce tutoriel fonctionne très bien aussi avec 10.2.0.4.
Attention la ligne ORACLE_HOSTNAME=vm01.adi100.concarnux.fr doit être changée en ORACLE_HOSTNAME=vm02.adi100.concarnux.fr sur la seconde VM.
Lancer l'installation du patch 10.2.0.5 ainsi
/mnt/Disk1/runInstaller -silent -responsefile $HOME/patch.rsp -ignoresysprereqs
En fin d'installation, ouvrir un second terminal sur la VM et se connecter root pour exécuter le script suivant :
/u01/app/oracle/product/10.2.0/db_1/root.sh
Accepter les choix par défaut.
Se connecter sqlplus pour vérifier l'installation correcte
[oracle@vm01 ~]$ sqlplus /nolog
SQL*Plus: Release 10.2.0.5.0 - Production on Dim. Déc. 18 12:08:27 2011
Copyright (c) 1982, 2010, Oracle. All Rights Reserved.
SQL> exit
[oracle@vm01 ~]$
Exécuter les mêmes opérations sur la seconde VM.
A ce stade l'environnement Oracle pour la mise en place du dataguard est opérationnel. On dispose donc de deux serveur identiques. Sur la première VM nous allons créer une base de données de production nommée YODA.
===== Création de la base de données YODA =====
La base de données YODA, outre sa configuration minimale ( 1 control file, 2 groupes de redolog ... ), comprendra un schéma nommé ALICE et contenant une table personne.
La configuration est volontairement simpliste, une base de production doit mirrorer ses control files et ses redologs.
La base de données YODA est créée sur vm01.adi100.concarnux.fr **en étant connecté oracle.**
==== Mise en place de l'environnement de la base YODA ====
=== Création des répertoires ===
la norme OFA sera respectée.
mkdir -p /u01/app/oracle/admin/YODA/adump
mkdir -p /u01/app/oracle/admin/YODA/bdump
mkdir -p /u01/app/oracle/admin/YODA/cdump
mkdir -p /u01/app/oracle/admin/YODA/udump
mkdir -p /u01/app/oracle/admin/YODA/pfile
mkdir -p /u01/app/oracle/oradata/YODA
mkdir -p /u01/app/oracle/backup/YODA
mkdir -p /u01/app/oracle/archlog/YODA
mkdir -p /u01/app/oracle/stdblog/YODA
* Les fichiers de la base seront sous /u01/app/oracle/oradata/YODA
* Les fichiers de sauvegarde RMAN sous /u01/app/oracle/backup/YODA
* Les archivelogs sous /u01/app/oracle/archlog/YODA
* Les standby redolog sous /u01/app/oracle/stdblog/YODA
=== Fichier de paramètres ===
Créer le fichier /u01/app/oracle/admin/YODA/pfile/initYODA.ora
db_name = YODA
db_block_size = 8192
audit_file_dest = /u01/app/oracle/admin/YODA/adump
background_dump_dest = /u01/app/oracle/admin/YODA/bdump
core_dump_dest = /u01/app/oracle/admin/YODA/cdump
user_dump_dest = /u01/app/oracle/admin/YODA/udump
control_files = /u01/app/oracle/oradata/YODA/control01.ctl
undo_management=auto
sga_target = 640M
pga_aggregate_target = 160M
Créer un lien symbolique vers le fichier de paramètre depuis $ORACLE_HOME/dbs
cd $ORACLE_HOME/dbs
ln -s /u01/app/oracle/admin/YODA/pfile/initYODA.ora initYODA.ora
=== Fichier de mot de passe ===
Dans une configuration dataguard, il est impératif d'utiliser un fichier de mot de passe pour l'identification privilégiée ( as sysdba ). De plus le mot de passe du sys doit être identique sur la base primaire et la base standby ( voir plus loin ).
Le fichier de mot de passe est généré par orapwd dans le répertoire $ORACLE_HOME/dbs
cd $ORACLE_HOME/dbs
orapwd file=orapwYODA password=manager10
==== Création de la base de données ====
Démarrer la base en mode nomount et créer le spfile, ceci est également un impératif pour la configuration dataguard.
export ORACLE_SID=YODA
sqlplus /nolog
SQL> connect / as sysdba
SQL> startup nomount;
SQL> create spfile from pfile;
SQL> shutdown immediate;
SQL> startup nomount;
SQL> create database YODA
character set UTF8
national character set UTF8
logfile
group 1 '/u01/app/oracle/oradata/YODA/redo01a.log' size 50M,
group 2 '/u01/app/oracle/oradata/YODA/redo02a.log' size 50M
datafile '/u01/app/oracle/oradata/YODA/system01.dbf' size 500M
autoextend on next 100M
maxsize 2G extent management local
sysaux datafile '/u01/app/oracle/oradata/YODA/sysaux01.dbf' size 500M
autoextend on next 100M maxsize 2G
undo tablespace UNDO_TBS
datafile '/u01/app/oracle/oradata/YODA/undo_tbs01.dbf' size 25M
default temporary tablespace TEMP
tempfile '/u01/app/oracle/oradata/YODA/temp01.dbf' size 50M;
Au début la base est démarrée sur son pfile, puis le spfile est immédiatement créé. le redémarrage permet la prise en charge du spfile.
=== Création des tables du dictionnaire ===
Toujours sous SQL*Plus en sysdba lancer deux scripts
SQL> @?/rdbms/admin/catalog.sql
SQL> @?/rdbms/admin/catproc.sql
=== User sys et system ===
Affecter les mots de passe pour sys et system
SQL> alter user sys identified by manager10;
SQL> alter user system identified by manager10;
Se reconnecter en system/manager10 et lancer le script pupbld.sql
SQL> @?/sqlplus/admin/pupbld.sql
SQL> exit;
=== Tablespace par défaut ===
Créer un tablespace par défaut à la taille minimale.
SQL> create tablespace users datafile '/u01/app/oracle/oradata/YODA/users_01.dbf' size 100K;
SQL> alter database default tablespace users;
=== PFILE ou SPFILE ? ===
Verification de l'activation du spfile
SQL> select decode(count(*), 1, 'spfile', 'pfile' ) from v$spparameter where rownum=1 and isspecified='TRUE';
DECODE
------
spfile
SQL>
==== Configuration Oracle*Net ====
La couche réseau de Oracle doit faire l'objet d'un soin particulier, car dans une configuration dataguard le transport des transactions d'une base à l'autre est assuré par ce biais.
=== Listener ===
En plus de la configuration standard du listener, il faut enregistrer statiquement la base de données dans le listener.
Créer le fichier $ORACLE_HOME/network/admin/listener.ora avec les lignes suivantes :
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS=(PROTOCOL = TCP)(HOST = vm01.adi100.concarnux.fr )(PORT = 1521))
)
)
SID_LIST_LISTENER =
(SID_DESC =
(GLOBAL_DBNAME = YODA)
(ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1)
(SID_NAME = YODA)
)
Le démarrer
lsnrctl start
=== Résolution de nom TNS ===
Nous allons utiliser la résolution par fichier tnsnames.ora, dite résolution locale. Créer le fichier $ORACLE_HOME/network/admin/sqlnet.ora avec la ligne suivante :
NAMES.DIRECTORY_PATH=(TNSNAMES)
Créer le fichier $ORACLE_HOME/network/admin/tnsnames.ora avec les lignes suivantes :
YODA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = vm01.adi100.concarnux.fr)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = YODA)
)
)
Tester la résolution
[oracle@vm01 ~]$ tnsping YODA
TNS Ping Utility for Linux: Version 10.2.0.5.0 - Production on 18-DÉC. -2011 13:39:33
Copyright (c) 1997, 2010, Oracle. All rights reserved.
Fichiers de paramètres utilisés :
/u01/app/oracle/product/10.2.0/db_1/network/admin/sqlnet.ora
Adaptateur TNSNAMES utilisé pour la résolution de l'alias
Attempting to contact (DESCRIPTION = (ADDRESS_LIST = (ADDRESS = (PROTOCOL = TCP)(HOST = vm01.adi100.concarnux.fr)(PORT = 1521))) (CONNECT_DATA = (SERVICE_NAME = YODA)))
OK (0 msec)
[oracle@vm01 ~]$
==== Création des données exemple ====
=== Schéma ALICE ===
Créer un tablespace pour les données et un tablespace temporaire qui seront affectés à un user alice.
sqlplus system/manager10@YODA
SQL> create tablespace data_alice datafile '/u01/app/oracle/oradata/YODA/data_alice_01.dbf' size 10M;
SQL> create temporary tablespace temp_alice tempfile '/u01/app/oracle/oradata/YODA/temp_alice_01.dbf' size 5M;
SQL> create user alice identified by ecila default tablespace data_alice temporary tablespace temp_alice;
SQL> grant connect, resource to alice;
=== Données du schéma ALICE ===
Se connecter alice sur la base YODA et créer la table personne, puis insérer des données.
SQL> connect alice/ecila@YODA
SQL> create table personne ( code char(2), prenom char(15), nom char(15));
SQL> insert into personne values ( '01', 'Alice','Cooper' );
SQL> insert into personne values ( '02', 'Bob','Woodward' );
SQL> insert into personne values ( '03', 'Charles', 'Aznavour') ;
SQL> commit;
A ce stade la base YODA est considérée comme base de production.
===== Préparation au dataguard =====
Pour mettre en place le dataguard, la base YODA doit :
* Etre en mode archivelog
* Avoir le paramètre force_logging à true
Le mode force logging permet lors de l'insertion de données en mode append ou de chargement direct par SQL*Loader de tracer les transactions, sinon en cas de recouvrement ( phase recover ) -> ORA-1578 : Blocs corrompus.
==== Passage en mode archivelog ====
Depuis la 10g Oracle propose une flash recovery area qui permet de simplifier la gestion du mode archivelog ainsi que des sauvegardes. Toutefois dans notre exemple nous allons donner "en dur" ces destinations.
sqlplus sys/manager10@YODA as sysdba
SQL> alter system set log_archive_dest_1='LOCATION=/u01/app/oracle/archlog/YODA' scope=both;
SQL> alter system set log_archive_dest_state_1=enable scope=both;
SQL> alter system set log_archive_format='arclog_%t_%s_%r.dbf' scope=spfile;
SQL> shutdown immediate;
SQL> startup mount;
SQL> alter database archivelog;
SQL> alter database open;
==== Activation du mode force logging ====
Il est indispensable d'activer cette fonction car dans le cas d'un dataguard tout doit être stocké dans les redologs, y compris les action en mode nologging.
SQL> alter database force logging;
La requête suivante permet de vérifier que l'archivelog et force_logging sont actifs.
SQL> select dbid, name, log_mode, force_logging from v$database;
DBID NAME LOG_MODE FOR
---------- --------- ------------ ---
4127452263 YODA ARCHIVELOG YES
SQL>
==== Modification du spfile de YODA ====
Activer les trois paramètres suivants :
SQL> alter system set standby_file_management=auto scope=spfile;
SQL> alter system set archive_lag_target=900 scope=spfile;
SQL> alter system set db_unique_name=YODA scope=spfile;
SQL> shutdown immediate;
SQL> startup;
* 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é.
* 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 =====
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.
sqlplus sys/manager10@YODA as sysdba
SQL> create pfile='$HOME/initLUKE.ora' from spfile;
Editer ensuite le fichier obtenu et remplacer toute occurence de YODA par LUKE **sauf pour le paramètre db_name où il faut laisser YODA.**
En fin de fichier rajouter les lignes suivantes :
db_file_name_convert=('YODA','LUKE')
log_file_name_convert=('YODA','LUKE')
db_unique_name=LUKE
Les deux paramètres db_file_name_convert et log_file_name_convert convertissent tous les noms de fichiers contenant YODA en LUKE
Ci dessous un exemple de fichier initLUKE.ora
db_block_size=8192
db_name='YODA'
audit_file_dest='/u01/app/oracle/admin/LUKE/adump'
background_dump_dest='/u01/app/oracle/admin/LUKE/bdump'
user_dump_dest='/u01/app/oracle/admin/LUKE/udump'
core_dump_dest='/u01/app/oracle/admin/LUKE/cdump'
control_files='/u01/app/oracle/oradata/LUKE/control01.ctl'
log_archive_dest_1='LOCATION=/u01/app/oracle/archlog/LUKE'
log_archive_dest_state_1='ENABLE'
log_archive_format='%t_%s_%r.dbf'
pga_aggregate_target=160M
sga_target=640M
undo_management='auto'
archive_lag_target=900
db_file_name_convert=('YODA','LUKE')
log_file_name_convert=('YODA','LUKE')
standby_file_management='AUTO'
db_unique_name=LUKE
Sur la VM vm02.adi100.concarnux.fr, créer l'arborescence de la base LUKE en étant connecté oracle.
mkdir -p /u01/app/oracle/admin/LUKE/adump
mkdir -p /u01/app/oracle/admin/LUKE/bdump
mkdir -p /u01/app/oracle/admin/LUKE/cdump
mkdir -p /u01/app/oracle/admin/LUKE/udump
mkdir -p /u01/app/oracle/admin/LUKE/pfile
mkdir -p /u01/app/oracle/oradata/LUKE
mkdir -p /u01/app/oracle/backup/LUKE
mkdir -p /u01/app/oracle/backup/YODA
mkdir -p /u01/app/oracle/archlog/LUKE
mkdir -p /u01/app/oracle/stdblog/LUKE
Il faut créer un répertoire d'accueil ( /u01/app/oracle/backup/YODA ) de la sauvegarde YODA qui permettra la copie via RMAN en base LUKE.
Depuis la VM vm01.adi100.concarnux.fr, copier le fichier initLUKE.ora créé ci-dessus vers la VM vm02.adi100.concarnux.fr
scp $HOME/initLUKE.ora oracle@vm02.adi100.concarnux.fr:/u01/app/oracle/admin/LUKE/pfile
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.
cd $ORACLE_HOME/dbs
ln -s /u01/app/oracle/admin/LUKE/pfile/initLUKE.ora initLUKE.ora
orapwd file=orapwLUKE password=manager10
**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.**
cd $ORACLE_HOME/dbs
scp orapwYODA oracle@vm02.adi100.concarnux.fr:/u01/app/oracle/product/11.2.0/dbhome_1/dbs/orapwLUKE
Sur la VM vm02.adi100.concarnux.fr, démarrer la base LUKE en mode nomount
export ORACLE_SID=LUKE
sqlplus /nolog
SQL> connect / as sysdba
SQL> startup nomount;
SQL> create spfile from pfile;
SQL> shutdown immediate;
SQL> startup nomount;
SQL> exit;
==== Configurer Oracle*NET sur LUKE ====
Sur la VM vm02.adi100.concarnux.fr, créer le fichier $ORACLE_HOME/network/admin/listener.ora
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS=(PROTOCOL = TCP)(HOST = vm02.adi100.concarnux.fr )(PORT = 1521))
)
)
SID_LIST_LISTENER =
(SID_DESC =
(GLOBAL_DBNAME = LUKE)
(ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1)
(SID_NAME = LUKE)
)
Démarrer le listener
lsnrctl start
Créer le fichier $ORACLE_HOME/network/admin/sqlnet.ora
NAMES.DIRECTORY_PATH= (TNSNAMES)
Créer le fichier $ORACLE_HOME/network/admin/tnsnames.ora, y mettre la base LUKE mais aussi YODA
LUKE =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = vm02.adi100.concarnux.fr)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = LUKE)
)
)
YODA =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = vm01.adi100.concarnux.fr)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = YODA)
)
)
Vérifier la configuration Oracle*Net
tnsping luke
tnsping 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.
Sur la VM vm01.adi100.concarnux.fr, lancer RMAN
export ORACLE_SID=YODA
rman target / nocatalog
RMAN> configure default device type to disk;
RMAN> configure device type disk backup type to compressed backupset;
RMAN> configure channel device type disk format '/u01/app/oracle/backup/YODA/bck_%U';
RMAN> backup current controlfile for standby;
RMAN> sql 'alter system switch logfile';
RMAN> backup database plus archivelog;
RMAN> exit;
Copier cette sauvegarde sur la VM vm02.adi100.concarnux.fr. Les répertoires doivent être identiques sur les deux machines.
cd /u01/app/oracle/backup/YODA/
scp * oracle@vm02.adi100.concarnux.fr:/u01/app/oracle/backup/YODA
Rajouter la base LUKE dans le fichier $ORACLE_HOME/network/admin/tnsnames.ora de vm01.adi100.concarnux.fr
LUKE =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = vm02.adi100.concarnux.fr)(PORT = 1521))
)
(CONNECT_DATA =
(SERVICE_NAME = LUKE)
)
)
Vérifier la configuration Oracle*Net
tnsping luke
===== Création de la standby database LUKE =====
Depuis la VM vm01.adi100.concarnux.fr, lancer RMAN pour la duplication.
[oracle@vm01 YODA]$ rman target sys/manager10@YODA auxiliary sys/manager10@LUKE
Recovery Manager: Release 10.2.0.5.0 - Production on Dim. Déc. 18 15:04:45 2011
Copyright (c) 1982, 2007, Oracle. All rights reserved.
connecté à la base de données cible : YODA (DBID=4127452263)
connexion établie avec la base de données auxiliaire : YODA (non montée)
RMAN> duplicate target database for standby nofilenamecheck dorecover;
RMAn> exit
===== Création des 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
...
Use the following SQL commands on the standby database to create
standby redo logfiles that match the primary database:
ALTER DATABASE ADD STANDBY LOGFILE 'srl1.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl2.f' SIZE 52428800;
ALTER DATABASE ADD STANDBY LOGFILE 'srl3.f' SIZE 52428800;
...
Les standby redolog sont à créer sur la base primaire et la standby database. L'action est effectuée depuis la base primaire, sur la VM vm01.adi100.concarnux.fr
sqlplus sys/manager10@YODA as sysdba
SQL> alter database add standby logfile '/u01/app/oracle/stdblog/YODA/srl1.f' size 50M;
SQL> alter database add standby logfile '/u01/app/oracle/stdblog/YODA/srl2.f' size 50M;
SQL> alter database add standby logfile '/u01/app/oracle/stdblog/YODA/srl3.f' size 50M;
SQL> connect sys/manager10@LUKE as sysdba
SQL> alter database add standby logfile '/u01/app/oracle/stdblog/LUKE/srl1.f' size 50M;
SQL> alter database add standby logfile '/u01/app/oracle/stdblog/LUKE/srl2.f' size 50M;
SQL> alter database add standby logfile '/u01/app/oracle/stdblog/LUKE/srl3.f' size 50M;
===== Paramétrage des destinations d'archives =====
Il s'agit d'indiquer sur chaque base où doivent aller les fichiers de redolog.
sqlplus sys/manager10@YODA as sysdba
SQL> alter system set log_archive_dest_2='service=luke lgwr sync affirm valid_for=( online_logfiles,primary_role) db_unique_name=luke' scope=both;
SQL> alter system set log_archive_dest_3='location=/u01/app/oracle/stdblog/YODA valid_for=( standby_logfiles,standby_role ) db_unique_name=yoda' scope=both;
SQL> connect sys/manager10@LUKE as sysdba
SQL> alter system set log_archive_dest_2='service=yoda lgwr sync affirm valid_for=( online_logfiles,primary_role) db_unique_name=yoda' scope=both;
SQL> alter system set log_archive_dest_3='location=/u01/app/oracle/stdblog/LUKE valid_for=( standby_logfiles,standby_role ) db_unique_name=luke' scope=both;
Comme le processus de transfert est LGWR, il faut indiquer la destination du standby redolog dans log_archive_dest_3. En cas d'utilisation de ARCH il faut utiliser standby_archive_dest.
===== Recouvrement de la standby database =====
C'est la dernière étape, il s'agit de demander à la base standby LUKE de générer toute les transactions de la base YODA en application immédiate. la base LUKE doit être en mode MOUNT.
sqlplus sys/manager10@LUKE as sysdba
SQL> recover managed standby database using current logfile disconnect;
L'option disconnect est indispensable pour détacher la session oracle après activation.
Le dataguard est opérationnel.
==== Tester la configuration ====
Sur la base primaire provoquer deux switches de redolog et controler le numéro de séquence. Depuis la base standby vérifier que le numéro de séquence est identique.
sqlplus sys/manager10@YODA as sysdba
SQL> alter system switch logfile;
SQL> alter system switch logfile;
SQL> select sequence#, to_char( first_time, 'DD/MM/YYYY HH24:MI') first, to_char( next_time, 'DD/MM/YYYY HH24:MI') next, applied from v$archived_log order by sequence#;
SQL> connect sys/manager10@LUKE as sysdba
SQL> select sequence#, to_char( first_time, 'DD/MM/YYYY HH24:MI') first, to_char( next_time, 'DD/MM/YYYY HH24:MI') next, applied from v$archived_log order by sequence#;
Les deux requêtes suivantes permettent de suivre l'avancement du recouvrement.
SQL> col dest_name format a20
SQL> col error format a40
SQL> select dest_name, target, status, error from v$archive_dest;
DEST_NAME TARGET STATUS ERROR
-------------------- ------- --------- ----------------------------------------
LOG_ARCHIVE_DEST_1 PRIMARY VALID
LOG_ARCHIVE_DEST_2 STANDBY VALID
LOG_ARCHIVE_DEST_3 PRIMARY VALID
LOG_ARCHIVE_DEST_4 PRIMARY INACTIVE
LOG_ARCHIVE_DEST_5 PRIMARY INACTIVE
LOG_ARCHIVE_DEST_6 PRIMARY INACTIVE
LOG_ARCHIVE_DEST_7 PRIMARY INACTIVE
LOG_ARCHIVE_DEST_8 PRIMARY INACTIVE
LOG_ARCHIVE_DEST_9 PRIMARY INACTIVE
LOG_ARCHIVE_DEST_10 PRIMARY INACTIVE
10 ligne(s) sélectionnée(s).
SQL> select sequence#, process, status from v$managed_standby;
SEQUENCE# PROCESS STATUS
---------- --------- ------------
15 ARCH CLOSING
14 ARCH CLOSING
16 LGWR WRITING
SQL>
==== Tester le basculement ====
Sur la base YODA se connecter alice et insérer une ligne dans la table personne.
sqlplus alice/ecila@YODA
SQL> insert into personne values ( '04','Denise','Richard');
SQL> commit;
SQL> select * from personne;
CO PRENOM NOM
-- --------------- ---------------
01 Alice Cooper
02 Bob Woodward
03 Charles Aznavour
04 Denise Richard
SQL>
==== Provoquer le switchover ====
sqlplus sys/manager10@YODA as sysdba
SQL> alter database commit to switchover to standby with session shutdown;
SQL> connect sys/manager10@LUKE as sysdba
SQL> alter database commit to switchover to primary with session shutdown;
SQL> shutdown immediate;
SQL> startup;
SQL> select * from alice.personne;
CO PRENOM NOM
-- --------------- ---------------
01 Alice Cooper
02 Bob Woodward
03 Charles Aznavour
04 Denise Richard
SQL>
Il faut de plus placer la base YODA en mode MOUNT et demander le recouvrement depuis LUKE
sqlplus sys/manager10@YODA as sysdba
SQL> shutdown immediate;
SQL> startup mount;
SQL> recover managed standby database using current logfile disconnect;
SQL> exit
======= Finalisation du dataguard ======
Dans cette configuration, le dataguard n'est pas pleinement opérationnel, il manque certains automatismes. Il importe de paramétrer la récupération automatique des différences ( gap ) entre les deux bases, pour celà on utilise un processus supplémentaire nommé FAL ( Fetch Archive Log ). Son paramétrage est simple.
* Le paramètre fal_server est le service réseau pour pouvoir récupérer les redologs
* Le paramètre fal_client est le service réseau pour pouvoir envoyer les redologs
Sur la base YODA
sqlplus sys/manager10@yoda as sysdba
SQL> alter system set fal_server='LUKE' scope=both;
SQL> alter system set fal_client='YODA' scope=both;
SQL> alter system set log_archive_config='dg_config=(YODA,LUKE)' scope=both;
Sur la base LUKE
sqlplus sys/manager10@luke as sysdba
SQL> alter system set fal_server='YODA' scope=both;
SQL> alter system set fal_client='LUKE' scope=both;
SQL> alter system set log_archive_config='dg_config=(YODA,LUKE)' scope=both;
===== Modification du stockage =====
Il s'agit d'un point plus délicat, actuellement notre dataguard gère le transfert correct des transactions. Une base n'est pas figée, il est possible que suite à un basculement sur la standby, des fichiers soient créés. Ceci ne pose pas de difficulté, car le paramètre standby_management_file='AUTO' gère cette situation.
Il y a toutefois un "hic" dans notre configuration.
Si la base primaire est LUKE et qu'un fichier est créé ainsi :
SQL> alter tablespace data_alice add datafile '/u01/app/oracle/oradata/LUKE/data_alice_02.dbf' size 5M;
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 :
* db_file_name_convert
* log_file_name_convert
Il s'agit en fait de faire la même manipulation que lors de la création de LUKE à partir de YODA, mais dans l'autre sens.
sqlplus sys/manager10@yoda as sysdba
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> shutdown immediate;
SQL> startup mount;
SQL> recover managed standby database using current logfile disconnect;
SQL> exit;
==== Cas des tempfiles ====
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 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
...
Dictionary check complete
*********************************************************************
WARNING: The following temporary tablespaces contain no files.
This condition can occur when a backup controlfile has
been restored. It may be necessary to add files to these
tablespaces. That can be done using the SQL statement:
ALTER TABLESPACE ADD TEMPFILE
Alternatively, if these temporary tablespaces are no longer
needed, then they can be dropped.
Empty temporary tablespace: TEMP_BOB
*********************************************************************
...
====== Mode de protection du dataguard ======
Ils sont au nombre de 3 :
* Maximum Performance : C'est le niveau par défaut. Le transport des transactions est assuré par le processus ARCH. Si la base de secours devient indisponible, il ne se passe rien.
* Maximum Protection : Dans ce mode le transport des transactions est assuré par le processus LGWR; Si la base de secours devient indisponible, tout s'arrête. Ce mode est appelé aussi aucune perte de donnée ( No Data Loss ).
* Maximum Avalability : C'est un mode intermédiaire. En fonctionnement normal le transport des transaction se fait via LGWR, si la base de secours vient à ne plus être disonible, le transport est assuré par ARCH.
La requête suivante, passée sur la base YODA ( primaire ) donne le niveau de protection.
SQL> select protection_mode, protection_level from v$database;
PROTECTION_MODE PROTECTION_LEVEL
-------------------- --------------------
MAXIMUM PERFORMANCE MAXIMUM PERFORMANCE
Pour activer le mode Maximum Avalability, l'action se fait sur la base primaire ( YODA )
SQL> alter database set standby database to maximize availability;
Base de données modifiée.
SQL> select protection_mode, protection_level from v$database;
PROTECTION_MODE PROTECTION_LEVEL
-------------------- --------------------
MAXIMUM AVAILABILITY RESYNCHRONIZATION
Au bout d'un temps le synchronisation des bases se termine et le résultat de la même requête est le suivant :
SQL> select protection_mode, protection_level from v$database;
PROTECTION_MODE PROTECTION_LEVEL
-------------------- --------------------
MAXIMUM AVAILABILITY MAXIMUM AVAILABILITY
====== Mise en place du broker ======
Il s'agit d'un utilitaire ligne de commmande ( dgmgrl ) permettant la configuration simple du dataguard et d'effectuer des basculement. Attention toutes les phases exposés précédement pour la mise en place de l'architecture dataguard doivent être faites.
===== Activation du broker =====
L'activation du broker se fait sur chaque base en initialisant le paramètre dg_broker_start à true.
sqlplus /nolog
SQL> connect sys/manager10@yoda as sysdba
SQL> alter system set dg_broker_start=true scope=both;
SQL> connect sys/manager10@luke as sysdba
SQL> alter system set dg_broker_start=true scope=both;
SQL> exit;
Il faut de plus modifier la configuration listener de chaque base en intégrant la definition du service pour chaque base du dataguard. Ce service est de la forme ////_DGMGRL.
Exemple de listener.ora sur vm01.adi100.concarnux.fr, a adapter sur vm02.adi102.concarnux.fr.
LISTENER =
(DESCRIPTION_LIST =
(DESCRIPTION =
(ADDRESS=(PROTOCOL = TCP)(HOST = vm01.adi100.concarnux.fr )(PORT = 1521))
)
)
SID_LIST_LISTENER =
(SID_LIST=
(SID_DESC =
(GLOBAL_DBNAME = YODA)
(ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1)
(SID_NAME = YODA)
)
(SID_DESC =
(GLOBAL_DBNAME = YODA_DGMGRL)
(ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1)
(SID_NAME = YODA)
)
(SID_DESC =
(GLOBAL_DBNAME = LUKE_DGMGRL)
(ORACLE_HOME = /u01/app/oracle/product/10.2.0/db_1)
(SID_NAME = LUKE)
)
)
Il faut recharger la configuration des listener
lsnrctl reload
L'option reload évite l'arrêt du listener, les connexions clientes sont donc maintenues.
===== Configuration du broker =====
En ligne de commande sur vm01.adi100.concarnux.fr, lancer dgmgrl
dgmgrl
DGMGRL for Linux: Version 10.2.0.5.0 - 64bit Production
Copyright (c) 2000, 2005, Oracle. All rights reserved.
Bienvenue dans DGMGRL, tapez "help" pour obtenir des informations.
DGMGRL> connect sys/manager10@yoda
Connexion établie
DGMGRL>
Créer la configuration
DGMGRL> create configuration 'JEDI' as primary database is YODA connect identifier is YODA;
DGMGRL> add database LUKE as connect identifier is LUKE maintained as physical;
DGMGRL> enable configuration;
La phase enable est un peu longue.
Vérifier la configuration
DGMGRL> show configuration;
Utiliser le broker, configure automatique le dataguard en mode Maximum performance. Si ce n'est pas le souhait, il faut le modifier.
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.
Au bout d'un temps la configuration s'affiche :
DGMGRL> show configuration
Configuration
Name: JEDI
Enabled: YES
Protection Mode: MaxAvailability
Fast-Start Failover: DISABLED
Databases:
yoda - Primary database
luke - Physical standby database
Statut actuel de "JEDI":
SUCCESS
DGMGRL>
===== Utilisation du broker =====
L'utilisation de dgmgrl facilite les tâches de basculement, ainsi pour passer LUKE en primaire, il suffit d'une seule commande:
DGMGRL> switchover to luke
Permutation de bases de données. Veuillez patienter...
L'opération requiert l'arrêt de l'instance "YODA" sur la base de données "YODA".
Arrêt de l'instance "YODA"...
ORA-01109: base de données non ouverte
Base de données démontée.
Instance ORACLE arrêtée.
L'opération requiert l'arrêt de l'instance "LUKE" sur la base de données "luke".
Arrêt de l'instance "LUKE"...
ORA-01109: base de données non ouverte
Base de données démontée.
Instance ORACLE arrêtée.
L'opération requiert le démarrage de l'instance "YODA" sur la base de données "YODA".
Démarrage de l'instance "YODA"...
Instance ORACLE lancée.
Base de données montée.
L'opération requiert le démarrage de l'instance "LUKE" sur la base de données "luke".
Démarrage de l'instance "LUKE"...
Instance ORACLE lancée.
Base de données montée.
La permutation de bases de données a réussi. La nouvelle base principale est "luke".
DGMGRL> show configuration
Configuration
Name: JEDI
Enabled: YES
Protection Mode: MaxPerformance
Fast-Start Failover: DISABLED
Databases:
YODA - Physical standby database
luke - Primary database
Statut actuel de "JEDI":
SUCCESS
DGMGRL>
====== Failover, perte de la base primaire ======
Cette situation est presque la justification principale du dataguard, dans notre exemple nous allons simuler la perte de la base YODA et l'activation en tant que base primaire de LUKE afin de poursuivre l'activité le temps du dépannage.
Simuler la perte de YODA
sqlplus sys/manager10@yoda as sysdba
SQL> shutdown abort;
SQL> exit;
Activation de LUKE en base primaire
sqlplus sys/manager10@luke as sysdba
SQL> recover managed standby database cancel;
SQL> alter database activate standby database;
SQL> shutdown immediate;
SQL> startup;
SQL> exit;
Avec le broker c'est encore plus simple
dgmgrl
DGMGRL> connect sys/manager10@luke
DGMGRL> failover to luke;
DGMGRL>
====== Conclusion ======
Bien que j'ai utilisé deux VM, cet exemple est facilement transposable avec des serveurs réels. Le cas présenté ici est la réplique exacte du site de production d'un des mes clients aux volumes de données près ). La principale difficulté avec le dataguard est dans la configuration Oracle*Net. Il faut donc y apporter un soin très particulier.