[INFO] Gestion d'un environnement TEST / PRODUCTION

**nuke_y** · 05/08/2005, 15h10

Bonjour,

le client chez qui je travaille en ce moment était quelque peu amateur de sensations fortes et travaillait toujours en production (oui oui je sais

).Heureusement des sauvegardes était faites, enfin bref c'est pas la question.

Donc, comme j'en avais marre de modifier directement les structures et de faire les tests en production (c'est sympa d'avoir un directeur du contrôle de gestion qui vous flagelle pendant que vous essayez de lui rétablir la production pour qu'il puisse bosser), je fais le forcing pour qu'on passe à un véritable environnement TEST / PRODUCTION.

Et vous le croirez pas mais... on y est arrivé !!! (si si).

Bon donc maintenant on a un serveur de production et un serveur de test et POUR L'INSTANT ils sont assez semblables au niveau des structures et des données.

Pour les structures je m'inquiète pas trop trop. Au pire on gérera à l'import/export et ça ne bougera pas sans prévenir.
Les données par contre c'est plus problématique. Je me demande comment avoir un environnement de test qui soit une copie de la production... mais seulement pour certaines tables !!

Je m'explique :
j'ai 2 tables A et B en production.
Mes développements m'ont conduit à créer une table C en TEST.
Maintenant pour tester mes développements il faudrait que je puisse récupérer les données de la prod pour les mettre en TEST mais seulement dans A et B ... et ne pas supprimer C. Donc déjà on oublie le DROP USER.
De même si je truncate A et B, ou si je les drop puis que j'importe, c'est la galère parce que j'ai des contraintes avec C dans le TEST que je n'avais pas en production (évidemment). Donc je dois désactiver tout ça puis réactiver ensuite ...

D'où ma question :

Sous une 9i, comment gérez vous la synchronisation entre la PRODUCTION et le TEST ?
Comment mettez-vous en production les nouvelles modifications ?
Ecrivez vous des scripts avec la liste des tables/contraintes à modifier ou plutôt du SQL dynamique ?
Y a t-il des solutions sans (trop de) coût ?

Notes :
- la base bouge toutes les nuits (il y a des traitements). Rarement pendant la journée.
- pas de soucis pour les sauvegardes, c'est une équipe de DBA sur Paris qui s'en charge. D'ailleurs est-ce qu'on pourrait imaginer de leur attribuer la gestion de la synchro entre PRODUCTION et TEST ?

Merci

**Jaouad** · 05/08/2005, 15h17

Scénario 1 :

1) Désactivation des contraintes ( SQL dynamique ) : il me semble que tu es un champion dans ce cela

2) Truncate reuse storage .
3) Import des tables A et B .
4) Ré activation des contraintes .

Si tout tourne bien , un script automatisé pourrait faire tout cela aprés le passage des Batchs.

Scénario2 :
Il n'y a pas bcp de tables qui existent en test et qui n'existent pas en production :

1) export des tables de test
2) Copie de base
3) Import des ces tables

**orafrance** · 05/08/2005, 15h21

ou alors tu crées la table C dans un autre tablespace est tu rafraichies via tablespaces transportables

**orafrance** · 05/08/2005, 15h23

truncate, avec un modéle idéal c'est même pas la peine, tu auras des violations de contraintes qui éviterons les doublons et basta

par contre, il faut désactiver les FK parce que les tables peuvent être importées dans un ordre qui ne convient pas

**nuke_y** · 05/08/2005, 15h25

Envoyé par jaouad

Scénario2 :
Il n'y a pas bcp de tables qui existent en test et qui n'existent pas en production :

1) export des tables de test
2) Copie de base
3) Import des ces tables

mais oui bon sang c'est évident !!!!!!! Non mais je rêve là !!! C'est pas croyable un abruti pareil !!!

Je vais faire comme bien sûr. Export de ce qui m'intéresse, écrasement du test par le production, puis ajout de ce qui manque (ajout des contraintes etc.)
Et ça me permet même de tester la procédure que je donnerais aux DBA pour le passage des modifications en production !!

Bravo Monsieur Jaouad.

