Vous avez supprimé vos répertoires oracle et oradata sur windows ? Vous avez accès d’une manière ou d’une autre à un export Data Pump full ? Vous avez du mal a mesurer le temps que prendra la restauration de vos données ?
N’esquivez plus le bureau de votre DSI ! Lisez ce retour d’expérience …

Cet article est un retour de première expérience d’import Data Pump full sous Windows. L’objectif est de vous montrer de façon immersive un cas concret, avec les erreurs et tatonnements. Pourquoi ? Réponses en conclusion de cet article.

« Dring Dring »

Le téléphone de mon bureau sonne. « EasyTeam, Service Support, bonjour ? »
Le client paniqué m’explique qu’il a définitivement supprimé ses répertoires oracle, oradata et backup sur son serveur de pré-production (PREPROD). Déployée par un tiers, le client ne peut me fournir aucune information sur l’installation qu’il avait. La seule chose que je retiens de ses « je crois que… » est : « Elle doit être isométrique à la production ».
[15 min]

Vérification(s) :

Je vérifie, corrige et éventuellement complète le diagnostic client : PREPPROD (Windows server 2003) ne contient plus de moteur Oracle, plus de base de données, plus de données et pas de sauvegardes. La situation est donc bien critique.

Il s’agit ici de ma première installation du moteur Oracle, première création de base vierge, et premier import dans un cas client concret sur Windows. Autant dire qu’il y aurait des raisons de paniquer à priori, mais je m’accroche à l’idée qu’il s’agit là d’une tâche « de base » (l’import) très probablement bien encadrée par l’éditeur américain.

[25 min]

Investigation(s) :

Je me connecte au serveur de production (PROD). OS = Windows Server 2003

SQL> select * from v$instance;
SQL> select * from v$version;

=> Oracle 10.2 Patchset 2.0.4.

SQL> select * from v$options;

=> Je note toutes les options de la base.

SQL> select * from sys.props$;
SQL> show parameter

=> Je note les paramètres suivants : db_block_size, nls_language, nls_territory, nls_character_set

Je note également les chemins des répertoires oracle, oradata et backup. Je note l’organisation des tâches de sauvegarde et copie les éventuels scripts.
Je vérifie les sauvegardes et note la présence d’un export Data Pump full (commande « expdp ») daté de la veille : backup.DMP
Je note la taille du fichier .DMP (40Go) et je note la taille du répertoire de données oradata (120Go), et du dossier oracle (négligeable).
Il s’agit d’un serveur mono-instance, mono-base.
ATTENTION : Ici j’ai eu la chance d’avoir accès aux informations nécessaires pour construire plus tard une base vierge capable d’accueillir les données de l’export. Dans le cas où vous n’auriez aucune information vous n’aurez pas d’autre choix que de monter plusieurs moteurs+bases vierges différents (version de base à tester x bd_block_size au minimum). Progression à tâtons donc. Mais en fonction de la date d’installation, de ce que le client faisait avec sa base  etc … Il y a déjà moyen de cerner un nombre de combinaison limité. Notez qu’à partir de la 10, les erreurs d’import peuvent énormément vous aider sur la nature des paramètres manquants comme par exemple si le db_block_size n’est pas bon dans la base d’accueil et bien le log vous le dit et vous donne le db_block_size à avoir.
[15 min]

Préparation(s) :

Je me connecte au serveur de PREPROD. Je nettoie les éventuels restes de l’ancienne installation.
Je recrée les répertoires oracle, oradata et backup au plus près de ce qui existe en PROD :

• Mes chemins d’accès sont différents (le nom des disques sont différents, le nom de la base sera différent : PREPROD au lieu de PROD)
• La place disponible n’est pas la même, je serais surement contraint d’effectuer un nettoyage minutieux.

Il va y avoir une problème de place, mon plus gros disque en PREPROD (D:) fait 140 Go et aucun autre disque ne dispose de plus de 40 Go d’espace libre. Je ne peux donc pas avoir à la fois mon export .DMP (40Go) et mes données importées (120 G0) sur ce serveur.

