Discussion :

[zidane2012]

bonjour
J'ai entendu parler de plusieurs types de sauvegardes d'une base Oracle ?
TSM
BCV
clonage
sur bande ...
Différences et existe t-il d'autres ?
Merci.

[rouardg]

Bonjour,

De nos jours, les sauvegardes de bases Oracle se font souvent par RMAN (Recovery MANager) qui est l'outil fourni en standard par Oracle.

RMAN est de plus en plus utilisé, surtout lorsque l'on évolue dans des environnements complexes avec de l'ASM et du RAC.

La sauvegarde peut se faire à froid (la base de données est quand même en status MOUNT, car RMAN sauvegarde des informations sur les sauvegardes dans les fichiers de contrôle). Il n'y a donc pas d'activité sur la base.

La sauvegarde peut aussi se faire à chaud, base ouverte donc et disponible aux utilisateurs et batchs. Cela nécessite que ta base soit en mode Archivelog.

Dans ce cas, le grand classique (mais ce n'est pas la règle) est de faire une sauvegarde complète le WE. En semaine, on effectue des sauvegardes incrémentales, qui sont soit différentielles, soit cumulatives.

Au niveau de la destination, Oracle est capable de sauvegarder sur bandes et sur disques. Souvent on utilise de la bande, car c'est un support économique, que l'on peut aussi externaliser (stocker dans un endroit distant) pour des besoins d'archivage et aussi de sécurité (imagine l'incendie ou la fuite d'eau dans la salle machine de prod).

A la base, la sauvegarde s'effectue en lignes de commande, à travers l'outil qui s'appelle RMAN. L'autre variante est que ce soit les outils de sauvegarde qui pilotent RMAN (via un jeu d'API). Par exemple, l'outil de sauvegarde NetBackup sait piloter RMAN, mais pour cela, il faut acheter l'agent Netbackup pour RMAN il me semble.

Voilà les grandes lignes. Maintenant il existe encore d'autres solutions.

Par exemple, tu peux sauvegarder ta base comme on le faisait dans le temps, avant l'apparition de RMAN.

A chaud, il fallait mettre les tablespaces un par un en mode BEGIN BACKUP et sauvegarder ses datafiles, avant de le repasser en END BACKUP. Il fallait aussi gérer les Archive Logs. Cette solution est dépassée, et non performante.

A froid, ta base étant proprement arrêtée, ce n'est plus qu'un ensemble de fichier (init.ora ou Spfile, Control Files, DataFiles, TempFiles, Redo Log Files) et il suffit de sauvegarder tout cela, comme de simples fichiers.

D'autres personnes encore sauvegardent leurs bases à l'aide de Snapshot. Certains utilisent la fonctionnalité de Snapshot de leurs baies SAN. D'autres utilisent le Snapshot dans le cadre de la virtualisation.

Bref, il existe plein de solutions, mais je pense t'avoir donné les grandes lignes. Tout cela est à voir et à étudier en fonction de ton environnement de travail et du contexte.

[zidane2012]

Merci pour toutes ces explications.

RMAN est-il adapté pour effectuer des sauvegardes de bases de données Oracle à FORTE volumétrie 10 To ?

Si NON , quelle est l'alternative ? TSM , BCV , CLONE ?

Thanks

[rouardg]

Bonjour,

Tout d'abord, je te donne les grandes lignes, car même si je pratique Oracle depuis 12 ans, je suis DBA d'études. Je n'ai juste fait que 2 années en production, et mon RMAN est loin.

Je pense que beaucoup d'autres personnes, surtout les DBA de prod, sont mieux placées que moi pour te répondre.

Donc oui, RMAN sait sauvegarder les fortes volumétries. Tout d'abord, il faudra utiliser le multi canal, c'est-à-dire allouer plusieurs canaux pour la sauvegarde.

Ensuite, il faudra activer la fonctionnalité de BCT (Block Change Tracking) :

Code :

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

1
2
3
alter database enable block change tracking  using file '.....' ;
 
select * from v$block_change_tracking ;

Le BCT sert lors des sauvegardes incrémentales. En effet, au lieu de scanner chaque bloc lors de la sauvegarde classique pour savoir si le bloc a été modifié depuis la dernière sauvegarde complète, RMAN lit le fichier binaire indiqué dans la commande ALTER d'au dessus, pour connaître les blocs modifiés.

Ce fichier des blocs modifiés est bien entendu mis à jour lorsqu'il y a de l'activité sur la base, activité qui modifie les blocs Oracle.



Après, comme je te le disais, il faut interfacer ta solution de sauvegarde avec RMAN. Je ne connais rien à TSM, mais il y a de nombreux blogs sur le Net à ce sujet.

En voici un qui parle du TDPO (Tivoli Data Protection for Oracle) :

http://blog.yannickjaquier.com/oracl...acle-tdpo.html


Après, comme je te disais, il y a d'autres alternatives, mais qui ne sont pas les plus efficaces.

Dans ma courte expérience de prod, j'ai connu une base Oracle 9iR2 de 200 Go, pour PeopleSoft, qui tournait sur de l'AIX 5.3.

La base était sauvegardée à froid toutes les nuits, via NetBackup et sur bande.

En temps normal, il fallait arrêter la base pendant 1h15, le temps de sauvegarder les 200 Go de fichiers de la base.

Afin de minimiser cette interruption de service à qq minutes, l'admin système utilisait la fonctionnalité de Snapshot de la baie HP EVA 6000.

En gros :
- tu arrêtes proprement ta base de prod
- tu démontes le FS pour être sur de tout flusher sur disque, et qu'il ne subsiste rien en cache JFS
- tu mets en place le Snapshot entre la baie SAN de prod et celle de préprod
- tu remontes ton FS et tu redémarres ta base.

Ensuite, tu n'as plus qu'à sauvegarder tranquillement ta base via le Snapshot.

Comment fonctionne ce Snapshot ?

Et bien Netbackup demande à sauvegarder les fichiers de la base, donc qq part des blocs OS. Tant que la base n'est pas modifiée, on lit ces blocs sur la baie SAN de prod.

Par contre, si tu fais un update en base qui modifie par exemple 1 ligne d'un bloc Oracle de 8 Ko, et que ce bloc est écrit par DBWR, ce sont 2 blocs OS de 4 Ko qui vont être écrits sur le SAN de prod.

Mais avant que cette écriture ne soit faite sur le SAN de prod, le Snapshot va répliquer les anciennes valeurs de ces 2 blocs sur le SAN de préprod.

Comme cela, si la sauvegarde Netbackup a besoin de ces 2 blocs, le Snapshot les restitue depuis la baie de préprod, et non pas celle de prod.

C'est comme cela que tu effectues une sauvegarde cohérente des fichiers de ta base, alors que celle-ci est ouverte en prod, et disponible aux utilisateurs et batchs. Et tu n'as arrêté la base que qq minutes, le temps de mettre en place le Snapshot, et non pas pendant 1h15m.