Mettre en place un observer

Bon, admettons que vous ayiez un dataguard qui fonctionne bien. C'est bien. Mais si ça plante à 2h00 du matin, faut vous appeler pour faire la bascule ? Hé non, y a observer pour ça, mais faut le configurer d'abord...

Standby OK

Commencez par vérifier que votre standby applique bien les redos de la primaire... (cf le billet Vérifier qu'une standby applique bien les logs)

LogXptMode

Il faut que la propriété LogXptMode soit settée à SYNC pour chaque base de données. La requête se lance sous dgmgrl.

SHOW DATABASE 'DB' 'LogXptMode';

Si la propriété n'est pas à SYNC, mettez-la à cette valeur :

EDIT DATABASE 'DB' SET PROPERTY 'LogXptMode'='SYNC';

Atention cette manipulation est à faire sur le maître et sur l'esclave!

FastStartFailoverTarget

Oui, c'est une succession de variable à setter... Je suis désolée. Cette option n'est à modifier que s'il y a ambiguïté sur la standby sur laquelle basculer.
Pour connaître la valeur de FastStartFailoverTarget, il faut faire ça:

SHOW DATABASE 'DB' 'FastStartFailoverTarget';

Pour modifier la valeur (sur la primaire uniquement) :

EDIT DATABASE 'DB' SET PROPERTY FastStartFailoverTarget='your_value';

Mode de protection

Il est temps de passer de 'Maximum performance' à 'Maximum availability'.

EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;

Flashback

C'est le moment d'activer le flashback sur vos bases. Pour savoir si c'est déjà fait (sous sqlplus sur chacune des bases) :

SELECT flashback_on FROM v$database;

Profitez-en pour vérifier aussi les valeurs des paramètres suivantes:

SHOW PARAMETER undo_retention;
SHOW PARAMETER undo_management;
SHOW PARAMETER db_flashback_retention_target;
SHOW PARAMETER db_recovery_file_dest_size;

SHOW PARAMETER db_recovery_file_dest;

Si c'est pas fait, utilisez les ordres ci-dessous (pour le maître):

ALTER SYSTEM SET undo_retention=3600 SCOPE=SPFILE;
ALTER SYSTEM SET undo_management='AUTO' SCOPE=SPFILE;
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;
SHOW PARAMETER undo;
ALTER SYSTEM SET db_flashback_retention_target=4320 SCOPE=BOTH;
ALTER DATABASE ARCHIVELOG;
ALTER SYSTEM SET db_recovery_file_dest_size=size;
ALTER SYSTEM SET db_recovery_file_dest=directory-specification;
ALTER DATABASE FLASHBACK ON;
ALTER DATABASE OPEN;

Pour l'esclave, il faut arrêter l'apply (puisque la base est déjà montée) via dgmgrl comme ça :

EDIT DATABASE db SET STATE='APPLY-OFF';

Puis on le remet en place :

EDIT DATABASE db SET STATE='APPLY-ON';

Démarrer l'observer

Il vaut mieux spécifier un fichier de log:

dgmgrl -logfile Your_logfile

Pour démarrer l'observer, il faut faire

start observer;

Dgmgrl ne vous rendra pas la main. Pour cette raison, il est préférable d'encapsuler tout ça dans un script lancé ensuite avec un nohup.

Activer le Fast-start failover

C'est ce qui permet de basculer rapidement, comme son nom l'indique. Il faut faire cette commande sous dgmgrl.

ENABLE FAST_START FAILOVER;

Vous pouvez vérifier que tout va bien en faisant ça sous dgmgrl:

SHOW FAST_START FAILOVER;

Ou ça sous sqlplus (sur chacune des bases) :

SELECT fs_failover_status, fs_failover_current_target, fs_failover_threshold, fs_failover_observer_present,fs_failover_observer_host FROM v$database;

Pour en savoir plus

la doc Oracle dispo ici : http://download.oracle.com/docs/cd/E11882_01/server.112/e17023/cli.htm#DGBKR3430

Faire redémarrer l'observer au reboot de la machine

Ben oui, c'est bête. Vous avez installé votre Data Guard, votre observer est démarré, tout baigne! Mais la machine reboot et l'observer ne se lance pas automatiquement! Ben oui, vous avez oublié ce point de détail.

Scripter

On commence par faire un script pour démarrer l'observer. (Appelons-le start_observer.sh, au hasard.)

export PATH="$PATH:oracle_home/bin";
export ORACLE_HOME="oracle_home";

dgmgrl -logfile logfile  << eof
connect /@alias
stop observer;
start observer;
eof

Tant qu'on y est, on va aussi scripter l'arrêt :

export PATH="$PATH:oracle_home/bin";
export ORACLE_HOME="oracle_home";

dgmgrl -logfile logfile  << eof
connect /@alias
stop observer;
eof

On remarquera l'utilisation intelligente des wallets ;-).

init.d

On va ensuite dans le magnifique répertoire init.d et on y met notre superbe script (dont on est très fier(e)), son petit nom est oraobserver chez moi) :

