DUPLICATION DE BASE DE DONNEES SOUS ORACLE9i
LES OPTIONS DE DUPLICATION ET LES ETAPES PREPARATOIRES

Les options de duplication

Lorsqu’un administrateur de bases de données souhaite procéder à la duplication d’une base de données, il dispose d’un ensemble d’options qu’il doit toujours avoir à l’esprit.
Passons en revue rapide ces différentes options de duplication de base de données :
- Exécuter la commande DUPLICATE avec ou sans un catalogue de récupération (recovery catalog, en anglais)
- Ne pas prendre en compte (c’est-à-dire « sauter ») les tablespaces en lecture seule, à l’aide de la clause « SKIP READONLY »
- Créer la database dupliquée sur une nouvelle machine. Si la structure de répertoires est la même sur la nouvelle machine, alors il est vivement conseillé de spécifier l’option NOFILENAMECHECK et réutiliser les noms de fichiers des fichiers de données de la base cible pour les fichiers de données de la base dupliquée.
- Utiliser l’option « SET UNTIL » quand on crée une base dupliquée pour la récupérer à un moment antérieur au moment de sauvegarde.
- Enregistrer la base dupliquée dans le même catalogue de récupération, option rendue possible du fait que la base dupliquée se voit attribuer un DBID différent de celui de la base cible pendant le processus de duplication.
- Attribuer au paramètre DB_NAME de la database dupliquée une valeur différente de celle correspondant au DB_NAME de la database cible.
Il sera beaucoup question dans les lignes qui von t suivre de la notion d’instance ou de base de données auxiliaire (en anglais auxiliary). Une base de données auxiliaire est une base de données RAC qui sera créée en tant que résultat de la duplication de la base de données cible. Dans la terminologie RMAN, l’instance auxiliaire identifie une instance à laquelle RMAN se connecte en vue d’exécuter la commande « duplicate ».


Les étapes préparatoires de la duplication

Etape 1 : Créer un fichier de mot de passe Oracle pour l’instance auxiliaire et s’assurer de la connectivité Oracle Net à cette instance.
Rappelons que la création d’un fichier de mots de passe sous Oracle9i se fait à l’aide de l’utilitaire orapwd fourni par Oracle. L’exécutable correspondant à cet utilitaire sur les plate-formes Unix porte le même nom et a la syntaxe suivante
$ orapwd file=chemin password=mot_de_passe_sys entries=nombre
Les symboles ne doivent pas avoir de caractères espace ni avant ni après.

Etape 2 : Créer un fichier de paramètres d’initialisation pour l’instance

En général, on fait une copie du fichier de paramètres d’initialisation d’une instance de la base de données d’origine et ensuite on procède aux modifications nécessaires. Une attention particulière doit être portée à tous les paramètres d’initialisation qui spécifient des noms de chemins d’accès. Il faut vérifier que tous les chemins spécifiés existent et sont accessibles sur la machine sur laquelle la base de données va être dupliquée. Le tableau ci-dessous récapitule quelques paramètres très importants (en complément des paramètres de chemin d’accès).