Bon je met résolu, mais n'hésitez pas à donner des cas particuliers, des techniques de sioux pour régler des problèmes de ce genre là, etc.

**Jaouad** · 05/08/2005, 15h26

Envoyé par orafrance

truncate, avec un modéle idéal c'est même pas la peine, tu auras des violations de contraintes qui éviterons les doublons et basta

Truncate intervient aprés la désactivation des contraintes

**Jaouad** · 05/08/2005, 15h29

Envoyé par nuke_y

mais oui bon sang c'est évident !!!!!!! Non mais je rêve là !!! C'est pas croyable un abruti pareil !!!

non mais attent , je ne te permet pas ...

sinon la solution des tbs transportables ( depuis la 8i ) d'Orafrance est pas mal

Il faut enlever l'étape 2 de la solution 2 ( ca sert à rien

)

**nuke_y** · 05/08/2005, 15h34

Euh oui, je la remplacerai par DROP des users moi carrément.

Ah si je crois me souvenir d'un problème. Si on a pas les mêmes tablespaces entre PROD et TEST, on fait comment ?

**orafrance** · 05/08/2005, 15h34

Envoyé par nuke_y

Euh oui, je la remplacerai par DROP des users moi carrément.

si t'écrase la base te casse pas la tête à droper quoi que ce soit

**Jaouad** · 05/08/2005, 15h35

Envoyé par orafrance

Envoyé par jaouad

Il faut enlever l'étape 2 de la solution 2 ( ca sert à rien

)

je ne l'ai pas fait parce qu'elle intervient dans la citation de nuke
Ca ne pose pas de probléme mon cher Modo ?

**orafrance** · 05/08/2005, 15h40

j'ai fait un peu de nettoyage... I've got the powaaaa

**Jaouad** · 05/08/2005, 15h42

Envoyé par orafrance

j'ai fait un peu de nettoyage... I've got the powaaaa

you are my hero

**nuke_y** · 05/08/2005, 15h42

Euh mais attention je vais pas écraser la base de test en entier, il y a peut-être des gens qui développent sur d'autres USER que les miens. Non je vais juste droper les schémas sur lesquels il y a des modifs et importer ceux de la prod. Il y a un ou deux schémas par métier en fait.

Sinon c'est quoi les tbs transportables?

**orafrance** · 05/08/2005, 15h44

c'est un export/import du tablespace

http://oracle.developpez.com/guide/a...ablespaces/#Lc

**Jaouad** · 05/08/2005, 15h46

Envoyé par nuke_y

Euh mais attention je vais écraser la base de test en entier, il y a peut-être des gens qui développent sur d'autres USER que les miens. Non je vais juste droper les schémas sur lesquels il y a des modifs et importer ceux de la prod. Il y a un ou deux schémas par métier en fait.

Sinon c'est quoi les tbs transportables?

Dans ce càs il faut te renseigner si il existe d'autres schémas sur cette base .

Si oui alors dans ce càs , la solution des TBS transportables est good for you

On export Le TBS avec tout les objets qu'il contient ?
donc chaque user a un ou plusieurs TBS qui lui sont propres et ainsi on exportent que les TBS qui correspondent à un USER

**nuke_y** · 05/08/2005, 15h49

Euh les tbs transportables c'est pas possible, je crois que c'est pas le même jeu de caractère (bizarre d'ailleurs).

Mais en fait suite à reflexion je pense qu'on a les mêmes tbs, au moins pour mes schémas à moi : MON_SHEMA_DATA et MON_SCHEMA_IDX pour chaque schéma.

Donc ça devrait aller. De toutes façons je fais un test lundi au plus tard (j'ai justement un développement à faire monter en production).

**Jaouad** · 05/08/2005, 15h52

Je vais squatter ce post pour poser une question , si tu le permet nuke
Orafrance

Quid des packages , procédures , focntions qui sont définit dans Tablespace SYSTEM .

Je m'explique : si on export ( TBS transportable ) le TBS DATA1 et INDEX1 concernant le user DVP , alors on n'exporte pas les segments dans le TBS system , il devrat donc les recréer à la main , non ?