Discussion :

[sygale]

Bonjour et joyeuses fêtes,

je dois mettre en place une nouvelle strategie de rafraichissement des bases de dev.
Nous avons 2 bases de dev sur 2 serveurs différents, bd_dev1 sur serv1 et bd_dev2 sur serv2, la base de production db_prod et enfin un clone db_clone.

Ce qui nous fait- serv0.db_prod = base de production
- serv0.rman = base rman

- serv1.db_clone = base clone (recopie de la production tous les matins avec rman sur serv0)
cette base est utilisé que pour les bugs bloquants en prod, elle est donc tres peu utilisée
- serv1.db_dev1 = base de dev n°1 test et developpement (recopie de la production sur demande des développeurs)

- serv2.db_dev2 = base de dev n°2 test et intégration (recopie de la production sur demande des développeurs)

Aujourd'hui rman est installé sur le serveur de production serv0.
On me demande qu'aucune remontée de base de dev doit impacter la production.
Il faut donc faire les rafraichissements de serv1.db_dev1 et serv2.db_dev2 à partir de serv1.db_clone.

Je ne sais quelle solution choisir :

- Faut-il mieux installer rman sur serv1 ou utiliser rman sur serv0 ? rman deja installé, mais sur serveur de prod !!?
- Le fait que serv1.db_clone soit modifiés tous les matins vas prendre bcp de place dans rman ? (modifiée à 10 % chaque jour)

Voilà, j'espere avoir été assez clair.

PS : Je suis ala recherche d'une documentation en francais, sur l'installation et utilisation de RMAN, excepté la super doc de présentation de Grégory BROISSARD

[sygale]

Toujours personne ?

RMAN si la base est en NOARCHIVELOG cela ne sert à rien ?

Sinon avez vous une documentation en FRANCAIS que je comprenne quelques choses ?

[Marc Musette]

je ne comprends pas très bien ton problème .

tu as une db de prod que tu dois ramener dans une db de dev ? sans impact sur db de prod ?

utilise le backup de la db de prod

[sygale]

utilise le backup de la db de prod

Cela serait extra mais : je n'ai pas acces au serveur de prod.

Cependant les DBAs de production me dupilique la base de prod un serveur de dev (serv1.db_clone ), et on me demande de mettre en place des remontées de bases à partir ce cette instance (serv1.db_clone).

Je voudrai utiliser RMAN, plutôt que des scripts UNIX pour faire cela.
Donc je voudrai faire une base pour RMAN qui gère toutes mes bases de dev. (6 identiques environs) avec comme target serv1.db_clone et auxilliary les 6 base de dev

Cependant comme serv1.db_clone est en NOARCHIVELOG et qu'elle est recréée tous les matins cela ne posera pas de pb ?
Je devrai re-faire un catalogu RMAN tous les matins ou les modifications de serv1.db_clone seront prise en compte automatiquement avec RMAN ?

[Marc Musette]

tu veux remonter quoi cer la db de prod ? des modifs de structures ? des data ? toutes les data ?

