RMAN : création d'une base auxiliaire depuis un backup puis Datapump

Version imprimable

02/11/2020, 17h33
Ikebukuro

RMAN : création d'une base auxiliaire depuis un backup puis Datapump

Salut les DBA,

Je m'arrache les cheveux sur le pb suivant, que je traîne depuis des années :ptdr::ptdr:

Ma base de test (en multi-tenants) n'a pas de catalog RMAN : c'est pas bien mais c'est comme beaucoup de clients.
J'ai créé, sauvegardé puis droppé un tablespace.
Celui-ci n'est plus connu du control file donc le restore/recover est impossible.

Une solution est de restaurer la base dans le passé (faire un PITR) MAIS je ne veux pas car cela signifie perdre toutes les modifications apportées à ma base depuis que j'ai droppé le tablespace.

Ma question est : est-il possible de créer une base auxiliaire depuis mon backup RMAN, puis de faire un expdp et un impdp de mon tablespace de ma base auxiliaire vers ma première base?
Attention, je ne veux pas faire un DUPLICATE depuis ma base actuelle, je veux utiliser ma sauvegarde RMAN pour créer une nouvelle base.

Je sais que cela fonctionne très bien depuis la 12.1 pour une table mais cela ne marche pas pour un tablespace : mes tests ici pour le recover complet d'une table
http://dbaoraclesql.canalblog.com/ar.../38384934.html

Un gros merci pour l'aide.
03/11/2020, 09h01
dell68

Bonjour
Vue que tu es en 18c, si exp/imp est toujours supporté, essaye peut-être de faire une récupération juste avant l'incident ensuite tu ouvre ta base en read only, tu fais exp sur le tablespace supprimé et pour finir
il reste plus qu'à faire une récupération de ta base
Pour ta question : créer une base auxiliaire à partir de ton backup oui
tu pourras regarder url suivante
http://oracleinaction.com/duplicate-db-no-db-conn/
Bonne chance
03/11/2020, 10h42
Ikebukuro

Je te remercie, ça n'a pas l'air si simple que ça mais je regarde dès que je suis calmé (je me suis arraché les cheveux hier pendant au moins trois heures...) et je suis encore très énervé!!!!!!
Et dire que depuis la 12.1 ça marche nickel pour un tbs supprimé mais pour une table...
04/11/2020, 18h41
pachot

Bonjour,
Il s'agit de Performing RMAN Tablespace Point-in-Time Recovery (TSPITR)
https://docs.oracle.com/en/database/...9-C5D855D47571
Et ça peut même être automatisé avec RMAN> TRANSPORT TABLESPACE qui génère un .dmp, les .dbf, et un script pour l'importer
J'ai un exemple sur les 5 premières minutes de: https://www.youtube.com/watch?v=8hLx...l=FranckPachot
Franck.

Salut Franck,

Alors dans la doc Oracle je lis
"Purpose of RMAN TSPITR
...
- To recover dropped tablespaces. In fact, RMAN can perform TSPITR on dropped tablespaces even when a recovery catalog is not used"

Incroyable, je n'ai pas regardé ta vidéo mais j'avais essayé la commande suivante et voilà ce qui se passait, en essayant de faire justement un TSPITR: en clair un RECOVER du tbs avec une base auxiliaire. Tout marche bien, sauf la fin...
Petite précision : quand j'ai supprimé mon tbs, j'ai supprimé en même temps le datafile associé; estc-e que cela empêche le TSPITR? A priori non selon la doc Oracle mais... je ne vois pas pourquoi mon RECOVER TABLESPACE échoue.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
RMAN> RECOVER TABLESPACE ZZTBS until SCN 2168640 auxiliary destination '/u01/oraaux/';
Starting recover at 02-NOV-20
current log archived
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=181 device type=DISK
RMAN-05026: warning: presuming following set of tablespaces applies to specified point-in-time

List of tablespaces expected to have UNDO segments
Tablespace SYSTEM
Tablespace ORCL:SYSTEM
Tablespace ORCL:UNDOTBS1
Tablespace UNDOTBS2

Creating automatic instance, with SID='zBxq'

initialization parameters used for automatic instance:
db_name=ORCL12C
db_unique_name=zBxq_pitr_ORCL12C
compatible=12.2.0
db_block_size=8192
db_files=200
diagnostic_dest=/u01/app/oracle
_system_trig_enabled=FALSE
sga_target=800M
processes=200
db_create_file_dest=/u01/oraaux/
log_archive_dest_1='location=/u01/oraaux/'
enable_pluggable_database=true
_clone_one_pdb_recovery=true
#No auxiliary parameter file used


starting up automatic instance ORCL12C

Oracle instance started

Total System Global Area     838860800 bytes

Fixed Size                     8798312 bytes
Variable Size                239079320 bytes
Database Buffers             583008256 bytes
Redo Buffers                   7974912 bytes
Automatic instance created


List of tablespaces that have been dropped from the target database:
Tablespace ZZTBS

