Discussion :

[janlouk]

Bonjour à tous,

Je débute dans Oracle mais je dois faire des refresh depuis notre environnement PROD vers 2 environnements de TEST.

J'ai effectué un dump de notre PROD, et j'aimerais savoir si je peux lancer 2 mêmes restore depuis le même fichier .dmp.

Avec la commande imp monuser/monpassword@moninstance FROMUSER=xxxxx TOUSER=wwww FILE=monfichier.dmp log=IMP.log &

Ca me ferait gagner beaucoup de temps, mais même si c'est de la lecture... Je crains pour des éventuelles corruptions en cas de lenteur de lecture du fichier par mes 2 commandes.

Merci
Jean-Luc

[ojo77]

Bonjour,

Pour des tas de raisons, il est préférable d'éviter de faire des restaurations d'environnement à partir de "dumps". On retiendra principalement la désorganisation des données des environnements restaurés par rapport à l'environnement initial (à moins de travailler en mode transportable tablespace ce qui, à la lecture votre question, me semble ne pas être votre cas). Il est donc préférable d'utiliser RMan pour ce genre d'opérations.

Au delà de ça, il ne devrait pas y avoir de souci particulier à restaurer deux bases à partir d'un même dump sous unix (ou linux), je ne parierais pas la même chose sur windows. Les possibles contentions d'accès dépendent de paramètres plus physiques que logiciels.

[Pomalaix]

... On retiendra principalement la désorganisation des données des environnements restaurés par rapport à l'environnement initial..

Salut, tu peux détailler un peu ton argument ?
L'import va certes pouvoir conduire à un placement différent des données dans les tables (avec un impact potentiel sur le clustering factor et donc les plans d'exécution), mais cet impact peut être tout à fait positif grâce à la défragmentation qui résulte de l'import.

[ojo77]

Bonjour Pomalaix,

Comme vous le dites, l'impact peut être positif (ou négatif) il y a donc bien impact et rien que ça n'est pas souhaitable.

Le premier impact avec un dump classique est le re-tassement des données tous les blocs composants le segment importé sont remplis jusqu'à leur PCT-FREE alors que le segment d'origine avait peut être subi mises à jour ou des effacements de lignes créant au choix et sans limitation vides, chained-rows et remplissage de blocs au delà du PCT-FREE. Bref le segment importé a peu de chance de ressembler au segment exporté.

D'autre part, si on utilise datapump (c'est un constat et je n'ai pas creusé le pourquoi) il semble que les données puissent être importées dans un ordre différent de l'ordre dans lequel elles étaient stockées dans la table d'origine et donc modifie l'affinité des colonnes avec leurs index (clustering factor).

Ces deux points sont importants parcequ'ils agissent directement sur l'exécution du SQL et notamment sur les plans d'exécution. Une telle duplication d'environnement peut être envisagée au mieux pour de la validation fonctionnelle du moment que l'on ne tient pas compte du SLA. Au delà, il faut clôner la base (avec Rman ou autre peu importe).

Mais tout cela vous le savez non ?

[janlouk]

Merci à tous les deux pour ces infos.

Mais dans mon cas, je ne prends pas toute la DB, mais que certaines tables. Rman peut faire cela aussi ? Je suis étonné de ce que vous dites pour l'ordre des données car c'est la procédure (faire un .dmp) que je dois suivre depuis plusieurs semaines et les développeurs ne se plaignent pas. Même si je pense que pour eux, le plus important c'est le nombre de lignes et la structure des colonnes et nom l'ordre des données.

Je vois ici http://oracle.developpez.com/guide/sauvegarde/rman/ qu'il y a moyen de faire des sauvegardes. Mais que certaines tables, c'est possible ?

C'est plus rapide qu'en ligne de commande exp xxxx ou imp xxxx ?

J'avais essayé de faire cela avec SQL Developer, mais c'était tellement lent... Il n'y a pas un utilitaire graphique, simple à utiliser pour faire ce genre de backup/restore ? (Désolé, je viens du monde Windows )

[ojo77]

Bonjour,

Il est en effet possible pour RMan (ou datapump) en mode 'transportable tablespace', de ne sauvegarder que certaines tables du moment que toutes les tables, index et contraintes sont dans un même ensemble de tablespaces et que ces tablespaces ne contiennent que ces tables, index ... Bref il faut l'avoir prévu d'avance et si les développeurs ne s'inquiètent pas de la manière dont leurs tables sont remplies, on se doute qu'ils s'inquiètent aussi assez peu du tablespace dans lequel elles e trouvent. Bref, je doute que cette possibilité soit, dans votre cas, ouverte.

Ne Resterait donc uniquement l'export ou le datapump au niveau table.