|
Publicité ' | |||||||||||||||||||||||
|
|
#1 |
|
Invité régulier
![]() Inscription : septembre 2008 Messages : 8 ![]() |
Bonjour à tous,
Je suis débutant sous Oracle et pourtant en charge des différentes bases Oracle (chez nous et chez les clients). Il me faut plus particulèrement recréer une base en 10g à partir d'un dump du client. Mais je n'ai aucune idée de la structure de la base exportée. Quelqu'un peut-il me donner la marche à suivre pour y arriver avec seulement un dump comme support ? Je ne connais même pas l'architecture du serveur initial (path de la base). Si le chemin de la base importée est sur un autre lecteur que le c:\ qu'est-ce qu'il se passe ? Le dump va-t-il recréer toute la structure de la base initiale (tablespaces) ? Merci de vos conseils. |
|
|
00
|
|
|
#2 |
|
Membre Expert
![]() Inscription : juin 2007 Messages : 1 497 ![]() |
Pas de panique
Déjà, créer une base Oracle 10g à vide en choisissant toi-même les chemins des controlfiles, redologs et datafiles des tablespaces SYS, SYSTEM, SYSAUX et UNDO (pas besoin que ce soient les mêmes que sur la base du client), démarre l'instance avec un pfile minimaliste et ouvre la base Ensuite lance la commande d'import dans cette base avec comme options "full=y show=y" pour juste voir le contenu de ton fichier dump, avec notamment les commandes de création des users (utilise le paramètre "log=..." pour tout conserver dans un fichier) Le plus simple est ensuite de créer sur ta base un tablespace unique DATA, de recréer les users avec comme tablespace par défaut DATA (en reprenant éventuellement les commandes "CREATE USER" dans le contenu de l'import si tu veux les mêmes passwords), et ensuite de lancer l'import de chaque user applicatif ("imp ... fromuser=... touser=... ignore=y", pour que tout soit importé dans le tablespace DATA. Niveau espace disque, laisse DATA en autoextend éventuellement si tu n'as aucune idée de la volumétrie de la base du client Ensuite à toi éventuellement de réorganiser la base, en créant d'autres tablespaces ou en déplaçant des objets Par contre si tu n'as pas les paramètres d'instance de la base du client, impossible de les retrouver dans le dump
__________________
La théorie, c'est quand on sait tout mais que rien ne fonctionne. La pratique, c'est quand tout fonctionne mais que personne ne sait pourquoi. Ici, nous avons réuni théorie et pratique : Rien ne fonctionne ... et personne ne sait pourquoi ! Réplication de base avec Postgresql : http://scheu.developpez.com/tutoriel.../log-shipping/ |
|
|
00
|
|
|
#3 | |
|
Invité régulier
![]() Inscription : octobre 2008 Messages : 6 ![]() |
Citation:
![]() ![]()
|
|
|
|
00
|
|
|
#4 |
|
Invité régulier
![]() Inscription : septembre 2008 Messages : 8 ![]() |
Merci pour la réponse,
L'opération s'est bien passée car j'ai recréé les tablespaces sur le c: avant l'import (merci le log avec show=y). J'ai également essayer en rajoutant un lecteur d: et là l'import recrée tout seul les tablespaces. Encore une question : avec un export Full, on récupère bien tous les schémas de tous les users d'un seul coup ? |
|
|
00
|
|
|
#5 | |
|
Membre Expert
![]() Inscription : juin 2007 Messages : 1 497 ![]() |
Citation:
Si la base source et la base cible sont dans la même version d'Oracle, tu peux même faire un import full pour tout importer d'un coup Par contre si les versions d'Oracle sont différentes (ex : dump d'une base 8i que tu veux importer dans une base 10g) ,c'est délicat et potentiellement dangereux de faire un import full, car ça importe aussi des objets du dictionnaire qui peuvent différer, j'ai déjà eu des soucis du coup je privilégie toujours l'import user par user entre deux versions différentes
__________________
La théorie, c'est quand on sait tout mais que rien ne fonctionne. La pratique, c'est quand tout fonctionne mais que personne ne sait pourquoi. Ici, nous avons réuni théorie et pratique : Rien ne fonctionne ... et personne ne sait pourquoi ! Réplication de base avec Postgresql : http://scheu.developpez.com/tutoriel.../log-shipping/ |
|
|
|
00
|
|
|
#6 |
|
Invité régulier
![]() Inscription : septembre 2008 Messages : 8 ![]() |
Merci pour tes conseils,
Je viens de récupérer un dump à jour du client et je dois remplacer l'ancienne base chez nous. Quelle méthode employer ? Je voulais dans un premier temps effacer le schéma TOTO qui a priori contient toutes les données de tous les utilisateurs créés ensuite dans l'application pour faire ensuite un import FULL. Et là je me rends compte que EM ne marche pas sur le serveur, et SQL Developper (toad non plus) ne me donne pas la visu des différents schémas de la base (logiquement SYS + TOTO) que je voulais vérifier !!! Question : comment voir les différents schémas d'une base en 10g ? avant DBAStudio le permettait sur une base en 8. Faut-il forcément supprimer les schémas avant un import FULL ? tous ou seulement TOTO dans mon cas ? à toute, |
|
|
00
|
|
|
#7 |
|
Membre Expert
![]() Inscription : juin 2007 Messages : 1 497 ![]() |
Regarde dans la vue dba_users pour voir les users créés sur ta base
Lis aussi ce tuto qui liste les utilisateurs spécifiques Oracle qui peuvent exister. Tes schémas applicatifs sont donc tous les utilisateurs existants sur ta base sauf ceux qui sont dans le tuto Si dans le dump que tu as eu toutes les tables sont contenues dans un seul schéma, fait juste un export/import de ce schéma dans ton schéma toto Le plus simple est de faire au préalable un "drop user toto cascade" avant de réimporter, ça évite les conflits si des tables existentes déjà, ou les insertions de doublons
__________________
La théorie, c'est quand on sait tout mais que rien ne fonctionne. La pratique, c'est quand tout fonctionne mais que personne ne sait pourquoi. Ici, nous avons réuni théorie et pratique : Rien ne fonctionne ... et personne ne sait pourquoi ! Réplication de base avec Postgresql : http://scheu.developpez.com/tutoriel.../log-shipping/ |
|
|
00
|
|
|
#8 |
|
Invité régulier
![]() Inscription : septembre 2008 Messages : 8 ![]() |
OK, c'est bien ce que je pensais.
Je connaissais le Tuto, le soucis est dans la définition même du schéma pour Oracle. Dans mes bases, j'ai a priori 3 schémas SYS, SYSTEM et TOTO (donné par DBAStudio et les scripts de création que j'ai retrouvés). Toutes les objets de l'applicatif se retrouvent dans le schéma TOTO. Partout dans les docs on me dit que pour Oracle, un user = un schéma particulier. Mais là, j'ai plein de users clients qui sont tous définis dans le schéma TOTO. Ils n'ont pas chacun 1 schéma. question : sur une base en 10g (pas de DBAStudio !!!) comment je visualise mes 3 schémas SYS, SYSTEM et TOTO si je ne connais rien sur cette base ? Avec un Drop user TOTO cascade, je touche le schéma TOTO avec toutes les données applicatives ou seulement le user TOTO au même titre que les dizaines de users clients ? Je suis preneur d'infos ou de doc claires sur le sujet des schémas car dans la pratique, ce n'est vraiment pas évident. Merci. |
|
|
00
|
|
|
#9 |
|
Membre Expert
![]() Inscription : juin 2007 Messages : 1 497 ![]() |
Si j'ai bien compris, toute ton application et ton modèle de données tiennent dans un seul schéma TOTO (il n'y a donc qu'un seul compte oracle TOTO hormis les comptes SYS et SYSTEM)
Tu confonds Compte Oracle et Connexion utilisateur Toutes les utilisateurs se connectent sans doute à la base en utilisant le même compte Oracle TOTO
__________________
La théorie, c'est quand on sait tout mais que rien ne fonctionne. La pratique, c'est quand tout fonctionne mais que personne ne sait pourquoi. Ici, nous avons réuni théorie et pratique : Rien ne fonctionne ... et personne ne sait pourquoi ! Réplication de base avec Postgresql : http://scheu.developpez.com/tutoriel.../log-shipping/ |
|
|
00
|
Copyright © 2000-2012 - www.developpez.com