contents of Memory Script:
{
# set requested point in time
set until  scn 2168640;
# restore the controlfile
restore clone controlfile;
 
# mount the controlfile
sql clone 'alter database mount clone database';
 
# archive current online log 
sql 'alter system archive log current';
# avoid unnecessary autobackups for structural changes during TSPITR
sql 'begin dbms_backup_restore.AutoBackupFlag(FALSE); end;';
}
executing Memory Script

executing command: SET until clause

Starting restore at 02-NOV-20
allocated channel: ORA_AUX_DISK_1
channel ORA_AUX_DISK_1: SID=229 device type=DISK

channel ORA_AUX_DISK_1: starting datafile backup set restore
channel ORA_AUX_DISK_1: restoring control file
channel ORA_AUX_DISK_1: reading from backup piece /u01/app/oracle/fast_recovery_area/orcl12c/ORCL12C/autobackup/2020_11_02/o1_mf_s_1055414350_ht0b0yfl_.bkp
channel ORA_AUX_DISK_1: piece handle=/u01/app/oracle/fast_recovery_area/orcl12c/ORCL12C/autobackup/2020_11_02/o1_mf_s_1055414350_ht0b0yfl_.bkp tag=TAG20201102T103910
channel ORA_AUX_DISK_1: restored backup piece 1
channel ORA_AUX_DISK_1: restore complete, elapsed time: 00:00:01
output file name=/u01/oraaux/ORCL12C/controlfile/o1_mf_ht0ck6w8_.ctl
Finished restore at 02-NOV-20

sql statement: alter database mount clone database

sql statement: alter system archive log current

sql statement: begin dbms_backup_restore.AutoBackupFlag(FALSE); end;

Removing automatic instance
shutting down automatic instance 
Oracle instance shut down
Automatic instance removed
auxiliary instance file /u01/oraaux/ORCL12C/controlfile/o1_mf_ht0ck6w8_.ctl deleted
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 11/02/2020 11:05:01
RMAN-06136: ORACLE error from auxiliary database: RMAN-20202: Tablespace not found in the recovery catalog
RMAN-06019: could not translate tablespace name "ZZTBS"

05/11/2020, 20h55
pachot

Citation:

Envoyé par Ikebukuro

RMAN-06136: ORACLE error from auxiliary database: RMAN-20202: Tablespace not found in the recovery catalog
RMAN-06019: could not translate tablespace name "ZZTBS"[/CODE]

Salut. Est-ce que tu est sûr que le tablespace était là au moment tu "until time" auquel tu fais le recover?
Parce que là, le controlfile est bien restauré au SCN 2168640 et il ne connait pas ZZTBS
05/11/2020, 20h57
pachot

et tu es en mutitenant, c'est un tablespace de CDB$ROOT? sinon il faut préfixer le nom du tablespace genre: PDBNAME:TBSNAME
05/11/2020, 22h05
Ikebukuro

Salut Franck,

1) le tbs a été supprimé, mettons le 01/11, et j'ai mis comme date "UNTIL 03/11" par exemple; je ne sais plus pourquoi j'ai fais cela mais est-ce que ça pose un pb de mettre une date supérieure à la date du DROP TABLESPACE? Le RESTORE du datafile se fera via RMAN depuis le backup du 30/10 par exemple et puis le RECOVER s'arrêtera le 01/11 puisqu'il n'y a rien après cette date sur le tbs (puisque supprimé).
2) houlala, effectivement, ce tbs est un tbs d'une PDB, pas du CDB$ROOT... ce serait lié à ça... oh non, tant de temps perdu pour rien... et ça expliquerait le message d'erreur puisque je parle à RMAN d'un tbs inconnu du root... :aie::aie:

Halalalalalala... je suis fatigué, fatigué si c'est ça... MAIS AU MOINS JE PROGRESSE :mrgreen::mrgreen::mrgreen:

Je teste ça ce week-end au plus tard!

UN GROS GROS MERCI, je dormirai mieux ce soir.
05/11/2020, 22h14
pachot

le UNTIL TIME doit être juste avant le DROP
-> pour que le controlfile connaisse le tablespace
-> et le recovery rejoue tout ce qui a été fait sur la base, et refera le DROP TABLESPACE si on dépasse ce point dans le temps

Donc:
1. mettre le nom du PDB devant
2. le UNTIL TIME juste avant le drop
06/11/2020, 09h22
Ikebukuro

Ah oui, le point 1... je me suis fais avoir là-dessus... mais c'est le 2 qui m'aura le plus bloqué...
07/11/2020, 13h20
Ikebukuro

Ca marche :mrgreen::mrgreen::mrgreen::mrgreen::mrgreen:

UN GROS GROS MERCI A TOI FRANCK!!!!!!!!!!!!

L'erreur était bête de ma part mais avec cette nouvelle architecture... tiens, je vais relire la partie RMAN de ton livre 8-)
08/11/2020, 20h16
pachot

Citation:

Envoyé par Ikebukuro

Ca marche :mrgreen::mrgreen::mrgreen::mrgreen::mrgreen:

Cool. Ce sont ces galères qui permettent de mieux comprendre les concepts ;)