Restore From RAC ASM to Standalone FS
- Détails
- Catégorie : Backup/Restore
- Publié le lundi 25 mars 2013 22:16
- Écrit par Administrator
- Affichages : 14358
Dans cet article nous allons voir comment restaurer une base de données en standalone sur filesystem à partir de fichier de backup RMAN, sans connaitre le nom de la base ni sa version exact, et sans savoir si elle était en filesystem et ni si elle était en RAC ou pas.
On ne le sait pas encore, mais dans cet exercice, la base source est une base RAC 11.2.0.3 sous ASM, alors que le serveur de restauration a un moteur oracle Standalone 11.2.0.2 et il n’y a pas d’ASM.
Les bases de données manipulées sont sous linux, mais cela ne change en rien les commandes (SQL et RMAN) sur un autre OS. De plus les bases sont en 11gR2, mais le principe reste le même pour des bases en 11gR1, 10gR2 et 10gR1. En 9i je ne sais pas, je ne connais le RAC sous cette version.
Récupération du nom de la base
Nous avons 6 fichiers de backup dans /backup:
$ ls -l
-rw-r-----. 1 oracle oinstall 24056832 Mar 21 21:53 arc_5
-rw-r-----. 1 oracle oinstall 3584 Mar 21 21:53 arc_7
-rw-r-----. 1 oracle oinstall 18546688 Mar 21 21:53 ctl_11
-rw-r-----. 1 oracle oinstall 98304 Mar 21 21:53 ctl_12
-rw-r-----. 1 oracle oinstall 18546688 Mar 21 21:53 ctl_9
-rw-r-----. 1 oracle oinstall 513761280 Mar 21 21:54 full_6
Ils ne portent pas le nom ni le DBID de la base. Au vu des noms et taille, il y a des backupsets de datafile et/ou archivelog et des backups de controlfile.
Un peu comme dans l’article « astuce », nous démarrons une base BIDON pour avoir une instance oracle capable d’aller lire des fichiers Oracle, et trouver le nom de la base de données.
Nous éditons et enregistrons donc un fichier initBIDON.ora dans $ORACLE_HOME/dbs, avec à l’intérieur une seule ligne :
db_name=BIDON
Ensuite il ne reste plus qu’avec RMAN démarrer l’instance BIDON, restaurer un controlfile et tenter de monter celui-ci :
$ export ORACLE_SID=BIDON
[oracle@oradbm1 backup]$ rman target /
RMAN> startup nomount
RMAN> restore controlfile from '/backup/ctl_9';
Starting restore at 22-MAR-13
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=19 device type=DISK
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:03
output file name=/oracle/11.2.0.3/database/dbs/cntrlBIDON.dbf
Finished restore at 22-MAR-13
SQL> alter database mount;
alter database mount
*
ERROR at line 1:
ORA-01103: database name 'ARKONA' in control file is not 'BIDON'
SQL>shutdown abort
La tentative de monter le controlfile échoue avec un message d’erreur très intéressant: la nom de la base de données stockée dans le controfile s’appelle ARKONA et pas BIDON. Parfait c’est que nous voulions savoir.
Remarque : nous aurions pu deviner la base en essayant de fichier de backup ctl_9, nous aurions vu la chaîne de caractère ARKONA, mais il y avait plusieurs chaînes de caractère. Le plus propre est quand même de lancer la restauration du controlfile.
Restauration des controlfiles et du spfile
Nous ne connaissons pas l’emplacement de la base ARKONA sur son ancien serveur, mais cela n’est pas un problème comme nous le verrons plus tard.
Nous allons restaurer ARKONA entièrement (pour simplifier l’article) dans /oradata/ARKONA.
Nous créons donc un premier fichier pfile initARKONA.ora dans $ORACLE_HOME/dbs avec les 2 lignes suivantes :
db_name=ARKONA
control_files='/oradata/ARKONA/ARKONA01.ctl','/oradata/ARKONA/ARKONA02.ctl'
Nous lançons alors la restauration des controlfiles:
$ export ORACLE_SID=ARKONA
$ rman target /
RMAN> startup nomount
RMAN> restore controlfile from '/backup/ctl_12';
Starting restore at 22-MAR-13
using channel ORA_DISK_1
channel ORA_DISK_1: restoring control file
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 03/22/2013 23:08:20
ORA-19697: standby control file not found in backup set
RMAN> restore controlfile from '/backup/ctl_11';
Starting restore at 22-MAR-13
using channel ORA_DISK_1
channel ORA_DISK_1: restoring control file
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
output file name=/oradata/ARKONA/ARKONA01.ctl
output file name=/oradata/ARKONA/ARKONA02.ctl
Finished restore at 22-MAR-13
Une fois les controlfiles restaurés, nous passons au spfile. Cette étape n’est pas obligatoire, nous pouvons très bien nous en passer. Mais il est intéressant de le restaurer, s’il est bien présent dans les backupsets. Il peut apporter quelques informations plus rapidement que sans, comme si la base est en RAC, en ASM, la version minimal de base grâce un paramètre COMPATIBLE…
RMAN> restore spfile from '/backup/ctl_11';
Starting restore at 22-MAR-13
using channel ORA_DISK_1
channel ORA_DISK_1: restoring spfile from AUTOBACKUP /backup/ctl_11
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of restore command at 03/22/2013 23:09:31
ORA-19687: SPFILE not found in backup set
RMAN> restore spfile from '/backup/ctl_12';
Starting restore at 22-MAR-13
using channel ORA_DISK_1
channel ORA_DISK_1: restoring spfile from AUTOBACKUP /backup/ctl_12
channel ORA_DISK_1: SPFILE restore from AUTOBACKUP complete
Finished restore at 22-MAR-13
RMAN> alter database mount;
RMAN> exit
$ cd ORACLE_HOME/dbs
$ sqlplus / as sysdba
SQL> create pfile='initARKONA.ora' from spfile;
SQL> shutdown abort
Nous avons donc restaurer le spfile, et générer un pfile à partir de celui-ci pour pouvoir le modifier à notre environnement.
Nous éditons donc le initARKONA.ora
$ vi initARKONA.ora
ARKONA1.__db_cache_size=276824064
ARKONA2.__db_cache_size=293601280
ARKONA1.__java_pool_size=4194304
[...]
ARKONA1.__streams_pool_size=0
ARKONA2.__streams_pool_size=0
*.audit_file_dest='/oracle/oraBase/admin/ARKONA/adump'
*.audit_trail='db'
*.cluster_database=true
*.compatible='11.2.0.0.0'
*.control_files='+DATA1/arkona/controlfile/current.256.808003327','+DATA2/arkona/controlfile/current.256.806278451'#Restore Controlfile
*.db_block_size=8192
*.db_create_file_dest='+DATA1'
*.db_create_online_log_dest_1='+DATA1'
*.db_create_online_log_dest_2='+DATA2'
*.db_domain=''
*.db_name='ARKONA'
*.db_recovery_file_dest='+FRA'
*.db_recovery_file_dest_size=8388608000
*.diagnostic_dest='/oracle/oraBase'
ARKONA1.instance_number=1
ARKONA2.instance_number=2
*.log_archive_dest_1='LOCATION=+FRA'
*.log_archive_format='%t_%s_%r.dbf'
*.memory_target=891289600
*.open_cursors=300
*.processes=150
*.remote_listener='racdb-scan:1521'
*.remote_login_passwordfile='exclusive'
ARKONA2.thread=2
ARKONA1.thread=1
ARKONA1.undo_tablespace='UNDOTBS1'
ARKONA2.undo_tablespace='UNDOTBS2'
A la lecture de ce init, nous pouvons en déduire que ARKONA :
- Est en ASM, les paths des fichiers de la base commencent tous par des +
- Est en RAC, cluster_database à TRUE, et autres paramètre renseigné propre au RAC
- Est une base de données de version minimale 11.2.0.0 (paramètre COMPATIBLE). Comme notre moteur installé est un 11.2.0.2, nous pourrons restaurer la base. Mais ensuite, suivant le version du dictionnaire de données il faudra l’upgrader ou la downgrader en 11.2.0.2.
Nous supprimons, tous les paramètres propres à RAC, transformons les chemins ASM en FS, supprimons l’audit standard… et créons évidement les répertoires adéquates.
*.audit_file_dest='/oracle/oraBase/admin/ARKONA/adump'
*.audit_trail='none'
*.compatible='11.2.0.0.0'
*.control_files='/oradata/ARKONA/ARKONA01.ctl','/oradata/ARKONA/ARKONA02.ctl'
*.db_block_size=8192
*.db_domain=''
*.db_name='ARKONA'
*.db_recovery_file_dest_size=8388608000
*.diagnostic_dest='/oracle/oraBase'
*.log_archive_dest_1='LOCATION=/oradata/ARKONA/arch'
*.log_archive_format='%t_%s_%r.dbf'
*.memory_target=891289600
*.open_cursors=300
*.processes=150
*.remote_login_passwordfile='exclusive'
*.undo_tablespace='UNDOTBS1'
Ne pas oublier de supprimer le spfileARKONA.ora.
Préparation à la restauration des datafiles
Maintenant il faut préparer la restauration des datafiles.
Dans un premier temps, il faut informer les controlfiles des backups disponibles dans /backup et aussi leur dire que les anciens backups dans leur ancien emplacement n’existent plus :
$ export ORACLE_SID=ARKONA
$ rman target /
RMAN> statup mount
RMAN> crosscheck backup;
RMAN> delete expired backup;
RMAN> crosscheck archivelog all;
RMAN> delete expired archivelog all;
RMAN> catalog start with '/backup/';
Ensuite comme ils ne vont pas être restaurés dans leur emplacement d’origine, car nous n’avons pas d’ASM, nous allons donc générer le script de restauration alternative.
Pour cela nous récupérons les identifiants des datafiles avec leur path :
$ export ORACLE_SID=ARKONA
$ sqlplus / as sysdba
SQL> statup mount
SQL>SELECT 'SET NEWNAME FOR DATAFILE ' || file# || ' to ''' || name || ''''
FROM V$DATAFILE
WHERE status in ('ONLINE','SYSTEM') ORDER BY file#;
'SETNEWNAMEFORDATAFILE'||FILE#||'TO'''||NAME||''''
--------------------------------------------------------------------------------
SET NEWNAME FOR DATAFILE 1 to '+DATA1/arkona/datafile/system.259.806278461'
SET NEWNAME FOR DATAFILE 2 to '+DATA1/arkona/datafile/sysaux.260.806278481'
SET NEWNAME FOR DATAFILE 3 to '+DATA1/arkona/datafile/undotbs1.261.806278497'
SET NEWNAME FOR DATAFILE 4 to '+DATA1/arkona/datafile/undotbs2.263.806278519'
SET NEWNAME FOR DATAFILE 5 to '+DATA1/arkona/datafile/users.264.806278525'
Restauration et récupération des datafiles
La restauration peut être lancée, en indiquant les nouveaux chemins et nom de datafile (modification en rouge du résultat de la requête précédente)
$ export ORACLE_SID=ARKONA
$ rman target /
RMAN> run {
SET NEWNAME FOR DATAFILE 1 to '/oradata/ARKONA/system01.dbf';
SET NEWNAME FOR DATAFILE 2 to '/oradata/ARKONA/sysaux01.dbf';
SET NEWNAME FOR DATAFILE 3 to '/oradata/ARKONA/undotbs1.dbf';
SET NEWNAME FOR DATAFILE 4 to '/oradata/ARKONA/undotbs2.dbf';
SET NEWNAME FOR DATAFILE 5 to '/oradata/ARKONA/users01.dbf';
restore database;
switch datafile all;
recover database;
}
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
executing command: SET NEWNAME
Starting restore at 22-MAR-13
using target database control file instead of recovery catalog
allocated channel: ORA_DISK_1
channel ORA_DISK_1: SID=20 device type=DISK
channel ORA_DISK_1: starting datafile backup set restore
channel ORA_DISK_1: specifying datafile(s) to restore from backup set
channel ORA_DISK_1: restoring datafile 00001 to /oradata/ARKONA/system01.dbf
channel ORA_DISK_1: restoring datafile 00002 to /oradata/ARKONA/sysaux01.dbf
channel ORA_DISK_1: restoring datafile 00003 to /oradata/ARKONA/undotbs1.dbf
channel ORA_DISK_1: restoring datafile 00004 to /oradata/ARKONA/undotbs2.dbf
channel ORA_DISK_1: restoring datafile 00005 to /oradata/ARKONA/users01.dbf
channel ORA_DISK_1: reading from backup piece /backup/full_6
channel ORA_DISK_1: piece handle=/backup/full_6 tag=TAG20130321T214235
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:35
Finished restore at 22-MAR-13
datafile 1 switched to datafile copy
input datafile copy RECID=6 STAMP=810776175 file name=/oradata/ARKONA/system01.dbf
datafile 2 switched to datafile copy
input datafile copy RECID=7 STAMP=810776175 file name=/oradata/ARKONA/sysaux01.dbf
datafile 3 switched to datafile copy
input datafile copy RECID=8 STAMP=810776175 file name=/oradata/ARKONA/undotbs1.dbf
datafile 4 switched to datafile copy
input datafile copy RECID=9 STAMP=810776175 file name=/oradata/ARKONA/undotbs2.dbf
datafile 5 switched to datafile copy
input datafile copy RECID=10 STAMP=810776175 file name=/oradata/ARKONA/users01.dbf
Starting recover at 22-MAR-13
using channel ORA_DISK_1
starting media recovery
channel ORA_DISK_1: starting archived log restore to default destination
channel ORA_DISK_1: restoring archived log
archived log thread=1 sequence=50
channel ORA_DISK_1: restoring archived log
archived log thread=2 sequence=16
channel ORA_DISK_1: reading from backup piece /backup/arc_7
channel ORA_DISK_1: piece handle=/backup/arc_7 tag=TAG20130321T214321
channel ORA_DISK_1: restored backup piece 1
channel ORA_DISK_1: restore complete, elapsed time: 00:00:01
archived log file name=/oradata/ARKONA/arch/1_50_806278449.dbf thread=1 sequence=50
archived log file name=/oradata/ARKONA/arch/2_16_806278449.dbf thread=2 sequence=16
unable to find archived log
archived log thread=2 sequence=17
RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of recover command at 03/22/2013 23:36:17
RMAN-06054: media recovery requesting unknown archived log for thread 2 with sequence 17 and starting SCN of 911000
L’erreur obtenue est une erreur normale. Le recover joue les archivelogs dans l’ordre chronologique des SCN contenus dans les threads (1 et 2 c’est un RAC à l’origine). Si nous avions suivit la documentation Oracle, nous n’aurions pas eu ce message d’erreur, nous aurions fait un recover until « pile poil » le bon SCN (voir <ici> prochainement pour retrouver le bon SCN).
Remarque:
Oracle pour une restauration à partir d’un backup de RAC, ne dit pas de faire comme nous venons de faire, c'est-à-dire un « recover database » sans clause « until ». Je ne sais pas pourquoi. C’est vrai que dans la méthode ci-dessus nous obtenons une erreur qui nous dit : media recovery requesting unknown archived log for thread 2 with sequence 17 and starting SCN of 911000. Oracle ne trouve pas pour le recover, l’archivelog du thread 2 avec la séquence 17, il s’arrête donc au SCN 911000 dans son recover. A part le message d’erreur tout va bien, c’est normal cette archivelog n’a jamais existé, le recover s’arrête donc avant.
Si nous voulons suivre la méthode officielle Oracle, il aurait fallu faire avant de lancer le block run ci-dessus :
RMAN> list backup of archivelog all;
List of Backup Sets
===================
BS Key Size Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
14 3.00K DISK 00:00:00 21-MAR-13
BP Key: 14 Status: AVAILABLE Compressed: NO Tag: TAG20130321T214321
Piece Name: /backup/arc_7
List of Archived Logs in backup set 14
Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- --------- ---------- ---------
1 50 910956 21-MAR-13 911004 21-MAR-13
2 16 910960 21-MAR-13 911000 21-MAR-13
BS Key Size Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ ---------------
15 22.94M DISK 00:00:00 21-MAR-13
BP Key: 15 Status: AVAILABLE Compressed: NO Tag: TAG20130321T214231
Piece Name: /backup/arc_5
List of Archived Logs in backup set 15
Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- --------- ---------- ---------
1 43 774588 18-FEB-13 803820 18-FEB-13
1 44 803820 18-FEB-13 824566 20-FEB-13
1 45 824566 20-FEB-13 844989 21-FEB-13
1 46 844989 21-FEB-13 867543 21-FEB-13
1 47 867543 21-FEB-13 888200 21-FEB-13
1 48 888200 21-FEB-13 908480 21-MAR-13
1 49 908480 21-MAR-13 910956 21-MAR-13
2 11 774592 18-FEB-13 803777 18-FEB-13
2 12 803777 18-FEB-13 803779 18-FEB-13
2 13 845895 21-FEB-13 867523 21-FEB-13
2 14 867523 21-FEB-13 867525 21-FEB-13
2 15 909045 21-MAR-13 910960 21-MAR-13
Il faut ensuite repérer l’archivelog qui a le plus grand Next SCN pour chaque thread, ici archivelog séquence 50 du thread 1 et archivelog séquence 16 du thread 2. Ensuite celui qui a le plus petit Next SCN (donc seq 16 thread 2 avec Next SCN 911000) on note son numéro de séquence, ici 16 et on rajoute 1. On obtient alors : sequence 17 thread 2.
Ensuite on aurait alors lancé le block run comme précédement mais avec la ligne du "until" en plus:
RMAN> run {
set until sequence 17 thread 2 ;
SET NEWNAME FOR DATAFILE 1 to '/oradata/ARKONA/system01.dbf';
SET NEWNAME FOR DATAFILE 2 to '/oradata/ARKONA/sysaux01.dbf';
SET NEWNAME FOR DATAFILE 3 to '/oradata/ARKONA/undotbs1.dbf';
SET NEWNAME FOR DATAFILE 4 to '/oradata/ARKONA/undotbs2.dbf';
SET NEWNAME FOR DATAFILE 5 to '/oradata/ARKONA/users01.dbf';
restore database;
switch datafile all;
recover database;
}
Et la dernière commande (recover) aurait rendu la main sans erreur:
archived log file name=/oradata/ARKONA/arch1_50_806278449.dbf thread=1 sequence=50
archived log file name=/oradata/ARKONA/arch2_16_806278449.dbf thread=2 sequence=16
media recovery complete, elapsed time: 00:00:00
Finished recover at 26-MAR-13
Ouverture de la base de données
La base est presque prête à être ouverte, cependant les controlfiles pointent encore sur les anciens chemins des journaux de transaction, donc un peu comme précédemment pour les datafiles nous récupérons les chemins pour les transférer
SQL> select 'alter database rename file '''||member||''' to '''||member||''';' from v$logfile
'ALTERDATABASERENAMEFILE'''||MEMBER||'''TO'''||MEMBER||''';'
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------
alter database rename file '+DATA1/arkona/onlinelog/group_1.257.806278453' to '+DATA1/arkona/onlinelog/group_1.257.806278453';
alter database rename file '+DATA2/arkona/onlinelog/group_1.257.806278455' to '+DATA2/arkona/onlinelog/group_1.257.806278455';
alter database rename file '+DATA1/arkona/onlinelog/group_2.258.806278457' to '+DATA1/arkona/onlinelog/group_2.258.806278457';
alter database rename file '+DATA2/arkona/onlinelog/group_2.258.806278459' to '+DATA2/arkona/onlinelog/group_2.258.806278459';
alter database rename file '+DATA1/arkona/onlinelog/group_3.265.806279705' to '+DATA1/arkona/onlinelog/group_3.265.806279705';
alter database rename file '+DATA2/arkona/onlinelog/group_3.259.806279707' to '+DATA2/arkona/onlinelog/group_3.259.806279707';
alter database rename file '+DATA1/arkona/onlinelog/group_4.266.806279713' to '+DATA1/arkona/onlinelog/group_4.266.806279713';
alter database rename file '+DATA2/arkona/onlinelog/group_4.260.806279715' to '+DATA2/arkona/onlinelog/group_4.260.806279715';
Nous modifions alors les chemins et éxecutons les requêtes générées :
SQL> alter database rename file '+DATA1/arkona/onlinelog/group_1.257.806278453' to '/oradata/ARKONA/redo_1a.redo';
SQL> alter database rename file '+DATA2/arkona/onlinelog/group_1.257.806278455' to '/oradata/ARKONA/redo_1b.redo';
SQL> alter database rename file '+DATA1/arkona/onlinelog/group_2.258.806278457' to '/oradata/ARKONA/redo_2a.redo';
SQL> alter database rename file '+DATA2/arkona/onlinelog/group_2.258.806278459' to '/oradata/ARKONA/redo_2b.redo';
SQL> alter database rename file '+DATA1/arkona/onlinelog/group_3.265.806279705' to '/oradata/ARKONA/redo_3.265.806279705';
SQL> alter database rename file '+DATA2/arkona/onlinelog/group_3.259.806279707' to '/oradata/ARKONA/redo_3.259.806279707';
SQL> alter database rename file '+DATA1/arkona/onlinelog/group_4.266.806279713' to '/oradata/ARKONA/redo_4.266.806279713';
SQL> alter database rename file '+DATA2/arkona/onlinelog/group_4.260.806279715' to '/oradata/ARKONA/redo_4.260.806279715';
Remarque : J'ai renommé les 4 premier redo car j'ai vu sur la base qu'ils sont associés au thread 1, et ils sont multiplexés d'où 1a et 1b. Mais les noms des redo n'ont pas d'importance, si vous voulez, vous pouvez les laisser avec leurs noms par défaut, seul le changement de chemin est important.
La base est prête, nous pouvons l’ouvrir:
SQL> alter database open resetlogs;
alter database open resetlogs
*
ERROR at line 1:
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00704: bootstrap process failure
ORA-39700: database must be opened with UPGRADE option
Process ID: 2718
Session ID: 18 Serial number: 3
Comme prévu précédemment, nous avons un problème de version Oracle. La base ARKONA n’est pas à la version 11.2.0.2.
Si nous regardons l’alert.log, le resetlog a bien eu lieu (redolog regénérés), mais le open a échoué à cause de la différence de version entre le moteur de notre serveur et le catalogue contenu dans la base. Ouvrons la base en mode upgrade pour enfin connaitre la version du catalogue :
SQL> alter database open upgrade;
Upgrade ou downgrade
Ce paragraphe est à suivre (et à adpater) que si la version de la base restaurée ne correspond pas au moteur Oracle installé. Sinon « c’est direct » le paragraphe suivant.
Dans notre cas donc, la version du moteur ne correspond pas au contenu du catalogue du dictionnaire de données de la base restaurée.
Pour connaître la version du dictionnaire :
SQL> select VERSION from dba_registry where COMP_ID='CATALOG';
VERSION
------------------------------
11.2.0.3.0
La base ARKONA est donc une 11.2.0.3.
Deux solutions :
- Upgrade du moteur de la version 11.2.0.2 à 11.2.0.3
- Downgrade du catalogue
Ici nous allons downgrader le catalogue :
SQL> shutdown immediate
SQL> startup downgrade
SQL> @$ORACLE_HOME/rdbms/admin/catdw.sql
SQL> shutdown immediate
SQL> startup upgrade
SQL> @$ORACLE_HOME/rdbms/admin/catrelod.sql
SQL> select VERSION from dba_registry where COMP_ID='CATALOG';
VERSION
------------------------------
11.2.0.2.0
Post restauration “from RAC to standalone”
Cette étape n’est pas optionnelle, elle est propre à une restauration d’une base RAC sur un moteur standalone.
Nous devons « tuer » le thread 2 :
SQL> select THREAD#, STATUS, ENABLED from v$thread;
THREAD# STATUS ENABLED
---------- ------ --------
1 OPEN PUBLIC
2 CLOSED PUBLIC
SQL> select group# from v$log where THREAD#=2;
GROUP#
----------
3
4
SQL> alter database disable thread 2;
SQL> alter database drop logfile group 4;
SQL> alter database drop logfile group 3;
Idem pour le undo 2, mais comme nous avions modifié le init, il a été restauré mais pas ramener à la vie.
En revanche un type de fichier ne peut pas être ressuscité, ce sont les tempfiles. Il faut les recréer et les rattacher sous un nouveau nom de tablepsace :
SQL> select name from v$tempfile;
NAME
--------------------------------------------------------------------------------
+DATA1/arkona/tempfile/temp.262.806278503
SQL> select tablespace_name from dba_tablespaces where contents='TEMPORARY';
TABLESPACE_NAME
------------------------------
TEMP
SQL> create temporary tablespace TEMP1 tempfile '/oradata/ARKONA/temp01.dbf' size 100m;
SQL> alter database default temporary tablespace TEMP1;
SQL> drop tablespace TEMP including contents and datafiles;
Et voilà 
Entreprise vers Standard et vice-versa
Et si la base source était en Entreprise Edition et le moteur Oracle sur le serveur de restauration en Standard Edition ? Et vice versa ?
Pas de soucis la restauration aurait fonctionné… eh oui, et la base aurait était consultable sans aucun soucis. Cependant, si par exemple, on avait fait une restauration d’une 11.2.0.2 EE vers un 11.2.0.2 SE alors il aurait fallu mettre à niveau le catalogue du dictionnaire de donnée pour plus de propreté.
Et si on avait des options d’installées présentent uniquement disponible en EE et pas en SE ? Je n’ai pas testé tous les cas, mais par exemple pour le partionning, la restauration aurait fonctionnée, les tables partionnées auraient été parfaitement consultables en SE, en revanche impossible de générer de nouvelles partitions. Le blocage du partitionning en Standard, n’est dû (d’après moi) qu’à un simple contrôle du binaire Oracle qui détecte qu’il est installé en Standard… d’ailleurs le dictionnaire de données contient des tables partitionnées en Standard.