export/import 9i -> 10g

**DjinnS** · 27/11/2007, 18h21

Bonsoir,

Je dois réaliser une migration d'une base 9i vers une 10g.

Cette migration n'est pas seulement l'occasion d'upgrade la version d'Oracle, mais aussi de changer le block size (et de passer en 64Bits, entre autres choses ...). C'est pour cela qu'il est nécessaire de recréer tous les tablespaces (corrigez moi si je me trompe).

La base fait 2To. Afin d'avoir une estimation du temps que cela allé nous prendre (sachant que nous avons 2 jours consécutifs pour le faire ... un WE en gros ...) nous avons réalisé un export de la base 9i avec l'outil export. 24h pour a peine ... 400Go ... Les disques sont des montages via un fiberchannel. Trouvez vous cela normal ? La machine est une Sun un peu vielle, mais même en sachant que la machine qui effectuera l'opération sera presque 2 fois plus puissante nous allons avoir du mal à faire tenir cela en 2 jours.

Mise à part l'export/import, qu'elles options je peux envisager pour faire la migration de ma base ? Est ce qu'avec un DBLink cela est envisageable ?

Merci d'avance si jamais vous avez des retours d'expériences.

**orafrance** · 27/11/2007, 18h27

Tu peux essayer de faire un upgrade de la base (probablement pas très long) et ensuite créer une 2° 10g (qui celle-ci sera la prod) avec export/import via datapump qui sera probablement plus performant sur ta 2° machine.

par contre 400G/j, il serait peut-être intéressant de voir un admin système pour voir comment améliorer les I/O

**DjinnS** · 27/11/2007, 18h31

L'admin système c'est moi ^^ Sympa !

Aucun paramètre n'a été passé a export mais j'ai vu qu'il existe un "buffer". Est ce que ça peut jouer améliorer les performances à votre avis ? Parce que bon ... ce sont des machines assez balaises donc moi aussi je trouve 400G/j c'est ULTRA LENT. Mais je n'arrive pas a savoir si ca vient de l'outil, de la base, de la machine, du matériel ...

Je précise aussi que Oracle tourne sous Solaris 10.

**orafrance** · 27/11/2007, 18h43

tu vois pas de contention sur la baie de disque ou des événements d'attentes particulier sur la session d'export ? Essaye en mode DIRECT=Y aussi et eventuellement un buffer plus grand.

C'est quoi ta ligne d'export ? Ton dump est sur les mêmes disques que la base ? T'as essayé avec un pipe ?

Essaye aussi RECORDLENGTH=65535

**DjinnS** · 28/11/2007, 10h22

Merci pour tes réponses.

Le DUMP est sur une partition qui est sur le SAN (toujours via FC).

Interessant le Pipe tu me conseilles donc d'utiliser le pipe vers un fichier et non vers /dev/null ?

**orafrance** · 28/11/2007, 10h30

Tu peux aussi utiliser le pipe dans l'import si export et import peuvent se faire à la suite

**DjinnS** · 28/11/2007, 10h35

Non les bases sont sur deux machines différentes.

Mais peut-on imaginer faire tourner un Oracle9I avec un Oracle10g sur la même machine ? Et du coup faire comme tu le proposes l'export/import en même temps ?

**orafrance** · 28/11/2007, 10h41

tu n'as pas compris je pense... tu copies ta 9i sur ta nouvelle machine, tu la migres en 10G et tu exportes ta base qui est désormais en 10G. Tu crées une autre 10g et tu importes le dump précédent. L'export/import permet de profiter pleinement des nouveautés 10g dans la gestion de l'espace.

Sinon, oui, il est possible d'avoir 9i et 10g sur le même serveur... mais ce ne sera pas ton cas si tu suis je que je te propose

**DjinnS** · 28/11/2007, 10h54

Migrer en 10g pour datapump ? (plus performant que export ?)

C'est une solution que nous envisageons à cause de notre problème de performance. Mais je préférerais pas à avoir aussi une migration applicative sur les bras ^^

**orafrance** · 28/11/2007, 11h10

mais t'es pas en train de parler de migration 10g là ? Je te parle d'utiliser datapump pour la migration... après si t'en veut pas, tu fais comme tu le sens

**LeoAnderson** · 28/11/2007, 11h10

Envoyé par orafrance

tu n'as pas compris je pense... tu copies ta 9i sur ta nouvelle machine, tu la migres en 10G et tu exportes ta base qui est désormais en 10G. Tu crées une autre 10g et tu importes le dump précédent. L'export/import permet de profiter pleinement des nouveautés 10g dans la gestion de l'espace.

Sinon, oui, il est possible d'avoir 9i et 10g sur le même serveur... mais ce ne sera pas ton cas si tu suis je que je te propose