Je demande au client de copier le backup .DMP trouvé en PROD sur un disque réseau accessible depuis la PREPROD.
[60 min] est le temps estimé de cette copie. Pendant ce temps je vais installer le moteur Oracle puis déployer une base vierge capable d’accueillir l’import Data Pump full.

[15 min]

Installation du moteur Oracle pour serveur mono-instance :

http://www.oracle.com/technetwork/indexes/downloads/index.html
Je télécharge un installeur qui correspond à mes besoins et je lance une installation avancée. Lorsqu’aucune des informations récupérées en PROD n’est affichée je laisse les choix par défaut. => Je ne détaillerai pas ici l’installation, il y a ce qu’il faut sur internet pour vous aider.
[45 min]

Installation de la base Oracle pour serveur mono-instance  :

Je lance l’outil « DBCA » présent dans ORACLE_HOMEBIN suite à ma précédente installation. Lorsqu’aucune des informations récupérées en PROD n’est affichée je laisse les choix par défaut. => Je ne détaillerai pas ici l’installation, il y a ce qu’il faut sur internet pour vous aider.
Voici les options choisies au fil de l’eau :

• Installation personalisée.
• SID.domaine (PREPROD.client.fr).
• Systèmes de fichiers.
• Emplacement commun pour les datafiles .dbf (/oradata).
• Pas de flash recovery.
• J’ai décoché : datamining, olap, spatial, label security.
• Dimensionnement : 16 au lieu du 8 en standard (comme sur la base en PROD).
• Jeu de caractère BLS_characterset AL32UFT8 et UTF8 (comme sur la base de PROD).
• Et enfin, conseil pratique, cocher la sauvegarde des scripts de création de la base, cela vous permettra de la reconstruire bien plus rapidement en cas de besoin.

Vérifications : J’ouvre une fenêtre de commande (cmd).

C: > D:
D: > set ORACLE_SID=PREPROD
D: > set ORACLE_HOME=D:oracleproduct10.2db
D: > sqlplus / as sysdba
SQL> select * from v$instance;
SQL> select * from v$version;
SQL> select * from v$options;
SQL> select * from sys.props$;
SQL> show parameter

Toutes les options et paramètres de ma base vierge doivent être conformes à la base de PROD.
=> Je lance SQL+ pour vérifier le réseau et le mappage : Échec. Problèmes avec tnsnames.ora et listener.ora
Je lance l’outil « NETCA » (OracleNet) qui permet de configurer rapidement la partie réseau et mappage de mon instance.
=> Je ne détaillerai pas ici la configuration, il y a ce qu’il faut sur internet pour vous aider.
===
La moteur Oracle et la base vierge sont prêts.
Le client a connecté un disque réseau Y: sur lequel se trouve l’export backup.DMP copié de la PROD.
===
[15 min]

Tentative d’import n°1 : Échec | Registre windows

(Fenêtre de commande (cmd) + Set de l’environnent + Placé dans ORACLE_HOME)

D:oracleproduct10.2.0db > cd BIN
D:oracleproduct10.2.0dbBIN > impdp system/password DIRECTORY=DATA_PUMP_DIR DUMPFILE=Y:BACKUP.DMP LOGFILE=DATA_PUMP_DIR:import_1.log FULL=Y

=> C’est un echec. J’obtiens une erreur ORA-12154.
=> Note metalink [898664.1].
=> Le registre de Windows avait gardé « souvenir » de l’ancienne installation (merci Windows), j’ai du tout nettoyer.
[15 min]

Tentative d’import n°2 : Échec | Répertoire non déclaré en base

(Fenêtre de commande (cmd) + Set de l’environnent + Placé dans ORACLE_HOME)

D:oracleproduct10.2db > cd BIN
D:oracleproduct10.2dbBIN > impdp system/password DIRECTORY=DATA_PUMP_DIR DUMPFILE=Y:BACKUP.DMP LOGFILE=DATA_PUMP_DIR:import_2.log FULL=Y

