Discussion :

[linux_sql]

Bonjour à tous,

je voudrais faire un backup de tout les tablespace présent dans ma base de données, mais en excluant certains.

Pour cela je sais qu'il existe une commande qui permet de faire un EXCLUDE des tablespace qu'on ne veux pas sauvegarder.

Sauf que, c'est uniquement valable si je sauvegarde entièrement ma base, ce qui implique que à la fin j'aurais un seul fichier en sortie

Ce que je voudrais c'est :

Avoir UN fichier de backup par tablespace en sortie, au lieu d'avoir un seul gros fichier qui contient tout.

Car, je ne veux pas a avoir éditer le script rman, et ajouter manuellement mes tablespaces, je veux automatiser cela.

Merci

[Pomalaix]

Si vous avez des tablespaces constitués d'un seul fichier (au besoin, utilisez des tablespaces BIGFILE), alors l'option FILESPERSET devrait faire l'affaire :

Code :

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

backup filesperset 1 database;

Mais j'avoue que je ne vois pas l'intérêt de ce que vous cherchez à faire...

[linux_sql]

Merci pour la solution, je vais tester.

Enfait voilà ce que je voudrais faire :

1) Faire un backup full de mes tablespaces chaque jours (en excluant tout ce qui est tablespace system etc).

2) Avoir un seul fichier de backup par tablespace

4) La retention étant configuration avec la redondance a 1 , j'aurais un fichier de backup par jour dans mon repertoire de sauvegarde

3) Via une tache automatisé dans netbackup on sauvegarde le repertoire en question, tout les jours

Si jamais je veux restaurer un tablespace datant de xx jours, je restaure le fichier de backup rman en question via netbackup, et je le restaure.

Ainsi en obtenant un seul fichier de backup par tablespace, je ne serai pas obligé de restaurer un gros fichier de xx gigaoctects pour restaurer un tablespace qui ne fait que xx mo par exemple.

Est ce que c'est un schéma compatible avec RMAN? Qu'en pensez vous?

[pachot]

Bonjour,

en excluant tout ce qui est tablespace system

Euh... les tablespace system et undo sont backuppées quand même ?

Ainsi en obtenant un seul fichier de backup par tablespace, je ne serai pas obligé de restaurer un gros fichier de xx gigaoctects pour restaurer un tablespace qui ne fait que xx mo par exemple.

Oui, c'est le but du fileperset - au niveau datafile mais pas tablespace

Si jamais je veux restaurer un tablespace datant de xx jours, je restaure le fichier de backup rman en question via netbackup, et je le restaure.

Là c'est un peu plus complexe. S'il s'agit de restaurer les données d'un tablespace telles qu'elles étaient il y a xx jours, ce qui s'appelle 'TableSpace Point In Time Recovery', il faudra:
-> restaurer SYSTEM,SYSAUX,UNDO et ton tablespace en question à partir d'un backup antérieur à xx jours mais ailleurs pour ne pas écraser la base actuelle
-> appliquer éventuellement quelques archivelogs pour arriver à la date xx
-> exporter les données que l'on veut. Si c'est tout un tablespace, ça peut se faire en Transportable tablespace, sinon export
-> importer ça dans la base actuelle

En bref, restaurer seulement le tablespace est inutile. Sans le dictionnaire de données (qui est dans SYSTEM) il est inutilisable. Donc il faut restaurer SYSTEM, et dans une autre base pour ne pas écraser la base courante.

Est ce que c'est un schéma compatible avec RMAN?

Rman peut communiquer directement avec netbackup. Pas besoin de passer par le repertoire de sauvegarde, pas besoin d'avoir une tâche de sauvegarde en plus, pas besoin d'aller chercher à la main les fichiers nécessaires.

Du coup, il suffit de fair 'backup database' pour faire une sauvegarde qui va directement dans netbackup. Et le 'TableSpace Point In Time Recovery' peut être assez automatisé dans les versions récentes d'Oracle.

Cordialement,
Franck.

[Arkhena]

Bonjour,

Oracle et Rman garantissent la consistance des données. Ne prendre qu'un morceau (tablespace) d'une base pour le restaurer ne permet plus de garantir cette consistance des données. Pour cette raison ces opérations sont plutôt complexes avec Rman.

- Si vous voulez juste conserver vos données et les réinjecter à la hussarde, je vous conseille plutôt d'utiliser datapump
- Si vous travaillez sur une base de test et que vous voulez revenir à un état propre avant vos tests, je vous conseille plutôt d'utiliser des points de flashback
- Si enfin votre souci, c'est de ne pas restaurer les tablespaces system, sysaux et compagnie, je vous assure que ce n'est pas cette opération qui est la plus gourmande.
- Enfin si vous avez plusieurs schémas comportant les données de plusieurs applications non liées entre elles sur la même base de données, séparez-les en autant de bases et vous n'aurez plus ce genre de soucis

Cordialement,

Arkhena

[Pomalaix]

Oracle et Rman garantissent la consistance des données. Ne prendre qu'un morceau (tablespace) d'une base pour le restaurer ne permet plus de garantir cette consistance des données.

Je ne suis pas d'accord avec ça.
Si une sauvegarde est faite à chaud, alors elle sera inconsistante, RMAN ou pas RMAN.
C'est le RECOVER qu'on effectuera à la restauration qui rendra la base consistante. Donc ne restaurer qu'un tablespace n'est pas un problème à cet égard. Si je dispose de tous les archivelogs nécessaires, alors tout va bien.