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

NID-00135 et ORA-01092

Oui, je sais on ne doit pas utiliser nid dans la vie normale d'une base de données, mais bon si l'outil existe c'est pour qu'on l'utilise, non ?

De plus, C'était vraiment nécessaire. Je ne vais pas détailler ici le pourquoi du comment, mais j'avais besoin de cloner une base à partir d'une standby et le rman duplicate ne fonctionne pas à partir d'une standby... J'expliquerai dans un prochain poste comment nous nous en sommes sorti (un projet de cette ampleur, ça ne peut être qu'un travail d'équipe!!)

A la pêche aux infos

Dans la doc Oracle, je trouve ça :

NID-00135: There are number active threads
Cause: is that the database crashed the last time it was shut down.
Action: Ensure that all threads are closed before retrying the operation. Start and open the database to perform crash recovery, then shut down with the NORMAL or IMMEDIATE options to close it cleanly. Finally, try running the utility again.

C'est parti!

Bon, ben allons-y gaiement, ma base était bien dans l'état mount, je tente donc ça :

SHUTDOWN IMMEDIATE.
STARTUP;
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;

Et ce petit coquin d'Oracle me sort :

startup

ERROR at line 1:
ORA-01092: ORACLE instance terminated. Disconnection forced

Là, ça sent pas bon du tout...

Re-pêche aux infos

Cette fois-ci, la doc Oracle ne me rassure pas trop :

ORA-01092: ORACLE instance terminated. Disconnection forced
Cause: The instance this process was connected to was terminated abnormally, probably via a shutdown abort. This process was forced to disconnect from the instance.
Action: Examine the alert log for more details. When the instance has been restarted, retry action.

Et c'est pire dans l'alert log :

ORA-00704: bootstrap process failure
ORA-39700: database must be opened with UPGRADE option

Pfff, on dirait que j'ai mis un sacré b***el sur ma base! Que dit la doc ?

ORA-39700: database must be opened with UPGRADE option
Cause: A normal database open was attempted, but the database has not been upgraded to the current server version.
Action: Use the UPGRADE option when opening the database to run catupgrd.sql (for database upgrade), or to run catalog.sql and catproc.sql (after initial database creation).

Résolution ?

Bon, ben c'est reparti :

SHUTDOWN IMMEDIATE.
STARTUP UPGRADE;
SHUTDOWN IMMEDIATE;
STARTUP MOUNT;

ouf c'est passé!

Un petit nid ?

Cette fois-ci nid s'est rédoulé sans problème... Nid me prévient gentiment de ce qu'il me reste à faire

Database name changed to ISI0RCT.
Modify parameter file and generate a new password file before restarting.
Database ID for database ISI0RCT changed to 3511798175.
All previous backups and archived redo logs for this database are unusable.
Database is not aware of previous backups and archived logs in Recovery Area.
Database has been shutdown, open database with RESETLOGS option.
Succesfully changed database name and ID.
DBNEWID - Completed succesfully.

Et on repart!

Après modification du dbname dans le pfile, j'ai pu redémarrer ma base correctement!

ASM a perdu ses disques après un reboot

J'ai rencontré ce problème sur du Red Hat 5.3, 5.4 et 5.5.

Symptômes

Je reboote la machine et oracleasm ne voit plus aucun disque! Mes disques sont des lv. Je n'ai pas rencontré ce problème avec des LUN.

Correction

C'est tout bête : il suffit de mettre en commentaire la ligne KERNEL=="dm-[0-9]*", ACTION=="add", OPTIONS+="ignore_device du fichier /etc/udev/rules.d/90-dm.rules.

C'est vraiment bête mais si on ne fait pas ça, ASM ne cherche ses disques que sous /dev/dm*.

Pour aller plus loin

Vous pouvez consulter cette page de blog : http://www.myoraclesupports.com/content/elrh-5-oracleasm-listdisks-not-showing-devices-after-reboot-or-restart
Ou le bug 6736803 https://support.oracle.com/CSP/main/article?cmd=show&type=BUG&id=6736803