#!/bin/bash
### BEGIN INIT INFO
# Provides: oraobserver
# Required-Start:
# Required-Stop:
# Default-Start:  3 4 5
# Default-Stop: 0 1 6
# Short-Description: Lance l'observer Oracle
# Description: Lance l'observer de la config Data Guard
### END INIT INFO
#
# source function library
. /etc/rc.d/init.d/functions


RETVAL=0


start() {
echo -n $"Starting Oracle Observer : \n"
nohup /home/oracle/start_obs.sh &
}


stop() {
echo -n $"Stopping Oracle Observer: \n"
/home/oracle/stop_obs.sh
RETVAL=$?
}


restart() {
stop
start
}


case "$1" in
start)
start
;;
stop)
stop
;;
restart)
restart
;;
*)
echo $"Usage: $0 {start|stop|restart}"
exit 1
esac


exit $RETVAL

On n'oublie pas de rendre le fichier exécutable.

Test

On peut tester le script en faisant :

/etc/init.d/oraobserver stop
/etc/init.d/oraobserver start
/etc/init.d/oraobserver restart

chkconfig

Ensuite, il suffit de dire à chkconfig d'ajouter ce service au démarrage :

chkconfig --add oraobserver

On peut ensuite vérifier les niveaux de démarrage en faisant :

chkconfig --list

Vérifier qu'une standby applique bien les logs (Oracle)

J'ai testé ces vérifications sur une standby physique, je ne suis pas sûre que cela fonctionne sur une standby logique.

Numéro de séquence

On commence par vérifier le numéro de séquence en cours avec cette requête sur le maître et l'esclave :

ARCHIVE LOG LIST

Il va répondre quelque chose de ce genre :

Database log mode              Archive Mode
Automatic archival             Enabled
Archive destination            USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence     2794
Next log sequence to archive   2796
Current log sequence           2796

On peut ensuite demander au maître de changer de numéro de séquence :

ALTER SYSTEM SWITCH LOGFILE;

Et revérifier les numéros de séquence!

Mrp0

Le process qui applique les redos sur la standby s'appelle mrp0. Si vous requêtez la vue v$managed_standby, vous pourrez voir dans quel état il est :

SELECT process, client_process, sequence#, status FROM V$managed_standby WHERE process='MRP0';

S'il vous répond "no rows selected", il faut le démarrer avec un ordre du genre :

ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;

S'il vous répond "Applying log", tout va bien.

Recovery mode

Vous pouvez vérifier le "recovery mode" ainsi :

SELECT recovery_mode FROM v$archive_dest_status WHERE dest_id=2 ;

Quelques statistiques

Voici deux requêtes vous permettant de récupérer des stats parfois utiles :

SELECT * FROM v$dataguard_stats;
SELECT start_time, item, units, sofar FROM V$recovery_progress ORDER BY 1, 2;