about News
11g/12c : avec GoldenGate
- Détails
- Catégorie : Migration
- Publié le samedi 21 novembre 2015 15:05
- Écrit par Administrator
- Affichages : 10675
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 : 9025
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 : 12237
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
Migration 11g/12c
- Détails
- Catégorie : News
- Publié le lundi 2 novembre 2015 20:05
- Écrit par Administrator
- Affichages : 56586
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.
Comment casser un mot de passe sans connexion à la base
- Détails
- Catégorie : Sécurité
- Publié le jeudi 29 octobre 2015 20:14
- Écrit par Administrator
- Affichages : 8581
(Titre un peu racoleur pour attirer le clic )
[MAJ 20/11/2015: correctif sur la force des mot de passe 10g et 11g]
Cet article fait suite à La sécurité des mots de passe dans lequel je récupérais le mot de passe crypté grâce à une connexion dans la base. Puis par brute force je décryptais le mot de passe. Puis j’écrivais alors :
Cependant il ne faut pas oublier qu’il [le mot de passe] est stocké dans une table, donc dans un datafile, qui plus est, appartenant au tablespace SYSTEM, ce qui signifie un fichier pas trop volumineux et dont le nom est très certainement de la forme system.dbf, en un mot, dans un fichier facilement identifiable. Il suffit à un administrateur qui a accès au compte root par exemple, de le copier et de chez lui, tranquillement, le décortiquer pour trouver le mot de passe chiffré. Ensuite il ne reste plus qu’à le déchiffrer par attaque au dictionnaire ou par force brute.
Je vous propose cette fois-ci de passer par la copie du datafile du tablespace SYSTEM, comme cité ci-dessus.
Lire la suite : Comment casser un mot de passe sans connexion à la base