=> C’est un echec. J’obtiens les erreurs ORA-39002 ORA-39070 ORA-39087
=> Note metalink [790163.1].
=> Le répertoire DATA_PUMP_DIR (D:oracleproduct10.2.0adminPREPRODdpdump) est reconnu et déclaré en base, mais pas le Y: du Y:BACKUP.DMP. Il faut donc que je déclare ce chemin à la base.

D: > set ORACLE_SID=PREPROD
D: > set ORACLE_HOME=D:oracleproduct10.2db
D: > sqlplus / as sysdba
SQL> create or replace directory IMPORT as 'Y:';
Repertoire cree.
SQL>  grant read,write on directory IMPORT to system;
Autorisation de privileges (GRANT) acceptee.

[30 min]

Tentative d’import n°3 : Échec | Oracle et droits réseaux

(Fenêtre de commande (cmd) + Set de l’environnent + Placé dans ORACLE_HOME)

D:oracleproduct10.2db > cd BIN
D:oracleproduct10.2dbBIN > impdp system/password DIRECTORY=DATA_PUMP_DIR DUMPFILE=IMPORTBACKUP.DMP LOGFILE=DATA_PUMP_DIR:import_3.log FULL=Y

=> C’est un échec :

Connected to: Oracle Database 10g Release 10.2.0.4.0 - 64bit Production
ORA-39001: valeur d'argument non valide
ORA-39000: specification de fichier de vidage erronee
ORA-31640: impossible d'ouvrir le fichier de vidage "Y:BACKUP.DMP" pour lecture
ORA-27041: ouverture du fichier impossible
OSD-04002: unable to open file
O/S-Error: (OS 3) Le chemin d'accès spécifié est introuvable.

=> Visiblement l’import n’arrive pas à accéder au lecteur réseau Y:, problèmes de droits.
Après avoir tenté de nombreuse idées (déclaration de Y: en base; investigations réseau et système poussées), finalement c’est grâce à un ensemble de codes d’erreur que je finis par trouver la note metalink [145843.1] sur laquelle je vais appuyer mon diagnostic.
=> Les droits locaux sur le lecteur réseau distant Y: ne suffisent pas à Oracle, il ne peut faire cette opération d’import qu’avec des droits de type domaine Windows. Le client n’a pas de stratégie de domaine, a une infrastructure réseau légère, une compétence réseau limitée. Le détail de la note metalink suggère quelque chose d’assez technique et nous entrainera très certainement dans d’autres problèmes en sus de celui que l’on a déjà.
Je suis donc contraint de demander au client de copier le fichier de backup .DMP sur un disque dur (en usb par exemple) directement branché au serveur PREPROD. Nous demandons à ce que le fichier de dump soit placé sur un disque externe tout ce qu’il y a de plus simple et que ce disque soit branché sur le serveur de préprod.
[60 min]
Le client copie le dit fichier sur un disque dur externe qu’il branche en usb au serveur. Lecteur Y:.

SQL> create or replace directory IMPORT as 'Y:';
  Repertoire cree.
  SQL> grant read,write on directory IMPORT to system;
  Autorisation de privileges (GRANT) acceptee.

[15 min]

Tentative d’import n°4 : Échec | Mapping des données

(Fenêtre de commande (cmd) + Set de l’environnent + Placé dans ORACLE_HOME)

D:oracleproduct10.2.0db > cd BIN
D:oracleproduct10.2.0dbBIN > impdp system/password DIRECTORY=DATA_PUMP_DIR DUMPFILE=IMPORTBACKUP.DMP LOGFILE=DATA_PUMP_DIR:import_4.log FULL=Y

=> Cela semble être un succès mais c’est un échec.
L’import s’effectue mais la majorité des données utiles n’ont pas été copiées car le chemin des datafiles .dbf du fichier d’import sont différents de ceux de la base créee. Exemple :
Sur la PROD et donc dans le fichier d’import on a E:ORADATAPRODUNDOTBS01.DBF or en PREPROD cela se traduirait par D:ORADATAPREPRODUNDOTBS01.DBF
=> Il va donc falloir traduire ces chemins durant l’import (remapping). Résultat net, ma base est remplie de structure et de certaines données. Je ne peux plus la considérée comme « vierge ».
[15 min]
Via DBCA je détruit l’ancienne base créée, puis comme j’ai gardé les scripts de création de ma première base, je recrée rapidement une nouvelle base vierge.
[15 min]
Je prépare mon remapping.
Sur la PROD je lance :

