l'import aussi :langue:
:mrgreen:
PS : pour les grosses bases, je suis prêt à faire des concessions... donc dans le cas présent, pourquoi pas :hola:
Version imprimable
l'import aussi :langue:
:mrgreen:
PS : pour les grosses bases, je suis prêt à faire des concessions... donc dans le cas présent, pourquoi pas :hola:
Et donc tu fais des MOVE ?Citation:
Envoyé par LeoAnderson
Et passer en 10g en upgrade et ensuite via datapump, ca serait pas plus rapide ?
Il faut voir quelles sont les évolutions à apporter, mis à part à passer en 10g....
Si c'est changer le block size, oui, move ou dbms_redefinition à chaud
je ferais tout pour m'économiser le passage par un fichier (dmp traditionnel ou datapump)
Si au passage, vous devez changer d'OS/plateforme, là, il y a l'étape intermédiaire de tablespace transportable qui est plus simple car on manipule les datafiles globalement en tant que tels (cp).
mais vu votre contexte, on doit pouvoir s'en passer...
L'OS ne change pas (solaris 10).
J'attends de voir les derniers "bench" pour envisager ou non une autre solution ...
Bonne nouvelle, avec les paramètres suivant:
303Go en 6 heuresCode:exp DIRECT=Y RECORDLENGTH=65535 ROWS=Y STATISTICS=NONE
Ca fait tout de même 39h pour 2To :/
Voyez vous d'autres optimisation possible pour l'export ?
Ne pas faire d'export/import ? :aie:
Au risque de me répeter, il n'y a AUCUN intérêt à le faire (la réorganisation, vous la ferez après, à chaud, en 10g avec DBMS_REDEFINITION)
Sachant qu'un import prend couramment 3 ou 4 fois plus de temps que l'export correspondant, vous pouvez déjà commander les sacs de café si vous devez surveiller l'opération de bout en bout !!!Citation:
Envoyé par DjinnS
J'ai vu le cas d'une base relativement moyenne (50 Go) dont l'export se faisait en mois de 10 heures et dont l'import seul a durer une semaine non-stop... :yaisse2:
il a dû en falloir des petites mains pour recopier les datas à la main pendant une semaine :mouarf:
et on t'appelles après 3 jours en te demandant ton avis...
on arrête et on recommence différement ou pas ??? :oops:
blague à part, ça veut dire que l'import et forcément plus long que l'export dans un facteur de 3 à 4 en moyenne, mais avec un écart-type assez fort !
Bref, si en 48 heures, vous devez migrer, n'exportez pas !
je connais dbms_redefinition mais bon, juste de nom ^^ Nous n'avons jamais eu l'occasion de nous entretenir en privé ...
Je vais me renseigner donc sur cette méthode:
- migrer en 10g
- redéfinir les tables, car oui, nous devons absolument changer le blocksize
Sinon, selon votre expérience, cette méthode prend combien de temps ? Est ce que la redefinition est un processus long ?
Après calcul de la taille, nous somme plus a 1.6To qu'a 2To, mais bon, ca fait toujours une belle bête.
Désolé pour le harcèlement ... mais ...
L'idée c'est de ne pas changer le block size de la base (db_block_size) mais de recréer mes tablespaces avec un autre blocksize, possibilité qu'il me semble avoir vu lors de ma formation 10g ^^
Mais bouger 1.6To avec dbms_redefinition sera plus rapide que l'import ?
Autre petit question, on passe de 32 à 64Bits, ca ne pose pas de problème particulier pour le stockage des données ?
Merci ^^
la redéfinition ne sera pas plus rapide que l'import, non, mais elle se fait à chaud : les données sont toujours accessibles pendant le temps de traitement. La contre-partie est que ça demande à un instant t le double de place disque.Citation:
Envoyé par DjinnS
Non, le changement d'architecture peut éventuellement vous imposer de passer par des tablespaces transportables comme indiqué dans la note que je mentionnais pour changer de machine.
Les fichiers restant sur la baie, il n'y a pas réellement de copie à effectuer.
Avec dbms_redefinition il faut aussi avoir les redos bien dimensionné, sinon je pense qu'on est pas à l'abri de se manger un snap shoot to old.
Je pense qu'on va faire l'export/import.
On a de toute facon la possibilité de le tester donc on va savoir combien de temps ca va prendre.
Vous n'avez donc manifestement pas compris le fonctionnement de la redéfinition... :oops:
La redéfinition se fait par l'utilisation de vues matérialisées.
L'undo est donc assez peu sollicité. (et c'est l'undo qui cause le snapshot too old, pas les redo)
Les redo pour le coups oui sont un peu sollicités, mais bon, ça, c'est pas la mort ! :)
mais bon... vous faites ce que vous voulez..
manifestement vous êtes payé au temps passé et non à l'optimisation des résultats et minimisation de l'interruption de service...
dans ce cas, je vous suggère de passer par un file csv et de l'importer avec utl_file ! :lol:
J'avais pensé rebondir sur tes propos totalement débiles, mais finalement je supprime ce que j'ai dit. Je dirais juste que j'ai un seul objectif: réaliser la migration dans de bonnes conditions. La volumétrie fait que nous avons des problèmes de temps mais l'utilisation de dbms_redefinition est bien trop lourd selon moi. C'est pour cela que je pose des questions, libre à toi de me faire bénéficier de ton expérience, ou pas.
Mais manifestement nous ne devons pas avoir les mêmes contraintes donc on peu pas se comprendre. La prochaine fois gardes tes commentaires pour toi :oops: (et les smileys qui vont avec).
Et sinon pour l'histoire l'export c'est effectué en une dizaine d'heures ce qui est totalement satisfaisant pour le projet. Reste à voir pour l'import avec datapump (qui est annoncé 15 a 45 fois plus rapide que le vieux import ...) qu'on va paralléliser en 4 threads (machine relativement balaise).
Attention datapump ne saura importer que ce qu'il a exporté !! 8O
Donc, dans votre cas, c'est mort !
Désolé si je vous ai vexé, mais tout de même, en quoi la redéfinition est trop lourde ? :roll:
Et merci de pointer les inepties que j'ai pu dire... je peux dire des conneries, oui, je le reconnais. sans problèmes. Mais dites moi où, que j'apprennes et cesse de les dire ! ;)
PS : je suis peiut-être "old school", mais j'apprécie le vouvoiement qui marque implicitement dans le respect auquel chacun a droit. On ne se connait pas, je fait le maximum pour VOUS aider, moi, je n'ai pas vos soucis... alors merci de vous modérer....
exactement... c'est bien pourquoi j'avais parlé d'une migration 10g avant l'export mais il semble que notre ami veuille utilisé une méthode personnelle malgré nos conseils :?Citation:
Envoyé par LeoAnderson
J'avais lu que datapump était compatible avec les anciennes version d'export/import.
J'ai pas l'intention d'utiliser une méthode personnelle, j'essaye juste de faire au mieux.
Il n'y a aucun manque de respect à tutoyer quelqu'un.
On va clore le sujet, ça commence à mal tourner. Merci pour votre aide. Il faut éviter le Godwin.
La note 132904.1 décrit le process de migration ;)
l'import doit ce faire avec l'outil d'import 10g mais pas datapump :?
Citation:
export dumpfiles created with the original Export utility cannot be read by the Import DataPump client.