Migration 11g/12c

  • Imprimer
Détails
Catégorie : News
Publié le lundi 2 novembre 2015 20:05
Écrit par Administrator
Affichages : 56595

Cela fait un petit moment maintenant que la 12c est sortie. Il est peut être donc temps de migrer votre vieille 11g en 12c… et pourquoi pas vers la 12c avec la nouvelle architecture CDB. De toute façon, officiellement, il va bien falloir un jour migrer vers les CDB puisque Oracle annonce le désupport de l’ancienne architecture après la 12c :

The non-CDB architecture is deprecated in Oracle Database 12c, and may be desupported and unavailable in a release after Oracle Database 12c Release 2. Oracle recommends use of the CDB architecture.

La pression monte… faut-il migrer en CDB alors ? Peut-être.

 

Ce qui est dommage c’est que sans l’achat de la licence multitenant, nous ne pouvons mettre qu’une seule base dans la base container (CDB).  Si nous voulons  donc mettre deux bases de données sur le même serveur, sans le multitenant, nous devons créer deux bases container avec dans chacune d’elles une seule bases. L’option multitenant n’est pas donnée, elle oblige l’achat de l’entreprise édition plus la licence multitenant à 17.500$ par cœur (prix septembre 2015).

Ce qui est sûr c’est que tôt ou tard il va falloir basculer en CDB, peut être en 13f ? Wink...alors migrons dès maintenant en CDB. Mais comment faire pour migrer une base 11g non-CDB en 12c CDB ?

Il y a de nombreux scénarii envisageables. Je vais en décrire quelques uns, tous portent sur une migration 11g 12c c'est-à-dire un changement hardware pas juste un upgrade.

Je pourrai commencer par la méthode la plus simple techniquement un export/import datapump classique mais il y a peu d’intérêt. Pas que c’est un mauvais choix, mais c’est sans doute une des méthodes qui prendra le plus de temps, et techniquement il n’y a aucun intérêt à l’expliquer.

 

Migration par Export/Import full tablespace transportable

Alors je vais commencer par l’export/import full avec tablespace transportable directement dans une CDB.  Cette méthode requière à un instant t de mettre tous les tablespaces applicatifs en read-only, puis de les copier sur le nouveau serveur à leur place définitive, et enfin de lancer l’export/import full avec tablespace transportable. Une fois cela effectué… c’est fini.

Tous les détails techniques ici >> 11g/12c : import full tablespace transportable <<

Bien sûr cette méthode impose que les datafiles copiés soient dans le même ENDIAN sur le serveur source et cible, cela est donc impossible par exemple d’un serveur AIX Power vers un Linux Intel. La méthode impose aussi que la base de données source soit en 11.2.0.3 minimum pour être compatible avec le « full transportable export/import ».

Avantage :

-          Assez simple techniquement.

-          Rapide si la migration se fait sur le même serveur, il n’ y aura aucun déplacement de données à effectuer.

Inconvénient :

-          Le temps de downtime. Il faut attendre la copie de tous les datafiles sur le serveur cible (dans le cas d’un changement de serveur). Pour une base volumineuse de plusieurs To cela peut faire long.

-          Le serveur source et cible doivent avoir le même ENDIAN, sinon il faut utiliser RMAN avec la commande CONVERT pour convertir les datafiles.

-          La base source doit être au minimum en 11.2.0.3 sinon un upgrade en 11.2.0.3 ou 11.2.0.4 est à prévoir en plus. (upgrade de la base source nécessaire)

 

Migration par Dataguard suivi d’export/Import full tablespace transportable

Cette méthode ressemble un peu à la précédente, elle est un peu plus complexe car elle met en œuvre une dataguard mais elle réduit considérablement le downtime.

