• Pour chacun des tablespaces

ALTER TABLESPACE  nom_tablespace BEGIN BACKUP;
	Pour chaque fichier l’y constituant
Le sauvegarder
ALTER TABLESPACE nom_tablespace END BACKUP;

ALTER DATABASE BACKUP CONTROLFILE TO ‘nom_du_fichier’;
ou
ALTER DATABASE BACKUP CONTROLFILE TO TRACE NORESETLOGS;

/*
|| hotback_cre.sql
|| Creation des scripts SQL pour le hot backup, et du .cmd utilisé pour 
|| récuperer les fichiers. La procedure renomme les fichiers copies pour éviter
|| les conflits de noms (2 fichiers, même nom, différents répertoires. 
|| Radu, 2000)
/*
set serveroutput on
set line 1000
spool lis/hotbackup_lance.sql
DECLARE 
  /* 
  || les fichiers qui constituent un tablespace 
  || l'embelir pour chercher uniquement les fichiers  
  || qui ne sont pas offline
  */
  CURSOR filespertablespace (le_tablespace VARCHAR2) IS
  select file_name from sys.dba_data_files 
  where tablespace_name = le_tablespace;
  /* 
  || les tablespaces du systeme
  || l'embellir pour chercher uniquement les tablespaces 
  || qui ne sont pas en read only (c.a.d. read write
  */
  CURSOR les_tablespaces IS
    select tablespace_name from sys.dba_tablespaces;
  commande_copie varchar2(1000):= ' copy ';
  destination varchar2(1000):= ' h:\hot_bck_idba\';
  
BEGIN
  /* boucle pour chaque tablespace */
  FOR un_tablespace IN les_tablespaces LOOP
     /* boucle pour chaque datafile */
     dbms_output.put_line( 'ALTER TABLESPACE '|| 
     		un_tablespace.tablespace_name || ' BEGIN BACKUP;' );
     FOR unfichier In filespertablespace(un_tablespace.tablespace_name) LOOP
      	dbms_output.put_line( commande_copie || ltrim(unfichier.file_name)
      		|| destination || translate(unfichier.file_name,':/\','@[]'));
     END LOOP;  /* fichiers per tablespace */
     dbms_output.put_line( 'ALTER TABLESPACE '|| 
     		un_tablespace.tablespace_name || ' END BACKUP;' );
   END LOOP; /* tablespaces per systeme */
END;
/
spool off
                       
spool lis/hotbackup_recover.cmd
DECLARE 
  CURSOR filespertablespace (le_tablespace VARCHAR2) IS
  select file_name from sys.dba_data_files 
  where tablespace_name = le_tablespace;
  CURSOR les_tablespaces IS
    select tablespace_name from sys.dba_tablespaces;
  commande_copie varchar2(1000):= ' copy ';
  destination varchar2(1000):= ' h:\hot_bck_idba\';
BEGIN
  /* boucle pour chaque tablespace */
  FOR un_tablespace IN les_tablespaces LOOP
     dbms_output.put_line( ':: Tablespace ' || un_tablespace.tablespace_name); 
     /* boucle pour chaque datafile */
     FOR unfichier In filespertablespace(un_tablespace.tablespace_name) LOOP
      	dbms_output.put_line( '-- ' || commande_copie || destination || 
      	       translate(unfichier.file_name,':/\','@[]')   || ' ' || 
      	       unfichier.file_name);
     END LOOP;  /* fichiers per tablespace */
   END LOOP; /* tablespaces per systeme */
END;
/
exit;
Code 1	Script générateur des fichiers de commande pour le Hot Backup
Le script de création du fichier de commandes qui recopie les fichiers est à lancer immédiatement après celui qui génère le hot backup !

Est-il nécessaire de faire un backup full (à froid) d’une base en ARCHIVELOG chaque semaine ?
Le seul réel avantage d’un full backup réside dans le fait qu’en faisant un SHUTDOWN de l’instance, nous libérons la mémoire, nous tuons les procès fantômes, etc. Certaines versions d’Oracle nécessitaient un cold backup pour RECOVERY. En réalité, la fréquence des backups à froid est dictée par les besoins de la boite. En fait, de mon point de vue, un cold backup limite les possibilités de restauration et nécessite une attention particulière lors de celle-ci : une restauration à froid effectuée d’une manière incorrecte peut n’en être pas une. Les fichiers copiés d’un backup d’hier n’ont pas besoin de restauration : ils sont en bon état !
Le hot backup – toute une stratégie
Une stratégie pour les hot backups est nécessaire. De notre point de vue, il constitue la seule réelle option de sauvegarde, même en environnement gigantesque, qui permet de sauvegarder en ligne, donc nécessaire en environnement 24/7. La figure ci-contre montre la stratégie de sauvegarde cyclique des fichiers qui constituent la base de données.
Dans notre cas, quatre fichiers constituent la base. Pour sa tranquillité le DBA a effectué avant t0 un backup a froid. N’oublions pas qu’il emploie l’archivage (automatique, bien sur). Ce moment peut bien avoir eu lieu il y a un an. Le DBA sauvegarde pendant une période préétablie (dT) la totalité de ses fichiers. Ce processus se réitérera régulièrement. A la fin de chaque période tn, il disposera de plusieurs jeux de copies des fichiers (celles effectués à tn-2,tn-1, etc.) Pourquoi cyclique ? Bien évidement, lors d’une catastrophe, le DBA remplacera le fichier (ou les fichiers) endommagé par leurs plus récentes copies et il va rejouer les archives. Si les copies ne sont pas très récentes, il devra rejouer TROP d’archives, donc la restauration risque de durer longtemps. Comment calculer l’intervalle idéal de répétition de sauvegarde des fichiers ? Le DBA s’est imposé un delta T maximal de restauration. Nous pouvons aisément estimer le nombre maximum de redologs à lire dans l’intervalle spécifie. Bien sur, dans les estimations nous allons prendre en compte les périodes chargées de la journée. En fonction du nombre de redologs ainsi obtenus, nous connaîtrons  l’intervalle de temps de répétition de sauvegarde en déterminant le nombre maximum d’archives lisibles dans l’intervalle spécifie. (en faisant des exercices, bien sur). Une fois cette stratégie déterminée, il devra s’affranchir des copies inutiles (trop vétustes). Un élément à prendre en considération, le nombre minimal mais suffisant de copies et archives à garder sur les disques. Lors d’une restauration qui nécessite des restaurations des fichiers sur bandes, le temps de restauration s’allonge. Lors du choix du backup full à froid, la complexité de gestion des cartouches s’accroît, les options de restauration risquent de s’alourdir.
http://www.tafora.fr/bin/img/hotbackup.gif


                           

                           

                      Création du script de copie des fichiers utilisable lors du recover











  
  

  

    

    

       

       

       

          Copyright © 1998-2002 Radu Caulea, 
          TAFORA
          
MAJ 06/11/2006
          

       
       

       
Commentaires et suggestions radu[CHEZ]tafora.fr