|
Publicité ' | |||||||||||||||||||||||
|
|
#1 |
|
Invité de passage
![]() Ingénieur systèmes et réseaux Inscription : août 2011 Messages : 2 ![]() |
Bonjour,
Je suis ingénieur système et pas DBA, j'ai besoin de votre aide. J'ai une base oracle en france sous windows server 2003 et en suisse mon nouveau serveur sous windows server 2008. Je dois réaliser un export full et ensuite un import full entre les deux serveurs. Voici mes questions: 1-Est ce que la base de donnée doit être de même version entre les deux serveurs? 2-Est ce que on doit installer la base de donnée oracle sur le serveur en suisse et faire l'import sur cette base ensuite? ou alors l'import installe tout? 3-Sachant qu'il y a des firewall, est ce que on fait un import par ftp? quels ports doivent être ouvert sur le réseau? bref que doit on faire pour qu'il n'y ai pas de problème de communication entre les deux serveurs et surtout entre les deux bases? 4-Quels sont les lignes de commandes pour faire l'export et l'import entre les deux serveurs si je n'utilise datadump? Merci d'avance pour votre réponse Cordialement Elyass |
|
|
00
|
|
|
#2 | ||
|
Membre du Club
![]() Inscription : octobre 2009 Messages : 62 ![]() |
Bonjour,
Alors, dans l'ordre : 1. Non, la base de données ne doit pas nécessairement être de la même version entre les deux serveurs. Cela dit, c'est plus facile si la base cible est dans une version supérieure ou égale (donc non inférieure) à la base source. 2. L'import va créer les objets sur la base cible s'ils n'existent pas au préalable. Il va aussi créer les tablespaces s'ils n'existent pas (... mais avec les mêmes datafiles et sur le même filesystem que sur la base source, ce qui n'est pas forcément ce qu'on veut). En revanche, tu dois au préalable créer l'instance Oracle avant de lancer l'import. 3. Je te conseille de faire d'abord le tranfert (par ftp ou autre chose) du fichier dmp de ton serveur source vers ton serveur cible, puis de lancer l'import en local sur le serveur cible (un import par Sql*Net c'est toujours très lent) 4. J'imagine que tu veux TOUT exporter de ta base source et TOUT importer dans ta base cible... Code :
|
||
|
|
00
|
|
|
#3 | |
|
Membre du Club
![]() |
Citation:
Dans le premier cas, un import full n'est pas nécessaire. Si vous avez déjà des bases installées en Suisse avec des utilisateurs, etc. un import full peut affecter le fonctionnement de votre système. Dans le deuxième cas, un export/import full fera l'affaire. |
|
|
|
00
|
|
|
#4 | |
|
Membre éclairé
![]() |
Citation:
IMPORT crée les tablespaces si on fait un FULL. Au cas où tu fais un import full, il faut que le systeme cible a les memes partitions systeme (OS) que le systeme source, sinon une erreur va se declancher. |
|
|
|
00
|
|
|
#5 |
|
Membre régulier
![]() |
Bonjour,
Voici ma contribution: - Pour eviter la lenteur de SQL*Net, utilise plutôt l'export/import des fichiers dumps - Evites de compresser les fichiers dumps car cela pourra générer des erreurs - Pour eviter plusieurs désagrements lors du full_import, importe plutôt les differents schema de ta base si tu les les connais. |
|
|
00
|
Copyright © 2000-2012 - www.developpez.com