Discussion :

[nuke_y]

Bonjour,

j'ouvre ce post pour discuter de techniques pratiques de gestion d'environnement dév / test / prod.

Chez le client où je suis actuellement nous avons la chance d'avoir un serveur de dev / test et un serveur de prod. Malheureusement le serveur de test est bien moins dimensionné que celui de prod (normal remarque) et je ne peux donc pas avoir exactement les mêmes données en test et en prod.

Je cherche donc des conseils pour utiliser correctement ces 2 environnements.

Voila comment je vois la chose :

- Toute modification de structure s'effectue d'abord en test, puis en prod une fois validée donc NORMALEMENT la structure en test et en prod est la même sauf en phase de validation. Donc il n'y a pas à reproduire la structure de prod sur le test.

- Les données sur lesquelles nous travaillons sont des données quotidiennes, avec des agrégations mensuelles. Donc il suffirait de ne garder dans les tables de test que le mois en cours. Donc je devrais juste mettre en place des traitements (pas avec des scripts mais avec un ETL que l'on utilise actuellement pour nos traitements) pour copier tous les jours les données quotidienne de la production vers les tables de test.


Maintenant les questions :

- quelle est la meilleure façon de copier les données ? Est-ce qu'un imp/exp pourrait aller aussi (si on peut le paramétrer) ?
- que faire quand un test n'a pas marché comme prévu ? Je supprime toutes les données et je redescend tout ?
- comment gérer le fait que je suis en train de valider une modification de structure ?
- comment gérer les clés étrangères ? Alimenter les tables dans le bon ordre ou bien les désactiver, descendre massivement les données de la prod vers le test et les réactiver ensuite ?

Sachant qu'avant on modifiait directement en production, je suis assez satisfait d'avoir réussi à inculquer au client certaines notions de prudence et de sécurité, cependant j'aimerais avoir finalisé les procédures à suivre avant de partir.


Merci de vos conseils / réponses / critiques / avis / expériences.

[nuke_y]

Personne ne gère ce genre d'organisation ? Ca existe pas l'environnement dev/prod sous Oracle ?

[SheikYerbouti]

En vérité, il faut également une instance d'intégration entre la dev et la prod.

Les modifs sont effectuées et validées sur la dev. Elles sont ensuite "jouées" sur l'intégration (après une inévitable sauvegarde).
La même chose pour passer de l'intégration à la prod.

[nuke_y]

Certes, mais c'est dans un cas idéal ça. Je voudrais savoir comment me débrouiller avec ce que j'ai actuellement à ma disposition.

Je pense que SI j'arrive à faire du bon boulot avec ce que j'ai là, on devrait pouvoir les convaincre de passer à une instance d'intégration.

Merci.

[orafrance]

pour rafraichir les données en cas d'erreur ou simplement pour réinitialiser l'environnement, la sauvegarde d'un environnement de référence me parait tout indiquée. Tu prends la dev à un instant t et tu décides (enfin, les testeurs/développeurs ) que cette sauvegarde sert de référence.

Dans le cas particulier que tu as : c'est impossible de travailler convenablement dans ces conditions

comment rafraichir l'environnement sans écraser les dévs ou simplement sans arrêter les dévs en cours ? Comment réduire la volumétrie ? Comment maintenir le Dév sans perturber le cours des projets ? C'est aussi le rôle du DBA d'alerter la DSI sur le manque de moyen et les méthodologies à appliquer

[nuke_y]

Ben tu sais avant ils faisaient les modifs à la main direct en prod... Genre un utilisateur des fois il bossait, d'un coup il avait un message d'erreur et pouf ça revenait avec une structure différente, des données différentes (quand ça marchait).

Donc j'essaye de les éduquer un peu mais c'est pas forcément évident... Je pense déjà que je vais leur imposer de ne faire qu'un dev à la fois par projet, comme ça je n'aurais rien à conserver quand je reproduit la prod sur le dev.

Au niveau descente de la production sur le test, est-ce qu'il y a une solution plus pratique/rapide que de virer tout le contenu du schéma sur le test, exp du schéma de la prod sans les données, imp sur le dev et copie des données du mois en cours via un ETL de la prod vers le test ?

[orafrance]

ça me parait compliqué, c'est un projet à par entière pour savoir comment conserver la cohérence des données et ainsi pouvoir extraire qu'un échantillon

[nuke_y]

Non, l'échantillon on se base sur le mois en cours, ça suffit (on bosse toujours comme ça, même en prod).

[orafrance]

alors l'export/import convient très bien avec l'option Query pour limiter filtrer les données

[nuke_y]

ahaaaaaaah. Ok je vais fouiner vers Query dans l'imp/exp. Merci.

[Jaouad]

ne fouine pas trop loin

Exporter selon une condition

[nuke_y]

ok merci

SQL> select * from dvp_loader ;
NOM SALAIRE
-------------------- ----------
Jaouad 100
orafrance 200
léoanderson 300
bouyao 400
Nuke_y 500
sheikyerbouti 600
pomalaix 700
titides 800
aline 900
denisys 1000
niourk 1100

Mouarf !

[Jaouad]

je suis génèreux avec mon prochain, mais c'est niourk ce dégueulasse qui a tout pris

[nuke_y]

Bon j'avance sur mon problème. Quand j'aurai une procédure convenable je la posterai ici pour donner des idées aux autres.

Là je bute sur le problème suivant :

- Mais comment écraser tous les objets de la base de test avec ceux de la base de production sans dropper/recréer le shéma ?

En fait le problème c'est que j'aimerais soit supprimer le schéma en test et le recréer mais autant récupérer le DDL ça va, autant c'est lourd d'aller chercher les grants, soit supprimer tous les objets du schéma mais ça m'oblige à faire un script et c'est lourd aussi (en fait). Une idée ?

[Zugg]

Je ne veux pas trop m'avancer, mais je crois que la seule solution est de supprimer le schéma. Pour la recréation, l'utilitaire IMP recréé les tables.

sinon, pour que ça soit plus rapide, faut faire un truncate des tables du schéma, donc un petit script...

ou encore, tu peux utiliser les tablespaces transportables si les données sont contenues dans le même schéma.
pour l'export :
1- passer le tablespace en lecture seule
2- faire l'exp

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 exp transport_tablespace=Y, tablespaces=MON_TABLESPACE FILE=MES_METADATA.DMP

3- copier le fichier dbf de ton tablespace
4- le remettre en read write

et pour l'import en gros il faut faire :
1- supprimer le tablespace de même nom que celui que l'on a exporté
2- copier le dbf de l'export
3- faire l'import :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 imp TRANSPORT_TABLESPACE=Y DATAFILES='chemin vers mon dbf copié en 2' TABLESPACES=MON_TABLESPACE TTS_OWNER=MON_PROPRIETAIRE_DU_DBF FROM USER=<...> TO USER <...> FILE=MES_METADATA.DMP

pour les tablespaces transportables il y a des contraintes d'utilisation comme par exemple, il faut que les données sont contenus dans ce tablespace et pas dans un autre, etc....
j'avais tester le scénario exposé ci-dessus, mais là je le redonne de mémoire....


mais je ne vois pas d'autre solution.

Dans mon soft, je fais un truncate des tables et ensuite je refais mon import pour mettre mes données, mais faut faire attention, ça ne marche que si les structures n'ont pas changées...

voilà c'était la solution que j'utilise....

[nuke_y]

Certes mais là le but c'est de gérer
1) des volumes trop gros pour dupliquer complétement la prod en test
2) des éventuelles modifications à ne pas écraser en test

et en même temps de
1) ne pas pénaliser la prod
2) avoir des données COHERENTES en test
3) ne pas réaliser les traitements en double (ce qui serais presque l'idéal en fait...).

Mais j'ai bien avanccé là, je ferais un beau post bien commenté pour expliquer tout ça.