RMAN est un outil de backup/restore , pas de réplication (il y a d'autres produits pour cela )

je pense à CHANGE MANAGER en 9i ou le grid control en 10g pour ce qui est des modifs de structures

[sygale]

RMAN est un outil de backup/restore , pas de réplication (il y a d'autres produits pour cela )

Oui cependant on peut le faire avec non ?

Je voudrai avec une base RMAN gèrer à la fois toutes mes bases de dev et être capable de faire une copie de la base clone sur une des bases de dev. c'est possible ca non ?

[Marc Musette]

oui c'est possible mais si la db à clôner est déjà recensée dans un catalogue RMAN il me semble que c'est celui-là que tu devras utiliser et non en recréer un autre

aussi, si RMAN est une excellente façon de cloner une base de données sous certaines conditions (db ouverte, à partir d'un backup, etc - c'est d'ailleurs certainement pour cette raison que le clonage de la db de prod est réalisée avec RMAN) , mais dans ton cas, je ne suis pas certain que ce soit la solution la plus simple

pourquoi ne pas tout simplement faire une copie base fermée via le filesystem ?

quel avantage aurais-tu à le faire via RMAN ? (Recovery Manager)

et aussi, 6 db de dev ... comment gères-tu le regroupement des modifs faîtes sur chacune ?

et tu n'as pas répondu à ma question : que veux-tu faire remonter de dev vers prod ? des modifs de structures je suppose ?

[sygale]

En fait le clone n'est pas référencé dans le RMAN de prod, c'est juste un auxiliary

Je compte faire une base dédiée à RMAN sur le serveur de dev avec le clone + les 6 bases de dev. Ce qui permet :
- gérer les sauvegardes des 6 bases de dev
- avoir un vrai processus sauvegarde/resto
- faire des copie du clone sur une des 6 bases de dev.
Et à ma connaissance seul RMAN peut faire tout cela en même temps

pourquoi ne pas tout simplement faire une copie base fermée via le filesystem ?

Juste pour tout gérer de la même facon, avec une seule méthode, soit tout par l'os soit totu via RMAN

quel avantage aurais-tu à le faire via RMAN ? (Recovery Manager)

il doit aussi gérer les 6 bases de dev et leur stratégie de sauvegarde/resto

et aussi, 6 db de dev ... comment gères-tu le regroupement des modifs faîtes sur chacune ?

Avec une base RMAN dédiée

et tu n'as pas répondu à ma question : que veux-tu faire remonter de dev vers prod ? des modifs de structures je suppose ?

Tout, je veux faire une copie de prod en fait, sachant que tous les matin le clone est déjà une copie de prod, j'aurai juste à faire une copie du clone avec une de mes 6 bases de dev. en auxiliary non ?

Aujourd'hui, les sauvegardes/resto sont gérer via sh, mais on me demande de faire tout ceci avec l'outil RMAN (décision groupe) c'est comme ca, cela permet aussi de découvrir l'outil !

[Marc Musette]

OK , dans ce cas utilise RMAN pour le backup et le clônage

par contre, RMAN ne te permettra pas de consolider l'activité de tes développeurs sur leurs 6 db distinctes.

pourquoi 6 bases de données ?

[sygale]

par contre, RMAN ne te permettra pas de consolider l'activité de tes développeurs sur leurs 6 db distinctes.

Je comprends pas si je créer une base avec seulement RMAN et un catalogu pour chacune des 6 bases, je peux gérer les sauvegarde/resto de chacune des bases ?!!? donc je peux consolider non ?

Sur une base on fait soit la resto d'une sauvegarde de la même base ou on écrase la base avec une copie du clone

6 bases car :
-3 bases de dev (infocentre, prod, référence)
-3 bases d'intégration (infocentre, prod, référence)
-3 bases formation (infocentre, prod, référence)

[Marc Musette]

à mon avis on parle pas de la même chose : 6 bases de dev alors qu'une seule de prod --> comment gères-tu les ALTER TABLE effectuées sur une des db de dev , et pas dans les autres ?

quid si un SQL marche sur une db (car table A n'a que deux colonnes par exemple) et pas sur l'autre (table A possède trois colonnes) ?

aussi quand je fais le calcul : 3+3+3 = ... 9

soit, en ce qui me concerne , je n'appréhende pas très bien ta problématique .

[sygale]

6 bases car :
-2 et non 3 bases de dev (infocentre, prod, référence)
-2 et non 3 bases d'intégration (infocentre, prod, référence)
-2 et non 3bases formation (infocentre, prod, référence)

En fait il ya 2 bases dite de prod dont une qui est un référentiel entreprise qui est en lien direct avec la prod prod !

2 bases de dev (et non 3, je fatigue je fatigue ) un de pour la prod une pour la référence
idem pour la plateforme intégration
idem pour la plateforme infocentre pour les bases infocentre de développement !

Pour une modif, elle est faite sur la plateforme de dev, ensuite sur l'intégration pour validation, et sur la plateforme infocentre pour voir les impacts.
Ensuite on passe en prod !

Pour le quid, le clone de la base de prod n'est pas compté ici, elle est copie de la prod tous les matins, donc les bug en prod on les reproduit avec

[Marc Musette]

OK . selon moi, il te faut utiliser un catalogue unique pour toutes tes db . le clonage de prod vers dev doit être recensé dans le catalogue afin que la db clone aie sa véritable identité et te permettre d'en faire à ton tour des clones.

si ce n'est pas le cas, et que ton clone est la copie identique de prod (y compris les control files, qui contiennent les infos RMAN) , tu auras des problèmes pour enregistrer ce clone dans ton catalogue dev via RMAN ou en tout cas, tu devras chaque fois reconfiguer la db à cloner ...

néanmoins, tout ceci n'est que supposition sur base de mon expérience -> cela mériterait que tu testes ta solution et voir si elle tient la oute ou si mes dires s'avèrent fondés.

bonne chance et bon travail