ORA-19705 ou comment perdre le plus de temps possible

Je suis tombée par hasard sur une erreur ORA-19705 "tag value exceeds maximum length of 31 characters". J'ai donc appris à mes dépends qu'un tag de sauvegarde RMAN ne peut pas faire plus de 31 caractères.
Cela ne m'aurait pas posé de problème si RMAN me l'avait dit AU DEBUT de la sauvegarde, mais ce petit plaisantin a attendu d'avoir sauvegardé mes 100 Go de données pour planter tout à la fin!

La solution

Comme vous vous en doutez, la solution a été de réduire la taille de mon tag de sauvegarde, quitte à ce qu'il soit moins précis...
Tout ça pour ça!

D'un autre côté, si je n'avais pas perdu du temps aujourd'hui pour cette broutille, je n'aurai peut-être pas aussi bien retenu qu'un tag ne doit pas faire plus de 31 caractères!

Duplicate : RMAN-06217 et RMAN-04006

Vous avez une nouvelle machine qui doit héberger une standby et vous voulez qu'rman s'en occupe tout seul comme il sait si bien le faire. Vous avez donc créé un pfile minimal et avez démarré l'instance. la base est en nomount. (Ben oui, elle peut pas aller plus loin, y a pas de control file.) Les fichiers tnsnames et de mots de passe sont OK. Le listener tourne, bref tout marche, sauf que non!

Arrivée de la RMAN-06217

Vous tentez donc une connexion rman comme ça : (Dans mes exemples la primaire s'appelle rachel et la standby trenton)

rman target sys/xxx@rachel auxiliary /

et ça semble marcher :

Recovery Manager: Release 11.2.0.1.0 - Production on Mon Oct 3 10:25:57 2011
Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.
connected to target database: RACHEL (DBID=YYY)
connected to auxiliary database: TRENTON (not mounted)
RMAN

puis, bous lancez votre duplicate et arrive l'erreur fatidique (sans avoir été invitée):

run 
{
allocate auxiliary channel t1 type disk;
allocate channel t2 type disk;
duplicate target database for standby from active database password file spfile;
}

using target database control file instead of recovery catalog
allocated channel: t1
channel t1: SID=95 device type=DISK

allocated channel: t2
channel t2: SID=13 device type=DISK

Starting Duplicate Db at 03-OCT-11
released channel: t1
released channel: t2
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 10/03/2011 10:26:15
RMAN-06217: not connected to auxiliary database with a net service name

Arrivée de la RMAN-04006

Vous remplissez donc consciencieusement votre tnsnames.ora. Vous faites même un petit tnsping pour être sûr :

tnsping trenton

TNS Ping Utility for Linux: Version 11.2.0.1.0 - Production on 03-OCT-2011 10:36:03

Copyright (c) 1997, 2009, Oracle.  All rights reserved.

Used parameter files:
/admin/oracle/network/admin/sqlnet.ora

Used TNSNAMES adapter to resolve the alias
Attempting to contact (DESCRIPTION = (ADDRESS = (PROTOCOL = TCP)(HOST = yyy)(PORT = 1521)) (CONNECT_DATA = (SERVER = DEDICATED) (SERVICE_NAME = TRENTON)))
OK (0 msec)

Fiers de vous, vous lancez donc la commande qui doit marcher :

rman target sys/xxx@rachel auxiliary sys/xxx@trenton

Recovery Manager: Release 11.2.0.1.0 - Production on Mon Oct 3 10:27:25 2011

Copyright (c) 1982, 2009, Oracle and/or its affiliates.  All rights reserved.

connected to target database: RACHEL (DBID=YYY)
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-00554: initialization of internal recovery manager package failed
RMAN-04006: error from auxiliary database: ORA-12528: TNS:listener: all appropriate instances are blocking new connections

Et le pire, c'est que c'est logique! La BDD secondaire n'a pas pu s'enregistrer auprès du listener (ben oui, elle est toujours à l'état nomount), on ne peut donc pas se connecter en utilisant un service name!

La solution

D'après la note metalink Connection to Auxilary using connect string failed with ORA-12528 (Doc ID 419440.1) (Attention, authentification nécessaire), il faut modifier le tnsnames comme ça :

TRENTON =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = yyy)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = TRENTON)
      (UR=A)
    )
  )

Les commandes Rman