SQL >select * from v$dba_data_files;
FILE_NAME
-----------------------------------
E:ORADATAPRODSYSTEM01.DBF
E:ORADATAPRODUNDOTBS01.DBF
E:ORADATAPRODSYSAUX01.DBF
E:ORADATAPRODPROD01.DBF
...

L’option REMAP_DATAFILE de ma commande d’import (impdp) s’écrira donc ainsi (d’après metalink) :

REMAP_DATAFILE="'E:ORADATAPRODSYSTEM01.DBF':'D:oradataPREPRODSYSTEM01.DBF','E:ORADATAPRODUNDOTBS01.DBF':'D:oradataPREPRODUNDOTBS01.DBF'...

Je note que sur internet de nombreux DBA ont eu des problèmes avec la syntaxe lors des remapping, et je constate qu’il y a au moins 4 façons différentes de les écrire. Je décide de me prémunir d’un nouvel échec en faisant une rapide copie de ma structure à fin de ne pas reperdre encore plus de temps.
[30 min]

Tentative d’import n°5 : Échec | Syntaxe de REMAP_DATAFILE

(Fenêtre de commande (cmd) + Set de l’environnent + Placé dans ORACLE_HOME)

D:oracleproduct10.2db > cd BIN
D:oracleproduct10.2dbBIN > impdp system/password DIRECTORY=DATA_PUMP_DIR DUMPFILE=IMPORTBACKUP.DMP LOGFILE=DATA_PUMP_DIR:import_5.log FULL=Y REMAP_DATAFILE="'E:ORADATAPRODSYSTEM01.DBF':'D:oradataPREPRODSYSTEM01.DBF','E:ORADATAPRODUNDOTBS01.DBF':'D:oradataPREPRODUNDOTBS01.DBF'...

=> Echec => « bad parameter » pour REMAP_DATAFILE

Après de multiples essais d’écriture,  l’import réussi enfin avec l’écriture suivante :

Import: Release 10.2.0.4.0 - 64bit Production on Friday, 25 March, 2011 10:04:02
Copyright (c) 2003, 2007, Oracle.  All rights reserved.
Connected to: Oracle Database 10g Release 10.2.0.4.0 - 64bit Production
Table maître "SYSTEM"."SYS_IMPORT_FULL_01" chargée/déchargée avec succès
Démarrage de "SYSTEM"."SYS_IMPORT_FULL_01" : system/******** DIRECTORY=DATA_PUMP_DIR DUMPFILE=IMPORTBACKUP.DMP LOGFILE=DATA_PUMP_DIR:import_5.log FULL=Y REMAP_DATAFILE='E:ORADATAPRODSYSTEM01.DBF':'D:oradataPREPRODSYSTEM01.DBF','E:ORADATAPRODUNDOTBS01.DBF':'D:oradataPREPRODUNDOTBS01.DBF','E:ORADATAPRODSYSAUX01.DBF':'D:oradataPREPRODSYSAUX01.DBF'...

L’import du fichier backup.DMP (40Go) a pris entre 3 et 4 heures pour une place finale d’environ 125 Go sur disque.

Conclusion :

Presque une journée de travail là où une demi-journée aurait pu suffire si j’avais pu éviter les 5 à 8 pièges rencontrés dans ce cas de figure. Et que dire si le client s’y était collé tout seul ?
Cet article re-démontre bien en quoi il est essentiel d’avoir une parfaite maîtrise des sauvegardes de ses données et de ses binaires. Il démontre également qu’une base de connaissance est réellement nécessaire pour éviter un à un les écueils d’une intervention sur l’autre. Enfin et surtout cette expérience m’a appris la marge de sécurité à prendre vis à vis des délais et des coûts annoncés au client sur toute opération « Oracle », même une tâche à priori « de base » peut vite se transformer en casse tête chinois.
= OraNewB =