PARAMETRE	DESCRIPTION
DB_NAME	Il s’agit du même nom utilisé dans la commande « DUPLICATE »
CONTROL_FILES	Paramètre bien connu
DB_FILE_NAME_CONVERT	Permet de spécifier une règle de conversion des noms de fichiers de données pour tout fichier de données non renommé à l’aide des commandes RMAN « SET NEWNAME » ou « CONFIGURE AUXNAME ». On peut spécifier de multiples paires de conversion et utiliser les groupes de disques ASM (Automatic Storage Management
LOG_FILE_NAME_CONVERT	Permet de spécifier une règle de conversion des noms de fichiers redo log. On peut spécifier de multiples paires de conversion. Ce paramètre permet en outre que les redo log existent aussi longtemps que les tailles correspondent dans la mesure où il utilise le paramètre REUSE lors de la création des redo logs. Si en plus de ce paramètre, on spécifie la clause LOGFILE dans la commande « DUPLICATE », alors RMAN utilise la clause LOGFILE.

Nous donnons ci-après un exemple très simplifié

DB_NAME=dupdb

CONTROL_FILES= (/oracle/dup_prod/cf/cf1.f, /oracle/dup_prod/cf/cf2.log)

DB_FILE_NAME_CONVERT=(/oracle/prod/db, /oracle/dup_prod/db, /disk2/db, /oracle/dup_prod/db)LOG_FILE_NAME_CONVERT=(/oracle/prod/log, /oracle/dup_prod/log)

Une fois le fichier PFILE créé, on peut, à l’aide de la commande SQL*PLUS « CREATE SPFILE », créer le fichier SPFILE correspondant dans le répertoire par défaut. Cette commande peut être lancée avant ou après le démarrage de l’instance auxiliaire.
SQL> CREATE SPFILE FROM PFILE=’/tmp/initDUPDB.ora’ ;

Etape 3 : Démarrer l’instance auxiliaire sans la monter sur le fichier spfile
SQL> connect SYS/aux_pwd@dupdb as sysdba
SQL> startup nomount

Etape 4 : Démarrer et monter ou démarrer et ouvrir la base de données cible
SQL> startup pfile='/oracle/dbs/initPRODB.ora'
ou
SQL> startup

Etape 5 : S’assurer que la nouvelle instance est déclarée dans la section SID_LIST du fichier listener.ora
Cette déclaration est le gage du succès des connexions de RMAN à la nouvelle instance. Par ailleurs il est aussi nécessaire de modifier le fichier tnsnames.ora de la machine à partir de laquelle on se connecte à la nouvelle instance de sorte que l’on puisse se connecter à cette instance via un alias de services réseau d’Oracle.
Voici un exemple d’extraits de fichier listener.ora
SID_LIST_LISTENER =
(SID_LIST =
(SID_DESC =
(GLOBAL_DBNAME = prodb.knmc.local)
(ORACLE_HOME = /oracle/ora92)
(SID_NAME = prodb)
)
(SID_DESC =
(GLOBAL_DBNAME = dupb.knmc.local)
(ORACLE_HOME = /oracle/ora92)
(SID_NAME = dupb)
)
)
Après cette modification du listener.ora, il faut faire en sorte que le listener prenne en compte ces modifications par la commande « reload » comme suit :
$ lsnrctl reload
Ensuite, il faut vérifier que tout fonctionne comme souhaité :
$ lsnrctl services
La modification du fichier tnsnames.ora consiste à y ajouter l’entrée correspondant à la nouvelle instance, c’est-à-dire les lignes qui suivent :
DUPDB =
(DESCRIPTION =
(ADDRESS_LIST =
(ADDRESS = (PROTOCOL = TCP)(HOST = jupiter)(PORT = 1521))
)
(CONNECT_DATA =
(SID = dupdb)
)
)
Note : Théoriquement la chaîne « SERVICE_NAME = dupdb » devrait marcher à la place de la chaîne « SID= dupdb ». Mais dans les faits, il semble que ce n’est pas toujours le cas.
Pour tester la connexion, il suffit de faire ce qui suit :
$ sqlplus "sys/pwsys@dupdb as sysdba"

Etape 6 : S’assurer que l’on a bien à disposition et accessibles (à partir de la machine sur laquelle la base de données dupliquée va être créée), les sauvegardes RMAN nécessaires et les redo logs archivés.
Lorsque la machine de duplication (sur laquelle sera dupliquée la base) est différente de la machine primaire (sur laquelle se trouve la base de départ appelée base cible dans la terminologie RMAN), il est impératif de rendre les sauvegardes et copies d’image se trouvant sur les disques de la machine primaire, disponibles sur la machine distante avec les mêmes chemins absolus de répertoire que sur la machine primaire. Cela se fait soit à l’aide des commandes du système d’exploitation du genre cp (Unix), soit à l’aide de la mise en œuvre de NFS ou de disques partagés.

Etape 7 : Allouer des canaux auxiliaires si des canaux automatiques ne sont pas configurés
Il s’agit de démarrer RMAN avec une connexion à la database cible, à la base dupliquée et s’il y a lieu, la database du catalogue de récupération

$ rman TARGET SYS/target_pwd@prodb CATALOG rman/cat_pwd@cat_str AUXILIARY SYS/aux_pwd@dupdb

Voici un exemple de cas où il n’y a pas de canaux automatiques configurés. Dans ces cas-là, on doit allouer manuellement au moins un canal auxiliaire dans la même commande RUN que la commande « DUPLICATE » et avant celle-ci. Le type de canal (DISK ou sbt) doit correspondre au média sur lequel se trouvent les sauvegardes de la database cible. Si les sauvegardes sont sur disque, la duplication sera d’autant plus rapide qu’il y aura plus de canaux alloués.

RUN {

# to manually allocate a channel of type sbt issue:

ALLOCATE AUXILIARY CHANNEL ch1 DEVICE TYPE sbt;

# to manually allocate three auxiliary channels for disk issue (specifying whatever

# channel id that you want):

ALLOCATE AUXILIARY CHANNEL aux1 DEVICE TYPE DISK;

ALLOCATE AUXILIARY CHANNEL aux2 DEVICE TYPE DISK;

ALLOCATE AUXILIARY CHANNEL aux3 DEVICE TYPE DISK;

...

...

...

DUPLICATE ...

}

Si l’on a configuré des canaux automatiques, alors RMAN peut utiliser ces canaux configurés pour la duplication même s’ils ne spécifient pas l’option AUXILIARY. Cependant, si les canaux auxiliaires ont besoin de paramètres spéciaux, alors on doit configurer un canal automatique avec l’option AUXILIARY.

DUPLICATION OU CLONAGE DE BASE DE DONNEES ORACLE
(Entre clarification et choix)

Dans la littérature technique de l’ingénierie des bases de données Oracle, clonage et duplication sont mélangés, permutés et parfois confondus.
Nous voulons par ce premier d’une série d’articles devant porter sur ces questions, clarifier les termes et montrer la nécessité de faire un choix en fonction de ses propres besoins. A la fin de ce premier article, nous donnerons quelques définitions de termes que le lecteur devra avoir à l’esprit pour une meilleure compréhension de la suite.
Les critères que nous avons décidés de retenir afin de distinguer les deux opérations (clonage et duplication) peuvent paraître arbitraires surtout aux littéraires. Mais nous avouons d’entrée de jeu que nous n’avions pas eu le choix à ce niveau-là ; nos seuls soucis sont : la clarté et l’efficacité pour que le lecteur et le technicien puissent s’y retrouver.

La duplication d’une base de données
Il s’agit de reproduire rapidement une base de données de production à l’aide de l’utilitaire RMAN, à des fins de tests (tests de sauvegarde/restauration, tests d’import/export, tests d’optimisation de performance, etc…) afin d’impacter le moins possible la base de données de production.
La base de données dupliquée est une copie de la base de départ (base cible) que l’on peut exécuter de façon indépendante de la base cible. Cette copie peut être identique à la base cible c’est-à-dire comporter les mêmes tablespaces et fichiers de données que l’originale ou ne contenir qu’un sous-ensemble des tablespaces d’origine.
Cette reproduction peut se faire sur la même machine mais sous un nom de base de données différent. Autre possibilité : la reproduction peut également se faire sur une autre machine ; dans ce cas la nouvelle base qui résulte de l’opération de duplication peut porter le même nom ou un nom différent, avoir ou non la même structure de répertoires.
Nous avons choisi le terme « duplication » par référence au fait que la commande Oracle qui se trouve au cœur de cette opération est la commande « DUPLICATE ».

Duplication n’est pas clonage
Une procédure de duplication diffère d’une procédure de clonage sur quelques points importants, même si les deux procédures sont assez proches l’une de l’autre et que dans la littérature technique, on trouve parfois la duplication sous le nom de clonage :
- Le clonage est destiné à créer une base appelée à remplacer celle dont elle est le clone ; la base résultant de l’opération porte le même nom et le même DBID. De ce fait, si la base clônée ne remplace pas la base de départ, les deux ne doivent pas être opérationnelles simultanément sur le même réseau et ne peuvent être enregistrées dans le même catalogue RMAN.
- L’opération de clonage est une opération « one shot » c’est-à-dire qu’à chaque fois, la procédure doit être mise en œuvre de la première à la dernière étape.
- Enfin le mécanisme de clonage est beaucoup plus rigide que celui de la duplication, comme nous allons le voir dans la série d’articles qui suivra.
- La duplication permet d’avoir une autre base de données portant un autre nom et un autre DBID mais gérant soit exactement les mêmes données ou un sous-ensemble de données de la base de données d’origine.
- Il est possible de rafraîchir à intervalles réguliers la base dupliquée afin de la ramener au même niveau de données que la base de départ.
- La base de données d’origine et celle résultant de la duplication peuvent cohabiter sur le même réseau y compris sur la même machine et être enregistrées dans le même catalogue RMAN.

De la terminologie
Passons en revue rapide quelques termes ou notions importantes qui seront nécessaires pour la suite.
RMAN : c’est l’acronyme de Recovery Manager. Il s’agit de l’outil performant qu’Oracle fournit avec la plupart des versions et éditions de ses bases de données et qui facilite et permet d’automatiser les sauvegardes et restaurations de ses bases. Tous les développements que nous ferons seront basés sur cet outil.
Target database /base de données cible : dans la terminologie RMAN, « target database désigne la base de données source (ou d’origine) à partir de laquelle se fait la duplication ou le clonage. Nous traduirons « target database » par les termes français « base de données cible ».
Auxiliary instance/auxiliary database (instance auxiliaire/base de données auxiliaire) : une base de données auxiliaire est une base de données RAC qui sera créée en tant que résultat de la duplication de la base de données cible. Dans la terminologie RMAN, l’instance auxiliaire identifie une instance à laquelle RMAN se connecte en vue d’exécuter la commande « duplicate ».

A suivre