Son principe est de créer une standby en dataguard  sur le nouveau serveur 12c. Evidement pour créer la standby il faut installer un moteur 11g. La création de la standby ne nécessite aucun arrêt de la base de production. Une fois la standby en place, quand on décide de basculer de serveur, il faut faire un failover sur le nouveau serveur, cette opération est rapide. Puis faire exactement comme la première méthode sauf qu’il n’y a pas de transfert de datafile ils sont déjà en local. C'est-à-dire que l’on met les tablespaces en read-only sur la nouvelle primaire puis on éteint l’instance 11g, puis on démarre la CDB 12c vide et enfin on lance un export/import full avec tablespace transportable en allant directement prendre les datafiles là où ils se trouvent.

Tous les détails techniques ici >> 11g/12c : dataguard - import full tablespace transportable <<

Avantage : 

-          Le temps de downtime est très réduit, il engloble un failover plus un export/import transportable tablespace « local ».

Inconvénient :

-          Cette méthode demande une compétence dataguard en plus de export/import transportable tablespace.

-          Dataguard nécessite Entreprise Edition. Cependant en Standard Edition, il possible de passer par une standby et de scripter le transfert des archivelogs  et leur application jusqu’au jour de la bascule. A la limite on peut sécuriser sa standby temporaire avec Dbvisit Standby et il faudra faire un update en EE avant export transportable tablespace.

 -          La base source doit être au minimum en 11.2.0.3 sinon un upgrade en 11.2.0.3 ou 11.2.0.4 est à prévoir en plus après le failover. (pas d’upgrade de la base source nécessaire)

 -          Le serveur source et cible doivent avoir obligatoirement le même ENDIAN (pas de phase de CONVERT par RMAN de possible)

 

GoldenGate

L’utilisation de GoldenGate est souvent préconiser par Oracle pour faire une migration sans arrêt de production. Son point fort c’est qu’il peut répliquer quasiment en temps réel les données sur des environnements hétérogènes. En revanche il faut acheter une licence 17.500$ par processeur, processeur étant ici calculer comme pour une Entreprise Edition c’est à dire nombre de core x core factor et non pas le nombre de socket. Et bien sûr il faut prendre en compte le nombre de processeur sur la base source et celui sur la base cible.  Il semblerait qu’il soit possible de prendre une licence GoldenGate sur un certain nombre de mois dans le cas de l’utilisation uniquement pour une migration, ce qui pourrait effectivement le rendre plus intéressant.

Le principe d’une migration par GoldenGate, c’est d’utiliser GoldenGate Tongue Out. Et le principe de fonctionnement de GoldenGate, c’est de lire les journaux de log (redolog) et d’extraire en temps réel les modifications des objets que l’on souhaite répliquer (il peut aussi lire dans les archivelog). Ces modifications sont stockées dans des fichiers TRAIL par un proccess nommé EXTRACT. Ensuite un process nommé DATAPUMP envoie ce TRAIL sur le serveur cible, et là un proccess nommé REPLICAT joue les modifications écrites dans le TRAIL sur la base cible. C’est le workflow classique et conseillé dans le cas d’une migration :

 

Avant de démarrer le REPLICAT, il faut que la base cible contiennent les objets de la base source plus ou moins à jour (à un SCN connu), c’est la phase INITIAL LOAD, qui peut être faite par RMAN ou export/import. Dans le cas d’une migration de moteur export/import sera privilégié et encore plus dans le cas d’OS hétérogène. Une fois le REPLICAT démarré et les bases synchros, la bascule peut se faire.

Tous les détails techniques ici >> 11g/12c : avec GoldenGate <<

 

Avantage : 

-          Pas de downtime

-          La base source et cible peuvent avoir des ENDIAN différents, des OS différents, des character-set différents… être hétérogènes.

Inconvénient :

-          Le prix de la licence GoldenGate (?)

-          Si des tables à migrer n’ont pas de clef primaire, il faut pouvoir définir au niveau de GoldenGate une colonne ou une combinaison de colonnes qui peut faire office d’identifiant unique, ce qui peut ralentir la réplication dans le cas d’un grand nombre de colonne.

 

 

 {jcomments on}