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.

[Arkhena]

C'est pour cette raison que j'ai bien précisé "Oracle ET Rman". Rman seul ne garantit pas la consistance des données car il permet de faire une restaure de sauvegarde non cohérente. Mais dans ce cas, Oracle ne voudra pas ouvrir la base tant que le recover n'aura pas été effectué.

C'est vrai que j'utilise trop souvent Oracle à la base d'Oracle Database...

[Pomalaix]

...

Je ne vois pas du tout où vous voulez en venir.
En quoi restaurer un seul tablespace poserait-il un problème de consistance ?

[linux_sql]

Merci pour vos réponses.. mais vu les contradictions entre les poste je ne comprends plus vraiment.

J'ai une vingtaine de serveurs Oracle, dont chacun héberge une seule instance, qui contient plusieurs schéma.

à l'heure actuelle, tout ces schéma sont lié à un même tablespace, et chaque schéma comporte des données totalement différente (ils sont donc indépendant les uns des autres, même si ils sont sur le même tablespace)

Et mes sauvegardes sont effectuées à l'aide d'un script en .bat qui fait du EXPDP, puis les fichiers .DMP sont sauvegardés via Netbackup en sauvegardant la partition.

J'ai envie de mettre en place RMAN pour plusieurs raisons :

-Mieux contrôler mes backup
-Pouvoir faire des restauration plus récente, ou remonter à une heure précise
-Et surtout ne pas à avoir modifier un fichier .bat tout bidon, si je veux faire un backup d'un nouveau schéma.. c'est invivable comme solution, car nous sommes plusieurs à travailler sur ces bases, nous faisons beaucoup de nouveaux schéma par jour etc.. et modifier un fichier .bat à chaque opération devient vite agaçant, sans compter les personnes qui ne le font pas

Vu que je dois mettre en place RMAN, je pensais définir un tablespace par schéma, afin de séparer les données de manière "physique", vu que le fichier de données est différent.

Je vais laisser de coté Netbackup pour le moment, et me concentrer sur RMAN.

Sachant l'ensemble de mes schéma sur certains serveurs fait plus de 30 GO, comment je vais faire pour conserver toutes ces données sur une partition? C'est pour cela que je voulais faire intervenir Netbackup, afin de faire un FlashBackup Windows, et ainsi pouvoir conserver des données de plusieurs mois, tout en vidant ma partition de backup rman sur windows, grace à l'option delete obsolete (redondance à 1).

L'idéal serait de faire une Full tout les soirs + une incremental niveau à midi par exemple.

Merci à tous pour vos conseils, je suis vraiment dans le flou du coup...

[ducho]

Bonjour,

Normalement, vous auriez dû dés le début séparer vos schémas
dans des tablespaces différents .

Le fonctionnement préconisé par les dba's en général est
1 owner = 1 schéma = 1 tablespace

donc dans un premier temps, créez autant de tablespaces qu'il y a de schémas .
ensuite utiliser rman pour sauvegarder toute votre base , rman étant suffisement puissant et faisant de la compression automatiquement
30 G ne représente pas grand-chose pour lui .

cordialement

[FSiebert]

Le fonctionnement préconisé par les dba's en général est
1 owner = 1 schéma = 1 tablespace

Il n'est pas aussi recommandé de séparer les tables et les index dans deux tablespaces distincts ?

[ducho]

depuis oracle10 , oracle ne conseille plus de séparer les index et les données
personnellement, je le fais encore quand je maitrise la strucure interne
ce qui n'est pas le cas pour les applications des éditeurs ...

[FSiebert]

Je suis en retard

Une raison sur ce changement de point de vue ?
À l'origine, pourquoi la séparation était recommandée ?

Edit : désolé de faire un peu dériver cette discussion, mais je pense que ça peut intéresser d'autres personnes

[ducho]

Bonjour,

Pomalaix pourrait mieux vous renseigner que moi, mais la séparation des données et des index était un moyen suppémentaire d'éviter la fragmentation des tablespaces gérés par le dictionnaire .

Maintenant Oracle gére tout cela tres bien et l'espace disque n'étant plus un pb la plupart du temps , on laisse oracle faire ...

