Extraction fonctionelle d'une base

J'ai une base de dev et une base de prod.
Ma base de dev est devenue inexploitable au fil des années.
J'aimerai la remettre d'équerre, mais j'ai 2 soucis :
1 - la prod est en 10g et la dev est en 9i
2 - la prod fait 1.5 Go et la dev n'est pas dimensionnée pour

Donc, outre le problème de version, je ne peux pas utiliser imp/exp pour aller de la prod/dev.

Du coup, je me demande si il existe des outils pour faire une extraction plus fonctionnelle de la base ?

Par exemple, j'ai un système de gestion des clients, je veux extraire mes clients utilisés uniquement en 2007 ?

Doit-on faire les extractions à la mano ? Où existe-t-il un outil type "aspirateur fonctionnelle" ?

D'avance merci pour votre aide.

pourquoi pas l'export avec le paramètre QUERY ?

Export avec le paramètre QUERY ?

Quel est l'outil ?

l'outil c'est l'export d'oracle et query c'est un paramétre de l'export qui permet d'appliquer une clause WHERE sur les données à exporter :mrgreen:

Sinon, t'as aussi la méthode de COPY sous sql*plus ou population des données via DB Link.

En passant, j'vois pas bien l'intérêt d'une prod en 10g si le dév peut même pas utiliser les nouveautés de cette version... j'pense qu'un upgrade serait fort utile :?

Citation:

---

Donc, outre le problème de version, je ne peux pas utiliser imp/exp pour aller de la prod/dev.

---

Est-ce que vous avez essayé d'utiliser l'export 9i et l'import 9i pour exporter la 10g et importer dans la 9i ? Je ne l'ai pas testé mais cela pourrait marcher d'après le Utilities Guide .

Il serait quand même plus judicieux de migrer la base de dev. en version 10 pour avoir exactement la même version que la base de production.

Ok d'accord.

Par contre, la méthode QUERY est valable uniquement dans le cas de l'export d'une table en particulier.

Moi, ce que je voudrai, c'est plutôt un export du type :

Table principale COMMANDE
Table associée CLIENT
Table associée FOURNISSEUR

Je veux faire un export de ma table commande pour le mois de septembre et qu'il emporte par la même les fournisseurs et les clients qui sont liés.

Je me suis déjà cassé les dents la-dessus : le paramètre QUERY n'autorise pas les jointures, donc tu es vite limité quand tu dois définir un périmètre fonctionnel comme c'est ton cas.

A mon avis, la meilleure solution est de faire des INSERT/SELET via un DBLink si tu en as la possibilité, mais j'avais moi le problème que les architectes interdisaient l'utilisation des DBLinks en prétextant la sécurité (au passage, on peut faire un DBLink sur un schéma dédié, accédant aux tables d'autres schémas uniquement en lecture seule via des synonymes).

Donc, pendant longtemps, je galérais à faire mes exports/imports manuellement via TOAD. Comme ça prenait plusieurs jours, que c'était gonflant et avec des gros risques d'erreurs, j'ai fini par prendre 2 semaines pour développer les spool d'un côté et les loaders de l'autre. Je pense que c'est la moins mauvaise des solutions faute de pouvoir utiliser les DBLinks...

Citation:

---

Envoyé par strikerm59

Moi, ce que je voudrai, c'est plutôt un export du type :

Table principale COMMANDE
Table associée CLIENT
Table associée FOURNISSEUR

Je veux faire un export de ma table commande pour le mois de septembre et qu'il emporte par la même les fournisseurs et les clients qui sont liés.

---

Dans ce cas, il faudra faire appel à un produit tiers (TRES cher) si tu veux pas faire de DB Link et charger ton dev :?

Sinon, tu peux faire un QUERY sur COMMANDE et import complet sur CLIENT et FOURNISSEUR qui sont probablement beaucoup moins volumineux :)

Je suis d'accord que dans un cas comme ça l'utilisation des DB_LINK est sans doute ce qu'il y a de plus "simple"...enfin çà dépend de ton nombre de tables, de ta volumétrie ainsi que de la complexité des clauses fonctionelles que tu veux utiliser.

Tu développes une procédure stockée qui te remplit ton environnement de dev avec ce que tu veux exactement (une série d'INSERT avec les clauses WHERE qui vont bien)
Mets un maximum de paramètres (ex le mois que tu veux charger) des le départ comme ça tu pourras le réutiliser et l'améliorer au fur et à mesure.
Et n'oublie pas de vider tes tables avant de les recharger ;)

Tu peux aussi développer un script/batch qui te fait tous les exports que tu souhaites (avec parametre query) et qui réimporte ce que tu veux. Cette deuxième solution sera sans doute plus performante que l'utilisation des DB_LINK.

Dans les deux cas, il y a du boulot... mais par contre tu auras un script/une procédure réutilisable à volonté pour recharger ton dev...

J'aurais tendance à dire que cela fait partie des premières choses à coder sur un projet ;)

A noter : un tel script peut aussi être réutilisé si tu as des besoins d'archivage par exemple (quand tu as envie de purger ta base des commmandes/factures datant de plus de deux ans par exemple en les mettant sous fichier plats)

Ok.

Merci pour vos réponses.

Je pense que je vais faire le nécessaire pour migrer vers la 10g et faire un dump de la base de prod.