Discussion :

[CinePhil]

Bonjour,

Je vais migrer de Oracle 11 G R2 (11.2.0.1) en Oracle 12.

Le prestataire me propose une méthode via RMAN, que je n'ai jamais utilisé mais auquel il ma formé il y a quelques semaines et qui deviendra notre outil de sauvegarde après la migration. Jusque là, nous ne faisions que des sauvegardes à froid par copie des datafiles, controlfile, archivelogs et redos.

Mais il me dit que pour assurer la bonne compatibilité lors de la migration, il faudrait que j'installe en parallèle la 11.2.0.4.
Problème : pas assez de place sur le serveur pour contenir les deux versions d'Oracle et comme nos machines sont externalisées, c'est un peu compliqué d'augmenter la capacité provisoirement.
Par contre, comme nous avons encore notre VM sur notre infrastructure datant d'avant l'externalisation et que là je peux augmenter la capacité assez facilement, je me demandais s'il est possible de se connecter au serveur de prod actuel (qui est en 11.2.0.1) à partir de l'ancien avec un RMAN 11.2.0.4 ?

Si oui, quelle serait la commande ?

[Pomalaix]

La syntaxe basique de connexion par RMAN à une base distante est :

Code :

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

rman target sys/mot_de_passe@alias_tns_vers_la_base_visée

Brièvement, il existe plusieurs techniques de migration, dont notamment :
1) Assistant graphique DBUA (Database Upgrade Assistant) qui enchaîne toute une série d'étapes. Il faut avoir la version 11.2 et 12.x sur la machine cible.
2) Procédure de migration manuelle (en gros, on fait la même chose que DBUA). Peut être nécessaire si on n'a que la version 12.x sur la machine cible
3) Export / import datapump, ou variante avec les tablespaces transportables

Pour les techniques 1 et 2, il est exact qu'il faut être au minimum en version 11.2.0.2. Si ce n'est pas le cas, il faudra faire une migration intermédiaire, usuellement en 11.2.0.4.
RMAN n'intervient là-dedans que pour obtenir une copie de la base sur la machine cible ; il ne constitue pas en lui-même une technique de migration. D'ailleurs, on pourrait parfaitement se dispenser de RMAN et travailler à l'aide d'une sauvegarde manuelle comme vous le faites actuellement.

Je ne saisis pas pourquoi vous voudriez vous connecter à distance à la base 11.2.0.1 à l'aide de RMAN 11.2.0.4.

En temps normal, on utilise le RMAN local correspondant à la version de la base concernée, que ce soit pour la sauvegarder ou la restaurer.
Si vous utilisez RMAN 11.2.0.4, il est possible que vous ayez une erreur, d'après le tableau de compatibilité https://docs.oracle.com/database/121...0-E2FFC355FD8F qui indique que le client RMAN doit être de version inférieure ou égale à celle de la base. Donc on pourrait plutôt se connecter à une base 11.2.0.4 avec un RMAN 11.2.0.1 que le contraire.

Il est à voir si vous n'auriez pas intérêt à utiliser plutôt la technique de l'export / import (si le volume n'est pas trop important, car sinon l'interruption pourrait être trop longue) compte tenu de cette migration en 2 phases à laquelle vous seriez contraint.

Et dernière réflexion : il peut être utile aussi d'envisager de travailler sur la 12c en mode monotenant : multitenant avec une seule base, ce qui n'exige pas d'option payante spécifique, et reste possible même en édition standard.
L'intérêt est que les futures migrations seront énormément facilitées.