Discussion :

[korian]

Bonjour,

A la base, je cherche à dupliquer une plateforme de PROD en une plateforme de DEV.
PROD: RAC (2 nodes) + ASM (Baie) + DB en 10.2.0.3 sur Solaris 5.10 sparc 64 bits, serveurs physiques.
DEV : même couche oracle mais sur Centos 5.10 64 bits, serveurs virtuels sur ESXi de VMWare (vSphère 5.0.1)

Les sauvegardes de la PROD se font par RMAN : des Incremental level 0 (1/sem) puis des incremental 1 (le reste de la semaine.)
Exemple du script de niv 0 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
connect target /;
connect catalog rman/rman@RMAN;
run {
allocate channel t1 type disk format '/sauvegardes/../OFFLINE_LEVEL0_%d_%u';
backup incremental level 0 as compressed backupset filesperset 3 database;
backup current controlfile;
alter database open;
release channel t1;
}

Pour diverses raisons liées à la disponibilités de la PROD, je n'ai pas souhaité réaliser de BACKUP full avant de me lancer dans le DUPLICATE et j'ai tenter d'utiliser les BACKUPSETs disponibles.
Pour simplifier les choses (), l'ESX n'arrive pas à lire les disques USB externes (Bug VMWare sur certaines machines) et j'ai donc transférer les fichiers (~50Go) par FTP. Sur notre réseau, c'est très long (+24h).
Je sais ça fait un peu Cosette, mais je n'ai pas vraiment de choix

La sauvegarde utilisée pour le DUPLICATE n'est donc pas la dernière en date (valeur par défaut), et j'utilise une clause UNTIL.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
duplicate target database to 'DEV' until time "TO_DATE('21/07/14 20:00:00','DD/MM/YY HH24:MI:SS')"
pfile='/sauvegardes/20140721/SRV/BDD/CTRL_SP/initDEV.ora'

RMAN trouve bien mes fichiers sur le serveur mais j'obtiens ces erreurs

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
ORA-19587: error occurred reading 0 bytes at block number 1
ORA-27091: unable to queue I/O
ORA-27067: size of I/O buffer is invalid

Mes fichiers sont bien en 666 donc l'erreur est dû au format binaire des fichiers, la notion de ENDIAN que je n'avais pas anticipé.
Solaris Sparc (big) et Linux 64bits (little) sont incompatibles sans CONVERT.

La documentation officielle mentionne le CONVERT de DATABASE, TABLESPACE, DATAFILES.
Notre base est constituée de 196 tablespaces et 197 datafiles (oui je sais ).

Et là, j'avoue, je suis perdu. Je cherche une stratégie car j'ai des contraintes d'espace-disque pour les sauvegardes et de d'organisation pour avoir la base en read-only.

Mes questions sont les suivantes (un peu en désordre, désolé) :
- Est ce que, si je convertis, je pourrais utiliser les fichiers produits dans le DUPLICATE ? (ou dois je utiliser une procédure spéciale basée sur le CONVERT ?)
- Mes sauvegardes actuelles sont au format COMPRESSED (50 Go pour une base de 450 Go) : dois je m'attendre à ce que les fichiers de CONVERT soient très gros ?
- Le DUPLICATE avait l'avantage de prendre la totalité des objets, on redémarrait la base et tout était OK. CONVERT et la notion de transport oblige à des actions particulières après le "restore" ? des actions dans SYSTEM par exemple ?

Toute aide, voire même des questions complémentaires, sont les bienvenues
Merci d'avance.

[korian]

Bonjour,

La problématique n'a pas changé mêmes si les questions diffèrent suite à la poursuite des tests après les vacances.

Je vais d'abord répondre à mes propres questions

- Est ce que, si je convertis, je pourrais utiliser les fichiers produits dans le DUPLICATE ? (ou dois je utiliser une procédure spéciale basée sur le CONVERT ?)

NON le DUPLICATE ne fait pas de convert "en dynamique". Dommage, c'était vraiment la solution la plus séduisante.

- Mes sauvegardes actuelles sont au format COMPRESSED (50 Go pour une base de 450 Go) : dois je m'attendre à ce que les fichiers de CONVERT soient très gros ?

