Discussion :

[antonomas]

Bonjour,

J'ai une base de données 11g contenant des données statistiques et économiques réparties dans plusieurs schemas/tablespaces. Il s'agit d'une base de production accessible via un extranet.

J'ai d'autre part des utilisateurs formés à SQL qui veulent pouvoir aller tripatouiller dans ces données, importer des données d'étude dans de nouvelles tables, faire des hypothèses en ajoutant ou supprimant des données, ... Il est bien entendu pas envisageable qu'ils puissent aller s'amuser sur la base de production.
De plus, le serveur de production étant hors de nos locaux, les temps de réponse via SQL*Developer ne sont pas toujours bons.

J'envisage donc de mettre en place une base de développement et de tests sur un serveur interne. Cette base va être la copie conforme à un instant T de la base de production. Mais cela va diverger. Et afin que leurs tests continuent à avoir un sens, il va falloir refaire une copie conforme de temps en temps.

Je suis donc à la recherche de la procédure la plus simple possible qui permettent de dire "on refait une copie conforme de la base de prod vers la base de test". Même si cela demande un peu de temps, on lancera ça le week-end. J'aimerais éviter de passer par des exp/imp car il y a vraiment beaucoup de données.

Il faudrait que cette procédure prenne la table A de prod, la table A' de test et rende A' égal à A en appliquant uniquement les différences entre A et A'.

ESt-ce que quelqu'un a une idée sur la manière de faire ? Voire même un tutoriel ?

Merci

[funoracle]

Bonjour,

avant d'aller plus loin, est-ce que votre base de prod est up 24/24-7/7 ? en archivelog ou pas ? Quel est le volume grosso modo ? Rman est utilisé sur la prod ? Qu'elle serait la fréquence de rafraichissement des données de DEV ?

Très rapidement je vois 2 façons de faire en s'évitant les datapump :
- Rman duplicate en utilisant les backupset les plus récents + sql pour recréer les fichiers de controle + spfile puis pour les mises à jour : application archivelog ou re duplication complète ou peut être datapump sur certains schémas simples.
- Copie physique brute à froid (targz ou zip + spfile + sql fichier de controle)

sql fichier de controle est produit par la requête suivante :

Code :

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

1
2
3
alter database backup controlfile to trace;
et oracle stocke le fichier trc dans diagnostic_dest/diag/rdbms/sid/SID/trace

L'idéal est de changer le nom pour la base de DEV, pour éviter toute confusion

Pour la procédure plus détaillée, tout dépends de la disponibilité de la base de prod et des réponses aux questions ci dessus.

Franck.

[antonomas]

Merci pour vos réponses,

la base est up 24/24-7/7 (internet oblige). Cependant, il s'agit d'un extranet professionnel. Donc il arrive tous les 36 du mois qu'une personne fasse des modifs le samedi et jamais le dimanche. De plus, vu le faible nombre d'utilisateurs (qui sont tous connus), il m'est tout à fait possible des les prévenir de ne pas avoir à toucher à la base pendant une période donnée, surtout si c'est le week-end.

Je n'utilise pas rman ni archivelog sur la prod. Les sauvegardes sont assurées par un exp toutes les nuits à 3h du matin (idem que pour le week-end : il n'y a jamais de modifs à cette heure-là). C'est brutal, mais simple.

La fréquence de resynchronisation de la base de dev : je ne sais pas. Cela va dépendre de l'activité et de la demande des utilisateurs. Partons sur une fois tous les 15 jours.

Enfin, le volume des données tourne aux environ de 300 Go réparties dans 6 tablespaces/schema dont un ne bouge quasiment jamais (données de références) et un contient uniquement des tables partitionnées.

Je voudrais avoir à toucher le moins possible au fonctionnement de la base de prod.

[funoracle]

D'accord, donc la procédure à laquelle je pense est la suivante : je part d'un environnement unix.

1) créer la base de DEV, on l'appelle "prodbis". Il s'agit d'un clone de la base de prod. Côté prod :
- Il faut générer le fichier sql trace des fichiers de contrôle
- Il faut générer un pfile à partir du spfile.
- Il faut arrêter la base de prod le temps de faire un tar.gz ou un zip des fichiers de la database. Avant de faire le tar on en profite pour faire la purge des fichiers anciens *tr* dans la diagnostic_dest, ça ne sert à rien de les embarquer dans le tar. Par contre il faut embarquer les fichiers générés ci dessus et tous les dbf, undo, redo.
- Démarrer la prod.
- Faire le ftp du tar.gz / zip et là la durée va dépendre de votre réseau, 300G même zippé ça commence à faire. On peut estimer à la louche à 30G le tar.gz

2) Créer la base prodbis
- il faut detarer le fichier tar
- il faut modifier le pfile : remplacer prod par prodbis dans tout le fichier et créer un lien sur ce fichier dans $ORACLE_HOME/dbs
- il faut modifier le fichier de création des fichiers de contrôle :
en supprimant les autres lignes, garder que le pave qui commence par
CREATE CONTROLFILE REUSE DATABASE "prod" NORESETLOGS
et remplacer par :
CREATE CONTROLFILE SET DATABASE "prodbis" RESETLOGS
et remplacer partout prod par prodbis
- supprimer les lignes après le ; du characterset.
- mettre à jour l'/etc/oratab en rajoutant prodbis
- sourcer la nouvelle instance:
. oraenv
- lancer sqlplus en sysdba puis exécuter le fichier sql modifié ci dessus :
@creation_prodbis_fichier_controle.sql

Il y a de la littérature sur cette procédure.

3) Faire les mises à jour tous les 15 jours en transférant le dernier dump du week end et datapump import du ou des schémas à rafraichir.
Si elle existe lancer la rotation des partitions.

les points 1 et 2 doivent prendre 1 à 2 jours la première fois et descendre à 0,5 jour une fois maitrisés.

Le point 3 dépends du volume des schémas mis à jour.

Franck

[antonomas]

Merci de votre réponse.

Je vais regarder ça dans les jours prochains.