Version imprimable
Bonjour,
Je migre actuellement une base Iso 9i stockage (length_semantics Byte) vers du UTF8 10g (length_semantics Char).
Volumétrie = 123 tables pour environ 80 Millions de lignes.
Mon problème se situe au niveau de l'import des données qui est très long.
A votre avis qu'elle serait le meilleur moyen d'optimiser l'import et la conversion.
merci
80 millions de lignes a travers 123 tables... ca ne devrait etre pas grand chose. Quelle taille plutot ?
Quelle est la duree ? OS source, OS cible ?
Nicolas.
Dans tous les cas on ne peut ni faire une copie physique de base ni transporter les tablespaces car le changement de jeu de caractères ne peut pas se faire par ces méthodes.
Eventuellement, si vous migrez la base source en 10g, il pourrait être plus rapide d'utiliser le Data Pump (expdp/impdp) qui peut éventuellement fonctionner en mode chargement direct et en mode parallèle.
Avec l'export/import classique (exp/imp), vous pouvez pour l'import:
- faire une sauvegarde complète de la base cible
- désactiver le mode ARCHIVELOG de la base cible
- laisser le paramètre COMMIT à sa valeur par défaut mais prévoir un undo tablespace assez grand
- augmenter le paramètre BUFFER.
Vous pouvez également essayer de faire du parallèlisme manuel (si le serveur cible est multiprocesseur), càd de lancer plusieurs imports en parallèle qui travaillent sur des données disjointes. Attention au tablespace undo qui doit être encore plus grand dans ce cas là.
Voir aussi la section à ce sujet dans le Utilities Guide.
OS : from Wintel 2000 adv server to Wintel 2003 adv server.
total tables = 357
total rows = 220 millions
La durée est d'environ 20 heures avec plantage.
Actuellement je teste différent scénarios avant une mise en production qui devra s'effectuer dans les meilleurs délais.
J'ai créé 3 fichiers d'export avec direct = y, puis je lance les 3 imports simultanément avec les paramètres suivants sans archivelog.
Commit = n constraints = y indexes = n commit =n buffer = 100000
- Existe-t'il un direct path pour les imports ? si oui la conversion s'effectuera t-elle ?
- En mettant le commit = n, le Undo est passé à 20 Gigas.
lorsque le undo retention est atteint, le commit est-il automatique ou perd t-on les données d'import dû a la réutilisation de l'espace du Undo ?
- Où puis-je trouver le datapump dans Oracle 9i ?
merci
Pour imp: non. Pour impdp: oui qui doit aussi faire la conversion de caractères.Citation:
Envoyé par lelent
Lorsque la durée de retention est atteinte, l'espace undo concerné peut être réutilisé par Oracle. Ceci n'a rien à voir avoir avec un COMMIT automatique pour les transactions qui utilisent ou réutilisent de l'espace undo. Il n'y a pas de lien direct entre la réutilisation ou non de l'espace undo et le COMMIT d'une transaction exécutée par imp.Citation:
Envoyé par lelent
Les outils expdp/impdp n'existent qu'en version 10.Citation:
Envoyé par lelent
Pour essayer d'améliorer les performances, vous pouvez aussi essayer d'agrandir la taille des online redo logs pour éviter des changements de redo logs trop fréquents qui nécessitent un checkpoint. Il ne faut pas hésiter à avoir des tailles de l'ordre du Go dans votre cas, surtout si vous avez des messages du type "checkpoint not complete, cannot allocate new log" dans l'alert.log de votre instance.
J'avais effectivement le "checkpoint not complete, cannot allocate new log" dans l'alert.
J'ai rebuildé les 4 fichiers de redo avec une taille de 1Go pour chacun.
Je n'ai plus de message dans le alert.log mais l'import reste lent malgrè tout.
A combien estimez-vous le temps normal pour l'integration d'une table de
20 Millions de lignes ?
ma ligne de commande : analyze=n FEEDBACK=100000 buffer=100000 commit=n rows=Y ignore=Y grants=n indexes=n constraints=Y
Actuellement mon Tbs devant contenir les rows est configurez ainsi.
Stockage
Type d'allocation Uniforme
Taille (Ko) 128
Gestion des segments d'espace Automatique
Activer la journalisation Oui
Taille de bloc (O) 8192
Pool partagé 500 Mb
Cache de tampon 600 Mb
Zone de mémoire LARGE POOL 416 Mb
PGA 400 Mb
db_file_multiblock_read_count = 128
db_writer_processes = 4
Y'a -t'il des paramétres à surveiller en particulier ? ...
Il est impossible de donner une estimation précise même avec les informations que vous avez donné: tout dépend de la performance du système (CPU, disque, configuration de l'instance).
Quelle est la taille du fichier à importer ?
Suivant la configuration globale du sytème, vous devez pouvez importer de 500 Mo à 1 Go par heure. SI vous avez des LOBs, c'est souvent plus lent.
Pour les paramètres de l'instance:
Citation:
The following suggestions about settings in your initialization parameter file may help to improve performance of an import operation.
Set LOG_CHECKPOINT_INTERVAL to a number that is larger than the size of the redo log files. This number is in operating system blocks (512 on most UNIX systems). This reduces checkpoints to a minimum (at log switching time).
Increase the value of SORT_AREA_SIZE. The amount you increase it depends on other activity taking place on the system and on the amount of free memory available. (If the system begins swapping and paging, the value is probably set too high.)
Increase the value for DB_BLOCK_BUFFERS and SHARED_POOL_SIZE.
La taille du fichier est de 6 Go. pas de LOB.
4 CPU dual core AMD opteron + 8 Go de RAM + raid 5
Le LOG_CHECKPOINT_INTERVAL = 0 . donc le checkpoint s'effectue lors du switch d'un online redo log file à l'autre. si j'augmente la valeur à plus de 1000 le checkpoint se fera quand même lors du switch. donc à priori c'est pareil.
SORT_AREA_SIZE = 1895536 , je suis en mode dedicated server.
Actuellement mon db_block_buffers = 0, n'est-il pas gérer automatiquement par Oracle où dois-je le fixer et si oui par quel multiple ?
merci
A priori, l'import semble beaucoup trop long surtout si la la seule connexion active à la base est celle de l'import et le serveur est dédié à la base.
Vous avez un cache de:
Pour savoir ce qui se passe vraiment pendant l'import, il faudrait mettre la session d'import en mode trace et analyser le résultat avec TKPROF (voir le tutoriel) ou utiliser Statspack/AWR.Citation:
Cache de tampon 600 Mb
Bonjour,
Merci pour votre aide.
L'analyse a permis de voir que le problème ne provenait pas d'Oracle.. mais de la mauvaise gestion des I/O de la carte Raid.
Quoi qu'il en soit, après remplacement de la carte et le tuning préconisé
j'ai chargé un Dump de 34 Go de données en un peu moins de 2 heures.
Cordialement