Pas d'option de compression dans la command CONVERT, donc les fichiers sont en taille "réelle", celle que l'on peut calculer en explorant les données relatives aux datafiles.

- Le DUPLICATE avait l'avantage de prendre la totalité des objets, on redémarrait la base et tout était OK. CONVERT et la notion de transport oblige à des actions particulières après le "restore" ? des actions dans SYSTEM par exemple ?

SYSTEM ne peut être transporté. Il faut donc s'assurer que tout ce
qui doit être migrer appartient à d'autre tablespaces ou scriptés
pour être recréés ensuite.


J'ai testé les transportable tablespaces mais l'organisation de la base (~200 tablespaces et datafiles, avec des tbs dediés aux index et d'autres aux lobs) ne permet de les mettre en oeuvre.
En effet, ils ne passent pas la vérification par DBMS_TTS.TRANSPORT_SET_CHECK.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
SYS@SQL> EXECUTE DBMS_TTS.TRANSPORT_SET_CHECK('BS_XXXX,BS_YYYY',TRUE);
 
PL/SQL procedure successfully completed.
 
SYS@SQL>
 
SYS@SQL> SELECT * FROM TRANSPORT_SET_VIOLATIONS;
 
VIOLATIONS
----------------------------------------------------------------------------------------------------------------------------------------------------------------
Table PROD.AC1352 in tablespace USERS points to lob segment
PROD.LOB_AC1_YYYY in tablespace BS_YYYY
Index PROD.SYS_IL0000005922C00057$$ in tablespace BS_YYYYpoints to table
PROD.AC1352 in tablespace USERS
Table PROD.ZZZZ in tablespace USERS points to lob segment
PROD.LOB_ACS_YYYYin tablespace BS_YYYY
Index PROD.SYS_IL0000005934C00023$$ in tablespace BS_YYYYpoints to table
PROD.ZZZZ in tablespace USERS
....

Pour résoudre le problème de place de la plateforme, nous utilisons maintenant des montages NFS.

Je suis en mesure de convertir mes tablespaces, et donc d'extraire des fichiers au format Linux 64 bits

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
RMAN> CONVERT TABLESPACE BS_XXXX,BS_YYYY
2> TO PLATFORM 'Linux IA (64-bit)'
3> FORMAT='/mnt/espace_TMP/201409081900/%U';

Seulement je n'arrive pas à le faire à partir des backupsets, je dois le faire sur la base de PROD et que mes tablespaces soient en READ ONLY.
Alors que la documentation mentionne le fait qu'on puisse le faire à partir de backup, je ne trouve nulle part la méthode pour y arriver.
Existe-t-elle ?

Ensuite, comment faire pour restaurer ces fichiers dans la structure ASM de DEV ?
Existe-t-il une meilleure stratégie ?

Toue aide est la bienvenue. Et même la critique ! Du moment qu'elle permet
d'avancer
Merci d'avance du temps passé sur mon cas... desespéré ?

[korian]

Bonjour à tous,

Dernier chapitre.
Bilan : Nous n'avons pu réussir notre transfert. Si certains connaissent une méthode efficace, je reste preneur

Pour réaliser le transfert des données entre les deux systèmes et préserver l'organisation des informations sur les disques, Oracle propose plusieurs solutions qui "agissent" simultanément.
Sans vouloir être exhaustif, voici la liste de ce que j'ai pu recenser :

P1 - RMAN / CONVERT DATABASE
Conversion d'une base complète puis déplacement.
P2 - RMAN / DUPLICATE
Copie d'une base à partir d'une sauvegarde et création automatique.
P3 - RMAN / TRANSPORTABLE TABLESPACES
Transformation du contenu d'une base au format Transportable pour insertion dans une autre base.
P4 - RMAN / RESTORE
Restauration d'une sauvegarde dans une nouvelle base avec reconfiguration obligatoire.
P5 - RMAN / CONVERT DATAFILES-TABLESPACES
Conversion des fichiers de la base pour intégration dans une nouvelle base avec reconfiguration obligatoire.
P6 - DATAPUMP / export-import
Export des métadonnées et données de schéma/tables/tablespaces puis import dans une nouvelle base.
P7 - EXP/IMP / export-import
Similaire à DATAPUMP mais avec des outils plus anciens, plus lents et plus complexes.

Ci dessous, les difficultés rencontrées qui ne nous ont pas permis de faire fonctionenr ces procédures :

Organisation logique de la persistance des données de PROD
Les contenus blobs des tables sont isolés dans des tablespaces distincts. Le même principe est appliqué aux index. Le nombre total de tablespaces avoisine 200, avec des usages dédiés aux index, blobs ou data [une configuration standard est plus proche de 20].
Cette dispersion des données rend impossible l'utilisation des solutions P3, P6 et P7.

Format d'écriture binaire (ou ENDIAN) d'ORACLE
ORACLE écrit sur disque dans un format binaire qui diffère suivant la plateforme physique et le système d'exploitation. Il existe deux formats binaires (Big et Little) qui sont incompatibles entre eux. Il faut alors convertir un fichier d'une plateforme à une autre par un outil ORACLE : RMAN. Les différents formats d'écriture binaire liés aux systèmes d'exploitation sont les suivants :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
PLATFORM_ID PLATFORM_NAME                       ENDIAN_FORMAT 
----------- ----------------------------------- -------------- 
 1          Solaris[tm] OE (32-bit)             Big
 2          Solaris[tm] OE (64-bit)             Big
 3          HP-UX (64-bit)                      Big
 4          HP-UX IA (64-bit)                   Big
 6          AIX-Based Systems (64-bit)          Big
 9          IBM zSeries Based Linux             Big
 16         Apple Mac OS                        Big
 18         IBM Power Based Linux               Big
 5          HP Tru64 UNIX                       Little 
 7          Microsoft Windows IA (32-bit)       Little 
 8          Microsoft Windows IA (64-bit)       Little 
 10         Linux IA (32-bit)                   Little 
 11         Linux IA (64-bit)                   Little 
 12         Microsoft Windows 64-bit for AMD    Little 
 13         Linux 64-bit for AMD                Little 
 15         HP Open VMS                         Little 
 17         Solaris Operating System (x86)      Little 
 19         HP IA Open VMS                      Little 
 20         Solaris Operating System (AMD64)    Little

La solution P1 ne peut s'exécuter que dans un seul format, elle ne peut donc être utilisée dans notre cas.

Pour les solutions P2, P4 et P5, il faut obligatoirement convertir les fichiers de la base de données extraits d'ASM dans le format Little.
Cela fonctionne pour tous les fichiers sauf un, celui supportant le tablespace SYSTEM. Ce tablespace est obligatoire à la reconstruction/restauration/copie d'une base. Ce dysfonctionnement est le résultat d'un bug ORACLE identifié mais non-corrigé.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Bug 10409625 - ORA-600 [ktu_format_nr: rbu mgc failed] during RMAN convert datafile [ID 10409625.8] To Bottom 
Description
If an ORA-600 [ktu_format_nr: rbu mgc failed] is raised when using RMAN to convert datafiles to a different endian then this might be the bug.

Ce bug apparu avec la version 10.2 n'a pas été réellement corrigé en version 11.2 (simple modification du message d'erreur généré pour être plus explicite).
A ce jour, les solutions P2, P4 et P5 ne peuvent donc aboutir.

En conclusion, la morale de l'histoire est : S'il faut migrer tel quel un serveur grâce à sa sauvegarde, utiliser les mêmes systèmes d'exploitation !

[dell68]

Voila, j'ai lu ta problèmatique pour cloner une base de production vers une base de développement,
Donc concernant les concepts de conversions des fichiers de la base entre deux différentes palteformes,
je n'ai pas de notions la-dessus, et c'est vrai c'est une étape supplémentaire avant de faire le duplicate sous RMAN .
Pourquoi t'essayes tu pas de faire un DATAPUMP EXPORT en mode full de la base prod, ensuite tu récupère le
fichier dump généré sur le serveur de la base de développement, et TU PROCEDE PAR UN SIMPLE TEST EN FAISANT
DATAPUMP IMPORT AU niveau TABLESPACE, ou SCHEMA (comme tes tablespaces sont bien dédiés aux données, indexes, LOB ..),
sur la base dev !