Je ne sais pas de quelle planète vient le gars qui a inventé les commandes rman, mais c'est pas la même que la mienne! Je galère pour retrouver la syntaxe des commandes à chaque fois.

En passant, c'est pas génial qu'Oracle n'ai pas prévu une certaine cohérence entre ses outils, mais bon, peut-être en 13c ?

Bref, voilà le lien vers la doc Oracle 11g pour les commandes rman : http://download.oracle.com/docs/cd/E11882_01/backup.112/e10643/rcmcomma005.htm

Archive logs

Ce qu'on appelle couramment des archive logs en Oracle sont en fait des archives des redo logs. C'est l'équivalent des WAL de postgreSQL.

Purge

Bien sûr ces archive logs s'amoncellent; Le mieux est de purger les fichiers obsolètes grâce à la commande suivante (sous Rman).

DELETE OBSOLETE;

(Hé oui, des fois Oracle, c'est simple).
Le mieux est de rajouter cette commande après chaque sauvegarde.
Si Oracle était totalement planté suite à full, il y a de grandes chances qu'rman refuse de se connecter à votre base. Vous pouvez alors supprimer les fichiers les plus anciens à la main (sous ASM ou sur filesystem) et ensuite n'oubliez surtout pas d'exécuter cette commande :

CROSSCHECK ARCHIVELOG ALL

(Sous ASM, les archive logs sont "cachés" sous des répertoires ayant pour format yyyy_mm_dd).
Si vous ne trouvez pas d'archive logs obsolètes et que vous avez vraiment besoin de place, vous pouvez aussi tenter la commande suivante (en vous assurant que le chef de projet est conscient des risques) :

DELETE ARCHIVELOG ALL COMPLETED BEFORE 'your_date';

Politique de retention

Comment fait Rman pour savoir si un fichier est obsolète ? C'est là qu'il faut aller voir du côté de la politique de rétention. Vous pouvez soit définir un nombre de fichiers à conserver, soit définir une fenêtre de temps à conserver.
On peut voir sa politique de rétention en faisant

SHOW RETENTION POLICY;

Par défaut, Rman considère qu'un seul backup de chaque fichier est nécessaire.
Voilà comment lui dire de conserver n version(s) de chaque fichier :

CONFIGURE RETENTION POLICY TO REDUNDANCY n;

Voilà pour donner une durée de rétention de n jours :

CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF n DAYS;

Politique de suppression

Ah bah oui, pourquoi il ferait pas tout tout seul notre Rman adoré?
Par défaut la politique de suppression n'est pas settée. Vous pouvez décider par exemple de supprimer tous les archives logs d'une instance maître s'ils ont été appliqués sur la standby:

CONFIGURE ARCHIVELOG DELETION POLICY TO APPLIED ON ALL STANDBY;

Restaure d'une sauvegarde full avec Rman

Ça peut sembler le B.A.-BA mais c'est pas si simple...

Prérequis

Vous aurez besoin du DBID de votre base avant de pouvoir faire la sauvegarde... Vous pouvez le récupérer grâce à cette simple requête SQL (possible dès l'état MOUNT):

SELECT dbid FROM v$database;

Et si la base ne peut pas être montée (pb de controlfiles par exemple) ?
J'espère que vous avez gardé les logs de votre sauvegarde full... C'est ce qui devrait vous sauver!

connected to target database: YYY (DBID=xxx)

La procédure

Toutes les actions suivantes peuvent être effectuées sous rman. il n'est pas nécessaire de se connecter à sqlplus pour effectuer les startup ou open de la base de données. On suppose que la base de données est arrêtée et droppée.

1. Settage du dbid

SET dbid=xxx;

2. démarrage en NOMOUNT de la base de données

STARTUP NOMOUNT;

3. Restaure des controlfiles

RUN 
{
ALLOCATE CHANNEL t1 TYPE='your_type';
RESTORE CONTROLFILE FROM TAG 'your_tag';
RELEASE CHANNEL t1;  
}

4. Passage de la base en mode MOUNT

ALTER DATABASE MOUNT;

5. Restore de la base

RUN 
{ 
ALLOCATE CHANNEL t1 TYPE='your_type';  
RESTORE DATABASE FROM TAG 'your_tag'; 
RELEASE CHANNEL t1;  
}

6. Ouverture de la base

ALTER DATABASE OPEN RESETLOGS;

Dans mon exemple, la sauvegarde full a a été faite à froid avec un tag.