(lorque qu'on avait des disques de 2 G, le moindre octet était bon à récupérer
dans les datafiles , je viens d'installer un serveur avec des disques de 2 T°,
on n'est vraiment plus à 1M prés !!!)

cdlt

[FSiebert]

Merci pour ces informations
Pomalaix, si vous avez des choses à ajouter, n'hésitez pas.

Il n'y avait pas un aspect d'utiliser deux tablespaces pour séparer les données et les index sur des disques (physiques) différents afin d'éviter des contentions à ce niveau ?

Le projet sur lequel je travaille n'a pas de tablespace distinct pour les tables et les index. J'avais posé la question il y a quelques temps et l'argument évoqué est le fait de travailler sur un SAN, les DBA n'ont donc plus la main pour placer les tablespaces sur les disques de leur choix.
Si on a encore la main sur les disques, cela peut-il s'avérer utile ?

[linux_sql]

Bonjour,

Normalement, vous auriez dû dés le début séparer vos schémas
dans des tablespaces différents .

Le fonctionnement préconisé par les dba's en général est
1 owner = 1 schéma = 1 tablespace

donc dans un premier temps, créez autant de tablespaces qu'il y a de schémas .
ensuite utiliser rman pour sauvegarder toute votre base , rman étant suffisement puissant et faisant de la compression automatiquement
30 G ne représente pas grand-chose pour lui .

cordialement

Oui, dans ce cas je sauvegarde la base de données entière? Je suis obligé de faire ça?

Je vais tester ce que ça donne en taille une base de 30go une fois sauvegardée avec rman.

[ducho]

Bonjour,

si vous utilisez netbackup que j'ai eu la chance de voir fonctionner mais
que nous n'avons pu acheter car trop cher, une sauvegarde compléte
de la Bdd de 30g se fait sans souci , vous installez l'agent oracle sur le
serveur , vous configurer la sauvegarde .
Avec la déduplication , vous aurez une 1 ou 2 G d'ecrits sur la librairie
disque .

(je crois qu'en plus , vous pouvez récupérer les scripts rman utilisés par netbackup) .

Cordialement

[linux_sql]

Merci pour ta réponse.

à vrai dire, rman est mon sujet de stage.. je sais que le but final sera de l'utiliser avec netbackup c'est pour cela que je me pose la questions.

Mais imaginons le schéma suivant :

J'ai une base de données oracle, avec 30go de données en tout, reparti sur 10 tablespaces environ.

Si je fais un full tout les soirs, et une incremental le jour (comme on le fait actuellement avec sql server chez nous), je ne vais pas tenir en terme de stockage disque.

Car il me faut une retention d'au moins 15 jours.

C'est pour cela que je voulais effectuer une sauvegarde de ma partition en entier, précédé d'un DELETE OBSOLETE.

C'est pas compliqué comme opération pour moi, j'ai juste à ajouter mon serveur dans la policy deja configuré dans netbackup...

J'ai bien configuré rman, mais j'ai toujours quelques zones d'ombres, concernant l'architecture de rman, car j'ai du mal avec tout ce qui est undo, dictionnaire de données ? Quelqu'un a un bon lien à me fournir pour comprendre tout ça?

Merci

[linux_sql]

Bonjour à tous,

il y a quelque chose que je ne comprends pas, voici le test que j'ai effectué :

Hier j'ai fait un backup database, tout s'est bien passé.

Aujourd’hui j'ai supprimé un pays dans la table countries du schema hr.

Afin de retrouver mon pays dans ma table, j'ai tapé les commandes suivantes :

Code :

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

1
2
3
4
5
6
RMAN> run {
2> SQL 'ALTER TABLESPACE users OFFLINE';
3> RESTORE TABLESPACE users;
4> RECOVER TABLESPACE users;
5> SQL 'ALTER TABLESPACE users ONLINE';
6> }

Tout se passe bien, sauf que je ne retrouve pas mon pays lorsque je fais un SELECT?

J'ai vu que lors du RECOVER rman, rejoue les derniers archivelog, donc c'est normal que je ne retrouve pas mon pays, c'est bien ça?

Comment faire dans mon cas?

merci

[ducho]

Bonjour,

Vous pouvez lire la doc rman qui explique assez bien tout le mécanisme du recocover :

http://www.oracle.com/pls/db112/port...p_and_recovery

en fait dans votre cas , les archive logs et le redo courant sont appliqués
(oracle n'a peut-être même pas eu besoin des archives )

voir les options de recover , notamment UNTIL

Cdlt