Mieux : tu copies ta 9i sur ta nouvelle machine
tu l'upgrade en 10g
et tu y restes

pour les blocksize et autres, il te suffira ensuite de faire des move qui peuvent même se faire à chaud (dbms_redefinition)
donc interruption limitée à la copie (qui n'en est pas une puisqu'elle resterait physiquement sur la même baie, seul l'attachement changeant) + migration = moins d'une demi-journée !

**orafrance** · 28/11/2007, 11h12

Ha oui, tu peux faire des MOVE dans des tablespaces 10g pur jus... m'enfin Oracle recommande quand même un import 10g pur plutôt qu'un upgrade... alors je fais pareil

**DjinnS** · 28/11/2007, 13h09

Je ne savais pas qu'on pouvait redefinir les tables comme ca a chaud avec MOVE (je suis "nouveau" dans le domaine dba Oracle ^^).

C'est une solution intéressante et je te remercie de me l'avoir indiqué. Toutefois comme le dit orafrance j'ai vu que Oracle préconise l'export/import pour la migration.

Je vais faire d'autres tests dans quelques minutes pour l'export apres quelques recherches, je vais utiliser cette ligne de commande:

Code :

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

DIRECT=Y RECORDLENGTH=65535 FULL=Y ROWS=Y CONSTRAINTS=Y CONSISTENT=N COMPRESS=Y STATISTICS=NONE

En plus des autres paramètres pour se connecter, etc ...

**LeoAnderson** · 28/11/2007, 13h21

Sur 2 To, la question, je ne me la pose même pas !

par contre, sur les recommandations Upgrade vs Import, tu as une note ?

**orafrance** · 28/11/2007, 13h50

Envoyé par LeoAnderson

par contre, sur les recommandations Upgrade vs Import, tu as une note ?

j'en ai pas sous la main, c'est le formateur qui me l'a confirmé après l'avoir entendu de nombreuses fois. Ca vient probablement de la conversion des entêtes de fichier qui n'est pas top et du coup ça peut poser quelques soucis sur SYSTEM et SYSAUX

**LeoAnderson** · 28/11/2007, 14h13

Moi j'ai une note 433918.1 qui dit justement que le mieux c'est d'upgrader !

(et après, de faire des TTS si besoin est !)

**orafrance** · 28/11/2007, 14h40

In Oracle you trust

Et en effet :

1. Upgrade to the newest Oracle Database 10g release on the current operating system platform
following the instructions in the Upgrade guide:
http://download-uk.oracle.com/docs/c...b14238/toc.htm (To upgrade to 10gR2)

en suivant la doc :

Oracle Database 10g supports the following tools and methods for upgrading a database to the new Oracle Database 10g release:

*Database Upgrade Assistant (DBUA)

Provides a graphical user interface (GUI) that guides you through the upgrade of a database. The DBUA can be launched during installation with the Oracle Universal Installer, or you can launch the DBUA as a standalone tool at any time in the future.
Note:
The DBUA is the recommended method for upgrading a database. Beginning with release 10.2, you can also use the DBUA to upgrade to a new patch release of Oracle 10g release 2.
* Manual upgrade using SQL scripts and utilities
* Export and Import utilities
* CREATE TABLE AS SQL statement

et je réponds... au bug prêt

Et j'ai trouvé : Note:420146.1

The Database Upgrade Assistant (DBUA) interactively steps you through the upgrade process and
configures the database for the new Oracle Database 10g release. The DBUA automates the upgrade
process by performing all of the tasks normally performed manually. It is very easy to use to the
DBUA, but if there are any errors/issues while using the DBUA for upgradation, it is very difficult to debug and troubleshoot.

Plus loin :

DBUA is very easy to use, but hard to troubleshoot if it gets errors. Finally Manual upgrade is
not as easy as using the DBUA, but you have total control of the process and its easier to troubleshoot if you have problems.

Conclusion : Il n'y a pas de meilleure méthode... donc je reste sur mon import avec un dictionnaire tout beau tout neuf

**LeoAnderson** · 28/11/2007, 14h47

pas forcément une confiance aveugle, mais sur des volumes conséquents, et 2 To, ça commence à l'être, je préfère éviter des grosses opérations, avec les complications qu'elles amèneront.... (TEMP qui explose pour la construction des indexes, To d'archiveds logs générés, contention disque, ...) pour rien...

Une montée de version, c'est mettre à jour le dictionnaire, pas se palucher une à une toutes les données applicatives qui ne bougeront !

sans compter que je te parle pas d'utiliser le DBUA mais de faire l'upgrade manually (catupgrd.sql principalement)
là, tu as la maitrise... autant que quant tu passes un catpatch ou un catexp..