Discussion :

[Ikebukuro]

Hello,

J'ai besoin qu'on éclaire ma lanterne car je me suis pris la tête avec un tablespace supprimé, impossible à récupérer.

Est-ce que dans le cas où je supprime un tbs, il faut que je restaure d'abord un control file référençant ce tbs dans le cas où je n'ai pas de catalogue RMAN?
Je dis ça car je n'ai pas pu restaurer mon tbs, même en utilisant une sauvegarde où il est bien présent. Le pb est que ce tbs n'est plus connu du référentiel RMAN, à savoir le control file, donc même si j'utilise une bonne sauvegarde, RMAN n'utilise pas les infos pour restaurer mon tbs.

Autre question : quand je fais un RECOVER au niveau du CDB$ROOT, on est d'accord pour dire que le RECOVER s'applique à toutes les PDB et au CDB$ROOT? Est-il possible de faire un RECOVER que au niveau d'une PDB? J'ai eu des messages d'erreur disant que le RECOVER n'était pas possible dans une PDB mais c'était visiblement l'option utilisée qui interdisait cela.

[pachot]

Bonjour,
Oui effectivement, pour faire un RESTORE TABLESPACE, RMAN doit connaître le tablespace et ses datafiles. Il est conseillé d'activer l'autobackup du control file pour en avoir toujours un à jour.
Le redo, donc le recovery, est au niveau CDB. Et oui, un RECOVER DATABASE fait le recovery de toute la CDB, CDB$ROOT et toutes les PDBs.
Cordialement,
Franck.

[Ikebukuro]

Merci pour la réponse Franck.

Donc, dans mon cas, il faut que je restaure un ancien control file avant de pouvoir faire un restore incomplet de ma PDB (jusqu'au SCN correspondant au DROP TABLESPACE), on est d'accord sinon RMAN ne connaîtra jamais mon tbs à restaurer?

Autre point : c'est moi ou c'est choquant que le RECOVER DATABASE se fasse au niveau du CDB$ROOT et donc impacte toutes les PDB de mon container alors que je n'ai un problème que sur une PDB et une seule? En clair, je risque, pour corriger un pb dans une PDB, de créer des pbs dans d'autres PDB (recréer des tbs, en supprimer...) avec ce RECOVER.

[pachot]

Bonjour,
L'idée n'est pas de restaurer sur la base courante. On ne peut pas avoir des tablespaces (ou PDBs) à des point-in-time différents. Il faut utiliser une instance auxiliaire et RMAN automatisé tout ça avec PDBPITR et TSPITR.

[Ikebukuro]

Aïe aïe aïe, c'est ce que je me disais en trainant sur le net, c'est pas simple du tout comme opération. En tout cas tu me confirmes que je dois faire au moins du TSPITR...

Si je comprends bien, je dois avoir une base de données à part (que tu appelles auxiliaire), en plus de ma PDB courante. Et c'est dans cette base auxiliaire que je vais recréer une partie de ma PDB (via PDBPITR) et mon tablespace supprimé (via TSPITR) pour retrouver ma PDB à un état du passé.

Et ensuite, il faut que je fasse un datapump export/import de mon tablespace de la base auxiliaire vers la PDB principale?

[EDIT]
Finalement, ce site me semble bien mais, ouf, c'est chaud
http://www.oracle.com/webfolder/tech.../pdb_pitr.html

[pachot]

Bonjour,

Finalement, ce site me semble bien mais, ouf, c'est chaud
http://www.oracle.com/webfolder/tech.../pdb_pitr.html

Pas tant que ça. RMAN automatise tout.
J'ai droppé le tablespace DEMO de PDB1 avant 2017-08-27 16:34:14.
Une seule commande sous RMAN me l'a récupérée:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

RMAN> recover tablespace PDB1:DEMO until time "timestamp '2017-08-27 16:34:14'" auxiliary destination '/u01/app/oracle/tmp';

Essaie sur une base de test, tu verras défiler tout ce qui est fait par RMAN: création d'une instance auxiliaire, restore de SYSTEM, SYSAUX,UNDO pour CDB$ROOT et PDB1, et restore de DEMO de PDB1, recover, tablespace en read-only, transportable tablespace avec data pump, etc.

Cordialement,
Franck.