Aller au contenu
  • Nos offres
  • Blog
  • Contact
  • Carrières
Menu
  • Nos offres
  • Blog
  • Contact
  • Carrières
Inscrivez-vous à la newsletter

Inscrivez-vous à la newsletter

Abonnez-vous maintenant et nous vous tiendrons au courant.
Nous respectons votre vie privée. Vous pouvez vous désabonner à tout moment.

Blog

  • Accueil
  • Actualités
  • Cloud
  • Infrastructure
  • Données / Sécurité
  • Intégration
  • Dev / DevOps
  • SAM / FinOps
Menu
  • Accueil
  • Actualités
  • Cloud
  • Infrastructure
  • Données / Sécurité
  • Intégration
  • Dev / DevOps
  • SAM / FinOps
  • le 08/07/2013
  • Laurent Berthier
  • Oracle

Duplicate database avec Transparent Data Encryption (TDE)

Partager sur linkedin
Partager sur twitter
Partager sur facebook

Si vous êtes amené à cloner une base Oracle 11g constituée d’au moins  un tablespace encrypté  par la fonctionnalité TDE (Transparent Data Encryption), cet article pourra vous être utile.
Je ne détaillerai pas dans cet article le processus de clonage d’une base Oracle via le DUPLICATE RMAN. Vous trouverez des articles traitant ce point dans ce blog.

Quelque soit le contexte du clonage de la base Oracle (standby database, pré-production), vous devrez gérer l’encryption de vos tablespaces par une master key (wallet) stockée sous forme de fichier dans un répertoire défini dans le fichier sqlnet.ora de votre serveur Oracle.
La master key (ewallet.p12) de la base source doit être copiée sur le deuxième serveur dans le répertoire défini par le paramètre ENCRYPTION_WALLET_LOCATION du fichier sqlnet.ora :

SQLNET.AUTHENTICATION_SERVICES = (NTS)
ENCRYPTION_WALLET_LOCATION =
(SOURCE = (METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = C:apporaclewallet)))

Puis, avant de lancer le DUPLICATE RMAN, vous devez appliquer deux pré-requis sur le deuxième serveur :

  • Démarrer l’instance Oracle en NOMOUNT
  • Ouvrir le wallet
ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "password" ;

Une fois le wallet ouvert, le DUPLICATE RMAN sera donc capable de restaurer les fichiers des tablespaces à partir des backups RMAN encryptés de la base de production.
Toutefois, lors du clonage d’une base Oracle, le DUPLICATE RMAN est amené à redémarrer la base auxiliaire plusieurs fois. Ainsi, lors du prochain redémarrage de l’instance, le wallet sera fermé et ne sera pas réouvert.
Vous obtiendrez donc l’erreur suivante :

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03002: failure of Duplicate Db command at 11/06/2013 10:02:34
RMAN-05501: aborting duplication of target database
RMAN-03015: error occurred in stored script Memory Script
ORA-19870: error while restoring backup piece F:backupprodPROD_DATA_23obcgkc_1_1
ORA-19913: unable to decrypt backup
ORA-28365: wallet is not open

La solution pour maintenir le wallet constamment ouvert pendant le DUPLICATE RMAN est la création d’un wallet AUTO_LOGIN via l’utilitaire orapki :

C:apporacle> orapki wallet create -wallet  C:apporacle -pwd "password" -auto_login

L’utilitaire orapki va donc créer un fichier cwallet.sso dans le même répertoire que le wallet.
Une fois le clonage de la base de production réalisé, il est fortement conseillé de supprimer le fichier cwallet.sso pour une question de sécurité afin de ne pas ouvrir implicitement le wallet lors de chaque STARTUP de la base.
Bien entendu, si vous effectuez le clonage de la base de production via un restore / recover manuel, il est inutile de générer le wallet AUTO_LOGIN vu que l’intance ne sera démarrée qu’une seule fois.

Laurent Berthier
Laurent Berthier
Voir tous ses articles

Laisser un commentaire Annuler la réponse

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Articles récents
  • Azure Database pour PostgreSQL [PaaS]
  • Azure Logic Apps : l’outil d’intégration Cloud de Microsoft
  • Purge automatique des archivelogs en PL/SQL
  • ASM et l’importance du usable_file_mb
  • Préparer un Windows Server 2003 pour une migration sur Azure

Mentions légales & Politique de confidentialité

En poursuivant votre navigation, vous acceptez l'utilisation de cookies tiers destinés à réaliser des statistiques de visites et de suivi. Accepter Refuser Personnaliser En savoir plus
Politique de confidentialité et cookies

Politique de confidentialité

Les informations collectées au travers de nos cookies sont exploitées à des fins statistiques (Google Analytics).
Google Analytics
Enregistrer & appliquer

8 JUIN 2022 A PARIS | 8H30 - 18H30

TECH FOR CLIMATE ?

Opportunités et limites de la technologie pour faire face au défi climatique

Programme & Inscriptions

Un évènement imaginé avec 🖤 par Constellation