• Skip to content
  • Jump to main navigation and login

Nav view search

Navigation

Search

Vous êtes ici : Home

about Oracle

  • about News
  • about Tech
  • about TestBed
  • about Retro
  • about MAP

about Me

  • Mon Parcours

Les 5 Derniers articles is closed

  • Unified Audit 12.2 vs 12.1
  • Une base dans Oracle Cloud Service
  • Testbed: Audit Vault 12.2
  • Historique du Load et de l'AAS
  • Trouver l'édition et la version Oracle

about News

11g/12c : avec GoldenGate

  • Imprimer
  • E-mail
Détails
Catégorie : Migration
Publié le samedi 21 novembre 2015 15:05
Écrit par Administrator
Affichages : 9608

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
Container : BIGDB

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.

Lire la suite : 11g/12c : avec GoldenGate

11g/12c : dataguard - import full tablespace transportable

  • Imprimer
  • E-mail
Détails
Catégorie : Migration
Publié le jeudi 5 novembre 2015 20:53
Écrit par Administrator
Affichages : 8097

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
Unique name : SHAKA

Nom de la base : SHAKA
Unique name : SHAKAMIG

Nom de la pluggable database : PONK
Container : BIGDB

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

  • Imprimer
  • E-mail
Détails
Catégorie : Migration
Publié le lundi 2 novembre 2015 20:07
Écrit par Administrator
Affichages : 9438

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
Container : BIGDB

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

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

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.

Lire la suite : Migration 11g/12c

Comment casser un mot de passe sans connexion à la base

  • Imprimer
  • E-mail
Détails
Catégorie : Sécurité
Publié le jeudi 29 octobre 2015 20:14
Écrit par Administrator
Affichages : 7467

(Titre un peu racoleur pour attirer le clic Wink)

[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

Plus d'articles...

  1. OLR/OCR/VOTING, kesako?
  2. 12c : recover table l'usine à gaz
  3. News about 12.1.0.2 : documentation et SE2
  4. TDE wallet in multi database environment

Page 4 sur 9

  • Début
  • Précédent
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • Suivant
  • Fin