Déplacement de tablespaces en environnement Data Guard

Avant d’attaquer une partie technique, il est nécessaire de parler de la partie fonctionnelle. La question pouvant être : pourquoi vouloir utiliser des tablespaces transportables (TTS) sur un Data Guard ?
L’idée est relativement simple. Prenez un serveur hébergeant deux bases de données critiques. La première instance est utilisée pour des chargements quotidiens d’une centaine de gigaoctets. La seconde, attaquée par un applicatif, reçoit les mises à jour à fin du chargement réguliers de la première instance.

Plusieurs solutions s’offrent bien sûr à nous mais peu sont viables. L’utilisation de vues matérialisées sur la seconde instance semble convenir… uniquement si l’on a une faible volumétrie. Nous parlons ici d’un dixième de la volumétrie globale. Le rafraîchissement des MV en mode FAST REFRESH peut prendre hélas très longtemps.
L’idée retenue est donc de mixer les technologies disponibles. Beaucoup de fournisseurs de baies de stockage permettent d’effectuer des clones de volumes. Utilisons-les !
Si toutefois vous ne pouvez pas utiliser de clones, vous avez toujours la possibilité de faire un simple copier/coller de vos fichiers de données et du fichier de metadata.
En termes de temps, la copie de fichiers de 400Go prend environ 1h30. Le clone et le snapshot nous prenne quelques secondes.
Dans un premier temps, voyons comment faire sans Data Guard.

L’idée générale étant posée, nous allons maintenant voir comment mettre en pratique ce mécanisme. Les commandes suivantes ont été testées sous Oracle 11g R2 (11.2.0.2.0) sous Red Hat Enterprise Linux Server release 5.4. Les baies de stockage sont des NetApp.
En termes de stockage physique des données, voici notre architecture :

/u02/instanceA/data/
 |-- /u02/instanceA/data/TTS
 |   |   |-- tts_data.dbf
 |   |-- tts_index.dbf
 |-- sysaux01.dbf
 |-- system01.dbf
 |-- undotbs01.dbf
 `-- users01.dbf

Les dossiers /u02/instanceA/ et /u02/instanceA/data/ sont des points de montages présentés par la baie à notre serveur. Rien de plus banal.
L’astuce consiste à exporter nos metadata Data Pump dans le dossier /u02/instanceA/data/ avant de cloner ce volume.
Pour ce faire, nous allons créer un objet DIRECTORY :

SQL> CREATE DIRECTORY export_tts as '/u02/instanceA/data/TTS';

Afin de pouvoir utiliser Data Pump en toute sécurité et pour respecter les mécanismes de TTS, nous allons passer nos tablespaces en mode Read Only. Attention, si des transactions sont en cours sur vos tablespaces, l’export sera bloqué. Il est donc important d’être sûr de pouvoir passer les tablespaces en mode RO (personnellement, j’ai choisi de passer la base de données en mode RESTRICTED et de killer toutes les sessions non-Oracle) :

SQL> ALTER TABLESPACE TTS_DATA READ ONLY;
SQL> ALTER TABLESPACE TTS_INDEX READ ONLY;

Maintenant que tablespaces sont en mode RO, nous pouvons exporter nos metadata.

$ expdp system/easyteam directory=EXPORT_TTS dumpfile=TTS.dmp logfile=TTS.log TRANSPORT_TABLESPACES=BMO_INDEX,BMO_DATA TRANSPORT_FULL_CHECK=YES REUSE_DUMPFILES=YES

Qu’en résulte-t-il au niveau de notre stockage :

/u02/instanceA/data/TTS
 |-- TTS.dmp
 |-- TTS.log
 |-- tts_data.dbf
 |-- tts_index.dbf

Nous disposons maintenant d’un fichier TTS.dmp qui contient les metadatas de nos objets et nous pouvons donc commencer les actions au niveau de la baie de stockage pour cloner le volume et le présenter à la seconde instance.
Si votre seconde instance contient déjà des tablespaces portant le nom des tablespaces à transporter, il est nécessaire de les supprimer préalablement.
InstanceB :

SQL> DROP TABLESPACE TTS_DATA INCLUDING CONTENTS ;
SQL> DROP TABLESPACE TTS_INDEX INCLUDING CONTENTS ;

Je vous fais grâce des commandes SAN dans le corps de l’article mais pourrais éventuellement vous les fournir si besoin.
Une fois le clone monté, nous obtenons l’archiecture suivante :

/u02/ instanceB/data/TTS
 |-- TTS.dmp
 |-- TTS.log
 |-- tts_data.dbf
 |-- tts_index.dbf

Une fois nos fichiers présents, nous allons importer les metadata mais avant cela, il nous faut avoir un objet DIRECTORY pointant vers notre point de montage :

SQL> CREATE DIRECTORY import_tts as '/u02/instanceB/data/TTS';
$ impdp system/easyteam directory=IMPORT_TTS dumpfile=TTS.dmp logfile=TTS.log TRANSPORT_DATAFILES=/u02/instanceB/TTS/tts_data.dbf,/u02/ instanceB /data/TTS/tts_index.dbf

Bien entendu, vous pouvez utiliser les clauses REMAP_TABLESPACE et REMAP_SCHEMA pour remettre en corrélation vos objets d’une instance à l’autre.
Et voila ! Nos données sont transportées d’une instance à l’autre.
Une dernière chose reste à faire pour éviter les coups de fil des utilisateurs. Souvenez-vous, nous avions passé nos tablespaces en mode RO. Remettons-les en état :
InstanceA :

SQL> ALTER TABLESPACE TTS_DATA READ WRITE;
SQL> ALTER TABLESPACE TTS_INDEX READ WRITE;

InstanceB :

SQL> ALTER TABLESPACE TTS_DATA READ WRITE;
SQL> ALTER TABLESPACE TTS_INDEX READ WRITE;

Voici nos instances propres et utilisables pour nos utilisateurs.
Tentons maintenant de nous rapprocher de notre problématique : le Data Guard.
Sur le papier, rien de très dur mais une subtilité est nécessaire. Si les fichiers de données ne sont pas présents sur notre secondaire, l’instance risque de rentrer dans un état que je ne souhaite à personne…

Le principe reste le même :

  • InstanceA site A:
    • Passage des tablespaces en mode RO
    • Export des metadonnées
    • Snapshot du volume
  • InstanceB site A :
    • Suppresion des tablespaces
  • InstanceB site B :
    • Vérification de la suppression des tablespaces
  • InstanceA Site A :
    • Clone du snapshot créé précédemment
  • InstanceA Site B :
    • Snapshot du volume
    • Clone du snapshot
  • InstanceB Site B :
    • Montage du clone sur sa destination
  • InstanceB Site B :
    • Montage du clone sur sa destination
    • Vérification de la présence des fichiers
  • InstanceB site A :
    • Import des metadata
  • Instance A site A :
    • Passage des tablespaces en mode Read Write
    • Recompilation des objects invalides
  • Instance B site A :
    • Passage des tablespaces en mode Read Write
    • Recompilation des objects invalides

En revanche, si je peux me permettre un conseil vis-à-vis du Data Guard, en mode max performance, il est nécessaire d’attendre la réplication sur le site B avant par exemple de poursuivre les manipulations suite à la suppression des tablespaces. Si comme moi, vous ne voulez pas attendre, vous pouvez ajouter un SWITCH LOGFILE pour forcer la réplication.
En cas de besoin, je peux vous fournir les différentes vérifications utilisées pour s’assurer de l’état des Data Guard et de l’état des tablespaces.
Au besoin, n’hésitez pas à utiliser les commentaires.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *