11g/12c : avec GoldenGate
- Détails
- Catégorie : Migration
- Publié le samedi 21 novembre 2015 15:05
- Écrit par Administrator
- Affichages : 10573
Cet article fait suite à Migration 11g/12c. Il décrit la migration d’une base de données nommée SHAKA en 11.2.0.4 Entreprise Edition sur un serveur en Oracle Linux 64bit vers une 12.1.0.2 Entreprise Edition sur un autre serveur Oracle Linux avec Oracle GoldenGate 12.1.2:
Système source |
Système cible |
Oracle Database 11.2.0.4 Entreprise Edition |
Oracle Database 12.1.0.2 Entreprise Edition |
Nom de la base : SHAKA |
Nom de la pluggable database : SHAKA |
Architecture : standalone |
Architecture : standalone CDB |
Nom du serveur : oradbm02 |
Nom du serveur : ora12cdb |
OS : Oracle Linux 6.4 64bit |
OS : Oracle Linux 6.7 64bit |
La base source et/ou la base cible pourraient être en Standard Edition, GoldenGate est indépendant de l’édition de la base de données. D’ailleurs la base source et cible peuvent aussi avoir un characterset différent et un endian différent , la base source pourrait être en Windows ou Linux Intel (Little Endian) et la base cible en AIX Power (Big Endian).
Le but de l’article n’est pas d’expliquer en détail GoldenGate. En revanche toutes les commandes sont suffisantes pour le mettre en oeuvre dans le cas d’une migration simple, d’un schéma 11g vers une schéma 12c, et donc aussi permettre une première prise en main pour ceux qui ne connaitraient pas GoldenGate.
11g/12c : dataguard - import full tablespace transportable
- Détails
- Catégorie : Migration
- Publié le jeudi 5 novembre 2015 20:53
- Écrit par Administrator
- Affichages : 8943
Cet article fait suite à Migration 11g/12c. Il décrit la méthode Migration 11g-12c CDB par Export/Import full par tablespace transportable.
La méthode de migration est proche de celle décrite dans 11g/12c : import full tablespace transportable mais elle fait appel à une dataguard pour éviter l’important downtime qui a lieu lors de la copie des datafiles en read-only de la base source vers la base cible. Evidement si la base source est en 11gR2 cela signifie que la base cible est aussi une 11gR2 tant qu’elle est en standby. Elle sera upgradée après le failover. L’avantage de passer par une dataguard est que pour monter une dataguard, la base source n’a pas besoins d’être arrêtée.
Les caractéristiques de la source et de la cibles sont identiques que dans l’article précédent 11g/12c : import full tablespace transportable, mais il y a un système intermédiaire :
Système source |
Système intermédiaire |
Système cible |
Oracle Database 11.2.0.4 Entreprise Edition |
Oracle Database 11.2.0.4 Entreprise Edition |
Oracle Database 12.1.0.2 Entreprise Edition |
Nom de la base : SHAKA |
Nom de la base : SHAKA |
Nom de la pluggable database : PONK |
Architecture : standalone |
Architecture : standalone |
Architecture : standalone CDB |
Nom du serveur : oradbm02 |
Nom du serveur : ora12cdb |
Nom du serveur : ora12cdb |
Proprio du moteur : oracle |
Proprio du moteur : oramig |
Proprio du moteur : oracle |
OS : Oracle Linux 6.4 64bit |
OS : Oracle Linux 6.7 64bit |
OS : Oracle Linux 6.7 64bit |
Lire la suite : 11g/12c : dataguard - import full tablespace transportable
11g/12c : import full tablespace transportable
- Détails
- Catégorie : Migration
- Publié le lundi 2 novembre 2015 20:07
- Écrit par Administrator
- Affichages : 12083
Cet article fait suite à Migration 11g/12c. Il décrit la méthode Migration 11g-12c CDB par Export/Import full par tablespace transportable.
Cet article décrit donc la migration d’une base de données nommée SHAKA en 11.2.0.4 Entreprise Edition sur un serveur en Oracle Linux 64bit vers une 12.1.0.2 Entreprise Edition
Système source |
Système cible |
Oracle Database 11.2.0.4 Entreprise Edition |
Oracle Database 12.1.0.2 Entreprise Edition |
Nom de la base : SHAKA |
Nom de la pluggable database : PONK |
Architecture : standalone |
Architecture : standalone CDB |
Nom du serveur : oradbm02 |
Nom du serveur : ora12cdb |
OS : Oracle Linux 6.4 64bit |
OS : Oracle Linux 6.7 64bit |
Avant de commencer à proprement parler de migration, il faut préparer la base cible. Nous voulons migrer directement dans un CDB, il faut donc créer la base container. Pour cela le plus simple est d’utiliser dbca. Rien de bien particulier, bien choisir « Advanced Mode » à l’étape Creation Mode, et à l’étape Database Identification bien cocher « Create As Container Database » et « Create an Empty Container Database » .
Lire la suite : 11g/12c : import full tablespace transportable